Ohne Spec, Leitplanken und Urteilsvermögen produzieren Agenten konsistenten Unsinn — schnell.
Du hast den Agenten angesetzt. Der Code kommt schnell, sieht ordentlich aus, kompiliert. Und nach drei Wochen merkst du, dass nichts davon zu deiner Architektur passt. Falsche Schichten, ignorierte Konventionen, Logik an Stellen, die niemand vorgesehen hat. Das ist kein Bug im Agenten — das ist ein Kontextproblem. Und es ist lösbar.
Der Agent baut, was du ihm zeigst — nicht, was du meinst
Coding Agents sind Wahrscheinlichkeitsmaschinen. Sie synthetisieren Code aus dem, was in ihrem Kontext steht: dein Prompt, deine Doku, deine bisherigen Dateien. Was fehlt, wird halluziniert oder aus Trainingsdaten ergänzt — mit Mustern, die nichts mit deiner Architektur zu tun haben.
Das erklärt das klassische Muster: Greenfield funktioniert gut. Leere Codebasis, klare Aufgabe, der Agent liefert. Sobald gewachsener Code ins Spiel kommt — jahrelange Konventionen, implizite Entscheidungen, historisch gewachsene Strukturen — bricht die Qualität ein. Nicht weil der Agent schlechter geworden ist. Sondern weil der Kontext zu dünn ist.
Zwei Fehler passieren dabei besonders häufig. Der erste: Vibe Coding. Kein Plan, kein Rahmen, einfach drauflos. Der Agent macht schon. Der zweite: Spec-Inflation als Gegenmittel. Alles wird dokumentiert, jede Entscheidung ausformuliert, jede Spalte vorab benannt — bis die Spec so groß ist, dass sie niemand mehr liest und kein Kontextfenster sie fasst. Beides produziert schlechten Output, nur aus verschiedenen Richtungen.
Was fehlt, ist kein mehr oder weniger. Was fehlt, ist die richtige Art von Kontrolle.
Spec ist kein Dokument — Spec ist Kontext für den Agenten
Der mentale Shift ist einfach, aber nicht trivial: Eine Spec ist nicht für Menschen geschrieben. Sie ist der Input, mit dem ein Agent entscheidet. Das verändert, was rein muss und was nicht.
Menschliche Doku erklärt. Agenten-Doku lenkt. Ein Mensch versteht aus dem Kontext, was „clean architecture“ in deinem Projekt bedeutet. Ein Agent tut das nur, wenn es explizit kodiert ist — als Regel, als Beispiel, als maschinenprüfbare Bedingung.
Wer Specs schreibt, die für Menschen gedacht sind, bekommt Agenten-Output, der für Menschen aussieht — aber architektonisch falsch ist.
Der Denkrahmen, der aus diesem Shift folgt: Architekturkontrolle ist keine Aufgabe nach dem Commit. Sie beginnt mit dem, was du dem Agenten gibst — und endet mit automatisierten Mechanismen, die sein Ergebnis prüfen. Spec, Doku und Feedback-Schleifen sind keine separaten Themen. Sie sind ein System.
Vier Ebenen, auf denen du den Agenten in die Spur bringst
Spec schreiben, die wirklich lenkt
Speaker: Roman Stranghöner & Torsten van Lessen
Zwischen Vibe Coding und Spec-Inflation liegt ein schmales Fenster, in dem Agenten wirklich funktionieren. Das Problem: Dieses Fenster ist nicht intuitiv — es erfordert ein anderes Schreiben.
Stranghöner und van Lessen arbeiten sich an genau diesem Fenster ab. Was muss in eine Spec, damit der Agent das Richtige baut? Welche Teile lenken produktiv, welche engen unnötig ein oder primen das Modell auf eine Lösung, die niemand wollte? Und wie sieht Architekturdoku aus, die nicht für Menschen geschrieben ist, sondern für Agenten — kompakt genug für den Kontext, präzise genug zum Lenken?
Der entscheidende Schritt: Specs und Doku „harness-ready“ zu schreiben bedeutet, aus einzelnen Aussagen direkt maschinenprüfbare Regeln ableiten zu können — ArchUnit-Regeln, Linter-Konfigurationen, Hooks.
Leitplanken bauen, die der Agent nicht ignorieren kann
Speaker: Alexander Kaserbacher
Selbst eine gute Spec ist kein Garant. Agenten weichen ab, kombinieren Muster unerwartet, interpretieren Konventionen kreativ. Was fehlt, ist eine Umgebung, die das verhindert — nicht durch mehr Anweisung, sondern durch automatisierte Prüfung.
Kaserbacher zeigt, wie Harness Engineering in der Praxis aussieht: Architekturziele als maschinenprüfbare Regeln formulieren — Guides steuern den Agenten vor der Aktion, Sensoren prüfen das Ergebnis danach. Im Workshop entstehen drei konkrete Komponenten: eine Architektur-Fitness-Function als automatisierter Test, maschinenlesbare Projektinstruktionen, die Konventionen kodieren, und ein Feedback-Hook, der Fehler direkt nach jeder Code-Änderung zurückmeldet.
Du verlässt den Workshop mit einem Projekt, das Architekturziele nicht dokumentiert, sondern kontinuierlich durchsetzt.
Wo Agenten bei bestehenden Systemen an ihre Grenzen stoßen
Speaker: Markus Harrer
Die Lücke zwischen Greenfield-Erfolg und Brownfield-Scheitern ist kein Zufall. Sie ist strukturell. Gewachsene Systeme enthalten Kontext, der nirgendwo explizit steht — implizite Konventionen, historische Entscheidungen, fachliche Logik, die sich über Jahre in Strukturen eingeschrieben hat. Agenten sehen Dateien. Den Rest müssen sie raten.
Harrer blickt hinter die Kulissen: Wie arbeiten Agenten wie Claude Code oder Codex CLI wirklich — und warum scheitern sie reproduzierbar genau dort, wo das System am komplexesten ist? Anhand konkreter Techniken und Heuristiken lernen Teilnehmende, sinnvolle Einsatzgebiete für agentische Ansätze bei der Softwaremodernisierung zu identifizieren — oder bewusst davon Abstand zu nehmen.
Die Entscheidung „Agent, klassisches Refactoring oder hybride Strategie“ trifft danach niemand mehr aus dem Bauch.
Was KI in der Architekturarbeit kann — und was nicht
Speaker: Lars Röwekamp
Die eigentliche Frage ist nicht „ersetzt KI Softwarearchitekt:innen?“ Die Frage ist: Welche Architekturaufgaben lassen sich sinnvoll delegieren — und wo ist menschliches Urteil unverzichtbar?
Röwekamp evaluiert gemeinsam mit den Teilnehmenden typische Aufgabenfelder von Softwarearchitekt:innen: Dokumentation, Entscheidungsvorbereitung, Musteranalyse, Trade-off-Bewertung. Welche davon lassen sich KI-gestützt beschleunigen? Wo produziert KI plausibel klingenden, aber gefährlich falschen Output? Verschiedene KI-Werkzeuge werden direkt ausprobiert und ihre Ergebnisqualität bewertet.
Das Ergebnis: ein konkretes Bild davon, wo KI deinen Architekturalltag entlastet — und wo du besser selbst entscheidest.
Was du heute tun kannst — ohne Workshop-Besuch
Prüfe deine aktuelle Architekturdoku auf Agent-Tauglichkeit. Stell dir die Frage: Würde ein Agent aus diesem Text die richtigen Entscheidungen ableiten — oder rät er? Fehlende Explizitheit bei Schichtgrenzen, Namenskonventionen und Abhängigkeitsregeln ist fast immer der erste Schwachpunkt.
Schreib eine einzige Architektur-Fitness-Function. Suche ein Architekturziel, das du heute nur im Kopf durchsetzt — und formuliere es als automatisierten Test. ArchUnit, NetArchTest oder ein simples Skript reichen für den Anfang. Das Ziel ist nicht Vollständigkeit, sondern das erste maschinenprüfbare Artefakt.
Starte mit einem Brownfield-Mapping, bevor du Agenten ansetzt. Dokumentiere explizit, welche Teile des Systems implizites Fachwissen enthalten. Diese Bereiche sind Hochrisiko-Zonen für agentisches Vorgehen — sie brauchen entweder deutlich mehr Kontext oder klassisches Refactoring.
Der Agent ist nicht das Problem. Der fehlende Rahmen ist es.
Coding Agents sind kein Risiko, das man managen muss. Sie sind ein Werkzeug, das einen Rahmen braucht — wie jedes andere auch. Spec, Harness und Urteilsvermögen darüber, wann Agenten helfen und wann nicht: Das ist keine Absicherungsstrategie. Das ist die eigentliche Architekturarbeit in einer agentic Welt.
Die Architekt:innen, die das jetzt verstehen, hören nicht auf zu entscheiden — sie entscheiden auf einer anderen Ebene. Sie bauen keine Features. Sie bauen die Umgebung, in der Agenten gute Features bauen können.
Architekturkontrolle verlagert sich nicht weg von Menschen. Sie verlagert sich früher — in Spec, Kontext und maschinenprüfbare Regeln.
Wer Spec Writing, Harness Engineering und die Grenzen von Agenten hands-on vertiefen will — die Workshops von Stranghöner & van Lessen, Kaserbacher, Harrer und Röwekamp beim Software Architecture Summit bieten genau das. Berlin, 12.–16. Oktober 2026. → softwarearchitektur.de
Key Takeaways
Coding Agents produzieren schlechten Output nicht wegen mangelnder Intelligenz, sondern wegen mangelndem Kontext — das ist ein lösbares Designproblem.
Spec ist kein Dokument für Menschen. Sie ist Kontext für einen Agenten — und muss so geschrieben sein, dass sie lenkt, nicht erklärt.
Harness Engineering macht Architekturziele maschinenprüfbar: Guides vor der Aktion, Sensoren danach.
Gewachsene Systeme sind strukturell schwieriger für Agenten als Greenfield — weil implizites Wissen nicht sichtbar ist. Das erfordert Strategie, keine Automatisierung.
Die Frage „ersetzt KI Architekt:innen?“ ist falsch. Die richtige: Welche Architekturaufgaben lassen sich delegieren — und welche nicht?
🔍 FAQ
1. Was ist der Unterschied zwischen Vibe Coding und Spec-Driven Development mit Agenten?
Vibe Coding bedeutet: kein expliziter Rahmen, der Agent interpretiert frei. Spec-Driven Development gibt dem Agenten strukturierten Kontext — Architekturentscheidungen, Konventionen, Randbedingungen. Das Problem: Zu wenig Spec führt zu inkonsistenter Architektur. Zu viel überfüllt den Kontext und macht die Spec unwirksam. Die Kunst liegt in der Dichte: präzise genug zum Lenken, kompakt genug für das Kontextfenster.
2. Was ist Harness Engineering in der Softwarearchitektur?
Harness Engineering bezeichnet den Aufbau einer Umgebung, in der Coding Agents gegen maschinenprüfbare Architekturregeln arbeiten. Ein Harness besteht typischerweise aus drei Elementen: Guides, die den Agenten vor der Aktion steuern; automatisierten Tests (Fitness Functions), die das Ergebnis prüfen; und Feedback-Hooks, die Fehler direkt zurückmelden. Ziel ist es, Architekturziele kontinuierlich durchzusetzen — nicht nur zu dokumentieren.
3. Warum scheitern Coding Agents bei bestehenden Systemen, obwohl sie bei neuen Projekten gut funktionieren?
Gewachsene Systeme enthalten Wissen, das nicht in Dateien steht: historische Entscheidungen, implizite Konventionen, fachliche Logik, die sich strukturell manifestiert hat. Agenten sehen nur, was explizit im Kontext ist. Was fehlt, wird aus Trainingsdaten ergänzt — mit Mustern, die nichts mit dem jeweiligen System zu tun haben. Das ist kein Bug, sondern ein strukturelles Merkmal, das expliziten Kontext-Aufbau erfordert.
4. Können KI-Tools Architekturentscheidungen vollständig übernehmen?
Nein — und das ist keine Einschränkung, die sich mit besseren Modellen auflöst. Architekturentscheidungen erfordern Trade-off-Bewertung unter Unsicherheit, Verständnis von Organisationskontexten und Abwägungen zwischen technischen und nicht-technischen Faktoren. KI kann dabei unterstützen: Optionen aufzeigen, Muster analysieren, Dokumentation erzeugen. Die Entscheidung selbst bleibt eine menschliche Aufgabe — weil sie Konsequenzen trägt, die kein Modell verantwortet.
5. Wie fange ich mit Harness Engineering an, ohne alles auf einmal umzubauen?
Mit einer einzigen Architektur-Fitness-Function. Wähle ein Architekturziel, das du heute nur manuell durchsetzt — eine Schichtgrenze, eine Abhängigkeitsregel, eine Namenskonvention. Formuliere es als automatisierten Test mit ArchUnit oder einem einfachen Skript. Koppele diesen Test an deinen CI-Prozess oder als Feedback-Hook für deinen Agenten. Das erste maschinenprüfbare Artefakt ist der Einstieg — nicht die vollständige Lösung.
