Von Kwame Boateng

KI-gestütztes Programmieren wird oft als eine schnellere Variante des Pair Programming beschrieben. Dieser Vergleich greift inzwischen zu kurz. Wenn ein Agent ein Repository untersuchen, mehrere Dateien ändern, Tools ausführen, eine Vorschau erzeugen und einen Pull Request eröffnen kann, besteht das zentrale Problem der Zusammenarbeit nicht mehr einfach darin: „Kann er Code schreiben?“ Es lautet vielmehr: „Können Menschen sehen, prüfen, genehmigen und später rekonstruieren, was geschehen ist?“

Deshalb könnte die wichtigste Designveränderung in agentengestützten Softwareteams der Wechsel von privaten Prompts zu sichtbaren Arbeitsbereichen sein. Slack Code wird beispielsweise als Kombination aus Projektkanälen mit Coding-Agenten, Prüfung von Code-Diffs, Live-HTML-Vorschauen, Feedback- und Genehmigungs-Workflows, automatischer Archivierung und Audit-Protokollen beschrieben. Auch die Copilot-App von GitHub hat einen Bereich „Meine Arbeit“ hinzugefügt, um Issues und Pull Requests projektübergreifend zu organisieren. Diese Funktionen weisen auf ein praktisches Prinzip hin: Die Arbeit eines Agenten sollte weniger wie eine undurchsichtige Antwort aussehen und mehr wie ein Änderungssatz, der einen kontrollierten Produktionsprozess durchläuft.

Der Chat ist nicht das Arbeitsprotokoll

Ein Gespräch mit einem Agenten kann nützlich sein, um eine Idee zu erkunden, ist aber ein schwaches System of Record. Wichtige Details können in einem langen Thread verborgen sein: Welche Dateien wurden geändert, welche Befehle ausgeführt, welche Annahmen hat der Agent getroffen, was hat ein Reviewer abgelehnt und weicht das Endergebnis vom ersten Vorschlag ab?

Ein dauerhafter Arbeitsbereich macht diese Details überprüfbar. Er sollte die Anfrage mit einem bestimmten Repository oder Projekt verknüpfen, den Plan des Agenten bewahren, Tool-Aktionen und Dateiänderungen anzeigen, auf Tests und Vorschauen verlinken und festhalten, wer das Ergebnis genehmigt hat. Die genaue Oberfläche kann variieren – Issue-Tracker, Pull Request, Kollaborationskanal oder Agentenkonsole –, aber die Informationen sollten nach Ende der Sitzung erhalten bleiben.

Das ist aus ganz gewöhnlichen technischen Gründen wichtig, nicht nur aus Gründen der Compliance. Wenn zwei Wochen später ein Fehler auftritt, braucht ein Team mehr als den abschließenden Diff. Es muss möglicherweise die ursprüngliche Anforderung, den generierten Plan, die Testergebnisse, die Kommentare des Reviewers und die Frage kennen, ob ein Mensch einen riskanten Kompromiss ausdrücklich akzeptiert hat. Ein dauerhaftes Protokoll verkürzt diese Untersuchung.

Fünf Ebenen sichtbarer Arbeit

Teams, die Coding-Agenten einsetzen, können jede Änderung als kleine, überprüfbare Fallakte behandeln. Fünf Ebenen sind besonders nützlich:

  1. Absicht: das Issue, die Abnahmekriterien, die Einschränkungen und der angeforderte Umfang.
  2. Plan: der vom Agenten vorgeschlagene Ansatz, bevor er Dateien bearbeitet. Bei einer nicht trivialen Aufgabe ist dies ein Genehmigungscheckpoint und keine Dekoration.
  3. Diff: die genau vorgenommenen Ergänzungen, Löschungen, Abhängigkeitsänderungen, Konfigurationsanpassungen und generierten Artefakte.
  4. Nachweise: Testergebnisse, Lint-Ausgaben, Sicherheitsprüfungen, Screenshots sowie gegebenenfalls eine Live- oder deploybare Vorschau.
  5. Entscheidungsprotokoll: Kommentare des Reviewers, angeforderte Änderungen, Genehmigung, Ablehnung, Rollback oder Folgearbeiten.

Es geht nicht darum, jede Änderung durch ein schwerfälliges Komitee zu schleusen. Ein Tippfehler und eine Änderung am Zahlungsablauf sollten nicht identischen Kontrollen unterliegen. Es geht darum, die Prüfintensität proportional zu den potenziellen Auswirkungen zu gestalten.

Genehmigungen sollten an Aktionen gebunden sein

„Human in the loop“ ist zu vage, um eine nützliche Kontrolle darzustellen. Eine Person könnte einen Plan genehmigen, ohne den daraus resultierenden Diff zu sehen, oder eine Codeänderung genehmigen, ohne zu bemerken, dass der Agent auch eine Deployment-Datei geändert hat. Bessere Workflows legen fest, was eine Genehmigung erlaubt.

Beispielsweise könnte ein Team einem Agenten erlauben, ein Repository zu lesen und lokale Tests automatisch auszuführen, eine Genehmigung verlangen, bevor außerhalb eines dafür vorgesehenen Branches geschrieben wird, und eine separate Genehmigung vor dem Mergen oder Deployen fordern. Ein Agent könnte eine Datenbankmigration vorschlagen, dürfte sie aber nicht in der Produktion ausführen. Der vorgeschlagene Ansatz der VAE, zu klassifizieren, welche Aufgaben Agenten erledigen und welche sie lediglich empfehlen dürfen, spiegelt dieses umfassendere Muster wider: Autonomie sollte nach Aufgabe zugewiesen und nicht global vorausgesetzt werden.

Auch Genehmigungen brauchen einen Geltungsbereich und ein Ablaufdatum. Eine Genehmigung für „den Text der Landingpage aktualisieren“ sollte nicht stillschweigend ein neues Analysepaket autorisieren. Ein gestern genehmigter Plan sollte heute nicht automatisch einen wesentlich veränderten Diff abdecken. Die Oberfläche sollte diese Grenzen sichtbar machen.

Vorschauen machen aus Review eine Inspektion

Code-Reviews sind oft einfacher, wenn Menschen das Ergebnis inspizieren können, statt es aus Quelldateien abzuleiten. Eine Live-HTML-Vorschau kann fehlerhafte Abstände, fehlende Zustände, nicht barrierefreie Bedienelemente oder eine unbeabsichtigte Änderung der Navigation aufdecken, die ein Reviewer in einem textuellen Diff möglicherweise übersieht.

Vorschauen sind kein Beweis für Korrektheit. Sie sollten neben Tests und Quellcodeprüfung stehen, diese aber nicht ersetzen. Sie schaffen jedoch ein gemeinsames Diskussionsobjekt: Ein Reviewer kann auf einen bestimmten Bildschirm, Zustand oder eine Interaktion verweisen und Feedback direkt an der vorgeschlagenen Änderung hinterlassen.

Das ist besonders wertvoll, wenn auch Nicht-Spezialisten an der Prüfung beteiligt sind. Ein Produktmanager kann möglicherweise eine Framework-Änderung nicht beurteilen, ist aber vielleicht die richtige Person, um zu bestätigen, dass der Ablauf der Anforderung entspricht. Ein Designer kann eine visuelle Regression validieren. Ein Sicherheitsspezialist kann sich auf Berechtigungen und den Umgang mit Daten konzentrieren. Der agentengestützte Arbeitsbereich kann jede Frage an die Person weiterleiten, die sie am besten beantworten kann.

Diffs brauchen Kontext, nicht nur Farbe

Ein vertrauter rot-grüner Diff bleibt unverzichtbar, aber von Agenten erzeugte Änderungen können umfangreich genug sein, um einen Reviewer zu überfordern. Teams sollten Agenten auffordern, Commits oder Änderungsgruppen eng zu halten, zu erklären, warum sich jede wesentliche Datei geändert hat, und generierte oder von Drittanbietern stammende Dateien gesondert zu kennzeichnen.

Nützliche Fragen für das Review sind:

  • Welches für Nutzer sichtbare Verhalten hat sich geändert?
  • Welche Dateien wurden ausschließlich zur Unterstützung der Implementierung geändert?
  • Welche Annahmen hat der Agent über das bestehende Verhalten getroffen?
  • Welche Tests wurden hinzugefügt, geändert oder nicht ausgeführt?
  • Könnte sich diese Änderung auf Berechtigungen, Datenaufbewahrung, Abrechnung oder externe APIs auswirken?

Diese Fragen machen aus einer vagen Bitte wie „Schau dir das mal an“ eine wiederholbare Prüfung. Sie helfen außerdem dabei, einen häufigen Fehler aufzudecken: ein plausibles Feature, zu dem eine unvollständige Testaktualisierung oder eine versehentliche Konfigurationsänderung gehört.

Die relevanten Überlegungen archivieren

Jedes einzelne Token aus jeder Modellkonversation aufzubewahren, ist nicht automatisch sinnvoll. Lange Verläufe können teuer in der Speicherung und schwer zu durchsuchen sein, während die Forschung zur Kontextkomprimierung davor warnt, dass Zusammenfassungen wichtige Informationen verlieren können. Ein praktischer Prüfpfad sollte daher entscheidungsrelevante Artefakte bewahren, statt wahllos alles zu speichern.

Bewahre mindestens die Anfrage, den genehmigten Plan, den finalen Diff, die Ergebnisse von Tools und Tests, die Referenz für die Vorschau oder Bereitstellung, die Entscheidungen der Reviewer und jede gewährte Ausnahme auf. Wenn ein Agent externe Quellen verwendet oder interne Dokumente abgerufen hat, halte die relevanten Quellenverweise und den Zeitpunkt fest, an dem sie die Änderung beeinflusst haben. Bei Arbeiten mit hohem Risiko kann es gerechtfertigt sein, die vollständige Interaktion und das vollständige Ausführungsprotokoll aufzubewahren.

Mache Aufzeichnungen, sofern die Tragweite es erfordert, manipulationssicher erkennbar und lege Aufbewahrungsregeln fest, bevor es zu einer Krise kommt. Ein Prüfpfad, der verschwindet, wenn ein Kanal archiviert wird – oder der ein geändertes Ergebnis nicht vom ursprünglichen unterscheiden kann –, wird eine ernsthafte Untersuchung nicht unterstützen.

Was das für Karrieren in der Softwareentwicklung verändert

Die neue Kompetenz besteht nicht bloß darin, bessere Prompts zu schreiben. Es geht darum, Arbeit so zu gestalten, dass eine andere Person sie prüfen und ihr vertrauen kann. Entwickler müssen sich damit auskennen, Abnahmekriterien festzulegen, Aufgaben zu zerlegen, Diffs in großem Umfang zu prüfen, aussagekräftige Tests zu erstellen und zu entscheiden, an welcher Stelle ein Agent anhalten und nachfragen muss.

Produkt- und Designfachleute werden eine größere Rolle bei der Prüfung von Vorschauen und der Klärung der Zielsetzung übernehmen. QA-Ingenieure können dabei helfen, Freigabestufen und Fehlerfälle zu definieren. Engineering Manager müssen den Durchsatz messen, ohne unsichtbares Eingehen von Risiken zu belohnen. Technische Redakteure und Betriebsspezialisten können dazu beitragen, Entscheidungen, Ausnahmen und Runbooks dauerhaft festzuhalten.

Eine nützliche Übung besteht darin, ein routinemäßiges Feature zu nehmen und seine Nachweiskette abzubilden: Anfrage, Plan, Branch, Diff, Tests, Vorschau, Genehmigung, Veröffentlichung und Rollback. Frage anschließend, an welchen Stellen ein künftiger Teamkollege gezwungen wäre zu raten. Jede solche Vermutung ist ein Kandidat für einen besseren Arbeitsbereich, eine klarere Berechtigung oder eine dauerhaftere Aufzeichnung.

Eine einfache Betriebsregel

Lass Agenten sich schnell innerhalb einer sichtbaren, reversiblen Leitplanke bewegen. Gib ihnen einen definierten Arbeitsbereich, beschränke sensible Aktionen, verlange an maßgeblichen Übergängen eine Genehmigung, verknüpfe Nachweise mit der Änderung und bewahre die abschließende Entscheidung auf. Das Ziel besteht nicht darin, die Automatisierung so weit zu verlangsamen, bis sie manueller Programmierung ähnelt. Es geht darum, Geschwindigkeit mit Verantwortlichkeit vereinbar zu machen.

Bei der agentengestützten Entwicklung ist der beste Kollaborateur nicht das System, das isoliert den meisten Code erzeugt. Es ist das System, dessen Arbeit verstanden, hinterfragt, genehmigt, rückgängig gemacht und aus der gelernt werden kann.