Bei den meisten Teams, die agentisches Programmieren einführen, verlagern sich die Engpässe von der Generierung zur Prüfung. Ohne diesen Kreislauf zu verbessern, ist der effektive Geschwindigkeitsgewinn nahezu null.
In großen CI-Umgebungen mit Millionen nächtlicher Tests und Hunderten technischen Fachkräften sind die wertvollsten Aufgaben für einen Agenten die Zuständigkeitszuordnung und Triage, nicht die Codegenerierung.
Brauchbare Ergebnisse eines Agenten halten einer Prüfung stand und erklären Ursachen, statt nur Muster abzugleichen.
Die Ebene zur Erfassung von Belegen und Zusammenstellung des Kontexts ist wichtiger als die Generierungsebene.
Die Diskussion über agentisches Programmieren beginnt meist noch mit einem einfachen Versprechen: mehr Code in kürzerer Zeit zu schreiben.
Manchmal entwickelt sich daraus die ehrgeizigere Vision, dass Agenten die Arbeit planen, Pull Requests eröffnen und Änderungen mit minimalem menschlichem Eingreifen ausliefern. Für die meisten Entwicklungsteams liegt der deutlichste kurzfristige Nutzen jedoch in einem engeren Bereich. Es geht darum, den Aufwand für Iterationen zu verringern.
Softwarebereitstellung umfasst mehr als die Codegenerierung. Das Schreiben von Code ist nur eine Phase in einem längeren Kreislauf, zu dem Prüfung, Tests, Bereitstellung und bei Problemen auch die Ursachenforschung gehören. Die meisten Teams, die agentisches Programmieren einführen, ohne den Prüfprozess neu zu gestalten, verlagern ihren Engpass lediglich auf einen späteren Schritt.
Eine schnellere Generierung allein macht ein Team nicht automatisch schneller. Sie kann lediglich den Aufwand für Prüfung, Verifizierung und Vertrauensbildung erhöhen.
In vielen Entwicklungsumgebungen ist nicht der erste Entwurf der kostspielige Teil, sondern die nötige Gewissheit über seine Qualität zu gewinnen.
Hat die Änderung das Problem tatsächlich behoben oder das System verbessert? Hat sie an anderer Stelle eine Regression verursacht? Liegt der Fehler im Code, in der Umgebung, in den Tests oder in einer Abhängigkeit? Behebt die vorgeschlagene Lösung die Ursache oder nur das sichtbare Symptom?
Agenten können hier helfen, nicht weil sie technische Fachkräfte ersetzen, sondern weil sie unübersichtliche Belege in einem strukturierten ersten Durchgang untersuchen können: Protokolle prüfen, jüngste Änderungen vergleichen, relevante Signale zusammenfassen, wahrscheinliche Ursachen verfolgen, Prüfungen ausführen und ein Ergebnis vorlegen, das ein Mensch kritisch hinterfragen kann.
In vielen Teams besteht der größte Nutzen eines Agenten nicht darin, Code von Grund auf zu generieren. Er besteht darin, den Suchraum eines Problems einzugrenzen, bevor ein Mensch Stunden mit der manuellen Suche verbringt.
Besonders deutlich wird dies bei umfangreichen Debugging-Abläufen. Stell dir eine nächtliche CI vor, die Millionen von Tests in Codebasen ausführt, an denen Hunderte technische Fachkräfte arbeiten. Für eines unserer Kundenunternehmen ist das Realität. Wenn etwas fehlschlägt, ist die Zuordnung zur zuständigen Stelle schwierig. Das Problem kann im Anwendungscode, in einer Abhängigkeit, im Test-Harness oder an anderer Stelle im Technologie-Stack liegen. Protokolle können mehrere Gigabyte umfassen, und das Team, das das Problem zuerst sieht, ist nicht immer dafür zuständig.
Bei einem solchen Arbeitsablauf liegt es nicht nahe, einen einzelnen Agenten die Lösung schreiben zu lassen. Er eignet sich vielmehr für ein System, das den Problemraum schnell eingrenzt.
Eine zweckmäßige Pipeline könnte Protokolle abrufen, relevante Belege auswählen, Wichtiges zusammenfassen, Code in einer Sandbox untersuchen und eine strukturierte Ursachenanalyse mit Konfidenzwert, Nachvollziehbarkeit und Vorschlägen für die nächsten Schritte erstellen. Um einen Konfidenzwert zu erzeugen, bewertet eine Fachperson das erste Ergebnis des Agenten. Diese Bewertung wird anschließend einem LLM als Bewertungsinstanz zugeführt, damit künftige Bewertungen automatisiert werden können und zugleich am menschlichen Urteil ausgerichtet bleiben.
Das Ziel ist nicht, technisches Urteilsvermögen zu beseitigen, sondern den Prüfenden einen besseren Ausgangspunkt zu geben. Regressionstriage, Prüfung von Pull Requests, Reparatur von Tests, Release-Validierung und Untersuchungen nach der Bereitstellung folgen demselben Muster. Sie erfordern viele Belege und Prüfungen und sind von Mehrdeutigkeit geprägt. Dabei soll ein Agent den Entwicklungsprozess nicht ersetzen, sondern lediglich dazu beitragen, ihn voranzubringen.
Deshalb sollten Teams auch sorgfältig überlegen, wie sie diese Systeme bewerten.
Die falsche Frage lautet, ob ein Agent für sich genommen etwas Beeindruckendes hervorbringen kann. Die bessere Frage ist, ob er einen echten Arbeitsablauf verbessert, ohne an anderer Stelle zusätzlichen Aufwand zu verursachen.
Entscheidend ist, ob das Ergebnis konkret genug für eine Überprüfung ist, ob es Ursachen erklärt, statt nur Muster abzugleichen, und ob es die Prüfung erleichtert, statt sie zu erschweren. Eine plausible Antwort ist nicht automatisch eine brauchbare Antwort. In der Praxis vertrauen Teams dem Ergebnis eines Agenten, wenn es einer genauen Prüfung standhält und konkrete Anhaltspunkte zur Überprüfung liefert.
Die grundlegende Erkenntnis lautet: Brauchbare agentische Systeme benötigen mehr als Generierung. Entscheidend ist, wie Belege erfasst, Kontext zusammengestellt und Ergebnisse geprüft werden und wie den Prüfenden Unsicherheiten aufgezeigt werden.
Deshalb wird die nahe Zukunft des agentischen Engineerings wahrscheinlich kein großer Sprung hin zur vollständigen Autonomie sein. Wahrscheinlicher sind sorgfältig gestaltete Kreisläufe, in denen Agenten Teams dabei unterstützen, ihre Arbeit zu untersuchen, zu prüfen, zu verifizieren und zu verfeinern, sodass zwischen den Schritten weniger Aufwand verloren geht.
Das mag weniger spektakulär sein als die umfassende Vision von Autonomie, entspricht aber viel eher der Art, wie brauchbare Systeme tatsächlich eingeführt werden.