Architektur statt Code: Was beim Arbeiten mit AI-Agents wirklich zaehlt

Vier unterschiedliche Stimmen haben in kurzer Zeit unabhaengig voneinander dieselbe Beobachtung formuliert: Wer mit AI-Agents arbeitet, braucht primaer kein besseres Prompt-Engineering. Er braucht Architektur-Denken.

Synthese: Vier Perspektiven, eine Richtung

Die Beitraege von Matt Webb, Thorsten Ball, John Regehr und dem Stanford JAI-Team klingen auf den ersten Blick unterschiedlich. Webb schreibt ueber das Gefuehl beim Viben, Ball fragt nach Wissensverteilung, Regehr denkt in Constraints, Stanford denkt in Sandboxen. Zusammen ergeben sie ein konsistentes Bild: Ein Agent ist kein besseres Autocomplete. Er ist ein ausfuehrendes System, und wer ihn gut einsetzen will, denkt wie ein System-Architekt.

Matt Webb: Architektur-Denken als primaere Faehigkeit

Matt Webb beschreibt seine Erfahrung mit Agent-gestuetztem Coding so:

"While I'm vibing, I am looking at lines of code less than ever before, and thinking about architecture more than ever before."

Der Punkt ist nicht, dass Code unwichtig wird. Der Punkt ist, dass Agents Details schleifen koennen, Architektur aber nicht. Wer einen Agent loslegt, ohne vorher ueber Modulschnitte, Verantwortlichkeiten und Erweiterbarkeit nachgedacht zu haben, bekommt schnell funktionierenden Code, der schwer zu aendern ist. Agents optimieren fuer "laeuft jetzt", nicht fuer "laesst sich in drei Monaten anpassen".

Die Konsequenz: Vor dem Prompten kommt das Denken ueber Struktur. Welche Abhaengigkeiten will ich? Wo sind die Grenzen zwischen Modulen? Welche Invarianten soll das System halten?

Thorsten Ball: Wissensverteilung als Schluessel

Thorsten Ball stellt in seinem Newsletter eine einfache, aber sehr praktische Frage: "Where is the knowledge?"

Ein Agent kann gut arbeiten, wenn das relevante Wissen an einem von drei Orten steckt:

• Im Prompt: Explizite Anweisungen, Kontext, Beispiele
• In der Codebase: Gut benannte Funktionen, lesbare Struktur, aussagekraeftige Tests
• Im Training: Weit verbreitete Patterns, bekannte Libraries, Standardloesungen

Probleme entstehen bei Wissensluecken. Wenn ein System auf einem internen Standard basiert, der nirgendwo dokumentiert ist, kann der Agent ihn nicht kennen. Wenn eine Codebase schwer zu lesen ist, fehlt dem Agent der Kontext. Das ist keine KI-Schwaeche, sondern eine Architektur-Aufgabe: Wissen so ablegen, dass ein Agent es findet.

Praktisch bedeutet das: ADRs schreiben, Konventionen dokumentieren, Tests als ausfuehrbare Spezifikation verwenden.

John Regehr: Constraints und Oracles statt Freiheit

John Regehr praegt den Begriff "Zero-Degree-of-Freedom LLM Coding". Die These: Agents arbeiten besser, wenn sie weniger Freiheitsgrade haben.

Das klingt kontraintuitiv, ist aber nachvollziehbar. Ein Agent mit unbegrenzter Freiheit kann jedes Problem auf jede Weise loesen, einschliesslich schlechter Wege. Wer dem Agent sagt, was er nicht tun darf und womit er seinen Output pruefen soll, bekommt zuverlaessigere Ergebnisse.

Regehr nennt "Executable Oracles": Mechanismen, die dem Agent Rueckmeldung geben, ob seine Loesung korrekt ist. Tests sind das naheliegendste Beispiel. Eine gute Testsuite zieht den Loesungsraum zusammen. Statt unendlich vieler moeglicher Implementierungen bleiben nur die uebrig, die alle Tests bestehen.

Die praktische Konsequenz: Erst Tests schreiben, dann Agent loslassen. Und Constraints explizit machen, nicht implizit voraussetzen.

Stanford JAI: Agents brauchen sichere Execution-Umgebungen

Das Stanford JAI-Team beschreibt es pragmatisch: "Go hard on agents, not on your filesystem."

Agents, die in einer Produktionsumgebung ausgefuehrt werden, koennen dauerhaften Schaden anrichten. Dateien loeschen, Konfigurationen ueberschreiben, Abhaengigkeiten aendern. Die Loesung ist strukturell, nicht disziplinaer: Agents gehoeren in Sandboxen. Isolierte Execution-Umgebungen, in denen sie experimentieren koennen, ohne irreversible Nebenwirkungen zu erzeugen.

Das ist eine Infrastruktur-Entscheidung, keine Prompt-Entscheidung. Wer Agents produktiv einsetzen will, plant die Execution-Umgebung genauso sorgfaeltig wie den Agent selbst.

Praxis-Takeaway

Was Entwickler heute konkret tun koennen:

Vor dem Agent-Einsatz: - Modul- und Schichtgrenzen explizit skizzieren, bevor der erste Prompt geschrieben wird - Domaenen-spezifisches Wissen dokumentieren: Was weiss ein neuer Kollege nicht, was der Agent auch nicht wissen kann? - Testabdeckung fuer den Bereich pruefen, in dem der Agent arbeiten soll

Waehrend der Agent-Arbeit: - Agents auf kleine, klar abgegrenzte Aufgaben beschraenken - Constraints explizit im Prompt formulieren ("Veraendere keine bestehenden Interfaces") - Ergebnisse gegen Tests pruefen lassen, nicht nur manuell reviewen

Umgebung: - Lokale Sandbox oder Branch verwenden, nie direkt auf produktivem Code - Dateisystem-Zugriff des Agents auf das noetwaendige Minimum begrenzen

Die uebergeordnete Botschaft: Gute Agent-Arbeit ist Architektur-Arbeit. Die Zeit, die man in Struktur, Wissen und Constraints investiert, zahlt sich beim Agent-Einsatz unmittelbar aus.

Quellen

• Matt Webb via Simon Willison: Vibing while thinking about architecture
• Thorsten Ball, Register Spill: Joy and Curiosity #80 -- "Where is the knowledge?"
• John Regehr: Zero-Degree-of-Freedom LLM Coding (Constraints und Executable Oracles)
• Stanford JAI: Go hard on agents, not on your filesystem