KI in der Entwicklung

Die Vorschläge im Editor gehören inzwischen zum Alltag. Code entsteht schon lange mit Unterstützung, Autovervollständigung gibt es seit Jahren. Mit KI-Assistenten hat sich das aber deutlich ausgeweitet: Boilerplate, einfache CRUD-Funktionen und Standard-Validierungen schreibt der Assistent weitgehend selbst. Das spart Zeit. Ich tippe weniger von dem, was ich schon hundertmal geschrieben habe, und kann mich auf die Teile konzentrieren, die im jeweiligen Projekt wirklich besonders sind.

Bei Prototypen ist der Nutzen am größten. Will ich prüfen, ob ein Ansatz trägt, lasse ich mir meist zuerst eine Grundstruktur erzeugen. Daran kann ich arbeiten, statt bei null anzufangen. Auch bei Tests und Dokumentation nehme ich die Hilfe an. Testfälle lassen sich gut ableiten, und Dokumentation bleibt gern liegen, wenn man sie komplett von Hand schreiben muss. Der Assistent erinnert mich daran, dass es sie geben sollte, und liefert gleich einen ersten Entwurf.

Wo die Grenzen liegen

Der erzeugte Code ist syntaktisch korrekt, passt aber nicht automatisch ins bestehende System. Der Assistent kennt unsere Entscheidungen von vor sechs Monaten nicht, auch nicht, warum wir bestimmte Bibliotheken meiden. Den Unternehmenskontext und die geplante Entwicklung des Systems kennt er höchstens teilweise. Übernehme ich einen Vorschlag ungeprüft, richte ich mich womöglich nach einem Muster, das wir gerade ablösen wollen.

Hinzu kommt: Mit jedem Vorschlag fällt eine Entscheidung darüber, wie etwas gebaut wird. Das schafft Fakten und im ungünstigen Fall technische Schulden.

Auch fachliche Nuancen fehlen. Eine Anforderung ist selten so eindeutig, wie sie im Prompt klingt, und die KI arbeitet mit Wahrscheinlichkeiten, nicht mit Wissen über unser Geschäft. Auf eine Funktionsbeschreibung folgt deshalb eine generische Lösung, die ich erst auf unsere Regeln zuschneiden muss. Das kostet oft mehr Arbeit am Prompt und am Ergebnis, als ich erwartet hatte. Ohne Kontrolle geht es nicht.

Besonders kritisch sind Randfälle. Den Happy Path liefert die KI zuverlässig. Fehler, leere Listen, Zeitüberschreitungen oder besondere Berechtigungen fehlen dagegen häufig oder sind nur oberflächlich behandelt. Fällt mir das im Review nicht auf, steckt später ein Bug in der Produktion. Der Vorschlag wirkt dabei auch dann überzeugend, wenn er falsch ist.

Technische Schulden durch ungeprüften Code

Wer Code übernimmt, den er nicht vollständig versteht, baut technische Schulden auf. Heute läuft er vielleicht. Ändern sich die Anforderungen, muss nachgebessert werden, und das gelingt kaum sicher, wenn unklar ist, warum der Code so aussieht.

Ein Extrem davon ist das sogenannte Vibe-Coding: Menschen ohne technischen Hintergrund lassen sich eine App zusammenstellen. Das funktioniert, solange nichts kaputtgeht. Läuft die Anwendung nach der nächsten Runde nicht mehr oder ändern sich die Anforderungen, bleibt ein Haufen Code, den niemand lesen kann.

Sich hinzusetzen und „Programmier mir das!“ zu sagen, funktioniert kurzfristig. Nachhaltig ist es meiner Meinung nach nicht. Man sollte den technischen Hintergrund kennen und die Zusammenhänge verstehen. KI-erzeugten Code muss man in jedem Fall verstehen und prüfen, bevor man ihn übernimmt.

Sicherheit und Datenschutz

Beim Prompt muss ich darauf achten, was ich hineinschreibe. Sensible Daten gehören nicht hinein: API-Keys, interne URLs und personenbezogene Daten dürfen nicht an externe Dienste gehen. Das ist weitgehend Gewohnheitssache. Vor dem Hineinkopieren von Kontext heißt es, bewusst innezuhalten.

Auch der Code selbst ist nicht automatisch sicher. Die Modelle lernen aus öffentlichen Repositories, in denen unsichere Muster ebenfalls vorkommen. Waren SQL-Injections oder schwache Verschlüsselung in den Trainingsdaten häufig, können sie auch als Vorschlag auftauchen. Ich prüfe den Code deshalb nicht nur auf Funktion, sondern auch auf Sicherheitslücken. Vorschläge ungeprüft zu übernehmen, ist ein Risiko, das ich im Team nicht eingehen möchte.

Was beim Menschen bleibt

Einiges lässt sich nicht abgeben. Die Anforderungen muss ich selbst definieren. Niemand sonst weiß genau, was der Nutzer braucht, was wirtschaftlich sinnvoll ist, wohin sich das Projekt entwickelt und welche Optionen offen bleiben sollen. Auch die Architektur bleibt meine Aufgabe: Ich entscheide, wie die Module zusammenhängen und wo ihre Grenzen verlaufen, und gebe die Leitplanken vor.

Entscheidungen trifft ebenfalls der Mensch. Die KI kann Optionen auflisten, die Verantwortung für die Wahl liegt bei mir. Das gilt auch für die Qualitätssicherung und erst recht für Reviews, Tests und die Freigabe ins Produktivsystem.

Die Rolle verändert sich

Meine Arbeit verschiebt sich. Routine schreibe ich weniger, dafür entwerfe, reviewe und integriere ich mehr. Die Verantwortung für die Qualität sinkt dadurch nicht, sie steigt: Wer schneller Code liefern kann, von dem wird auch ein stabileres Ergebnis erwartet. Zwischen Idee und Implementierung vergeht weniger Zeit. Das darf nicht zulasten von Verständnis und Qualität gehen.

Entwickler werden stärker zu Architekten und Entscheidern. Wer KI sinnvoll einsetzen will, muss die Ergebnisse einordnen können, das technische Verständnis wird dadurch wichtiger. Kann ich einen Vorschlag nicht beurteilen, nützt mir die Geschwindigkeit nichts. Ich bin Kontrolleur der KI, nicht Befehlsgeber.

KI beschleunigt die Arbeit und nimmt mir Dinge ab, die mich vorher aufgehalten haben. Gute Software entsteht aber weiterhin durch Menschen, Prozesse und Kontrolle. Wer erzeugten Code weder versteht noch prüft, produziert nur schneller technische Schulden. Entscheidend ist am Ende nicht, wie schnell der Code geschrieben wurde, sondern ob er morgen noch funktioniert und sich ändern lässt.