Architekturarbeit im agentischen Zeitalter

Unsere Position. Für uns ist das Generieren von Code gelöst (öffnet in einem neuen Tab). Offen bleibt, was ein Irrtum im Design kostet. Ein Agent optimiert nur dann auf Tiefe im Design, wenn ein Mensch sie benennt, einfordert und im Review prüft (öffnet in einem neuen Tab). Dieses Urteil ist Geschmack, und Geschmack lässt sich nicht komprimieren.

Warum zählt Architektur mehr, wenn Agenten den Code schreiben?

Anthropic sagt in seinem Trendreport für 2026 voraus, dass die KI den Großteil der taktischen Arbeit übernimmt: Code schreiben, debuggen und pflegen. Engineers konzentrieren sich dann auf Architektur, Systemdesign und strategische Entscheidungen darüber, was gebaut wird. Ihr Beitrag zählt vor allem dort, wo sie Systemarchitektur entwerfen, Agenten koordinieren, Qualität bewerten und Probleme zerlegen (2026 Agentic Coding Trends Report).

Befunde aus der Praxis zeigen in dieselbe Richtung. In einer Studie von 2025, die 99 erfahrene Entwickler:innen befragte und 13 bei der Arbeit beobachtete, delegierten die Profis Boilerplate und Scaffolding an den Agenten. Komplexe Geschäftslogik, sicherheitskritischen Code und das Architekturdesign behielten sie selbst in der Hand (Professional Software Developers Don’t Vibe, They Control (öffnet in einem neuen Tab)). Auch das Code Review verschiebt sich: weg vom Lesen Zeile für Zeile, hin zum Review von Mustern und Architektur (Vibe Coding vs. Agentic Engineering).

Die Disziplin beginnt, ihr Wissen in einer Mustersprache festzuhalten. Der verlinkte Artikel stellt Agentic Engineering Patterns als Leitfaden in Kapiteln vor, lose angelehnt an das Buch Design Patterns von 1994. Er beginnt mit einer Beobachtung: Funktionierender erster Code kostet fast nichts mehr. Damit brechen bisherige Intuitionen darüber, wie Einzelne und Teams arbeiten (Writing about Agentic Engineering Patterns (öffnet in einem neuen Tab)). Parallel dazu sammelt ein Community-Katalog 51 Patterns, 10 Anti-Patterns und 15 Hindernisse für KI-gestützte Entwicklung. Er benennt ausdrücklich, wie sie zusammenhängen (Augmented Coding Patterns (öffnet in einem neuen Tab)).

Auch neue Vorschläge für die Struktur von Systemen tauchen auf. Capability-Centric Architecture hält Schichten-, hexagonale und Clean Architecture für gescheitert, sobald Systeme das Spektrum von Embedded bis Enterprise abdecken oder KI-Komponenten aufnehmen. Solche Komponenten bringen laut dem Artikel eigene Infrastruktur, Versionierung und Inferenz-Eigenschaften mit. Der Vorschlag setzt Systeme deshalb aus Capabilities zusammen, jede ein Kern aus Essence, Realization und Adaptation. Capabilities verbinden sich über Verträge, die festlegen, was sie bereitstellen, was sie brauchen und über welche Protokolle sie sprechen. So kann sich jede Capability unabhängig weiterentwickeln (Capability-Centric Architecture (öffnet in einem neuen Tab)).

Drei Mechanismen setzen das um:

• Eine Capability Registry erzwingt die Regeln mechanisch. Sie lehnt jede Bindung ab, die eine zirkuläre Abhängigkeit erzeugen würde, und erzwingt einen Umbau mit saubereren Grenzen.
• Evolution Envelopes machen Versionierung, Deprecation und Migration pro Capability zu einem vollwertigen Mechanismus.
• Efficiency Gradients erlauben innerhalb derselben Capability beides: Der kritische Pfad läuft direkt auf Bare Metal, der Storage-Pfad voll abstrahiert (Capability-Centric Architecture (öffnet in einem neuen Tab)).

Für Produkte mit eingebetteten Agenten setzt der Leitfaden zu agent-nativen Architekturen zwei Grundprinzipien. Parität heißt: Was Nutzer:innen über die UI tun können, kann der Agent über Tools tun. Granularität heißt: Tools sind atomare Primitive, Features sind Ergebnisse, die in Prompts beschrieben werden. Daraus leitet der Leitfaden eine allgemeine Designregel ab. Entwerft für das, worüber Agenten schlussfolgern können, in der Praxis also Strukturen, die ein Mensch schon beim Ansehen versteht (Every - Agent-native Architectures (öffnet in einem neuen Tab)).

Die Aufgabe des Menschen ist in dieser Aufteilung Architektur, nicht Tippen. Der Talk von Modern Software Engineering sieht die eigentliche Grenze im Kopf, nicht in der Mechanik. Wie schnell agentische Entwicklung vorankommt, hängt davon ab, wie schnell man das Problem kennenlernt und die Komplexität beherrscht. Die Grenze liegt nicht darin, wie schnell das Modell gültige Syntax ausgibt. Ohne ein tragfähiges mentales Modell des Designs hilft euch der Agent vor allem, schneller ein Chaos anzurichten (Modern Software Engineering (YouTube) (öffnet in einem neuen Tab)).

Manche Teams ziehen diese Arbeitsteilung kompromisslos durch. Das Team von System Initiative liefert eine Open-Source-CLI aus, bei der Menschen nur Designentscheidungen, Randbedingungen und Invarianten verantworten. Jede Zeile Code schreiben Agenten, und jeden Pull Request, den ein Mensch geschrieben hat, löscht das Team. Ihre Zusammenfassung in einem Satz: Intent ist die neue Architektur, und Kontext ist der neue Code (If humans architect the system, the AI writes the code (YouTube) (öffnet in einem neuen Tab)).

Eine Blogserie über regenerative Software treibt diese Umkehrung weiter, als wir es tun würden, bis zu einer Definition. Werden die Implementierungen eines Systems neu generiert statt gepflegt, bestimmt allein das Unlöschbare seine Architektur. Übrig bleiben vier Primitive, die sich nicht weiter reduzieren lassen (The Phoenix Primitives (öffnet in einem neuen Tab), April 2026):

1. Verhaltensspezifikationen. Die Serie grenzt sie über die Richtung von Dokumentation ab. Herkömmliche Doku beschreibt Code, der schon existiert. Eine regenerative Spezifikation ist dagegen ein generativer Input, aus dem die Implementierung entsteht. Laut der Serie hält genau das beide davon ab, auseinanderzulaufen.
2. Evaluationen. Das sind ausführbare Verträge, die jede Implementierung erfüllen muss.
3. Kontextgrenzen. Gemeint sind die API-Verträge und Event-Schemas, an denen Regenerationseinheiten aufeinandertreffen. Daraus folgt, wohin das Handwerk wandert. Ist die interne Code-Struktur wegwerfbar, zeigt sich Architekturkönnen darin, wo man die Grenzen zwischen unabhängig regenerierten Teilen setzt. Wie der Code innerhalb dieser Teile angeordnet ist, gehört nicht mehr dazu.
4. Provenienznachweise. Diffs auf Zeilenebene sagen wenig, wenn die Zeilen generiert wurden. Festhalten lohnt sich deshalb die Kausalität: Welche Version der Spezifikation hat eine Implementierung erzeugt, welche Evaluation hat sie freigegeben, und was hat die Regeneration ausgelöst (The Phoenix Primitives (öffnet in einem neuen Tab), April 2026)?

Die übrige Serie arbeitet dieselbe These in Design-Heuristiken ein. Dazu gehören ein Löschtest, mit dem ihr ein System bewertet, und eine Neufassung von “keep things small” als “safe to delete”. Ihr Gegengewicht liefert die Serie gleich mit. Reife Implementierungen sammeln in ihren Validierungen und ihrer Fehlerbehandlung hart erarbeitete Lektionen an, die keine Organisation irgendwo aufgeschrieben hat. Genau diese Lektionen verwirft eine Regeneration (The Phoenix Architecture (öffnet in einem neuen Tab), Dezember 2025 bis August 2026).

Verwandte Seiten

• Architektur agentischer Systeme: dieselben Designfragen, wenn Agenten innerhalb des Systems laufen.
• Specs, Tests und Kontext: die Artefakte, die Intent und Randbedingungen zum Agenten tragen.
• Architekturprinzipien: die Prinzipien, an denen ein Mensch ein Design weiterhin im Review misst.
• Engineering-Philosophie: warum Urteilsvermögen knapp bleibt, wenn Wissen über Implementierung billig wird.
• Senior Engineering Skills: die Fähigkeiten jenseits des Programmierens, auf die Architekturarbeit jetzt baut.

Quellen

Artikel

• Agent-native Architectures (öffnet in einem neuen Tab) - Leitfaden von Every, der Parität und Granularität als Grundprinzipien für Produkte setzt, deren Agenten über dieselben Tools handeln wie die Nutzer:innen.
• Augmented Coding Patterns (öffnet in einem neuen Tab) - Community-Katalog mit 51 Patterns, 10 Anti-Patterns und 15 Hindernissen für KI-gestützte Entwicklung, mit ausdrücklich benannten Zusammenhängen.
• Capability-Centric Architecture (öffnet in einem neuen Tab) - Blogartikel, der Systeme aus Capabilities vorschlägt, verbunden über Verträge, als Alternative zu Schichten-, hexagonaler und Clean Architecture.
• The Phoenix Architecture (öffnet in einem neuen Tab) - Blogserie über regenerative Software, mit Design-Heuristiken wie einem Löschtest und den Lektionen, die eine Regeneration verwirft.
• The Phoenix Primitives (öffnet in einem neuen Tab) - Artikel, der die Architektur eines regenerierten Systems über vier Primitive definiert: Spezifikationen, Evaluationen, Kontextgrenzen und Provenienznachweise.
• Writing about Agentic Engineering Patterns (öffnet in einem neuen Tab) - Blogpost, der einen Leitfaden in Kapiteln zu Agentic Engineering Patterns vorstellt, lose angelehnt an das Buch Design Patterns von 1994.

Posts

• An agent will not optimize for depth (öffnet in einem neuen Tab) - LinkedIn-Post mit der These, dass Tiefe im Design nur entsteht, wenn ein Mensch sie benennt, einfordert und im Review prüft.
• Code generation is solved (öffnet in einem neuen Tab) - LinkedIn-Post mit der These, dass nach generiertem Code nur noch zählt, was ein Irrtum im Design kostet.

Talks und Videos

• The Humans Architect the System, the AI Writes the Code (öffnet in einem neuen Tab) - Talk von AI Native Dev auf der AI Native DevCon im Juni 2026 über ein Team, in dem Menschen Design und Randbedingungen verantworten und Agenten jede Zeile schreiben.
• This Mental Model Changed How I Design Software FOREVER (öffnet in einem neuen Tab) - Video von Modern Software Engineering mit der These, dass agentisches Tempo davon abhängt, wie schnell ihr das Problem versteht, nicht vom Code-Ausstoß.