Bleibe informiert
Unser Newsletter informiert dich regelmäßig über die Module, Trainer:innen, Specials und alles andere Wissenswerte zum Thema Software Architecture.
Coding Agents brauchen mehr Zusammenarbeit – nicht weniger.
Coding Agents verändern nicht nur, wie Software entsteht, sondern auch, wie Teams zusammenarbeiten und Architektur gestalten. Damit gewinnen zentrale Ideen aus Agile und DDD neue Aktualität. Die Software Architecture Camps greifen diese Entwicklung auf: Architekturhandwerk, Fachlichkeit, kollaboratives Arbeiten und Agentic Engineering rücken näher zusammen.
„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.“ Als das Agile Manifesto diesen Satz 2001 formulierte, war die Stoßrichtung klar: Gute Software entsteht nicht allein durch bessere Prozesse und bessere Werkzeuge. Entscheidend sind die Menschen und die Art, wie sie miteinander arbeiten.
25 Jahre später bekommt dieser Satz eine neue Gegenspielerin.
Coding Agents versprechen Entwickler:innen eine Form von Selbständigkeit, die es so bisher nicht gab. Wer früher mit einem Stacktrace zum Kollegen gegangen wäre, fragt heute Claude. Wer eine fremde API verstehen muss, lässt sie sich vom Agenten erklären. Wer eine Idee ausprobieren will, kann innerhalb weniger Stunden Software erzeugen, für die früher mehrere Personen nötig gewesen wären.
Softwarearchitekt Michael Seel beobachtet deshalb ein „Lone-Wolf-Problem“: Entwickler:innen verbringen immer mehr Zeit im Zwiegespräch mit ihren Agents. Menschliche Berührungspunkte verschwinden. Und selbst dort, wo weiterhin Teams existieren, kann agentische Entwicklung dazu führen, dass jeder mit seinem eigenen Agenten in seiner eigenen Ecke arbeitet.
War „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“ also ein Satz für eine andere Epoche? Nein, sagt Seel. Genau das Gegenteil ist der Fall.
Wenn lokale Produktivität zum Teamproblem wird
Welche Folgen Coding Agents für die Zusammenarbeit in Entwicklungsteams haben, diskutierten Michael Seel (INNOQ) und Martin Günther (Martin Günther Consulting) in einem Fullstack-Liveevent auf entwickler.de.
Seel beschrieb dort, wie schnell der Produktivitätsschub einzelner Entwickler:innen in ein Problem für das Gesamtsystem kippen kann: „Ich habe Fälle erlebt, in denen Entwickler 50 Merge Requests in einer Woche erzeugen – und niemand kommt mit dem Review hinterher, nichts ist abgenommen.“
Für ihn ist das ein Warnsignal: „Beim agentischen Arbeiten entsteht schnell eine Illusion von Produktivität.“ Der einzelne Entwickler erzeugt mehr Output, doch Reviews, fachliche Entscheidungen und Abnahmen werden dadurch nicht automatisch schneller. „Lokal steigt die Geschwindigkeit, aber auf Ebene der Organisation entsteht dadurch zunächst nur mehr Reibung.“
Das erinnert an eine alte Einsicht aus Eliyahu Goldratts Managementklassiker The Goal: Der Durchsatz eines Systems steigt nicht automatisch, nur weil ein einzelner Prozessschritt schneller wird. Der Engpass wandert, verschwindet aber nicht.
Auf Agentic Engineering übertragen heißt das: Wenn die Implementierung plötzlich massiv beschleunigt wird, verlagert sich der Flaschenhals zu Review, fachlicher Klärung, Architekturentscheidungen und Abnahme. Mehr Code generiert dann nicht automatisch mehr Wert. Im ungünstigsten Fall wächst vor allem der Stapel an Arbeit, die auf Entscheidungen wartet.
Seel folgert: Agentisches Entwickeln braucht Strukturen, in denen fachliche und technische Entscheidungen in einem Takt fallen können, der zur Geschwindigkeit der Agents passt. Die Lösung liegt nicht in noch autonomeren Einzelentwicklern, sondern in anders zusammengesetzten Teams.
Das agentische Mini-Team: Fachlichkeit und Technik in einem Raum
Als Gegenmodell zum Lone Wolf setzt Seel das kleine, cross-funktionale Team. Drei bis vier Menschen, davon ein bis zwei mit fachlicher und ein bis zwei mit technischer Perspektive. Wichtig ist, dass das Team sowohl das Wissen als auch die Vollmacht besitzt, die nächsten Schritte gemeinsam zu entscheiden.
Das klingt zunächst wenig revolutionär. Cross-funktionale Teams gehören seit Jahrzehnten zum Vokabular von Agile und Domain-driven Design. Neu ist nicht die Idee, sondern die Konsequenz, mit der sie unter agentischen Bedingungen gelebt werden muss.
Im klassischen Übergabemodell kann die Fachseite Anforderungen formulieren, die Entwicklung übernimmt und einige Wochen später folgt die Abnahme. Wenn ein Coding Agent nun aus einer Anforderung innerhalb weniger Stunden lauffähige Software macht, gerät dieses Modell unter Druck. Zwei Stunden Implementierungszeit helfen wenig, wenn die nächste fachliche Rückmeldung zwei Wochen dauert.
Deshalb bleibt die Fachseite in Seels Mini-Team während der Entwicklung dabei. Ein Agent erzeugt einen ersten Stand, Entwickler und Domänenexperten schauen gemeinsam darauf, entdecken falsche Annahmen, treffen Entscheidungen und schicken die nächste Iteration los. Aus der Übergabe wird ein gemeinsamer Arbeitsprozess.
Damit bekommt auch Domain-driven Design eine neue Aktualität. Was dort seit Langem mit Ubiquitous Language, Collaborative Modelling oder der engen Zusammenarbeit mit Domain Experts angelegt ist, wird im Agentic Engineering unmittelbar wirksam: Fachwissen darf nicht nur zu Beginn als Spezifikation oder am Ende in Form einer Abnahme auf die Software treffen. Es muss während ihrer Entstehung verfügbar sein.
Je schneller Agents implementieren, desto enger müssen Techniker mit denen zusammenarbeiten, die entscheiden können, was überhaupt implementiert werden soll.
Gute Friktion: Zusammenarbeit muss gestaltet werden
Doch das richtige Team zusammenzustellen genügt noch nicht. Drei oder vier Menschen in einen Raum zu setzen, garantiert weder gemeinsames Verständnis noch gute Entscheidungen.
Hier setzt Martin Günther an. In seinem Vortrag über Facilitation in Architektur- und Entwicklungsteams beschreibt er ein vertrautes Muster: Acht Personen diskutieren eine schwierige Entscheidung. Nach zwanzig Minuten sind die wesentlichen Argumente genannt, nach vierzig Minuten dreht sich die Diskussion im Kreis. Drei Personen haben gesprochen, fünf kaum oder gar nicht. Am Ende wird die Entscheidung vertagt.
„Der Verlust in dem Fall [ist] gar nicht so sehr die Stunde, sondern das Wissen, das im Raum war und nicht in die Entscheidung eingegangen ist“, sagt Günther.
Für agentische Teams ist das kritisch. Wenn Fachbereich, Entwicklung und Architektur enger zusammenrücken, muss relevantes Wissen tatsächlich in die Entscheidung gelangen, rechtzeitig für die nächste Iteration.
Dabei geht es nicht darum, Reibung zu vermeiden – im Gegenteil: Widerspruch, Rückfragen und unterschiedliche Perspektiven können kritische Annahmen sichtbar machen und verhindern, dass ein Team mit hoher Geschwindigkeit in die falsche Richtung läuft. Offene Diskussionen allein leisten das nicht, betont Günther: „Oft gibt es zwar die Möglichkeit, sich zu beteiligen, aber es fehlen Leitplanken, die die Gruppe zu einem gemeinsamen guten Ergebnis führen.“
Solche Leitplanken schafft Günther durch bewusst gestaltete Interaktionsstrukturen: kleinere Gesprächsgruppen, Timeboxing, Visualisierung, Collaborative Modelling oder Formate, in denen zunächst jeder für sich nachdenkt, bevor gemeinsam entschieden wird.
Gute Friktion entsteht also nicht von selbst. Sie muss bewusst organisiert werden.
Agenten brauchen Entscheidungsräume
Mehr Zusammenarbeit bedeutet nicht, dass Menschen künftig jede einzelne Entscheidung gemeinsam treffen müssen. Damit agentische Entwicklung skaliert, müssen Teams bewusst festlegen, welche Entscheidungen ein Agent selbst treffen darf.
Softwarearchitekt Julius Mischok beschreibt dafür ein Engineering-System aus drei Ebenen: Architektur und Standards müssen klar formuliert sein, ihre Einhaltung muss durch Tooling überprüft werden, und für die verbleibenden Entscheidungen braucht es Menschen mit ausreichendem Urteilsvermögen.
Besonders wichtig sind knapp formulierte Prinzipien. Statt langer Projektdokumentation bekommt der Agent etwa die Vorgabe: „Backend Owns Business Logic“ – Berechnungen, Aggregationen und fachliche Entscheidungen liegen im Backend. Solche Prinzipien geben nicht jeden einzelnen Schritt vor, sondern definieren einen Rahmen, innerhalb dessen der Agent situativ entscheiden kann. Architecture Decision Records halten zusätzlich fest, welche grundsätzlichen Entscheidungen bereits getroffen wurden und nicht bei jeder neuen Aufgabe wieder infrage gestellt werden sollen.
Ob der Agent diesen Rahmen einhält, lässt sich weitgehend automatisieren. Mischok nennt Linter für stilistische Vorgaben, Unit- und Integrationstests für funktionales Verhalten, Mutation Testing zur Prüfung der Testqualität sowie Architekturtests mit ArchUnit. Quality Gates in der CI/CD-Pipeline können verhindern, dass Verstöße weitergereicht werden; End-to-End-Tests prüfen das Verhalten des Gesamtsystems.
Diese Werkzeuge schaffen einen Bereich, in dem der Agent selbstständig handeln kann, weil Verstöße automatisiert erkannt, zurückgemeldet oder gestoppt werden. Damit wird die Grenze zwischen menschlicher und agentischer Entscheidung gestaltbar.
Wo Prinzipien eindeutig sind und ihre Einhaltung automatisch überprüft werden kann, muss kein Mensch jeden Schritt freigeben. Menschliche Aufmerksamkeit lässt sich auf jene Fragen konzentrieren, bei denen Fachlichkeit, Abwägung oder Architekturverständnis tatsächlich gebraucht werden.
Auch Architektur bekommt damit eine zusätzliche Aufgabe. Sie definiert nicht nur die Struktur der Anwendung, sondern auch Leitplanken, innerhalb derer Agents autonom handeln dürfen.
“Agentic Engineering skaliert erst dann, wenn die Qualitätsprüfung mit dem Tempo der Codeerzeugung Schritt halten kann.”
Welche Kompetenzen Agentic Engineering jetzt braucht
Damit führt Agentic Engineering überraschend zu Prinzipien zurück, die Softwareentwicklung seit Jahrzehnten begleiten: kurze Feedbackzyklen im agilen Arbeiten, enge Zusammenarbeit zwischen Fachlichkeit und Technik im Domain-driven Design sowie klare Architekturprinzipien mit automatisierter Qualitätssicherung.
Coding Agents erfinden diese Ideen nicht neu. Sie erhöhen vielmehr den Druck, sie tatsächlich umzusetzen. Wenn Software innerhalb weniger Stunden entstehen kann, muss die Fachseite ebenso schnell beurteilen können, ob das Richtige entsteht. Wenn Agents selbstständig arbeiten sollen, müssen Domänen- und Architekturwissen so klar vorliegen, dass Entscheidungen nicht immer wieder von vorn getroffen werden müssen.
All das wird zur Voraussetzung dafür, die Geschwindigkeit der Agents sinnvoll nutzen zu können.
Für Softwarearchitekt:innen erweitert sich damit das Kompetenzfeld. Sie brauchen weiterhin ein solides architektonisches Fundament: Anforderungen analysieren, Systeme entwerfen, Entscheidungen dokumentieren und Qualität bewerten. Gleichzeitig gewinnen Fähigkeiten an Bedeutung, die lange eher als Ergänzung galten: gemeinsam mit Fachexpert:innen Modelle entwickeln, Gruppen zu tragfähigen Entscheidungen führen und technische Leitplanken schaffen, innerhalb derer Agents selbstständig arbeiten können.
Genau bei diesen Aufgaben setzen die Software Architecture Camps an. Das Foundation Level – kompakt oder als Foundation Flexible – vermittelt das methodische Fundament der Softwarearchitektur. Das Modul DDD – Domain-driven Design vertieft die gemeinsame Modellierung von Fachlichkeit und Technik. SOFT – Soft Skills für Softwarearchitekt:innen fokussiert Kommunikation, Moderation und Gruppenentscheidungen. Und AGENTA – Architektur für Agentic Software Engineering zeigt, wie Architekturwissen, Context und Harness Engineering, Architecture Rules, Tests und Quality Gates zusammenspielen, wenn Coding Agents Teil der täglichen Entwicklung werden.
Gemeinsam statt einsam
„Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“ war also kein Satz für eine Zeit vor den mächtigen Werkzeugen. Gerade weil die Tools mächtiger werden, müssen wir bewusster gestalten, wie Menschen mit ihnen – und wie sie miteinander – arbeiten.
Take-aways
Take-away #1: Coding Agents können einen Lone-Wolf-Effekt begünstigen: Einzelne Entwickler:innen arbeiten zunehmend für sich und erhöhen ihr Tempo. Wenn Reviews, fachliche Entscheidungen und Abnahmen nicht mithalten, wird daraus jedoch kein höherer Durchsatz für das Team.
Tipp: Suche im aktuellen Projekt nach der Stelle, an der Arbeit liegen bleibt – Review, fachliche Rückfrage, Architekturentscheidung oder Abnahme – und verkürze genau diesen Feedbackweg.
Take-away #2: Agentic Engineering braucht kleine, cross-funktionale Teams, in denen Fachlichkeit und Technik eng zusammenarbeiten und Entscheidungen schnell getroffen werden können.
Tipp: Stelle für ein konkretes Feature ein Mini-Team aus drei bis vier Personen zusammen und arbeite einen längeren Block gemeinsam daran, statt Anforderungen nur zu übergeben.
Take-away #3: Nähe allein reicht nicht. Widerspruch, unterschiedliche Perspektiven und gemeinsames Nachdenken müssen so organisiert werden, dass daraus belastbare Entscheidungen entstehen.
Tipp: Ersetze bei der nächsten schwierigen Architekturfrage die offene Diskussion durch eine einfache Struktur: erst individuell nachdenken, dann in kleinen Gruppen austauschen, anschließend gemeinsam entscheiden.
Take-away #4: Nicht jede Frage gehört ins Team. Klare Leitplanken aus Architekturprinzipien, ADRs, Tests und Quality Gates schaffen Entscheidungsräume, in denen Agents selbstständig handeln können.
Tipp: Formuliere ein wichtiges Architekturprinzip so knapp, dass auch ein Agent damit arbeiten kann, und sichere es möglichst direkt mit einem Test, Linter oder Quality Gate ab.
Take-away #5: Agentic Engineering macht zentrale Ideen aus Agile und DDD dringlicher: Je schneller Agents implementieren, desto wichtiger werden kurze Feedbackzyklen, gemeinsames Domänenverständnis und kollaboratives Arbeiten.
Tipp: Behandle den Einsatz von Coding Agents selbst als Lernprozess. Nicht nur die Software wird iterativ entwickelt, sondern auch die Art, wie Menschen und Agents zusammenarbeiten. Wähle ein überschaubares Vorhaben und beobachte gezielt, welche Annahmen sich als falsch erweisen, wo zusätzlicher Kontext nötig wird und welche neuen Abhängigkeiten entstehen. Halte diese Erkenntnisse fest und passe Arbeitsweise, Architektur und Verantwortlichkeiten iterativ an, statt davon auszugehen, dass der richtige Prozess schon vorab vollständig feststeht.
Autor:in
Hartmut Schlosser begleitet die IT-Szene seit mehr als 15 Jahren als Redakteur bei Software & Support Media. Als Content Operations Lead verantwortet er die Planung und Steuerung hochwertiger Fachinhalte rund um Softwareentwicklung, Architektur und IT.
