Die Rolle Entwicklung: Wenn niemand mehr den Code von Hand schreibt

Dies ist der dritte Beitrag einer Serie über die agentische Engineering-Pipeline für den SDLC. Der Auftakt hat das Vorgehen als Ganzes beschrieben und seine sechs Prinzipien benannt, der Beitrag davor ist in die Business-Analyse und ihr Zusammenspiel mit UX gegangen. Jetzt geht es um die Stelle, an der die meisten Menschen den eigentlichen Akt der Softwareentwicklung vermuten: das Schreiben des Codes.

In dieser Pipeline schreibt die Entwicklung den Code nicht mehr. Diese Aussage ist unbequem, und ich halte sie trotzdem für richtig. Es gibt keine IDE mehr im alten Sinn, keine integrierte Entwicklungsumgebung, in der eine Person Datei für Datei öffnet und Zeile für Zeile tippt. Die Entwicklerin sieht den einzelnen Quelltext nicht mehr beim Entstehen, weil der Agent ihn schreibt. Das klingt nach Kontrollverlust, ist aber keiner. Die Arbeit verschiebt sich auf eine Ebene, auf der die schwierigen Entscheidungen ohnehin schon immer gefallen sind. Wer Code zeilenweise tippt, verbringt einen großen Teil seiner Zeit unterhalb dieser Ebene.

Warum gerade diese Rolle die These auf die Probe stellt

Die Business-Analyse und das UX arbeiten schon lange mit Sprache als ihrem Hauptmaterial. Eine Analystin, die ein Quelleninventar etikettiert, oder ein Designer, der einen Fehlerzustand in Geschäftssprache beschreibt, hat noch nie eine Compiler-Fehlermeldung gesehen. Bei diesen Rollen wirkt der Agent als Beschleuniger einer Tätigkeit, die im Kern aus Lesen, Vergleichen und Formulieren besteht. Die Entwicklung ist anders. Sie hat ein Handwerk, das über Jahrzehnte eine eigene Werkzeugwelt aufgebaut hat: Editoren mit Syntaxhervorhebung, Debugger, Refactoring-Tasten, Autovervollständigung. Diese Werkzeugwelt war der Stolz des Berufs. Wenn ich behaupte, dass sie in einer agentischen Pipeline weitgehend verschwindet, dann rühre ich an das Selbstverständnis vieler Kolleginnen und Kollegen, und das verlangt eine Begründung, die über ein Schlagwort hinausgeht.

Entwickler und Architekt sind eine Rolle geworden

Bevor ich von der Mechanik rede, muss ich eine organisatorische Entscheidung erklären, die hinter dieser Rolle steht. In der klassischen Aufstellung sind Architektur und Entwicklung getrennt. Es gibt jemanden, oft mit dem Titel Software- oder Lösungsarchitekt, der vorab entscheidet, wie ein System aufgebaut wird, welche Komponenten miteinander reden, welche Muster gelten. Daneben gibt es die Entwicklung, die diese Vorgaben in Code übersetzt. Diese Trennung hatte einen ökonomischen Grund. Architekturentscheidungen sind teuer, wenn man sie spät korrigiert, und das Tippen von Code war langsam genug, dass sich eine vorgelagerte Planungsphase lohnte.

Der Agent verschiebt dieses Gleichgewicht. Wenn eine erste lauffähige Umsetzung in Minuten statt in Tagen entsteht, dann wird die scharfe Trennung zwischen dem, der die Architektur entwirft, und dem, der sie umsetzt, künstlich. Die Architektin muss ohnehin gegen das gewachsene Bestandssystem prüfen, das Brownfield, ob ihre Idee dort hält, und diese Prüfung läuft jetzt über denselben Agenten, der später baut. Es ergibt keinen Sinn mehr, das Architekturwissen in eine getrennte Vorphase und eine getrennte Person auszulagern, wenn die Rückkopplung zwischen Entwurf und Realität so eng wird. In der Pipeline sind Entwickler und Architekt deshalb eine zusammenhängende Rolle. Das Architektur-Review ist eine eigene Station innerhalb derselben Rolle, die auch baut.

Diese Station hat ihren festen Platz in der Kette. Sinngemäß läuft sie so: Aus den Prinzipien des Projekts, einer Art technischer Verfassung, und der fachlichen Spezifikation entsteht zunächst eine Klärung offener Punkte. Danach folgt das Architektur-Review, in dem entschieden wird, wie die Änderung in das gewachsene System passt. Erst darauf folgen der Plan, die Aufgaben und die eigentliche Umsetzung, bevor das Quality Gate greift. Die Architektur sitzt also vor dem Code, aber in derselben Hand, die den Code verantwortet.

Die Fähigkeit, die ein Modell nicht hat

Wenn der Agent den Code schreibt, stellt sich die Frage, was die Entwicklerin überhaupt noch beiträgt. Die Antwort ist das architektonische Urteil und das Gespür für das konkrete Brownfield, und das ist kein vages Talent, das man beschwört, wenn die Argumente ausgehen.

Eine erfahrene Architektin erkennt, dass eine Änderung an einer Stelle drei Stellen weiter etwas auslöst. Im Code steht das nicht. Sie erkennt es, weil sie ein vergleichbares System an genau dieser Stelle schon einmal scheitern sah. Eine Speicherlogik, die an drei Stellen denselben Datensatz anfasst und an einer davon eine Annahme trifft, die die anderen beiden nicht kennen, ist im Quelltext nicht als Gefahr markiert. Sie ist eine Gefahr, weil ein Mensch die Geschichte des Systems kennt und weiß, wo es schon einmal weh getan hat. In einem Repository ist dieses Erfahrungswissen nirgends abgelegt, es lebt in den Köpfen derer, die das System betreut haben.

Der Agent hat etwas anderes. Er hat Trainingsmuster, also einen Durchschnitt aus sehr vielen Systemen, die er im Training gesehen hat. Das macht ihn stark bei allem Üblichen. Beim Eigenen dieses einen Systems wird er unsicher, und im Brownfield zählt fast immer das Eigene: Spaltennamen, die eine alte Fachsprache konservieren; eine Ablauflogik, die irgendeine Auflage von vor zehn Jahren umsetzt, ohne dass der Grund noch dokumentiert wäre; stillschweigende Konventionen, an die sich der Code hält, ohne dass irgendwo steht, warum. Solche Eigenheiten kann ein Modell nicht aus dem Durchschnitt der Welt ableiten. Sie muss jemand kennen, der das System aus eigener Arbeit kennt.

Daraus folgt eine Verschiebung, die ich für den Kern dieser Rolle halte. Das Review von Verhalten, Diff und Tests ist die neue zentrale Arbeit der Entwicklung. Diff meint den Unterschied zwischen dem Code vor und nach einer Änderung, also genau das, was der Agent angefasst hat. Dieses Review verlangt mehr Urteil als das Tippen. Wer eine Funktion selbst tippt, denkt über Syntax nach, über die richtige Schleife, über den Variablennamen. Wer einen Diff prüft, den ein Agent erzeugt hat, muss die Frage beantworten, ob diese Änderung im gewachsenen System das Richtige tut, ob sie an den drei Stellen wirkt, die sie treffen muss, und an keiner, die sie nicht treffen darf. Das ist die schwierigere Frage, und sie war früher unter dem Tippen begraben.

Wie der Agent die Arbeit übernimmt: die Machbarkeitsprüfung

Die erste konkrete Aufgabe der Entwicklung in der Pipeline ist die Machbarkeitsprüfung, im Fachjargon der Feasibility-Check. Sie ist lesend. Der Agent verändert in dieser Phase keine einzige Zeile Code. Er liest stattdessen das gewachsene System. Er sucht im Quelltext, liest die Versionsgeschichte über git log und git blame, wertet Architecture Decision Records aus, also dokumentierte Architekturentscheidungen, liest Runbooks, das sind die Betriebsanleitungen für den laufenden Betrieb, und untersucht die Datenbankschemata. Dass der Agent frei lesen darf, aber für jede Veränderung eine Freigabe braucht, ist eines der wichtigen Prinzipien der Pipeline. So bleibt das Erkunden des Systems jederzeit möglich, während ein Eingriff in den Code eine bewusste Entscheidung verlangt.

Das eigentliche Ergebnis dieser Phase ist eine Aussage darüber, ob die Änderung machbar ist, nicht machbar oder nur unter bestimmten Bedingungen. Mit dieser Aussage kommt eine Liste der betroffenen Komponenten. Festgehalten wird außerdem, welche Annahmen des fachlichen Tickets sich am Brownfield bestätigt haben und welche sich widerlegt haben. Wenn das Ticket der Business-Analyse annimmt, dass ein bestimmtes Feld immer gefüllt ist, und die Machbarkeitsprüfung am realen Datenbestand feststellt, dass es in vielen Bestandsdatensätzen gar nicht gefüllt ist, dann ist das eine widerlegte Annahme, und sie gehört dokumentiert, bevor irgendjemand Code schreibt. Hinzu kommen Rückfragen an die Fachseite und eine kurze Lösungsskizze. Sie gibt eine Richtung an und enthält noch keine Implementierung.

Die Rückfragen wandern nicht in den Chat. Sie gehen zurück in das fachliche Ticket, dorthin, wo sie die Business-Analyse sieht und beantworten kann. Sie werden außerdem klassifiziert. Eine Rückfrage ist entweder blockierend, dann kann die Umsetzung ohne Antwort nicht beginnen. Oder sie betrifft etwas, das man notfalls aus dem Umfang herausschneiden kann, dann hält sie das Ticket nicht auf. Oder sie ist rein eine Frage der Umsetzung, dann kann die Entwicklung sie selbst entscheiden, ohne die Fachseite zu behelligen. Diese Klassifizierung verhindert, dass jede technische Detailfrage zur Rückfrage an die Fachseite aufgeblasen wird, und sie verhindert umgekehrt, dass eine wirklich blockierende Lücke unter den Tisch fällt.

Vom Ticket zur Aufgabe: der technische Schnitt

Wenn die Machbarkeit geklärt ist, schneidet die Entwicklung technische Tickets. Hier gilt eine Regel, die in der Praxis viel Disziplin verlangt: Ein Ticket umfasst genau eine Veränderung mit einem eigenen Akzeptanztest.

Die Reihenfolge der Tickets folgt dem natürlichen Aufbau einer Änderung, die von unten nach oben durch die Schichten eines Systems wächst. Zuerst das Datenmodell, weil alles andere darauf aufsetzt. Darauf die Geschäftslogik, die mit diesen Daten arbeitet, dann die Schnittstelle, über die andere Systeme oder die Oberfläche zugreifen, die API, und schließlich die Oberfläche selbst. Die Tests entstehen, sofern nicht ohnehin pro Ticket, danach, die Dokumentation zuletzt. Diese Reihenfolge sorgt dafür, dass jedes Ticket auf einem Fundament aufsetzt, das schon steht.

Jedes technische Ticket enthält einen Rückverweis. Es nennt die Akzeptanzkriterien des fachlichen Tickets, die es umsetzt, und die UX-Zustände, die es bedient. Ich schreibe diese Verweise in der Praxis als kurze Marken, etwa als Verweis auf ein bestimmtes Akzeptanzkriterium oder einen bestimmten UX-Zustand. Der Sinn dahinter ist die Rückverfolgbarkeit. Wenn später jemand fragt, warum diese eine Codeänderung existiert, dann führt der Verweis vom technischen Ticket zum fachlichen Kriterium und von dort zur ursprünglichen Anforderung. Diese Kette ist im Brownfield wertvoll, weil Bestandscode notorisch an Begründung verliert. Niemand weiß nach drei Jahren mehr, warum eine bestimmte Prüfung existiert, und die Versionsgeschichte allein reicht oft nicht, wenn die Commit-Nachricht damals dürftig war.

Als grobe Heuristik für die Größe eines technischen Tickets nehme ich ein bis drei Stunden Arbeit. Gemeint ist der Zuschnitt einer Aufgabe. Die Zahl ist kein abzurechnendes Zeitbudget. Ein Ticket, das in einer bis drei Stunden umsetzbar und testbar ist, hat eine Größe, die ein Mensch noch im Kopf behalten kann, wenn er den Diff prüft. Ein Ticket, das einen ganzen Tag umfasst, produziert einen Diff, der zu groß ist, um ihn verantwortlich zu reviewen. Der kleine Schnitt hat einen handfesten Grund. Ohne ihn lässt sich das Review am Ende kaum noch sauber durchführen.

Die Kaskade aus Plan, Epic und Tickets

Über den einzelnen Tickets liegt eine Kaskade, die von der ersten Recherche bis zur autonomen Umsetzungsschleife führt.

Am Anfang steht die Recherche, und sie ist lesend. Hier passiert dasselbe wie in der Machbarkeitsprüfung: Der Agent liest den Bestandscode, ohne etwas zu verändern. Darauf baut das Epic. Es beschreibt das Ziel der gesamten Änderung, den Umfang und die übergeordneten Akzeptanzbedingungen, und bildet die Klammer, unter der die einzelnen Tickets hängen. Aus dem Epic werden dann die Tickets geschnitten, klein und testbar, nach den Regeln, die ich gerade beschrieben habe. Der Plan legt anschließend die Reihenfolge der Arbeit fest, dazu die Quality Gates, die unterwegs passiert werden müssen, und die Definition of Done, also die Bedingung, unter der die Arbeit als fertig gilt. Zuletzt läuft die Schleife, in der der Agent den Plan tatsächlich abarbeitet.

Diese Schleife steuere ich mit einer einzigen Anweisung, die ich hier wörtlich wiedergebe, weil ihre Formulierung wichtig ist:

Mache weiter mit dem nächsten Schritt laut Implementierungsplan. Stoppe erst wenn der Plan beendet ist. Setze die Aufgabe strukturiert und sorgfältig um. Sei genau. Halte dich an die Qualitätsanforderungen (Lint, Tests) absolut. Committe häufig und frühzeitig. Dokumentiere deinen Fortschritt im Implementierungsplan, den Epic und den Tickets.

Diese eine Anweisung erlaubt langes autonomes Arbeiten ohne ständige Mikrosteuerung, weil ihre Leitplanken außerhalb des Agenten liegen. Sie verweist auf einen Plan, der vorher von einem Menschen geprüft wurde, und auf Qualitätsanforderungen, die maschinell durchgesetzt werden, also auf Lint und Tests, die hart fehlschlagen, wenn etwas nicht stimmt. Ihr Stop-Kriterium ist klar, nämlich das Ende des Plans. Ohne den geprüften Plan und ohne die harten Gates wäre dieselbe Anweisung gefährlich, weil sie den Agenten zwanzig Schritte in die falsche Richtung schicken könnte, bevor jemand merkt, dass die Richtung falsch war. Mit Plan und Gates wird sie zum Werkzeug für die autonome Arbeit, die den Geschwindigkeitsgewinn überhaupt erst auszahlt.

Das häufige und frühe Committen verbindet die Schleife mit dem Prinzip, das ich für das wichtigste der ganzen Pipeline halte: dass der Zustand in Artefakten liegt, nicht im Chat.

Git als Quelle der Wahrheit

Ein Agent hat kein Gedächtnis über die Sitzung hinaus, und auch innerhalb einer Sitzung verliert ein langer Chatverlauf an Wirkung. Was im Repository steht, bleibt dagegen erhalten. Die Versionsverwaltung ist in dieser Rolle die eigentliche Quelle der Wahrheit über den Stand der Arbeit, weit mehr als nur die Ablage für fertigen Code.

Dabei entstehen drei nützliche Spuren ganz ohne Zusatzaufwand. Die Commit-Nachricht hält das Warum einer Änderung fest, sofern man sie ernst nimmt und nicht mit einem Wort abspeist. Über git blame lässt sich die Herkunft jeder Zeile zurückverfolgen, wann sie von wem und mit welcher Begründung entstand, und git diff zeigt den genauen Unterschied zwischen zwei Punkten der Geschichte. Anders als eine separat gepflegte Notizdatei, die in jedem Projekt herumliegt und beim nächsten Code-Wechsel veraltet, hängt diese Spur am Code selbst und bleibt damit aktuell. Wer vor einer Änderung die Historie der betroffenen Datei liest, rät weniger.

Was die Rolle produziert

Am Ende ihrer Arbeit hinterlässt die Entwicklung eine Reihe von Artefakten. Ich benenne sie einzeln, weil das Quality Gate später an genau diesen Artefakten ansetzt.

Den Anfang macht die Machbarkeitsaussage, festgehalten in einem eigenen Block für Entwicklungsnotizen innerhalb des fachlichen Tickets, dort, wo die Business-Analyse sie findet. Es folgen das Epic und die technischen Tickets, von denen jedes eine Teststrategie enthält. Diese Teststrategie benennt, welche Tests auf welcher Ebene entstehen: Unit-Tests für einzelne Funktionen, Integrationstests für das Zusammenspiel mehrerer Teile, End-to-End-Tests für den durchgehenden Ablauf aus Nutzersicht. Sie benennt außerdem etwas, das oft fehlt und das ich für besonders wichtig halte: den Anti-Test. Damit meine ich die ausdrückliche Festlegung, was bewusst nicht getestet wird und warum. Eine Teststrategie, die nur sagt, was getestet wird, lässt offen, ob eine Lücke beabsichtigt oder vergessen wurde. Wenn die Strategie ihre Lücken ausdrücklich benennt, kann ein Reviewer die Entscheidung dahinter nachvollziehen und beim Test darauf zurückkommen.

Dazu kommen der Implementierungsplan und die Pull Requests. Ein Pull Request ist die Einheit, in der eine abgeschlossene Änderung zum Review vorgelegt wird. Hier gilt eine Bedingung, die ich für entscheidend halte: Der Pull Request muss aus sich heraus verständlich sein, aus dem Diff, den Tests und dem Plan, ohne dass jemand den Chatverlauf mit dem Agenten kennt. Wenn ein Reviewer den Pull Request nur verstehen kann, indem er nachvollzieht, was im Chat zwischen Mensch und Agent besprochen wurde, dann ist die Übergabe gescheitert, weil dieser Chat flüchtig ist und niemand ihn archiviert. Und schließlich das Fortschrittsprotokoll, das festhält, welcher Schritt wann mit welchem Ergebnis abgeschlossen wurde.

Das Quality Gate dieser Rolle

Die Entwicklung hat in der Pipeline zwei Prüfpunkte, und sie liegen an unterschiedlichen Stellen der Arbeit.

Das Plan-Review steht vor dem ersten Code. Geprüft werden die Reihenfolge der Arbeit, die Teststrategie, die Risiken und die betroffenen Dateien. Dieses Review ist der wirksamste Punkt der ganzen Rolle, weil ein Fehler hier am billigsten ist. Solange er im Plan steht, genügt eine Korrektur im Text. Hat der Agent ihn erst über zwanzig Schritte in den Code eingebaut, kommt zur Code-Korrektur noch die Suche nach der Stelle, an der die Richtung kippte. Den Plan vorab zu prüfen kostet wenig und erspart diese teure Nacharbeit.

Das Code-Review am Pull Request kommt danach. Hier prüft ein Mensch das Verhalten, den Diff und die Tests. Das Pflichtartefakt dieser Rolle besteht aus zwei Teilen: dem geprüften Plan und dem Pull Request mit grünen Checks. Grüne Checks heißt, dass alle automatischen Prüfungen bestanden sind. Ohne diese beiden Artefakte gibt es keine Übergabe an die nächste Rolle.

Unter den menschlichen Prüfpunkten liegt eine maschinelle Schicht, die niemand von Hand durchgehen muss. Deterministische Prüfungen laufen, bevor die teuren Modell-Stationen überhaupt anlaufen. Die statische Sicherheitsanalyse untersucht den Code auf bekannte Schwachstellenmuster. Der Lizenz- und IP-Check prüft, ob der erzeugte Code fremde Bestandteile unter einer unverträglichen Lizenz hereinholt. Die Erkennung von Prompt Injection fängt eingeschleuste Anweisungen ab, die ein Modell aus einer gelesenen Datei heraus manipulieren könnten. Diese Prüfungen laufen als Skripte mit nachvollziehbarem Ergebnis, und sie laufen bewusst zuerst, damit kein Modell Rechenzeit auf offensichtlich fehlerhaftem Material verbraucht. Sie erledigen, was sich eindeutig bestimmen lässt, und entlasten so die menschlichen Gates, an denen es um Urteilsfragen geht.

Die ökonomische Umkehr: Qualität, die plötzlich bezahlbar ist

An dieser Rolle beschäftigt mich ein Punkt am meisten: Er kehrt eine Rechnung um, die jahrzehntelang gegen die Qualität lief.

Codequalität hatte immer einen Preis in Entwicklerstunden. Hundertprozentige Abdeckung durch Unit-Tests, also der Zustand, in dem jede Zeile des Codes mindestens einmal von einem automatischen Test ausgeführt wird, war in den meisten Projekten ein theoretisches Ideal. Sie kostete so viel Zeit, dass sie unter Termindruck als Erstes gestrichen wurde. Lint im strikten Modus, also ein Werkzeug, das den Code gegen alle Stilregeln und Verdachtsmuster prüft, ohne dass irgendeine Regel als Ausnahme durchgewunken wird, war ähnlich teuer, weil jede Regel, die anschlägt, einen Menschen kostet, der sie behebt. Dasselbe gilt für durchgehende Formatierung und lückenlose statische Prüfung. Diese Disziplinen waren das, was als Erstes dem Termindruck zum Opfer fiel, weil ihr Nutzen in der Zukunft lag und ihre Kosten in der Gegenwart.

Der Agent verschiebt diese Rechnung, weil die Einhaltung dieser Disziplinen ihn fast nichts kostet. Es kostet keine zusätzliche Entwicklerstunde mehr, hundert Prozent der Zeilen mit Tests abzudecken, wenn ein Agent die Tests schreibt. Es kostet keinen menschlichen Aufwand, jede Lint-Regel zu befriedigen, wenn der Agent den Code so lange anpasst, bis keine Regel mehr anschlägt. Formatierung und statische Prüfung sind nicht mehr verhandelbar, weil ihre Einhaltung in der Schleife passiert, ohne dass ein Mensch dafür Zeit aufwenden muss. Damit kehrt sich die Rechnung um. Disziplinen, die früher dem Termindruck zum Opfer fielen, weil sie teuer waren, sind jetzt der Standardfall, weil sie billig geworden sind. Was vorher ein Ideal war, das man sich leisten musste, ist jetzt der Weg des geringsten Widerstands.

Aber, hundertprozentige Testabdeckung ist nicht dasselbe wie Korrektheit. Abdeckung misst, ob eine Zeile von einem Test ausgeführt wurde, nicht, ob der Test das Richtige prüft. Ein Agent kann Tests schreiben, die jede Zeile berühren und trotzdem nichts Sinnvolles behaupten, weil sie nur bestätigen, was der Code ohnehin tut, statt zu prüfen, ob er das Richtige tut. Eine Suite aus solchen Tests gibt ein grünes Licht, das nichts wert ist. Die volle Abdeckung verschiebt das Problem also nur. Sie sorgt dafür, dass die billigen Fehler maschinell auffallen, und lässt die teuren Fehler, die im Verständnis der Anforderung liegen, weiter offen. Deshalb braucht es nach der Entwicklung die Rolle Test, und deshalb muss diese Rolle eine andere Perspektive mitbringen als die, die den Code und seine Tests erzeugt hat.

Was die ökonomische Umkehr trotzdem wertvoll macht, ist die Verschiebung des Bodens. Früher war die Frage, ob ein Projekt sich überhaupt eine ordentliche Testabdeckung und strikte statische Prüfung leistet. Diese Frage stellt sich nicht mehr, weil die Antwort kostenlos ja lautet. Die Energie, die früher in das Erreichen dieses Bodens floss, steht jetzt für die schwierigere Arbeit zur Verfügung. Dazu gehört das Review, ob die Tests das Richtige prüfen, und das Urteil, ob die Änderung im Brownfield das Richtige tut. Das Grundniveau erledigt der Agent, sodass die Menschen Zeit für diese Fragen haben.

Wie die Compliance-Regeln in dieser Rolle wirken

Die Pipeline enthält eine Reihe von Compliance-Anforderungen, die sich durch alle Rollen ziehen. In der Entwicklung werden einige davon besonders konkret, weil hier zum ersten Mal Code entsteht, der echte Wirkung haben kann.

Die statische Sicherheitsanalyse und der Lizenz- und IP-Check setzen direkt am erzeugten Code an. Sie gehören zur maschinellen Schicht unter dem Code-Review und laufen nicht erst später. Der Sicherheitstest fängt bekannte Schwachstellenmuster ab, bevor sie in einen Pull Request gelangen. Der Lizenz-Check verhindert, dass fremder Code unter einer Lizenz, die mit dem Projekt unverträglich ist, unbemerkt hineingerät. Das ist eine Form der IP-Kontamination, die im agentischen Arbeiten ein reales Risiko ist, weil ein Modell Code aus seinem Training reproduzieren kann, dessen Herkunft niemand kennt.

Jede KI-erzeugte Änderung bekommt eine Markierung. In der Entwicklung sitzt diese Markierung im Commit-Kommentar, und sie nennt die Operation, die ausgeführt wurde, die verantwortliche Person und die Version des Modells oder der Skill-Definition, die den Code erzeugt hat. Eine Skill-Definition ist hier die wiederverwendbare Anweisung, mit der eine bestimmte Aufgabe an den Agenten gegeben wird. Diese Markierung ist die Transparenzanforderung des EU AI Act, der Verordnung 2024/1689, in der täglichen Praxis. Ob eine Codezeile von Hand geschrieben oder von einem Modell vorgeschlagen und nur bestätigt wurde, lässt sich so später in der Versionsgeschichte ablesen.

Der Agent arbeitet in einer isolierten Sandbox, also einer abgeschotteten Umgebung, und nicht auf dem Laptop der Entwicklerin. Er hat weder Zugriff auf das Dateisystem des Menschen, der ihn steuert, noch auf Produktionsumgebungen. Seine Wirkung beschränkt sich auf Entwicklung, Test und Integration. Eine Operation auf einer Produktionsumgebung ist durch eine technische Sperre aktiv blockiert, nicht nur durch eine Konvention untersagt. Diese Trennung ist die Voraussetzung dafür, dass langes autonomes Arbeiten überhaupt verantwortbar ist, denn ein Agent, der nichts an der Produktion anrichten kann, darf in der Entwicklungsumgebung mehr Freiheit haben.

Am Pull Request steht das menschliche Gate. Eine namentlich verantwortliche Person gibt die Änderung frei oder bessert sie nach, und diese Verantwortung wird durch die KI-Unterstützung nicht gemindert. Hinzu kommt die Zweit- und Drittmeinung aus dem fünften Prinzip der Serie. Im Code-Review prüft ein zweites Modell den Patch, das ihn nicht selbst geschrieben hat. Ein Modell, das seinen eigenen Code prüft, hängt an der eigenen Logik und übersieht dieselben Fehler, die es beim Schreiben gemacht hat. Ein zweites Modell mit anderen Trainingsdaten und anderen blinden Flecken bringt eine unabhängige Perspektive. Stimmen beide überein, ist der Befund verlässlicher; weichen sie voneinander ab, muss ein Mensch genauer hinsehen. Dieselbe Trennung härtet auch gegen Prompt Injection, weil ein eingeschleuster Angriff zwei verschiedene Modelle auf zwei verschiedene Weisen überlisten müsste.

Ein Wort an die, die das ungern hören

Ich habe diesen Beitrag mit einer These begonnen, die das Selbstverständnis vieler Entwicklerinnen und Entwickler berührt, und ich will sie zum Schluss nicht weichspülen. Der Beruf, wie ihn viele gelernt haben, war zu einem guten Teil vom Gehirn über die Tastatur in den Editor. Die Beherrschung des Editors, die Geschwindigkeit beim Schreiben, das formalisierte und konzeptionelle Denken, das Auswendigwissen einer Programmiersprache bis in ihre Ecken waren Kompetenzen, auf die man stolz sein durfte und die jetzt an Wert verlieren. Das ist ein realer Verlust für die, die viel in diese Fertigkeiten investiert haben, und ich halte nichts davon, ihn als reinen Gewinn zu verkaufen.

Was an die Stelle tritt, verlangt mehr Erfahrung als das Tippen: einen Plan zu entwerfen, der hält, die Tickets so zu schneiden, dass das Review funktioniert, und zu beurteilen, ob ein Diff im gewachsenen System das Richtige tut. Die Berufseinsteigerin, die früher über das Schreiben von Code in die Materie hineinwuchs, steht vor einem schwierigeren Weg, weil der Einstieg über das Handwerk wegfällt und der über das Urteil eine Erfahrung voraussetzt, die sie noch nicht haben kann. Wie dieser Weg in Zukunft aussieht, weiß ich nicht. Die Studie von Christopher Potts und Moritz Sudhof von der Stanford University, „A paradox of AI fluency" (arXiv:2604.25905), gibt einen Hinweis darauf, dass Übung einen Unterschied macht: Geübte Anwender sehen Fehler im Dialog deutlich häufiger als ungeübte. Aber wie man diese Übung erwirbt, wenn der traditionelle Übungsweg verschwindet, ist eine offene Frage, und ich habe darauf keine fertige Antwort.

Ausblick

Die Entwicklung liefert in dieser Pipeline einen Pull Request mit grünen Checks und voller Testabdeckung. Damit ist die Arbeit noch nicht zu Ende. Abdeckung ist nicht Korrektheit, ein Agent kann Tests schreiben, die alles berühren und nichts Sinnvolles prüfen, und das schwierige Urteil über die Richtigkeit einer Änderung bleibt beim Menschen. Hier setzt die nächste Rolle an. Der folgende Beitrag der Serie behandelt die Rolle Test, die mit einer anderen Perspektive auf dasselbe Feature schaut als die, die es gebaut hat, und die dort ansetzt, wo ein grüner Haken aus der Entwicklung noch keine Gewähr für korrektes Verhalten ist.