Code-Generierung kann einen erfahrenen Entwickler seltsam ersetzbar wirken lassen. Eine Aufgabe, die früher einen Nachmittag brauchte, liefert nun in Minuten einen überzeugenden ersten Entwurf.
Der Fehler liegt darin, den Job an Tastenanschlägen zu messen. Softwareentwicklung bestand nie nur aus dem Schreiben von Quellcode. Sie ist die Arbeit, einen unklaren Bedarf in ein System zu verwandeln, das sich auch nach dem Release weiter korrekt verhält.
Trenne Output von Outcome
Ein KI-Tool kann einen Patch erzeugen. Das Engineering-Ergebnis umfasst viel mehr:
- die Anforderung passt zum Problem der Nutzer;
- das Design passt zum bestehenden System;
- Fehler- und Missbrauchsfälle sind behandelt;
- Daten bleiben bei der Migration korrekt;
- die Änderung lässt sich betreiben und zurücknehmen;
- jemand kann sie sechs Monate später noch warten.
Generierter Code macht Output günstiger. Er nimmt dir diese Pflichten nicht ab. In manchen Teams vermehrt er sie sogar, weil mehr Code schneller im Review landet.
Verlagere Aufwand auf die Entscheidungspunkte
Die wertvolle Arbeit verschiebt sich zu Entscheidungen, die viele spätere Schritte beeinflussen.
Spezifikation heißt, aus „Berechtigungen hinzufügen“ Akteure, Ressourcen, Aktionen, Standardwerte, Vererbungsregeln, Audit-Anforderungen und verbotene Zustände zu machen.
Zerlegung heißt, eine Reihenfolge zu wählen, in der jede Änderung klein genug zum Verifizieren und sicher genug zum Ausliefern ist.
Review heißt, Verhalten, Architektur, Sicherheit, Daten, Betrieb und Wartbarkeit zu prüfen. Die Formatierung ist der leichte Teil.
Verifikation heißt, Belege auszuwählen, die die Fertigmeldung des Agenten widerlegen können. Ein grüner Test, der den geänderten Pfad nie ausführt, ist Dekoration.
Übe die Fähigkeiten, die Modelle nicht besitzen können
Engineering-Urteilsvermögen lässt sich gezielt trainieren.
Schreibe bei jeder Aufgabe die Akzeptanzkriterien, bevor du den Editor öffnest. Vergleiche nach der Umsetzung den Diff mit diesen Kriterien und notiere, was sie nicht vorhergesehen haben.
Erkläre beim Review generierten Codes ein verworfenes Design in einfachen Worten. Benenne die verletzte Invariante oder die künftigen Kosten, statt zu sagen, die Lösung „fühle sich falsch an“.
Debugge anhand von Belegen. Reproduziere den Fehler, grenze die Schicht ein, bilde eine falsifizierbare Hypothese und führe das kleinste Experiment durch, das zwei mögliche Ursachen trennt.
Lies Systeme außerhalb des Features, das du änderst. Verfolge eine Anfrage durch Netzwerk, Anwendung, Datenbank, Queue, Metriken und Deployment-Pfad.
Programmiere weiter
Weniger Code zu tippen heißt nicht, ihn nicht mehr zu verstehen. Generierten Code zu lesen, ohne ihn schreiben oder ändern zu können, erzeugt oberflächliche Sicherheit.
Baue weiter kleine Komponenten von Grund auf. Verfolge unbekannte Bibliotheken nach. Schreibe Tests, bevor du den Agenten um eine Implementierung bittest. Debugge, ohne sofort einen Ersatz-Patch anzufordern.
Diese Übungen erhalten das mentale Modell, das du brauchst, um schnelleren Output zu beurteilen.
Ändere, wie du dich selbst misst
Codezeilen und Stunden am Keyboard sind schlechte Maßstäbe. Bessere Fragen sind:
- Habe ich Unsicherheit reduziert?
- Habe ich den gefährlichen Randfall vor der Produktion gefunden?
- Habe ich ein kleineres und klareres System hinterlassen?
- Kann ein anderer Engineer überprüfen, warum diese Änderung korrekt ist?
KI verändert die Verteilung des Aufwands. Der Entwickler, der das Problem rahmen, die Lösung eingrenzen und das Ergebnis beweisen kann, bleibt für das System verantwortlich.
Diese Verantwortung ist kein Trostpreis nach dem Coden. Sie ist der Job.