Agentic Coding — wenn Softwareentwicklung zur Orchestrierung wird

Die auffällige Veränderung ist leicht zu benennen: Wo mit KI-Agenten gearbeitet wird, wird berichtet, dass weniger selbst getippt werde. Sie ist auch die, über die gesprochen wird. Die folgenreiche zeigt sich später und leiser — sie betrifft nicht, wie Code entsteht, sondern wo die Arbeit an einem System klemmt.

Die Frage ist deshalb nicht, was ein Agent kann. Sie lautet: Wenn das Erzeugen von Code billiger wird — wo klemmt die Arbeit dann? Die Antwort lautet nicht „nirgends". Unsere These — und sie ist unsere, kein Befund — lautet: Die Engpassstelle verschiebt sich, weg vom Produzieren von Code hin zum Definieren, Orchestrieren, Prüfen und Verantworten von Arbeit. Wohin genau sie wandert, beschreibt das nächste Kapitel entlang einer Einteilung, die ebenfalls unsere ist. Der Text nennt dabei kein Produkt, kein Modell und keine Zahl. Was hier zählt, ändert sich nicht mit dem Werkzeugstand — und eine belastbare Zahl für diese Arbeitsform, die wir vertreten würden, kennen wir nicht.

1. Was sich tatsächlich verschiebt

Was vorher nebenher entstand — die Festlegung, was gebaut werden soll, und die Gewissheit, dass das Gebaute stimmt —, wird zur eigentlichen Arbeit. Der empfundene Gewinn beim Erzeugen ist deshalb nicht die ganze Rechnung: Der Aufwand wird nicht kleiner, er verteilt sich anders. Der Einwand, Festlegen und Prüfen hätten immer schon dazugehört, trifft zu. Neu ist nicht die Tätigkeit, sondern ihr Anteil. Ob dabei auch ein Nebenprodukt wegfällt — ob sich Wissen im Bauen anders bildet als im Prüfen —, ist eine offene Frage; das achte Kapitel kommt darauf zurück.

Wir beschreiben die Arbeit an einem System entlang von vier Stationen: Definieren, Produzieren, Prüfen, Verantworten. Diese Einteilung ist unsere Denkfigur, kein Ergebnis der Forschung. Solange das Produzieren die teuerste Station war, klemmte die Arbeit dort, und alles andere ordnete sich um diesen Engpass herum. Wird das Produzieren billiger, löst sich die Verengung nicht auf — sie wechselt die Stelle.

Schema: Unsere Denkfigur — der Engpass verschwindet nicht, er wechselt die Stelle.

Trade-off. Die Verschiebung anzunehmen heißt, den empfundenen Gewinn beim Erzeugen gegen einen unsichtbaren Zuwachs beim Festlegen und Prüfen zu verrechnen — die Rechnung fällt nüchterner aus als der erste Eindruck.

Kosten. Die neue Arbeit ist schlecht sichtbar und wird deshalb selten eingeplant; sie erscheint in keiner Schätzung, die den alten Zuschnitt der Arbeit voraussetzt.

Wann wir anders entscheiden. Wo eine Aufgabe klein, isoliert und folgenlos ist, wiegt die Verschiebung nicht — dort fällt die neue Arbeit kaum an, und es bleibt bei dem, was die Arbeitsform ohnehin verspricht.

2. Der Unterschied zu Autovervollständigung und Chat

Eine Vervollständigung schlägt vor, ein Chat antwortet; in beiden Fällen übernimmt oder verwirft der Mensch und führt aus. Ein Agent handelt: Er liest im Repository, zerlegt ein Ziel in Schritte, ändert über mehrere Dateien hinweg, ruft Werkzeuge auf, liest deren Ergebnis und macht damit weiter. Diese Rückkopplung aus der Umgebung ist das Kennzeichen: Der nächste Schritt hängt davon ab, was der vorige bewirkt hat. Wir unterscheiden die drei Formen entlang von fünf Merkmalen — die Abgrenzung ist unsere, keine Klassifikation aus der Forschung:

Unsere Lesart des Unterschieds lautet: Der Sprung liegt im Handlungsumfang, nicht in der Güte des Modells dahinter. Wer einwendet, das sei nur ein besserer Assistent, übersieht, wer die Zwischenschritte ausführt: Solange ein Mensch jeden Schritt auslöst, ist er auch dessen Prüfer. Fällt das weg, wird Prüfen zu einem eigenen Arbeitsschritt.

Trade-off. Mit dem Handlungsumfang wächst, was ein Werkzeug übernehmen kann — und im selben Zug die Menge dessen, was niemand mitgelesen hat.

Kosten. Eine Änderungsfolge über mehrere Dateien lässt sich nicht überfliegen wie ein Vorschlag — sie muss nachvollzogen werden, und das kostet knappe Aufmerksamkeit.

Wann wir anders entscheiden. Wo eine Aufgabe aus einem einzigen, überschaubaren Schritt besteht, ist der geringere Handlungsumfang die passendere Wahl — nicht die schwächere.

3. Arbeit definieren: Aufgaben, Abnahmekriterien und Grenzen

Wer nicht sagen kann, woran „fertig" erkennbar ist, kann eine Aufgabe nicht delegieren. Aufgabenzerlegung und Abnahmekriterien sind damit keine Vorarbeit mehr, sondern die Leistung selbst. Der Einwand, das sei Wasserfall durch die Hintertür, geht daran vorbei: Festgelegt wird nicht die Lösung, sondern die Abnahme. Der Weg bleibt offen; prüfbar sein muss das Ziel. Bei paralleler Arbeit gilt das umso mehr: Parallelität vervielfacht die Definitions- und Prüflast, statt sie zu beseitigen — der Engpass wird früher erreicht, nicht später. Dieses Zuschneiden dessen, was nebeneinander laufen soll, ist das Orchestrieren, von dem der Titel spricht.

Der zweite Ort der Festlegung ist das System selbst. Wir halten es für entscheidend, dass Grenzen dort stehen, wo sie maschinell wirken: in Modulschnitten, Typen, Verträgen, Tests und Konventionen — nicht in der Aufgabenbeschreibung. Eine Grenze in der Beschreibung ist billig und hält nicht; eine in der Struktur ist teuer und trägt. Sie leistet zweierlei: Sie ist die Rückkopplung, an der ein Agent erkennt, ob ein Schritt trug, und das Gate, an dem ein Mensch prüft. Ein Repository, dessen Regeln maschinell prüfbar sind, führt; eines, dessen Regeln implizit im Kopf einiger Leute liegen, überlässt beides dem Zufall.

Trade-off. Festlegung und Struktur kosten genau dort Zeit, wo die Arbeitsform Zeit verspricht — der empfundene Gewinn schrumpft dadurch.

Kosten. Struktur ist Vorleistung: Sie verlangsamt die erste Aufgabe, um die zwanzigste zu ermöglichen, und sie muss gepflegt werden wie jeder andere Teil des Systems.

Wann wir anders entscheiden. Bei einer wegwerfbaren Erkundung, deren Ergebnis niemand übernimmt, wäre eine formale Abnahme überflüssig und die Struktur verschwendet.

4. Prüfen: Tests, CI und das Gate vor der Wirkung

Dieselbe Rückkopplung, die einen Agenten führt, kann seine Arbeit nicht abnehmen. Ein Ergebnis aus der Umgebung sagt ihm, ob ein Schritt zum nächsten taugt — nicht, ob das Ganze verantwortbar ist. Deshalb gehört der Beweis nach außen: deterministisch und außerhalb der Schleife, die er prüft. Das ist dieselbe Bauregel, mit der wir Wahrscheinliches in Produktivsystemen einfassen — auf den Herstellungsweg angewendet.

Schema: Eingang ist die Aufgabe mit ihren Abnahmekriterien. Die Schleife darf iterieren — Wirkung entfaltet sie erst hinter Prüfung und Freigabe.

Ein Gate ist mehr als eine Testsuite: Tests prüfen Verhalten, ein Review prüft Passung — ob eine Änderung zu diesem System und seiner Absicht gehört. Eine Änderung kann alle Prüfungen bestehen und trotzdem nicht angenommen werden; sichtbar wird diese Lücke, sobald agentisch erzeugte und menschliche Beiträge nebeneinanderlaufen. Der Einwand, Gates seien Bürokratie, verkennt sie: Wer die Trennung von bestandener Prüfung und angenommener Änderung nicht zieht, hat sie hinter die Wirkung verlegt, nicht abgeschafft. Weil ein Fehlschluss in einer mehrstufigen Schleife die folgenden Schritte trägt, gehört das Gate nicht ans Ende, sondern an jeden Übergang, an dem Wirkung entstünde.

Trade-off. Jedes Gate kauft Verlässlichkeit mit einem Teil des Tempos, das dieser Arbeitsform zugeschrieben wird.

Kosten. Gates sind selbst Software: Sie werden entworfen, gepflegt und laufen bei jeder Änderung — und ein Gate, dem niemand traut, wird nach unserer Erfahrung umgangen.

Wann wir anders entscheiden. Wo ein Ergebnis den Menschen ohnehin nur als Vorschlag erreicht und ihn nicht bindet, ist er bereits das Gate; ein zusätzliches wäre Zeremonie.

5. Die Prüflast und wer sie trägt

Wo mehr erzeugt wird, muss mehr nachvollzogen werden. In einer Längsschnittbefragung professioneller Engineers — befragt zu assistierenden Werkzeugen, nicht zu agentischer Arbeit — verschiebt sich der Anteil der Arbeit vom Herstellen zum Prüfen und Korrigieren, und für diese Tätigkeit ist dort ein eigener Begriff vorgeschlagen worden: aufsichtsführende Ingenieursarbeit. Dass sie mit dem Handlungsumfang eines Agenten eher zu- als abnimmt, ist unsere Schlussfolgerung. Gleichmäßig verteilt sie sich ohnehin nicht. Eine Beobachtungsstudie an gewachsenen Open-Source-Projekten — nach Einführung eines assistierenden, nicht eines agentischen Werkzeugs — deutet darauf hin, dass die zusätzliche Prüf- und Nacharbeit dort landet, wo das Urteil am knappsten ist: bei den Erfahrenen, die dadurch mehr prüfen und weniger selbst bauen. Eine Tendenz, kein Gesetz — für das eigene Team lässt sich das nur feststellen, nicht annehmen.

Damit zur unbequemsten Eigenschaft dieser Arbeitsform: Wahrnehmung ist kein Messinstrument. In einer kontrollierten Untersuchung fielen der Eindruck der Beteiligten und die Messung auseinander — sie betraf assistierende Werkzeuge eines vergangenen Werkzeugstands, nicht agentische Arbeit, doch dieser Teil ihres Befundes hängt nicht daran. Die Beteiligten waren erfahren und aufmerksam; die Fehleinschätzung ist also keine Nachlässigkeit, sondern eine Eigenschaft der Situation. Auch wo Befragte durchgängig Verbesserungen berichteten, nannten dieselben Leute zugleich Verschlechterungen an anderer Stelle. Wir sagen damit nichts über die Richtung des Effekts, sondern dies: Der eigene Eindruck trägt keine Entscheidung über Einführung, Ausweitung oder Rücknahme. Dafür braucht es eine Messung — wer sein System nicht beobachtet, sieht auch diese Wirkung nicht. Und der naheliegende Schluss, es brauche mehr erfahrene Leute, ist nicht der einzige: Ein System mit maschinell prüfbaren Regeln verlagert nach unserer Einschätzung einen Teil dieses Urteils in die Struktur — und senkt damit den Bedarf, den dieses Kapitel beschreibt.

Trade-off. Prüfkapazität sichtbar zu machen begrenzt, wie viel parallel laufen darf — sie wirkt wie eine Bremse, und sie ist eine.

Kosten. Eine Messung aufzubauen ist Arbeit, die selbst nichts ausliefert, und ihre Ergebnisse sind oft unbequem für die, die die Einführung betrieben haben.

Wann wir anders entscheiden. Bei einem befristeten Versuch mit klarer Abbruchbedingung genügt aufmerksame Beobachtung; die formale Messung gehört zu Entscheidungen mit Bestand.

6. Berechtigungen, Grenzen und menschliche Freigabe

Handlungen sind nicht gleichwertig: Lesen, Schreiben, Ausführen, Ausliefern und Löschen unterscheiden sich kaum im Aufwand, aber erheblich im Schaden eines einzelnen Fehlschlusses. Deshalb ist Vertrauen das falsche Ordnungskriterium: Der Schaden bleibt gleich, unabhängig davon, wie zuverlässig es zuletzt lief. Unser Kriterium ist die Umkehrbarkeit; die folgende Staffelung ist unsere, keine Norm:

Wie bei wahrscheinlichen Komponenten in Produktion gilt auch hier: Menschliche Kontrolle gehört nicht überall und nicht nirgends hin — überall aufgestellt macht sie die Delegation sinnlos, nirgends aufgestellt verlagert sie das Risiko hinter die Wirkung. Der Einwand, Freigaben machten den Einsatz unwirtschaftlich, trifft nur die erste Variante — nach Umkehrbarkeit gestaffelt bleiben die meisten Handlungen frei. Dass agentische Systeme in der Sicherheitsarbeit als eigene Klasse mit eigenen Standards geführt werden, getrennt von der Sicherheit sprachverarbeitender Systeme, ist selbst ein Hinweis: Der Unterschied liegt im Handeln, nicht im Antworten.

Trade-off. Gestaffelte Freigaben kaufen Beherrschbarkeit mit Reibung im Alltag — und Reibung wird nach unserer Erfahrung umgangen, wenn sie an der falschen Stelle sitzt.

Kosten. Jede Grenze ist Konfiguration, die gepflegt werden muss — eine veraltete Freigabeliste ist gefährlicher als keine, weil sie Sicherheit vortäuscht.

Wann wir anders entscheiden. Wo eine Handlung folgenlos rückgängig zu machen ist, wäre eine Freigabe reine Zeremonie — der Maßstab ist der mögliche Schaden, nicht das Unbehagen.

7. Warum dieselben Werkzeuge gegensätzlich wirken

Der Befund, auf den wir uns hier stützen, handelt nicht vom Werkzeug, sondern von der Organisation, die es einsetzt: KI-Werkzeuge vergrößern die Stärken gut aufgestellter Organisationen und ebenso die Fehlfunktionen schlecht aufgestellter — erhoben für KI-Nutzung im Allgemeinen, nicht für agentische Arbeit im Besonderen. Sichtbar wird das an einer Doppelbewegung: Wo mehr Durchsatz berichtet wird, wird zugleich mehr Instabilität berichtet. Wer nur die eine Hälfte liest, hat die Rechnung halb gelesen. Der Einwand, am Ende sei es doch eine Werkzeugfrage, scheitert genau daran.

Dass Werkzeuge richtungsblind verstärken, haben wir an anderer Stelle beschrieben; hier zählt, was daraus für diese Arbeitsform folgt. Wo das Erzeugen billiger wird, wird die Richtung einer Arbeit nicht dort gesetzt, sondern beim Definieren — an genau der Station, an der die Arbeit ohnehin gerade klemmt. Wer dort ungenau ist, vervielfältigt die Ungenauigkeit. Dazu kommt ein Zeitprofil, mit dem in der Praxis gerechnet wird und das eine frühe Bewertung in die Irre führen kann: eine Phase, in der es zunächst schlechter wird. Wer zu früh bewertet, misst diese Phase und nicht das, was danach kommt — in welche Richtung auch immer.

Trade-off. In Praxis und Struktur zu investieren wirkt nach unserer Erfahrung stärker als die Werkzeugwahl, liefert aber nichts Vorzeigbares und dauert länger.

Kosten. Den berichteten anfänglichen Einbruch einzuplanen heißt, ihn gegenüber Erwartungen verteidigen zu müssen, die sofortigen Gewinn versprechen.

Wann wir anders entscheiden. Wo Praxis, Tests und Auslieferung bereits tragen, ist die Werkzeugfrage die nächste offene — dort ist Zurückhaltung nur noch Zögern.

8. Was sich an der Rolle erfahrener Engineers ändert

Was zurücktritt, ist nach dem, was für assistierende Werkzeuge berichtet wird, das Schreiben selbst; was zunimmt, sind Anleiten, Bewerten, Korrigieren. Wir halten dagegen, wo daraus ein Abgesang wird: Der Entwickler verschwindet nicht; seine Aufgabe wandert eine Ebene nach oben. Womit sie sich füllt — Problemschnitt, Architekturführung, Prüfkriterien, Verantwortung —, ist unsere Beschreibung dieser Ebene, keine beobachtete Verlagerung. Und sie verteuert das Urteil: Wer eine Änderung verantwortet, die er nicht geschrieben hat, braucht mehr Kontextwissen, nicht weniger, und muss beurteilen können, was er nicht selbst durchdacht hat. Dazu kommt der Zuschnitt der Aufgabe selbst: Wer prüft, muss in kurzer Zeit beurteilen, was über viele Schritte hinweg entstanden ist.

Damit steht eine Frage im Raum, die wir nicht auflösen können. Diese Urteilskraft entstand bisher als Nebenprodukt des Selbermachens: aus Fehlern, aus Umwegen, aus der Mühe, ein System durchdrungen zu haben. Kontrollierte Lernuntersuchungen — an Lernenden, über Stunden, nicht an Berufserfahrenen über Jahre — berichten, dass Unterstützung die Sofortleistung hebt und zugleich Verständnis, Codelesen und Behalten belasten kann. Ein Anhaltspunkt darin ist, dass Formen der Zusammenarbeit, die kognitive Beteiligung verlangen, den Lernerfolg auch mit Unterstützung erhielten; ob das über Wochen in einem echten System ebenso gilt, ist uns nicht bekannt. Beides sind Laborbefunde über kurze Zeiträume, und beide beantworten die Frage nicht, die hier zu stellen ist: Wenn erfahrene Engineers weniger selbst implementieren — woraus entsteht dann künftig die praktische Erfahrung, aus der Urteilskraft für Architektur, Review und Verantwortung erwächst?

Trade-off. Die Ebene nach oben zu gehen heißt, den Teil der Arbeit abzugeben, der bisher den größten Teil des Tages füllte — und dessen Nebenwirkungen niemand vermessen hat.

Kosten. Verantwortung für Arbeit zu tragen, die man nicht selbst geschrieben hat, ist als Leistung schwer sichtbar zu machen — sie hinterlässt kein Artefakt, auf das man zeigen kann.

Wann wir anders entscheiden. Wo die Abnahme einer Aufgabe länger dauert als die Aufgabe selbst, ist Delegation der teurere Weg.

9. Wo Agentic Coding trägt — und wo nicht

Die erste Bedingung ist das System. Wo Regeln in Tests, Typen und Verträgen stehen, hat der Agent eine Rückkopplung und der Mensch ein Gate; wo sie implizit bleiben, fehlt beides zugleich. Die zweite Bedingung betrifft die Erwartung, mit der man antritt. Dieselbe kontrollierte Untersuchung, die schon im Kapitel zur Prüflast vorkam, fand nicht die erwartete Beschleunigung; die Autoren nennen Vertrautheit und Reife der bearbeiteten Systeme selbst als beitragende Faktoren, die Stichprobe war klein, und sie schränken die Übertragbarkeit ausdrücklich ein. Sie betraf Assistenzwerkzeuge eines vergangenen Werkzeugstands, nicht agentische Arbeit — als Urteil über Agenten taugt sie nicht. Was sie zeigt, ist etwas anderes und Zeitloseres: Eine pauschale Beschleunigungserzählung hat einer Messung schon einmal nicht standgehalten. Das ist kein Argument gegen die Arbeitsform, sondern eines gegen das Annehmen statt Messen.

Daraus folgt für uns kein Verzicht, sondern Zurückhaltung bei Versprechen. Nach unserer Erfahrung trägt diese Arbeitsform bei gut abgegrenzten Aufgaben in Systemen mit Netz. Sie trägt nicht bei schwach spezifizierten Problemen, in unverstandenen Altsystemen ohne Prüfbarkeit und dort, wo die Wirkung nicht umkehrbar ist. Das ist ein Erfahrungsurteil, keine belegte Klassifikation. Der unbequeme Fall bleibt das Altsystem: Dort kann die erste sinnvolle Aufgabe darin bestehen, Prüfbarkeit überhaupt herzustellen — unter engerer Freigabe, und als eigenes Vorhaben, nicht nebenbei.

Trade-off. Die Prüfbarkeitsbedingung trifft zuerst die Systeme, in denen Entlastung am dringendsten wäre — dort ist die erste Aufgabe nicht die Entlastung, sondern die Prüfbarkeit.

Kosten. Prüfbarkeit nachträglich herzustellen ist ein eigenes Vorhaben mit eigenem Aufwand — es zahlt sich aus, aber nicht in der Aufgabe, die den Anlass gab.

Wann wir anders entscheiden. Wo ein System ohnehin abgelöst wird, lohnt es nicht, es erst prüfbar zu machen, um einen Agenten darin arbeiten zu lassen.

10. Typische Fehler

Die wiederkehrenden Muster, an denen diese Arbeitsform scheitert — fast alle sind Varianten davon, die eine Stelle zu entlasten und die anderen unverändert zu lassen:

• Den empfundenen Gewinn beim Erzeugen für die ganze Rechnung halten und die Arbeit übersehen, die dadurch an anderer Stelle entsteht.
• Eine Aufgabe delegieren, für die niemand sagen kann, woran „fertig" erkennbar wäre.
• Grenzen in die Aufgabenbeschreibung schreiben statt in die Struktur des Systems.
• Das Prüfgate in dieselbe Schleife legen, die es prüfen soll.
• Einen bestandenen Test für eine angenommene Änderung halten.
• Prüfkapazität als Nebenprodukt behandeln statt als endliche Größe — und dann parallelisieren.
• Freigaben nach dem Vertrauen in den Agenten staffeln statt nach der Umkehrbarkeit der Handlung.
• Die Wirkung am eigenen Eindruck bemessen, statt sie zu messen.

11. Entscheidungs-Checkliste

Vor und während der Einführung agentischer Arbeit der Reihe nach zu klären:

• Aufgabe prüfbar formuliert? Steht fest, woran „fertig" erkennbar ist — bevor jemand beginnt?
• Grenzen im System? Tragen Modulschnitte, Typen, Verträge und Tests die Regeln, oder stehen sie nur in der Beschreibung?
• Gate außerhalb der Schleife? Ist der Beweis deterministisch und unabhängig von dem, was ihn erzeugt hat?
• Test und Annahme getrennt? Ist klar, dass bestandene Prüfungen noch keine angenommene Änderung sind?
• Prüfkapazität geplant? Ist sie als endliche Größe eingeplant — und ist bekannt, bei wem sie landet?
• Freigaben nach Umkehrbarkeit? Sind Lesen, Schreiben, Ausführen, Ausliefern und Löschen unterschiedlich behandelt?
• Kontrolle dort, wo Wirkung entsteht? Steht ein Mensch im Weg, wo eine falsche Handlung etwas auslöst — und nur dort?
• Gemessen statt gefühlt? Gibt es eine Messung der Wirkung, oder entscheidet der Eindruck der Beteiligten?
• Verfassung vor Werkzeug? Ist geprüft, ob Praxis, Tests und Auslieferung tragen — bevor das Werkzeug die Antwort sein soll?

Wer diese Fragen beantworten kann, hat die Arbeit an der Stelle organisiert, an der sie klemmt, wenn das Erzeugen billiger wird — und nicht dort, wo sie früher klemmte.

FAQ

Was unterscheidet Agentic Coding von Autovervollständigung und Chat? Nach unserer Lesart der Handlungsumfang, nicht die Güte des Modells. Eine Vervollständigung schlägt vor, ein Chat antwortet — in beiden Fällen führt ein Mensch aus und ist damit Prüfer jedes Schritts. Ein Agent zerlegt ein Ziel, ändert über mehrere Dateien hinweg, ruft Werkzeuge auf, liest deren Ergebnis und macht damit weiter. Was ohne menschlichen Zwischenschritt geschieht, wächst — und damit die Menge dessen, was nachträglich geprüft werden muss.

Verschwindet Arbeit — oder verschiebt sie sich nur? Sie verschiebt sich. Belegt ist das für assistierende Werkzeuge, nicht für agentische Arbeit: Dort sinkt der Anteil des Herstellens und steigt der Anteil des Prüfens und Nachbesserns. Dass diese Verschiebung mit dem Handlungsumfang eines Agenten eher zu- als abnimmt, ist unsere Schlussfolgerung, keine Messung. Was vorher nebenher entstand — die Festlegung, was gebaut werden soll, und die Gewissheit, dass es stimmt —, wird zur eigentlichen Arbeit.

Was muss ein Repository mitbringen, damit ein Agent darin tragfähig arbeiten kann? Wir arbeiten nur mit maschinell prüfbaren Regeln: Tests, Typen, Verträge, klare Modulschnitte. Sie geben dem Agenten in jedem Schritt eine Antwort darauf, ob er auf dem eingeschlagenen Weg bleiben kann, und sie geben dem Menschen einen Punkt, an dem er prüfen kann, ohne die ganze Änderungsfolge im Kopf nachzubauen. Wo diese Regeln nur im Kopf einiger Leute liegen, fehlt beides — dem Agenten der Halt, dem Review der Maßstab.

Wie prüft man Arbeit, die man nicht selbst geschrieben hat? Mit einem deterministischen Gate außerhalb der Schleife, die es prüft: Tests, Typprüfung, CI, kleine umkehrbare Schritte — und einem Review für die Passung, die Tests nicht erfassen. Ein bestandener Test ist noch keine angenommene Änderung. Dazu gehört, die Wirkung im Ganzen zu messen statt sie zu fühlen: Wo Eindruck und Messung schon einmal auseinanderfielen, trägt der Eindruck die Entscheidung über Einführung oder Ausweitung nicht.

Welche Handlungen sollte ein Agent nie ohne menschliche Freigabe ausführen? Unsere Regel: die nur begrenzt oder gar nicht umkehrbaren. Ausliefern in Produktion; Löschen, Migrieren, Zugänge oder Konfiguration ändern. Lesen, Ändern im eigenen Arbeitszweig und Ausführen in einer isolierten Umgebung bleiben frei. Maßstab ist die Umkehrbarkeit der Handlung, nicht das Vertrauen in den Agenten — denn der Schaden bleibt gleich, unabhängig davon, wie zuverlässig es zuletzt lief. Freigaben, die überall stehen, werden nach unserer Erfahrung im Alltag umgangen.

Wo ist Agentic Coding die falsche Wahl? Nach unserer Erfahrung dort, wo Prüfbarkeit fehlt: in unverstandenen Altsystemen ohne Tests und Verträge, bei schwach spezifizierten Problemen, deren Abnahme niemand formulieren kann, und überall dort, wo eine Handlung nicht umkehrbar ist. Das ist ein Erfahrungsurteil, keine belegte Klassifikation. In einem Altsystem kann die erste sinnvolle Aufgabe darin bestehen, Prüfbarkeit überhaupt herzustellen — als eigenes Vorhaben und unter engerer Freigabe, nicht nebenbei.

Weiterführend

• Gute Werkzeuge verstärken — die Engineering Story dazu: Verstärkung wirkt in beide Richtungen.
• KI in Produktionssystemen — dasselbe Muster im Produkt: das Unsichere hinter etwas Prüfbares stellen.
• Wann sich Tests wirklich lohnen — Prüfen als Ökonomie, wenn das Erzeugen billiger wird.
• Sicherheit als Architektureigenschaft — warum Berechtigungsgrenzen in den Entwurf gehören.
• Reversibilität vor Vorhersage — warum Tempo nur trägt, solange Umkehren billig bleibt.

Grundlage ist die Batunet Engineering Method: das Problem rahmen, bevor gebaut wird; beweisen statt annehmen; das Urteil beim Menschen halten.

Abschließendes Engineering-Prinzip

Was ein System tragfähig macht, war nie das Tippen. Es war die Klarheit darüber, was gebaut werden soll, der Beweis, dass es stimmt, und die Bereitschaft, dafür einzustehen. Solange das Erzeugen teuer war, konnten diese drei Dinge nebenher erledigt werden — sie hatten keinen eigenen Ort im Arbeitstag, weil das Erzeugen ihn füllte. Wo das nicht mehr gilt, brauchen sie einen. Das ist die Veränderung, und sie ist unbequemer als das Versprechen, mit dem sie kommt: Nicht die Arbeit wird weniger — die Stelle wechselt, an der sie klemmt, und die neue lässt sich schlechter delegieren als die alte. Wer eine Aufgabe abgeben will, muss sie so genau kennen, dass er sagen kann, woran ihr Gelingen zu erkennen ist. Das war noch nie Fleißarbeit.

Ein Agent kann eine Aufgabe ausführen. Verantworten kann sie nur, wer sagen konnte, was zu tun war — und beurteilen kann, ob es getan wurde.