KI Programmierung richtig einsetzen – Assistenz statt Autopilot

Was KI gut kann: Boilerplate, Recherche, Refactoring-Vorschläge

Wir nutzen KI-Tools jeden Tag in unserer Arbeit. Nicht weil es modern klingt, sondern weil es uns tatsächlich schneller macht — bei den richtigen Aufgaben. Der Schlüssel liegt in den Worten „bei den richtigen Aufgaben".

Es gibt eine Kategorie von Programmierarbeit, die repetitiv ist. Standardmäßige Grundgerüste für neue Funktionen, Datenbankabfragen nach bekanntem Muster, Konfigurationsdateien, die einem festen Schema folgen. Erfahrene Entwickler nennen das „Boilerplate" — notwendiger Code, der nach klaren Regeln aufgebaut ist. Hier ist KI hervorragend. Sie liefert in Sekunden, was früher Minuten oder Stunden gedauert hat.

Auch bei der Recherche spart KI erheblich Zeit. Wenn ein Entwickler wissen will, wie eine bestimmte Bibliothek funktioniert oder welche Lösungsansätze für ein bekanntes Problem existieren, liefert KI einen brauchbaren Überblick. Nicht immer perfekt, aber als Startpunkt deutlich schneller als das Durchsuchen von Dokumentationen.

Der dritte Bereich, in dem KI echten Wert liefert, sind Refactoring-Vorschläge. Das bedeutet: bestehenden, funktionierenden Code besser zu strukturieren. KI kann Muster erkennen und Vereinfachungen vorschlagen. Das ist hilfreich — solange jemand prüft, ob der Vorschlag im Gesamtzusammenhang Sinn ergibt.

Was alle drei Bereiche gemeinsam haben: Es sind klar umrissene, in sich abgeschlossene Aufgaben. Die KI muss nicht verstehen, was Ihr Unternehmen tut. Sie muss nicht wissen, wie Ihre Software historisch gewachsen ist. Sie liefert ein Ergebnis für eine isolierte Frage — und ein erfahrener Entwickler ordnet es ein.

Genau dieses Zusammenspiel ist der Grund, warum KI-gestützte Entwicklung funktioniert. Nicht KI allein. Sondern KI in den Händen von jemandem, der weiß, was er tut.

Was KI nicht kann: Architektur, Kontext, Geschäftslogik

Jetzt zum unbequemen Teil. Denn so gut KI bei isolierten Aufgaben ist, so unzuverlässig wird sie, sobald es um das große Ganze geht.

Architektur — also die Frage, wie eine Software grundlegend aufgebaut ist — erfordert Entscheidungen, die weit über einzelne Codezeilen hinausgehen. Welche Teile der Anwendung kommunizieren miteinander? Wie werden Daten gespeichert und weitergegeben? Was passiert, wenn sich Anforderungen ändern? Diese Entscheidungen beeinflussen alles, was danach kommt. Und sie lassen sich nicht aus Trainingsbeispielen ableiten.

KI kennt Ihren Geschäftskontext nicht. Sie weiß nicht, dass Ihre Kundenverwaltung eine Sonderregel für Bestandskunden hat, die vor 2019 angelegt wurden. Sie weiß nicht, dass die Schnittstelle zum Warenwirtschaftssystem nur unter bestimmten Bedingungen funktioniert. Sie weiß nicht, dass eine bestimmte Berechnung absichtlich anders läuft als der Standard, weil Ihre Branche das erfordert.

Besonders problematisch wird es bei bestehenden Projekten. Jede gewachsene Software hat eine Geschichte. Manche Entscheidungen im Code sehen auf den ersten Blick seltsam aus, existieren aber aus gutem Grund. Wenn KI solchen Code sieht, schlägt sie oft vor, ihn zu „verbessern" — und bricht damit etwas, das absichtlich so gebaut war. Die Auswirkung merken Sie dann nicht sofort, sondern Wochen später, wenn ein bestimmter Geschäftsfall eintritt.

Das Grundproblem ist kein technisches Detail. Es ist eine fundamentale Einschränkung: KI imitiert Muster aus Trainingsbeispielen. Sie versteht nicht, was der Code tut. Sie erkennt Ähnlichkeiten und erzeugt plausibel aussehende Ergebnisse. Plausibel und korrekt sind zwei verschiedene Dinge.

Wer mehr über die typischen Probleme erfahren will, die dabei entstehen, findet eine ausführliche Übersicht in unserem Artikel über typische KI-Fehler beim Programmieren.

Der richtige Workflow: KI als zweite Meinung nutzen

Wenn KI weder Allheilmittel noch nutzlos ist — wie setzt man sie dann richtig ein? Die Antwort liegt im Workflow. Es gibt einen entscheidenden Unterschied zwischen zwei Herangehensweisen.

Der eine Ansatz — oft als Vibe Coding bezeichnet — funktioniert so: Man beschreibt in normaler Sprache, was man will. Die KI generiert den Code. Man probiert, ob es funktioniert. Wenn ja, ist man fertig. Wenn nein, beschreibt man das Problem erneut, und die KI versucht es noch einmal. Es fehlt die Prüfung durch jemanden, der versteht, was im Hintergrund passiert.

Der andere Ansatz — KI-assistierte Entwicklung — funktioniert grundlegend anders:

1. Der Entwickler plant die Lösung. Er kennt die Anforderungen, die bestehende Architektur und die Zusammenhänge im System.
2. Die KI liefert Entwürfe. Für klar definierte Teilaufgaben generiert sie Vorschläge — Boilerplate, Implementierungsvarianten, Dokumentation.
3. Der Entwickler prüft und entscheidet. Er bewertet, ob der Vorschlag zum Gesamtsystem passt, ob er sicher ist und ob er unter realen Bedingungen funktioniert.
4. Der Entwickler integriert und testet. Nicht die KI entscheidet, was in die Software kommt. Das tut jemand, der die Konsequenzen versteht.

Der Unterschied klingt subtil, ist aber grundlegend. Im ersten Fall steuert die KI. Im zweiten Fall steuert der Entwickler und nutzt die KI als Werkzeug. Das Ergebnis unterscheidet sich massiv — nicht auf den ersten Blick, aber in der Qualität, Sicherheit und Wartbarkeit der Software.

Ein guter Vergleich: KI ist wie ein sehr schneller Praktikant mit viel angelerntem Wissen. Er liefert brauchbare Zuarbeit, wenn man ihm klare Aufgaben gibt. Aber man würde ihn nie allein über die Architektur eines wichtigen Systems entscheiden lassen.

In unserer Arbeit haben wir diesen Workflow über viele Projekte verfeinert. Er ist der Grund, warum wir KI täglich nutzen und trotzdem auf Erfahrung setzen. Das eine schließt das andere nicht aus — im Gegenteil.

Prompt Engineering für Code: Präzise Anweisungen geben

Selbst wenn Sie KI nur als Hilfswerkzeug einsetzen, macht die Art der Anweisung einen großen Unterschied. Hier kommt Prompt Engineering ins Spiel — die Fähigkeit, KI-Systemen so präzise Anweisungen zu geben, dass die Ergebnisse tatsächlich brauchbar sind.

Für Code gilt das besonders. Vage Anweisungen erzeugen vage Ergebnisse. Wenn Sie einer KI sagen „Erstelle mir eine Login-Funktion", bekommen Sie irgendetwas, das wie ein Login aussieht. Ob es sicher ist, ob es zu Ihrem System passt, ob es Randfälle berücksichtigt — das hängt davon ab, wie genau die Anweisung war.

Erfahrene Entwickler geben KI-Systemen Kontext mit. Sie beschreiben nicht nur, was entstehen soll, sondern auch:

• Welche technischen Rahmenbedingungen gelten
• Welche bestehenden Konventionen eingehalten werden müssen
• Welche Sonderfälle berücksichtigt werden sollen
• Welche Lösungsansätze ausdrücklich vermieden werden sollen

Das ist kein Geheimwissen. Aber es setzt voraus, dass man weiß, welche Rahmenbedingungen relevant sind. Und genau hier liegt das Problem beim Einsatz durch Nicht-Entwickler: Wer die technischen Zusammenhänge nicht kennt, kann sie auch nicht in die Anweisung aufnehmen. Die KI bekommt dann unvollständige Informationen — und füllt die Lücken mit Annahmen, die falsch sein können.

Ein Beispiel: Wenn Sie einer KI sagen „Füge eine Exportfunktion hinzu", erstellt sie eine. Sie exportiert Daten. Soweit sichtbar, funktioniert sie. Was die KI nicht von sich aus berücksichtigt: Wie viele Datensätze Ihr System hat. Ob der Export bei 50.000 Einträgen den Server überlastet. Ob in den exportierten Daten sensible Informationen enthalten sind, die nicht in eine einfache Datei gehören.

Ein erfahrener Entwickler denkt an diese Dinge, bevor er die KI überhaupt anweist. Er formuliert die Anweisung so, dass die Antwort diese Aspekte einbezieht. Oder er erkennt in der Antwort, was fehlt, und korrigiert. Das ist der Unterschied, der am Ende zählt.

Qualitätssicherung: Jeden KI-Vorschlag prüfen

Der vielleicht wichtigste Punkt in diesem Artikel: KI-generierter Code muss geprüft werden. Immer. Ohne Ausnahme. Nicht weil KI schlecht ist, sondern weil sie anders arbeitet als ein Mensch — und weil ihre Fehler anders aussehen.

Menschliche Entwickler machen auch Fehler. Aber diese Fehler folgen meist erkennbaren Mustern: Tippfehler, vergessene Sonderfälle, Flüchtigkeitsfehler. KI-Fehler sind anders. Der Code sieht sauber aus. Er läuft im Test. Er folgt sogar Konventionen. Aber unter der Oberfläche passieren Dinge, die ohne systematische Prüfung unsichtbar bleiben.

Typische Probleme, die bei ungeprüfter Übernahme von KI-Code auftreten:

• Die Anwendung wird langsamer. Nicht sofort, sondern schleichend. Mit jedem neuen Datensatz, mit jedem Monat Nutzung. Weil der Code zwar funktioniert, aber auf eine Art, die bei wachsendem Datenbestand nicht mitskaliert.
• Sicherheitslücken bleiben verborgen. Der Code tut, was er soll. Aber er prüft nicht ausreichend, wer ihn aufruft und mit welchen Daten. Für den Test ist das egal. Für den Echtbetrieb ist es ein Risiko.
• Änderungen erzeugen Seiteneffekte. Die KI löst ein Problem an Stelle A. Dabei verändert sie ein Verhalten, das Stelle B und Stelle C voraussetzen. Die Auswirkung zeigt sich nicht beim Testen der neuen Funktion, sondern irgendwann bei einem ganz anderen Vorgang.
• Die KI erfindet Dinge. Das klingt absurd, passiert aber regelmäßig. KI verweist auf Bibliotheken, Funktionen oder Schnittstellen, die nicht existieren. Wenn niemand das prüft, entsteht Code, der auf Fantasie basiert.

Die Qualitätssicherung, die wir bei KI-gestützter Entwicklung anwenden, unterscheidet sich im Grunde nicht von der bei manuell geschriebenem Code. Aber sie ist noch wichtiger, weil KI-Fehler so plausibel aussehen. Für unseren Prozess bedeutet das: Jeder Vorschlag durchläuft eine manuelle Prüfung, wird im Kontext des Gesamtsystems bewertet und unter realistischen Bedingungen getestet — nicht nur mit Testdaten, die genau ins Schema passen.

Für Sie als Entscheider heißt das: Wenn Ihnen jemand verspricht, Ihre Software „schnell und günstig mit KI" zu bauen, fragen Sie, wer den Code prüft. Wer entscheidet, ob ein KI-Vorschlag übernommen wird oder nicht. Und wer die Verantwortung übernimmt, wenn etwas schiefgeht. Wenn die Antwort „die KI macht das schon" lautet, sollten Sie skeptisch werden.