Agentic Coding ist nicht 'Mach mir X'

12 Min. Lesezeit

Echtes Agentic Coding beginnt mit Grenzen

Der sauberste Weg, Agentic Coding zu erklären, ist keine Produktdemo. Produktdemos lügen beruflich. Der sauberste Weg ist ein tatsächlicher Arbeits-Prompt und die Form der Antwort, die er hervorbringt.

Ein Entwickler formulierte eine Aufgabe ungefähr so: Bleib innerhalb von Spring-Events, verirre dich nicht in die Benutzeroberfläche, drifte nicht in anwenderbezogene Belange ab und hilf dabei, ein System zu definieren, in dem Emittenten und Konsumenten später hinzugefügt werden können. Kontakt, Anruf oder E-Mail ist nur der erste Fall. Die Zukunft mag UI-Zugriff und dialogbasierte KI-Werkzeuge beinhalten, aber nicht jetzt. Beginne mit der Event-Architektur.

Das ist bereits eine völlig andere Art von Konversation als “Bau mir ein eventgesteuertes System.”

Sie benennt die Grenze. Sie benennt die zurückgestellten Belange. Sie benennt die zukünftige Ausrichtung, ohne zu fordern, dass diese Zukunft heute implementiert wird. Sie sagt dem Agenten, wo er nicht clever sein soll.

Der Prompt forderte nicht zuerst Code

Die Antwort spie nicht sofort Klassen, Schnittstellen und Annotationen aus wie ein koffeinisierter Praktikant mit Commit-Rechten. Sie grenzte das Problem zuerst weiter ein und bat darum, benachbarten Code zu inspizieren, der bereits Pipelines, Warteschlangen und Event-Listener handhabte.

Das ist entscheidend.

Wie Wenn KI zu einem Denkpartner wird zeigt, liegt der Wert nicht in der Tippgeschwindigkeit. Der Wert liegt darin, dass das Modell lokal suchen, Muster vergleichen und mit Bewusstsein für die Codebasis antworten kann, anstatt einen generischen Konferenzvortrag zu halluzinieren.

Dann kam die Antwort mit einer vernünftigen Architekturform zurück:

• trenne Domänen-Events von Workflow-Events
• emittiere Geschäfts-Events aus Service-Grenzen anstatt aus Controllern
• trage Mandanten-, Aggregat- und Korrelationskontext explizit mit
• behandle Event-Namen als stabile Verträge
• halte Protokollierungs- und Warteschlangenmechanik aus demselben konzeptionellen Eimer fern wie Geschäfts-Events

Das ist nicht “Mach mir X”. Das ist kollaborative Architekturarbeit mit begrenzter Autonomie.

Das Modell ersetzte kein Urteilsvermögen. Es nahm an einer urteilsintensiven Konversation teil und erledigte die langweilige Aufklärung schnell genug, damit der Mensch bei der Entscheidung bleiben konnte.

Was “Mach mir X” normalerweise hervorbringt

Vergleichen Sie das nun mit dem üblichen Anti-Pattern.

Jemand öffnet ein Chat-Fenster und schreibt so etwas wie: Bau mir ein Event-System für Anrufe, E-Mails, UI-Updates, Analytics und KI-Werkzeuge.

Das Modell hat fast keine nützlichen Randbedingungen. Also tut es, was Modelle tun. Es rundet das Problem auf die statistisch vertrauteste Form ab.

Sie erhalten einen generischen Event-Bus. Vielleicht einen zentralen Dispatcher. Vielleicht einen Ordner namens events/common. Vielleicht einen Basis-Nutzlasttyp mit Feldern, die niemand durchdacht hat. Protokollierung, Workflows, Geschäfts-Events, Wiederholungsversuche und UI-Benachrichtigungen werden alle in denselben Topf geworfen, weil der Prompt sie zuerst gemischt hat. Es sieht für etwa fünfzehn Minuten umfassend aus.

Dann beginnt die Wartung, und die Rechnung kommt.

Spec-Driven Development ist Wasserfall mit besserem Marketing

Jetzt hat die Industrie ein respektableres Kostüm für denselben alten Fehler produziert. Es nennt sich Spec-Driven Development.

Auf dem Papier klingt es modern. Sie schreiben eine detaillierte Spezifikation. Die KI liest sie gehorsam. Die KI implementiert das System. Angeblich gibt Ihnen das Gründlichkeit, Geschwindigkeit und Ausrichtung auf einmal.

Was es Ihnen normalerweise gibt, ist Big Design Up Front mit einem frischen Anstrich.

Die alte Wasserfall-Fantasie ist nie wirklich gestorben. Sie hat nur die Kleidung gewechselt. Zuerst kamen Anforderungsdokumente, die dick genug waren, um Nutztiere zu betäuben. Dann kamen funktionale Spezifikationen, abgesegnet von sechs Managementebenen, liebevoll losgelöst davon, wie sich Software verhält, sobald echte Benutzer sie berühren. Jetzt ist derselbe Impuls zurück, außer dass Sie das Dokument nicht einem widerwilligen Entwickler übergeben, sondern einer unendlich geduldigen Maschine, und das Ergebnis als Fortschritt bezeichnen.

Das ist keine Revolution. Es ist Bürokratie mit Autovervollständigung.

Die versteckte Annahme ist dieselbe wie in jedem BDUF-Ritual: Wenn wir das System im Voraus detailliert genug beschreiben, wird die Realität den Anstand haben, sich daran zu halten. Die Realität hatte diesen Anstand nie, als Menschen den Code schrieben, und sie erwirbt nicht plötzlich Manieren, nur weil der Implementierer ein Sprachmodell ist.

Spezifikationen verrotten immer noch beim Kontakt mit echten Einschränkungen. Sonderfälle tauchen immer noch spät auf. Geschäftsregeln kollidieren immer noch. Namensgebung verbirgt immer noch Missverständnisse. Integrationspunkte verhalten sich immer noch wie Betrunkene auf einer Hochzeit. Der einzige Unterschied besteht darin, dass die KI weiter durch das Dokument marschiert, ohne mit den Augen zu rollen, was einige Manager mit Zuverlässigkeit zu verwechseln scheinen.

Was sie wirklich kaufen, ist ein unermüdlicher digitaler Diener für den ältesten Management-Traum in der Softwareentwicklung: Denken vom Handeln trennen, das Denken früh einfrieren und die Implementierung so billig machen, dass niemand mehr widerspricht. Dieser Traum war dumm mit Menschen. Er ist lediglich schneller mit KI.

Gute Entwickler wollen keinen stummen Sklaven, ob Mensch oder Maschine. Sie wollen eine Rückkopplungsschleife, die falsche Annahmen früh aufdeckt. Das bedeutet, Ideen gegen Code, bestehende Architektur und laufendes Verhalten zu testen. Spec-Driven Development, wenn es als große Methode verstanden wird, versucht das Gegenteil. Es versucht, das Argument zu gewinnen, bevor das System das Recht verdient hat zuzustimmen.

Die Management-Version dieses Fehlers klingt so: “Wenn die KI so schlau ist, warum brauchen wir dann dieses ganze Hin und Her?”

Weil in diesem Hin und Her die eigentliche Arbeit stattfindet.

Die Entwickler-Version klingt so: “Gib mir einfach den Code.”

Das ist oft nur Ungeduld mit einem technischen Anstrich.

Wenn die Systemgrenze falsch ist, ist es kein Vorteil, Code schnell zu bekommen. Es ist der Weg, wie man die falsche Entscheidung industrialisiert.

Der menschliche Beitrag ist der Kurs, nicht die Tastenanschläge

Dies ist der Teil, den die Führungsebene immer wieder falsch versteht.

Wenn Führungskräfte eine kompetente Agentic-Sitzung beobachten, fixieren sie sich oft auf das sichtbare Wunder. Die KI hat Dateien gelesen. Die KI hat eine Architektur vorgeschlagen. Die KI hat Muster in der gesamten Codebasis identifiziert. Deshalb sind Entwickler optional.

Nein. Das sichtbare Wunder ist der billige Teil.

Der wertvolle Teil war, dass ein Entwickler wusste, wie man die Arbeit eingrenzt:

• die architektonische Oberfläche beschränken
• den gegenwärtigen Umfang von zukünftigen Ambitionen trennen
• erkennen, dass UI-Belange die Diskussion kontaminieren würden
• nach einem System fragen, das wachsen kann, ohne so zu tun, als ob alles auf einmal gelöst werden müsste
• beurteilen, ob die Antwort Domänen-Events von Workflow-Unterbau auf eine Weise unterschied, die den Kontakt mit einer echten Codebasis überleben würde

Das sind keine dekorativen Fähigkeiten. Das ist die eigentliche Arbeit.

Ein Chatbot ist keine KI-Strategie gilt aus genau demselben Grund, aus dem eine Programmierdemo keine Software-Strategie ist. Das Werkzeug kann das Denken beschleunigen. Es beseitigt nicht die Notwendigkeit des Denkens. In der Praxis bestraft es die Abwesenheit von Denken schneller. Das ist auch der Grund, warum Spec-Driven-Theater für das Management so attraktiv ist: Es verspricht den emotionalen Komfort von Wasserfall bei den Arbeitskosten eines Chatbots.

Wenn Sie eine Führungskraft sind, die hofft, dass Agentic Coding es Ihnen ermöglicht, die Leute zu entlassen, die Ihre Systeme verstehen, kaufen Sie in Wirklichkeit eine Maschine, die bei unsauberer Rahmensetzung falsche Antworten in industrieller Geschwindigkeit produzieren kann.

Der Entwickler-Beitrag sind bessere Einschränkungen

Es gibt auch eine Falle auf Seiten der Entwickler.

Einige Entwickler hören “Agentic” und nutzen das Werkzeug immer noch wie einen Verkaufsautomaten mit besseren Manieren. Aufgabe rein. Code raus. Vielleicht ein zweiter Prompt, wenn das erste Ergebnis ein bisschen verflucht aussieht.

Das ist keine Zusammenarbeit. Das ist Spielautomaten-Software.

Ein besserer Prompt tut normalerweise ein paar unmissverständliche Dinge:

• benennt genau die Oberfläche, um die es geht
• legt fest, was vorerst nicht im Geltungsbereich liegt
• erklärt, welche zukünftige Erweiterbarkeit wichtig ist und was warten kann
• zeigt auf den ersten echten Anwendungsfall anstelle eines abstrakten Traumsystems
• fordert den Agenten auf, bestehende Muster zu inspizieren, bevor er ein neues empfiehlt

Dieser letzte Punkt ist der, an dem viele schwache Prompts scheitern. Das Modell sollte nicht dafür belohnt werden, eine parallele Architektur zu erfinden, nur weil es das kann. Es sollte gedrängt werden, zuerst nach der zuständigen Abstraktion zu suchen.

Das ist auch der Grund, warum Tests Anweisungen schlagen wichtig ist. Ein guter Prompt gibt die anfängliche Richtung vor. Das Repository, die Tests und die Werkzeuge halten die Sitzung danach ehrlich. Ohne diese Rückkopplungsschleifen wird “Agentic” nur ein respektableres Etikett für Vibe Coding.

Was Agentic Coding tatsächlich ist

Von Marketing-Parfüm befreit, bedeutet Agentic Coding normalerweise fünf Dinge:

1. Ein Mensch rahmt das Problem und die Grenzen ein.
2. Das Modell kann das lokale System durch Dateien, Werkzeuge oder Tests inspizieren.
3. Das Modell schlägt den nächsten Schritt innerhalb dieser Grenze vor oder implementiert ihn.
4. Das Ergebnis wird gegen Code, Tests, Laufzeitverhalten oder andere Beweise geprüft.
5. Der Mensch zieht den Rahmen entweder enger oder akzeptiert das Ergebnis und geht weiter.

Was es nicht bedeutet, ist mystische Autonomie. Es bedeutet nicht, dass das Modell mit Produktverständnis aufgewacht ist. Es bedeutet keine Architektur ohne Kompromisse. Es bedeutet nicht, dass “Mach mir X” ein Ersatz für Softwareentwicklung geworden ist.

Wie Vibe Coding ist keine Softwareentwicklung deutlich macht, kann Agentic Coding Softwareentwicklung sein. Aber nur, wenn die Schleife Grenzen, Beweise und einen Menschen enthält, der den Unterschied zwischen einem plausiblen Entwurf und einer dauerhaften Entscheidung kennt.

Kontinuität wird entworfen, nicht erhofft

Es gibt ein weiteres Detail, das echte Agentic-Arbeit von Prompt-Theater trennt: Kontinuität über Sitzungen hinweg.

Irgendwann kam die offensichtliche Frage auf: Wie stellen Sie sicher, dass das Event-System in zukünftigen Sitzungen fortgeführt wird und nicht in etwas anderes abdriftet?

Die Antwort war nicht: “Vertrauen Sie darauf, dass das Modell sich erinnert.” Das wäre idiotisch.

Die Antwort war, die Entscheidung an drei Orten zu verankern, nicht an einem. Erstens wurde die architektonische Absicht in das Repository-Gedächtnis geschrieben, sodass zukünftige Sitzungen mit demselben Regelwerk beginnen: Gemeinsame Domänen-Events verwenden einen Vertrag, funktionslokale Workflow-Events bleiben lokal, es sei denn, sie werden befördert. In diesem Fall befand sich die Notiz in /memories/repo/nilo-assistant-notes.md.

Zweitens zog der stärkere Schutz in den Code um. Die Event-Form wurde in app/src/main/java/neo/app/events/NiloDomainEvent.java explizit, wo diese Art von Regel hingehört, sobald sie aufhört ein Gedanke zu sein und zur Architektur wird.

Drittens kann die umgebende Implementierung dann dieselbe Grenze durch konkrete Event-Klassen, Listener, Tests und Nutzungsmuster verstärken. An diesem Punkt muss eine zukünftige Sitzung härter arbeiten, um abzutreiben, als um fortzufahren.

Dann machte die nächste Fortsetzungsfrage das Beispiel noch besser: Bevor Sie mit dem Feature fortfahren, ziehen Sie ArchUnit in Betracht. Das Repo hatte es bereits. Könnte es hier helfen?

Auch das ist ein echter Agentic-Schritt. Nicht “bitte weiter implementieren.” Eher: Halt, inspiziere die bestehende architektonische Testoberfläche und verwende die engste Absicherung, die das System bereits versteht.

Die Antwort tat genau das. Sie überprüfte die bestehenden ArchUnit-Tests, stellte fest, dass das Repo bereits Paketgrenzen in diesem Stil durchsetzte, und fügte einen weiteren Architektur-Test hinzu, anstatt ein paralleles Führungsdogma zu erfinden.

Die neue Absicherung tat zwei sehr einfache und sehr nützliche Dinge. Erstens musste alles, was NiloDomainEvent implementiert, ein Java-record sein, was das stille Abdriften zurück zu veränderlichen, Ad-hoc-Event-Klassen blockiert. Zweitens durfte nur der vorgesehene Contact-Activity-Projection-Service direkt von dem Contact-Activity-Repository abhängen, was bedeutet, dass zukünftiger Feature-Code den Event-Fluss nicht beiläufig umgehen und von wo auch immer in den Activity-Store schreiben kann.

Das ist der Unterschied zwischen Kontinuitäts-Theater und Kontinuitäts-Engineering. Das Gedächtnis sagt: “Bitte machen Sie es weiterhin so.” Code sagt: “Das ist die Form.” ArchUnit sagt: “Der Build schlägt fehl, wenn du versuchst clever zu sein.”

Der beste Teil ist, wie unglamourös das Follow-up war. Der erste Test-Runner-Pfad führte den neuen Architektur-Test nicht aus, also täuschte die Sitzung keinen Erfolg vor. Sie versuchte es erneut mit Maven für genau diese Testklasse, bestätigte, dass die Regel tatsächlich lief, und behandelte die Absicherung erst dann als real. So sieht disziplinierte Agentic-Arbeit aus: keine glorreiche Spezifikation, sondern ein ausführbarer Stolperdraht.

Das ist das wahre Muster. Chat-Verlauf ist ein schwaches Gedächtnis. Repository-Gedächtnis ist besser. Code ist noch besser. Tests sind der Teil, der beißt.

Aus diesem Grund verfehlt die spezifikationsgetriebene Religion den Punkt so sehr. Das Problem besteht nicht darin, ein Dokument so detailliert zu schreiben, dass eine gehorsame KI Ihren Plan für immer ausführen kann. Das Problem besteht darin, genug lebendige Struktur zu hinterlassen, damit die nächste Sitzung, ob Mensch oder Maschine, das System durch die richtige Tür betritt.

Das Beispiel zählt, weil es gewöhnlich aussieht

An dem Spring-Event-Beispiel ist nichts Theatralisches. Genau deshalb ist es nützlich.

Keine glänzende UI. Kein roboterhafter Produktmanager. Kein falsches Autonomie-Theater. Nur ein Entwickler, der ein KI-Werkzeug so nutzt, wie eine ernsthafte Person Hebelwirkung nutzt: die Frage eingrenzen, die lokale Wahrheit inspizieren, Kategorien trennen, die nicht gemischt werden sollten, und den Kurs festlegen, bevor Code anfängt sich zu vermehren.

So sieht Agentic Coding aus, wenn es echt ist.

Nicht “Mach mir X”.

Eher: Hier ist der Teil der Realität, den wir berühren, hier ist der Teil, den wir nicht berühren, hier ist die Form, die diese Entscheidung bewahren muss, nun hilf mir, innerhalb dieses Zauns zu denken und zu bauen.

Dieser Workflow sollte Entwickler beruhigen und faule Manager beunruhigen.

Entwickler werden nicht durch einen Chatbot ersetzt, der besser in der Autovervollständigung geworden ist. Sie werden herausgefordert, auf einem Niveau zu arbeiten, auf dem Struktur, Urteilsvermögen und Verifizierung wichtiger sind als Tippen.

Manager kaufen keinen Ersatz für Softwareentwickler. Sie kaufen Hebelwirkung für Softwareentwickler, die bereits eine gute von einer schlechten Grenze unterscheiden können.

Das sind zwei sehr unterschiedliche Geschichten.

Nur eine davon ist wahr.