Blog

Vom KI-Skeptiker zum KI-Pragmatiker

Rockford Lhotka

Rockford Lhotka

Aktualisiert März 17, 2026
13 Minuten

Vor ein paar Monaten war ich noch ein KI-Skeptiker. Ich hatte die Befürchtung, dass KI ähnlich wie Blockchain vor allem ein Hype ist, der abgesehen von ein paar Nischenanwendungen kaum praktische Anwendung findet.

Ich denke immer noch, dass KI überbewertet wird, aber nachdem ich LLMs und KI-Agenten absichtlich eingesetzt habe, um Software zu entwickeln, bin ich vom Skeptiker zum Pragmatiker geworden.

Ich weiß immer noch nicht, ob KI in irgendeinem objektiven Sinne "gut" ist. Sie verbraucht viel Wasser und Strom, und die Trainingsdaten werden oft auf ethisch fragwürdige Weise beschafft. Aber darum geht es in diesem Beitrag nicht, denn über dieses Thema wurde bereits ausführlich geschrieben.

Die Sache ist die, dass ich in den letzten Monaten bewusst KI eingesetzt habe, um mich beim Softwaredesign und der Entwicklung zu unterstützen, vor allem über Copilot in VS Code und Visual Studio, aber auch mit Cursor und einigen anderen KI-Tools.

In diesem Beitrag möchte ich über meine Erfahrungen mit dem erfolgreichen Einsatz von KI berichten und darüber, was ich dabei gelernt habe.

Meiner Meinung nach müssen wir als Industrie und Gesellschaft die Ethik der KI diskutieren. Diese Diskussion muss über den Ausgangspunkt "KI ist nicht nützlich" hinausgehen, denn es hat sich gezeigt, dass KI nützlich sein kann, wenn man weiß, wie man sie effektiv einsetzt. Daher muss die Diskussion anerkennen, dass KI ein nützliches Werkzeug ist, und dann können wir über die Ethik ihres Einsatzes diskutieren.

Die Lernkurve

Das erste, was ich gelernt habe, ist, dass KI keine Magie ist. Man muss lernen, wie man sie effektiv einsetzt, und das erfordert Zeit und Mühe. Es ist auch so, dass sich die "Best Practices" für den Einsatz von KI in dem Maße weiterentwickeln, wie wir sie nutzen. Daher ist es wichtig, sich mit anderen auszutauschen, die ebenfalls KI nutzen, um von ihren Erfahrungen zu lernen.

Ich habe z.B. zunächst versucht, mit einfachen Aufforderungen einfach nur "Vibe Code" zu machen, in der Erwartung, dass die KI einfach das Richtige tut. Die KI ist jedoch nicht deterministisch und dieselbe Eingabeaufforderung kann jedes Mal zu unterschiedlichen Ergebnissen führen, je nachdem, welchen Zufallswert die KI verwendet. Es ist im wahrsten Sinne des Wortes ein Schuss ins Blaue.

Um vernünftige Ergebnisse zu erzielen, müssen Sie der KI einen Kontext bieten, der über die Äußerung eines einfachen Wunsches hinausgeht. Hierfür gibt es verschiedene Muster. Das, was ich verwende, ist dieses:

  1. Wer bin ich? (z.B. "Ich bin ein Senior Software Engineer mit 10 Jahren Erfahrung in C# und .NET.")
  2. Wer sind Sie? (z.B. "Sie sind ein KI-Assistent, der Software-Ingenieuren hilft, hochwertigen Code zu schreiben.")
  3. Wer ist der Endnutzer? (z.B. "Die Endnutzer sind Finanzanalysten, die schnell und zuverlässig auf Marktdaten zugreifen müssen.")
  4. Was bauen wir? (z.B. "Sie bauen eine RESTful API auf, die Zugang zu Marktdaten bietet").
  5. Warum bauen wir sie? (z.B. "Die API wird Finanzanalysten helfen, bessere Anlageentscheidungen zu treffen, indem sie ihnen Marktdaten in Echtzeit zur Verfügung stellt.")
  6. Wie wird sie erstellt? (z.B. "Sie verwenden C#, .NET 8 und SQL Server, um die API zu erstellen").
  7. Wie lauten die Einschränkungen? (z.B. "Die API muss sicher, skalierbar und leistungsfähig sein.") Sie können auch andere Zusammenhänge angeben, aber dies ist ein guter Ausgangspunkt. Das bedeutet, dass Ihre erste Aufforderung, mit der Arbeit zu beginnen, ziemlich lang sein wird - mindestens ein Satz pro obigem Punkt, aber in vielen Fällen wird jeder Punkt ein Absatz oder mehr sein.

Nachfolgende Aufforderungen in einer Sitzung können kürzer sein, da die KI über diesen Kontext verfügt. Die KI-Kontextfenster sind jedoch begrenzt. Wenn Ihre Sitzung also länger wird (genügend Aufforderungen und Antworten), müssen Sie den Kontext möglicherweise erneut bereitstellen.

Zu diesem Zweck ist es manchmal eine gute Idee, Ihren Kontext in einem Dokument zu speichern, so dass Sie in späteren Anfragen oder Sitzungen auf diese Datei verweisen können. Dies ist in VS Code oder Visual Studio leicht zu bewerkstelligen, da Sie dort in Ihren Prompts auf Dateien verweisen können.

Ein Mentalitätswandel

Beachten Sie, dass ich manchmal den Begriff "wir" verwende, wenn ich mit der KI spreche. Das ist Absicht, denn ich habe festgestellt, dass es am besten ist, die KI als Kollaborateur und nicht als Werkzeug zu betrachten. Dieses Umdenken ist wichtig, denn es verändert die Art und Weise, wie Sie mit der KI interagieren.

Verstehen Sie mich nicht falsch - ich betrachte die KI nicht als Person - sie <em>ist</em> wirklich <em>ein Werkzeug</em>. Aber es ist ein Werkzeug, das mit Ihnen zusammenarbeiten kann, und nicht nur ein Werkzeug, das Sie benutzen.

Wenn Sie die KI als Mitarbeiter betrachten, werden Sie ihr eher den Kontext zur Verfügung stellen, den sie benötigt, um ihre Arbeit effektiv zu erledigen. Außerdem ist es wahrscheinlicher, dass Sie die Ergebnisse der KI überprüfen und verfeinern, anstatt sie einfach für bare Münze zu nehmen.

Rate der Veränderung

Selbst in der kurzen Zeit, in der ich AI aktiv nutze, haben sich die Modelle und Tools erheblich verbessert. Ständig kommen neue Funktionen hinzu, und die Möglichkeiten der Modelle werden schnell erweitert. Wenn Sie die KI vor ein paar Monaten bewertet haben und zu dem Schluss gekommen sind, dass sie für ein bestimmtes Szenario nicht geeignet ist, kann sie dieses Szenario jetzt sehr wohl bewältigen. Oder auch nicht. Ich will damit sagen, dass Sie Ihre Meinung nicht auf eine einzige Momentaufnahme stützen können, weil sich die Technologie so schnell weiterentwickelt.

Effektiver Einsatz von KI

Die Nutzung von KI selbst kann teuer sein. Wir wissen, dass sie viel Wasser und Strom verbraucht. Daher ist es aus ethischer Sicht wichtig, ihren Verbrauch zu minimieren. Außerdem werden viele KI-Dienste nach Verbrauch abgerechnet, so dass die Minimierung des Verbrauchs auch unter Kostengesichtspunkten wichtig ist.

Das bedeutet für mich, dass es oft am besten ist, KI zu verwenden, um deterministische Tools zu erstellen, die dann ohne KI verwendet werden können. Anstatt KI für sich wiederholende Aufgaben während der Entwicklung zu verwenden, nutze ich KI oft, um Bash-Skripte oder andere Tools zu erstellen, die dann für diese Aufgaben ohne KI verwendet werden können.

Anstatt alle meine KI-Anweisungen und den Kontext immer wieder von Hand einzutippen, speichere ich diese Informationen in Dateien, auf die die KI (und künftige Teammitglieder, die die Software pflegen müssen) verweisen kann. Ich finde, dass die KI bei der Erstellung dieser Dokumente sehr hilfreich ist, insbesondere Claude Sonnet 4.5.

GitHub Copilot verwendet automatisch eine spezielle Datei, die Sie im Stammverzeichnis Ihres Repo ablegen können:

/.github/copilot-instructions.md

Es hat sich herausgestellt, dass Sie zahlreiche Dateien in einem Ordner instructions unter .github ablegen können, und Copilot wird sie alle verwenden. Dies ist ideal, um Ihre Anweisungen in mehreren Dateien zu organisieren.

Diese Datei kann alle Anweisungen enthalten, die Copilot bei der Codegenerierung verwenden soll. Ich habe festgestellt, dass dies sehr hilfreich ist, um Copilot mit Kontext zu versorgen, ohne ihn jedes Mal eintippen zu müssen. Es handelt sich nicht um Anweisungen für einzelne Prompts, sondern um allgemeine Projektanweisungen. Es ist ein großartiger Ort, um die oben erwähnten Punkte "Wer bin ich?", "Wer sind Sie?", "Wer ist der Endbenutzer?", "Was bauen wir?", "Warum bauen wir es?", "Wie bauen wir es?" und "Was sind die Einschränkungen?" zu formulieren.

Sie können dieses Dokument auch verwenden, um Copilot anzuweisen, bestimmte MCP-Server zu verwenden oder die Verwendung bestimmter Server zu vermeiden. Dies ist nützlich, wenn Sie sicherstellen möchten, dass Ihr Code nur mit Modellen erzeugt wird, denen Sie vertrauen.

Prompt-Regeln

Fühlen Sie sich frei, Begriffe wie "immer" oder "nie" in Ihren Aufforderungen zu verwenden. Diese sind zwar nicht narrensicher, da KI nicht deterministisch ist, aber sie helfen, das Verhalten der KI zu steuern. Sie könnten zum Beispiel sagen: "Verwenden Sie immer async/await für E/A-Operationen" oder "Verwenden Sie niemals dynamische Typen in C#". Dies hilft der KI, Ihre Codierungsstandards und Vorlieben zu verstehen.

Vermeiden Sie es, in Ihren Aufforderungen passiv oder unklar zu sein. Anstatt zu sagen "Es wäre toll, wenn Sie...", sagen Sie "Bitte tun Sie X". Diese Klarheit hilft der KI, genau zu verstehen, was Sie wollen.

Wenn Sie eine Frage stellen, sollten Sie explizit darauf hinweisen, dass Sie eine Frage stellen und nach einer Antwort suchen. Andernfalls könnte die KI (im Agentenmodus) einfach versuchen, auf der Grundlage Ihrer Frage Code oder andere Assets zu erstellen, da sie diese für eine Anfrage hält.

Mit GitHub Copilot können Sie Markdown-Dateien mit vorgefertigten Prompts in einem Prompts-Ordner unter .github ablegen. Sie können diese Prompts dann in Ihren Codekommentaren referenzieren, damit Copilot sie mit der Standard-Syntax für Dateireferenzen # verwendet. Dies ist eine großartige Möglichkeit, Prompts in Ihrem Team zu standardisieren.

Modelle nach Bedarf wechseln

Sie werden feststellen, dass verschiedene KI-Modelle für verschiedene Zwecke oder Aufgaben besser geeignet sind.

Ich verwende z.B. oft Claude Sonnet 4.5 zum Schreiben von Dokumentation, weil es anscheinend klarere und prägnantere Texte produziert als andere Modelle. Allerdings verwende ich oft GPT-5-Codex für die Codegenerierung, weil es den Code besser zu verstehen scheint.

Allerdings kenne ich auch Leute, die genau das Gegenteil tun, so dass Ihre Erfahrungen variieren können. Das Wichtigste ist, mit verschiedenen Modellen zu experimentieren und herauszufinden, welche für Ihre speziellen Bedürfnisse am besten geeignet sind.

Der Punkt ist, dass Sie sich nicht auf ein einziges Modell für alles festlegen müssen. Sie können die Modelle je nach Bedarf wechseln, um die besten Ergebnisse für Ihre spezifischen Aufgaben zu erzielen.
In GitHub Copilot ist die Verwendung von Premium-Modellen mit einem Multiplikator verbunden. So ist (im Moment) Sonnet 4.5 ein 1x Multiplikator, während Haiku ein 0,33x Multiplikator ist. Einige der älteren und schwächeren Modelle sind 0x (kostenlos). Sie können also ein Gleichgewicht zwischen Kosten und Qualität herstellen, indem Sie das passende Modell für Ihre Aufgabe wählen.

Agentenmodus vs. Fragemodus

GitHub Copilot hat zwei primäre Betriebsmodi: Agent-Modus und Ask-Modus. Andere Tools haben oft ähnliche Konzepte.

Im Fragemodus antwortet die KI auf Ihre Aufforderungen im Chatfenster und nimmt keine Änderungen an Ihrem Code oder andere Aktionen vor. Die Benutzeroberflächen von vscode und Visual Studio ermöglichen es Ihnen normalerweise, die Antwort der KI auf Ihren Code anzuwenden, aber das müssen Sie manuell tun.

Im Agentenmodus kann die KI Ihren Code ändern, Dateien erstellen und andere Aktionen in Ihrem Namen durchführen. Das ist leistungsfähiger, aber auch riskanter, denn die KI könnte Änderungen vornehmen, die Sie nicht wollen oder erwarten.

Ich empfehle Ihnen, mit dem Fragemodus zu beginnen, bis Sie mit den Fähigkeiten und Grenzen der KI vertraut sind. Sobald Sie damit vertraut sind, können Sie für komplexere Aufgaben in den Agentenmodus wechseln. Der Agent-Modus ist eine enorme Zeitersparnis für Sie als Entwickler!

Standardmäßig werden Sie im Agentenmodus in den meisten Fällen zur Bestätigung aufgefordert. Sie können diese Aufforderungen im Laufe der Zeit deaktivieren, um die Beschränkungen zu lockern, wenn Sie mit der KI besser zurechtkommen.

Trauen Sie der KI nicht

Die KI kann und wird Fehler machen. Vor allem, wenn Sie sie bitten, etwas Komplexes zu tun oder eine große Codebasis zu durchsuchen. Ich habe Copilot zum Beispiel gebeten, eine Liste aller Klassen zu erstellen, die eine Schnittstelle in der CSLA .NET-Codebasis implementieren. Die meisten wurden gefunden, aber nicht alle, und einige enthielten auch Klassen, die die Schnittstelle nicht implementierten. Ich musste die Liste manuell überprüfen und korrigieren.

Ich denke, es wäre besser gewesen, die KI zu bitten, mir einen grep-Befehl oder etwas anderes zu geben, das eine Suche für mich durchführt, anstatt zu versuchen, die KI die Arbeit direkt erledigen zu lassen.
Ich lasse die KI jedoch oft eine begrenzte Anzahl von Dateien untersuchen und sie ist fast immer korrekt. Wenn ich die KI zum Beispiel nach einer Liste von Eigenschaften oder Feldern in einer einzelnen Klasse frage, ist sie in der Regel korrekt.

Verwenden Sie Git Commit wie "Spiel speichern".

Ich bin schon fast mein ganzes Leben lang ein Gamer und eine Sache, die ich beim Spielen gelernt habe, ist das Konzept der "Spielstände". In vielen Spielen können Sie Ihren Fortschritt an jedem beliebigen Punkt speichern und diesen Speicher wieder laden, wenn Sie einen Fehler machen oder einen anderen Ansatz ausprobieren möchten.

Das gilt auch für die Arbeit mit KI. Bevor Sie die KI bitten, wesentliche Änderungen an Ihrem Code vorzunehmen, sollten Sie einen Git-Commit durchführen. Wenn die KI Änderungen vornimmt, die Sie nicht wünschen oder erwarten, können Sie auf diese Weise leicht zum vorherigen Zustand zurückkehren.

Ich ertappe mich dabei, dass ich jedes Mal einen Commit mache, wenn ich Code kompiliere, Tests bestanden habe oder einen anderen Meilenstein erreiche - selbst einen kleinen. So können Sie sicher mit KI experimentieren, ohne Angst haben zu müssen, Ihre Arbeit zu verlieren.

Ich will damit nicht sagen, dass Sie jedes Mal auf den Server pushen oder eine Pull-Anfrage (PR) stellen sollen - ein lokaler Commit ist für diesen Zweck ausreichend.

Manchmal gerät die KI aus den Fugen und bringt Ihren Code durcheinander. Mit einem aktuellen Commit können Sie schnell zu einem bekannten guten Zustand zurückkehren.

Erstellen und Verwenden von MCP-Servern

Wie Sie sich vielleicht vorstellen können, verwende ich CSLA .NET sehr häufig. Da CSLA Open-Source ist, weiß die Copilot-KI im Allgemeinen alles über CSLA, da der Open-Source-Code Teil der Trainingsdaten ist. Das Problem ist, dass die Trainingsdaten alles von CSLA 1.0 bis zur aktuellen Version abdecken - also jahrzehntelange Änderungen. Das bedeutet, wenn Sie Copilot bitten, Ihnen mit CSLA-Code zu helfen, kann es sein, dass er Ihnen Code liefert, der nicht mehr aktuell ist.

Ich habe einen MCP-Server für CSLA erstellt, der Informationen über CSLA 9 und 10 enthält. Wenn Sie diesen MCP-Server zu Ihren Copilot-Einstellungen hinzufügen und Fragen zu CSLA stellen, erhalten Sie Antworten, die sich speziell auf CSLA 9 und 10 beziehen, und nicht auf ältere Versionen. So etwas können Sie in Ihre /.github/copilot-instructions.md Datei aufnehmen, um sicherzustellen, dass alle in Ihrem Team die gleichen MCP-Server verwenden.

Die Ergebnisse der KI sind bei Verwendung eines solchen MCP-Servers wesentlich besser als ohne ihn. Wenn Sie KI zur Unterstützung eines bestimmten Frameworks oder einer Bibliothek verwenden, sollten Sie einen MCP-Server für dieses Framework oder diese Bibliothek einrichten.

Sie können auch Ihren eigenen MCP-Server für Ihr Unternehmen, Ihr Projekt oder Ihre Codebasis erstellen. Ein solcher Server kann Codeschnipsel, Muster, Dokumentationen und andere kontextspezifische Informationen bereitstellen, die die Qualität der KI-Ausgabe erheblich verbessern können.

Ich habe einen Blogbeitrag über den Aufbau eines einfachen MCP-Servers geschrieben.

Fazit

KI ist ein nützliches Werkzeug für die Softwareentwicklung, aber sie ist keine Zauberei. Sie müssen lernen, wie man sie effektiv einsetzt, und Sie müssen bereit sein, ihre Ergebnisse zu überprüfen und zu verfeinern. Wenn Sie die KI als Mitarbeiter betrachten, ihr Kontext zur Verfügung stellen und MCP-Server verwenden, können Sie viel bessere Ergebnisse erzielen.

Als Branche müssen wir die Vorstellung überwinden, dass KI nicht nützlich ist, und anfangen, darüber zu diskutieren, wie wir sie ethisch und effektiv nutzen können. Nur dann können wir die Auswirkungen dieser Technologie vollständig verstehen und fundierte Entscheidungen über ihren Einsatz treffen.

Setzen Sie Ihre KI-Reise fort

Wenn Ihnen dieser Artikel gefallen hat, finden Sie es vielleicht auch nützlich, zu untersuchen, wie unterschiedliche KI-Ansätze die Ergebnisse in der realen Welt beeinflussen, insbesondere beim Übergang von der Theorie zur Praxis:
Agent vs. Agentisch: Was ist der Unterschied und warum spielt er eine Rolle?

Suchen Sie nach einem tiefergehenden, praktischen Leitfaden? In unserem kostenlosen Whitepaper "AI Enablement in Organizations" erfahren Sie, wie Unternehmen KI verantwortungsbewusst und effektiv in großem Maßstab einsetzen können, und zwar in Bezug auf Strategie, Betriebsmodelle und die für den Erfolg erforderlichen Fähigkeiten.

Laden Sie das kostenlose Whitepaper hier herunter

Verfasst von

Rockford Lhotka

Hello, I’m Rocky Lhotka, software architect, open source contributor, author, and speaker. I am VP of Strategy for Xebia-Microsoft Services USA and Chief Software Architect at Marimer LLC. Find me at; Mastodon: @rockylhotka@fosstodon.org GitHub: rockfordlhotka Link tree: Rockford Lhotka

Contact

Let’s discuss how we can support your journey.