1975 – Fred Brooks formulierte sein Gesetz: „Adding manpower to a late software project makes it later.“ Diese Erkenntnis aus „The Mythical Man-Month“ gilt bis heute. Matthew Brunelle erinnert in seinem Essay über agentisches Engineering daran. Seine These: Agentisches Engineering ist im Kern die Summe all jener Praktiken, die wir als Softwareentwickler längst hätten befolgen sollen – und die wir unter Zeitdruck gerne weglassen.
Brunelle beobachtet mit einer Mischung aus Erleichterung und Wehmut, wie plötzlich alles darum kreist, dass KI-Agenten saubere Issues bekommen, Dokumentation lesen, Tests bestehen und Code-Reviews durchlaufen. Das sind keine neuen Praktiken – aber sie wurden oft als lästige Pflicht betrachtet, die man unter Zeitdruck weglässt. Jetzt, da die Agenten nicht über das implizite Wissen eines erfahrenen Entwicklers verfügen, werden explizite Beschreibungen, klare Konventionen und vollständige Dokumentation überlebenswichtig.
Du fragst dich vielleicht, warum dein Team so viel Wert auf Issue-Tracking legt, nur weil ein Bot daran hängt. Brunelle bringt es auf den Punkt: Wir halten die Bots auf einem Standard, den wir für uns selbst nie akzeptiert hätten. Wir verlangen von ihnen, dass sie jede Anforderung nachlesen, jeden Test bestehen und jedes Feedback dokumentieren – während wir Menschen uns oft mit vagen Notizen und mündlichen Absprachen zufriedengeben. Das ist der Kern seiner Beobachtung: Agentisches Engineering zwingt uns, die Tugenden zu praktizieren, die wir längst hätten verinnerlichen sollen.
Die Wiederentdeckung der Grundlagen
Brunelle listet Beispiele auf, die zeigen, wie banal die Anforderungen an gute Agenten sind. Ein Issue-Tracker, in dem nicht nur der Titel steht, sondern auch Kontext, Akzeptanzkriterien und der Stand der Arbeit. Dokumentationsstrings an Methoden, die erklären, warum etwas existiert, nicht nur was es tut. Deskriptive Pull Requests, die Änderungen nachvollziehbar machen. Aktuelle Dokumentation, die nicht veraltet ist, sobald sie geschrieben wurde. Sinnvolle Tests – oder überhaupt Tests. Automatisches Linting, das für einheitlichen Stil sorgt. Und die gute alte Gewohnheit, vor der Implementierung einen Entwurf zu besprechen, anstatt direkt loszucoden.
All diese Praktiken werden gemeinhin unter „Best Practices“ zusammengefasst – und meistens bleiben sie genau das: praktisch, aber nicht praktiziert. Der Grund ist simpel: Sie kosten Zeit, und unter Termindruck wird die Doku aufgeschoben, der Test als entbehrlich abgetan, das Review zur Formalie. Wir Menschen können das kompensieren, weil wir einander im Gespräch klären können, was nicht dokumentiert ist. Ein Agent kann das nicht. Er hat nur das, was explizit aufgeschrieben ist – sei es in Form von Kommentaren, Tickets oder Konventionen.
So entsteht eine Ironie: Was wir als lästige Pflicht empfanden, wird zur essenziellen Grundlage für den Einsatz von KI. Plötzlich ist nicht mehr die Frage, ob wir uns an unsere eigenen Regeln halten, sondern ob wir sie überhaupt haben. Brunelle berichtet von einem Kollegen, der nach einem Code-Review ein grundlegendes Prinzip im Team feststellen wollte und es in der Dokumentation verankerte – mit der Begründung, dass alle künftigen Agenten es dann automatisch befolgen würden. Hätte man das vorher getan, hätte man das gesamte Team belehren müssen. Jetzt reicht eine Textdatei.
Warum wir es bisher nicht getan haben
Die Frage liegt nahe: Warum haben wir diese Praktiken nicht längst umgesetzt? Brunelle glaubt, es liegt nicht an fehlendem Wissen, sondern an fehlender Konsequenz. Softwareentwickler automatisieren ihr Handwerk seit Jahrzehnten – von Skripten für Code-Formatierung bis zu Continuous-Integration-Pipelines. Aber was nicht leicht zu automatisieren ist, wie das Verstehen von Kontext oder das Treffen von Abwägungen, wurde gerne auf später verschoben. Es gibt keine CI-Pipeline, die prüft, ob deine Code-Kommentare den Zweck hinreichend erklären. Kein Linter erkennt, dass du das Meeting-Protokoll nicht verschickt hast. Also unterbleibt es.
Hinzu kommt ein psychologischer Effekt: Solange du mit deinen Kollegen interagierst, gleicht ihr Lücken durch Gespräche aus. Du fragst nach, du erklärst, du erinnerst dich. Diese informellen Absprachen sind flexibel und anpassungsfähig – aber sie sind auch flüchtig. Wer nicht in einem Meeting war, hat Pech gehabt. Wer später ins Team stößt, muss alles mühsam rekonstruieren. Die mündliche Überlieferung funktioniert nur so lange, bis jemand den Raum verlässt. Agenten können nicht fragen, wenn etwas fehlt. Sie können nur das tun, was sie gelernt haben.
Das führt zu einer paradoxen Situation: Wir erwarten von KI-Agenten, dass sie sich strikt an Regeln halten, die wir selbst über Bord geworfen haben, sobald es unbequem wurde. Brunelle formuliert es treffend: „Warum halten wir die Bots auf höherem Standard als uns selbst?“ – und zielt damit auf eine tiefere Frage ab: Sollten wir uns nicht an dieselben Standards halten, die wir von unseren Tools verlangen? Vielleicht braucht es manchmal einen externen Anstoß, um gute Gewohnheiten zu etablieren. Agentisches Engineering, so scheint es, ist dieser Anstoß.
Die Grenze des Expliziten: Mētis und Erfahrung
Doch es gibt einen Haken, und Brunelle macht das mit einem Konzept aus James C. Scotts Buch „Seeing Like a State“ deutlich. Scott spricht von „mētis“ – dem praktischen Wissen, das man nur durch langjährige Erfahrung erwirbt. Es ist die Fähigkeit, Regeln im konkreten Kontext angemessen anzuwenden. Ein erfahrener Koch schmeckt, ob die Sauce mehr Salz braucht; ein erfahrener Entwickler sieht, ob eine Architektur überdimensioniert ist. Diese Urteilskraft lässt sich nicht vollständig in Dokumentation oder Regeln fassen. Sie ist lokal, situativ, ständig in Anpassung begriffen.
Agenten fehlt diese mētis. Sie operieren mit explizit formulierten Anweisungen und Mustern aus Trainingsdaten. Das funktioniert gut für klar definierte Probleme – wie das Formatieren von Code, das Befolgen von Lint-Regeln oder das Schreiben von Standard-Doku. Aber sobald eine Situation unvorhergesehene Nuancen aufweist, stoßen sie an Grenzen. Denk an einen Roboter, der einen Baum fällen soll, aber nie gelernt hat, dass der Boden nass sein kann. Er wird nach Plan arbeiten, und das Ergebnis wird unzureichend sein.
Diese Erkenntnis hat praktische Konsequenzen. Wenn wir agentisches Engineering nutzen wollen, müssen wir akzeptieren, dass wir niemals alles in Textform abbilden können. Wir müssen also entscheiden, welche Aspekte wir explizit machen können und welche nicht. Code-Syntax ist gut beschreibbar, stilistische Konventionen auch – aber das Verständnis für den Geschäftskontext, für politische Dynamiken im Team oder für den ungeschriebenen Code of Conduct lässt sich nur schwer kodifizieren. Brunelle weist darauf hin, dass eine schriftliche Regel immer weniger flexibel ist als das Urteilsvermögen eines Menschen. Sie ist aber besser als gar keine Regel.
Das ist der Punkt, an dem viele Projekte scheitern: Sie versuchen, alles explizit zu machen, und enden mit einer Flut von Dokumenten, die niemand liest. Oder sie machen nichts explizit und überfordern die Agenten mit vagen Anweisungen. Die Kunst liegt darin, das richtige Maß zu finden. Dazu gehört, sich bewusst zu machen, dass mētis nicht via Text übertragbar ist. Agenten können sie nicht erwerben – sie können höchstens lernen, typische Muster zu erkennen. Deshalb müssen wir als Entwickler mehr Verantwortung übernehmen und die Lücken schließen, die die Agenten nicht sehen können.
Wenn das System dysfunktional ist, hilft auch kein Agent
Brunelle erzählt von einem Freund, dessen Team eine Abhängigkeit mitten im Sprint änderte, ohne die anderen zu informieren. Der Freund musste einen Agenten verwenden, um ein Refactoring durchzuführen, aber das Ergebnis war nutzlos, weil die Umgebung sich ständig veränderte. Seine Schlussfolgerung: „Wenn agentisches Engineering nur normales Engineering mit Robotern ist, dann gilt auch: Alles, was Engineering schwieriger macht, macht agentisches Engineering noch schwieriger.“ Genau das ist der Kern – und es ist eine Lektion, die weit über den Einsatz von KI hinausreicht.
Wenn dein Team Schwierigkeiten hat, sich abzustimmen, wenn deine Codebasis keine klaren Grenzen hat, wenn deine Spezifikationen unklar sind, dann wird ein Agent diese Probleme nicht lösen. Im Gegenteil, er wird sie vergrößern. Ein Mensch kann improvisieren, wenn sich die Anforderungen kurzfristig ändern. Ein Agent kann das nicht – er ist auf Angaben angewiesen, die sich im Nachhinein als falsch erweisen. Das macht ihn nicht unbrauchbar, aber es macht ihn abhängig von der Qualität deines Prozesses.
Diese Erkenntnis erinnert an das Brooks’sche Gesetz: Mehr Leute machen ein verspätetes Projekt nicht wieder flott, sie machen es schlimmer. Ein KI-Agent ist eine weitere Person – wenn auch eine synthetische. Wenn du ein Team hast, das an der Überlastung scheitert, wirst du mit einem Agenten nicht besser. Du wirst nur eine zusätzliche Quelle von Fehlern und Missverständnissen haben. Deshalb lohnt es sich, die zugrunde liegenden Probleme zu lösen, bevor du automatisierte Helfer einschaltest.
Was bedeutet das für die Praxis?
Brunelles Botschaft ist nicht, dass agentisches Engineering überflüssig ist. Es ist eine Chance, unsere eigenen Defizite zu erkennen und zu beheben. Aber sie wirkt nur, wenn wir bereit sind, die harte Arbeit zu leisten, die wir bisher aufgeschoben haben. Das bedeutet, dass wir unsere Dokumentation endlich ernst nehmen – nicht als lästige Pflicht, sondern als Grundlage für kollaborative Arbeit. Es bedeutet, dass wir klare Konventionen aufstellen und sie automatisch prüfen lassen. Und es bedeutet, dass wir uns bewusst machen, wo die Grenzen des Expliziten liegen – und dass wir diese Lücken durch menschliche Interaktion füllen müssen.
Für dich als Entwickler bedeutet das: Wenn du mit einem Agenten arbeiten willst, fang nicht mit dem Werkzeug an, sondern mit deinem Projekt. Überprüfe, ob deine Issues aussagekräftig sind, ob deine Doku aktuell ist, ob deine Tests den Anforderungen entsprechen. Wenn du feststellst, dass das fehlt, dann ist das ein klares Signal – nicht für den Einsatz von KI, sondern für die Verbesserung deiner eigenen Arbeitsweise. Agenten sind kein Ersatz für Engineering-Disziplin, sie sind ihr vielleicht größter Antreiber.
Die Ironie ist offensichtlich: Wir haben jahrelang über den Mangel an Best Practices geklagt, aber ohne konkrete Notwendigkeit haben wir nichts geändert. Jetzt, wo wir Bots ans Laufen bringen wollen, stellen wir fest, dass wir uns selbst nicht auf dem Niveau bewegen, das wir von unseren Tools erwarten. Vielleicht ist das der eigentliche Gewinn des agentischen Engineerings: Es zwingt uns dazu, die Grundlagen zu beherrschen, bevor wir die nächste Stufe erklimmen. Es ist wie beim Klettern: Du kannst nicht das nächste Seil anbringen, ohne den Standplatz zu sichern. Und wenn du es doch tust, wirst du fallen – egal wie gut der Roboter ist, der dir den Rucksack trägt.
Brunelles Text endet mit einem Beinahe-Zitat von Brooks: „Ein Fake-Mensch ist nicht besser.“ Das ist eine nüchterne Warnung, aber auch eine Bestätigung: Die Prinzipien der Softwareentwicklung sind zeitlos. Sie gelten für Menschen und Maschinen gleichermaßen. Wenn wir das akzeptieren, können wir agentisches Engineering nutzen, um unsere eigene Arbeit zu verbessern – nicht als Ersatz, sondern als Verstärker. Die Werkzeuge ändern sich, aber die Regeln, die gute Arbeit ausmachen, bleiben dieselben.
Quelle: blog.matthewbrunelle.com
