KI bringt enormen Speed in die Softwareentwicklung. Aber: Die Organisation muss sich bewegen. Sonst verpufft agentischer Speed in alten Strukturen.
Die meisten Diskussionen über agentische Softwareentwicklung beginnen an der falschen Stelle: beim Tool.
Welcher Agent? Welches Framework? Wie viel Autonomie? Wie groß ist das Kontextfenster? Wie gut ist der Code?
Das ist alles nicht egal. Aber es ist nicht die eigentliche Frage. Die eigentliche Frage ist: Wie organisieren wir Softwareentwicklung, wenn Code nicht mehr der Engpass ist?
Denn genau das verschiebt sich gerade. Agenten schreiben Code, erzeugen Prototypen, recherchieren APIs, refactoren, testen, dokumentieren. Nicht perfekt. Nicht ohne Kontrolle. Aber schnell genug, dass sich die Knappheit verlagert.
Knapp wird nicht mehr zuerst die Umsetzung. Knapp wird gemeinsames Verstehen.
Der Lone Wolf gewinnt das falsche Rennen
Agentische Softwareentwicklung wird oft als Geschichte über Einzelne erzählt: eine Person, ein Agenten-Setup, ein Wochenende, und plötzlich steht da etwas. Diese Geschichte stimmt. Ich kenne sie von mir selbst. Ich habe in den letzten zwei Jahren mehr gebaut als je zuvor.
Für Solopreneure ist gerade die beste Zeit überhaupt. Früher musste man erst sechsstellig Kapital einsammeln, um ein paar Entwickler für ein paar Monate zu bezahlen. Heute schließt man ein Abo wie Claude Max für 200 Euro im Monat ab und baut einfach los.
Aber in Organisationen ist das nur die halbe Wahrheit.
Wenn Einzelne plötzlich deutlich schneller werden, wird nicht automatisch die Organisation schneller. Oft entsteht erstmal ein Geschwindigkeitsbruch. Eine Person rennt los, der Rest hängt weiter in denselben Übergaben, Freigaben, Meetings und Review-Schleifen. Lokal entsteht Geschwindigkeit. Global entsteht Reibung.
Das kann sogar einsam machen. Der Agent wird zum wichtigsten Gesprächspartner. Das eigene Setup wird besser, die Zusammenarbeit schlechter. Man produziert mehr Output, aber weniger gemeinsames Verständnis.
Kurzfristig fühlt sich das produktiv an. Langfristig ist es gefährlich.
Die neue Basiseinheit ist das Mini-Team
Mein Zielbild ist deshalb nicht der einzelne superproduktive Entwickler mit eigener Agentenflotte. Mein Zielbild ist ein kleines, fokussiertes Mini-Team.
Zwei bis drei Menschen. Eine fachliche Stimme. Eine technische Stimme. Manchmal Produkt oder UX dazu. Nicht als Gremium, nicht als neues Meetingformat, sondern als operative Einheit.
Dieses Mini-Team sammelt Anforderungen, priorisiert, lässt bauen, schaut auf das Ergebnis, holt Feedback und geht direkt in die nächste Runde. Fachlichkeit und Engineering sitzen im selben Raum, statt über Proxy-POs, Tickets und spätere Abnahmen getrennt zu sein.
Es kommt dabei weniger auf die Besetzung an als auf die Vollmacht. Die fachliche Stimme muss entscheiden dürfen und nicht nur Input liefern. Die technische muss urteilen, nicht bloß umsetzen. Fehlt diese Vollmacht, ist es wieder nur ein Meeting, das seine Entscheidungen anderswo einholt, und der kurze Loop ist dahin.
Der Unterschied ist nicht romantisch, sondern praktisch: Der Feedback-Loop wird kurz.
Die Person, die beurteilen kann, ob der Agent fachlich in die richtige Richtung läuft, ist schon dabei. Die technische Person sieht sofort, wo Begriffe unscharf sind. Die Fachperson sieht sofort, welche Annahme gerade in Code gegossen wird.
Der Agent ersetzt dieses Gespräch nicht. Er hört mit, stellt die richtigen Fragen und notiert die Erkenntnisse.
Jetzt kann man einwenden: Das ist doch nur ein cross-funktionales Team, das gibt es seit Jahren. DDD, agile Produktteams, ordentliche Discovery, das wollte Fachlichkeit und Engineering schon immer zusammenbringen. Stimmt. Die Richtung ist nicht neu. Neu ist das Tempo, mit dem ein Missverständnis heute in lauffähige Software gegossen wird. Wenn ein Agent eine falsche Annahme über Nacht in funktionierenden Code verwandelt, kostet sie nicht mehr eine Diskussion im nächsten Refinement, sondern Tage Arbeit in die falsche Richtung. Genau deshalb trägt das alte Übergabemodell noch weniger als früher.
Mehr Leine, aber nicht alleine
Der Reiz agentischer Arbeit liegt darin, Agenten mehr Leine zu geben. Nicht jede Zeile kontrollieren. Größere Aufgaben delegieren. Von Code-Review zu Entscheidungs-Review wechseln: Hat der Agent die richtige Richtung gewählt? Waren die Annahmen plausibel? Passt das Ergebnis zur Fachlichkeit?
Das ist richtig. Aber es kippt, wenn ein Mensch allein mit dem Agenten operiert und den Harness optimiert.
Mehr Autonomie braucht mehr gemeinsamen Kontext, nicht weniger. Sonst entstehen lauter schnelle lokale Lösungen, die niemand zusammen gedacht hat.
Mini-Teams sind dafür ein guter Zuschnitt: klein genug für Tempo, breit genug für Perspektive. Sie können eine Idee direkt schärfen, ausprobieren, verwerfen, neu bauen. Ohne dass jede Entscheidung durch eine Organisation wandern muss.
Prototypen sind Teil des Denkens
Zum kurzen Loop gehört noch etwas: schnelle Prototypen.
Ein Prototyp ist kein halbfertiges Produkt, sondern ein Denkwerkzeug. Man baut ihn, um etwas zu lernen, zeigt ihn früh und wirft ihn im Zweifel wieder weg. Das Gelernte fließt zurück in das gemeinsame Verständnis des Teams.
Gerade mit Agenten wird das wichtig. Wenn ein Prototyp schnell entsteht, kann man mehrere Richtungen ausprobieren, bevor sich die Organisation emotional auf eine Lösung festlegt. Geschwindigkeit ist dann nicht der Grund, früher zu committen. Sie ist die Chance, früher falsch zu liegen.
Das funktioniert aber nur, wenn allen Beteiligten von Anfang an klar ist, dass der Prototyp zum Wegwerfen gebaut wurde. Vorher, nicht hinterher. Sobald etwas Lauffähiges im Raum steht, ist die Versuchung groß, es einfach zu behalten. Es tut ja schon was. Die Fachseite sieht endlich etwas, das funktioniert, und will es nicht mehr hergeben. Genau dann wird aus dem Denkwerkzeug klammheimlich das Produkt, und man schleppt einen schnellen Hack über Jahre mit. Mit Agenten ist das besonders heikel, weil der Prototyp auch noch sauber und fertig aussieht, obwohl er es nicht ist. Deshalb gehört der Satz „das werfen wir gleich wieder weg” an den Anfang und nicht ans Ende. Wenn das alle wissen, darf ein Prototyp ruhig hässlich sein und an jeder Ecke schummeln. Er muss eine Frage beantworten, nicht in Produktion gehen.
Drei Köpfe sind robuster als einer
Bleiben zwei Sorgen, die ich an dieser Stelle oft höre. Beide sind berechtigt.
Die erste: Schaffe ich mir mit so kleinen Einheiten nicht schon wieder Kopfmonopole? Wir wollen doch Team-Ownership, nicht ein paar Leute, die als Einzige durchblicken. Nur ist das Kopfmonopol nicht das Mini-Team, sondern der Lone Wolf von vorhin. Eine Person plus eigene Agentenflotte, das ist Bus-Faktor eins in Reinform. Das Mini-Team verteilt das Verständnis auf zwei, drei Köpfe und, viel wichtiger, in die Spec. Wenn das Gespräch mitläuft, verdichtet und nachlesbar wird, hängt das Wissen nicht mehr in einem einzelnen Hirn. Das ist mehr geteiltes Verständnis als in vielen großen Teams, wo das echte Wissen als Stammesfolklore bei zwei Leuten klebt.
Die zweite Sorge sitzt tiefer: Was ist mit Urlaub? Drei Leute, einer drei Wochen weg, das tut weh. Ja. Aber das große Team hat dasselbe Problem, nur versteckt. Der eine, der das Zahlungsmodul wirklich versteht, ist auch dort der Engpass. Große Teams kaschieren den Bus-Faktor, sie lösen ihn nicht. Das Mini-Team mit Spec macht die Übergabe wenigstens billig. Wer einspringt, liest Spec und Transkripte, statt sich durch alte Tickets zu graben.
Und manchmal steht eine Sache eben, wenn die Schlüsselperson fehlt. Das ist kein Versagen. Die ehrliche Alternative ist nicht heldenhaftes Weiterrennen, sondern sauber anhalten und später ohne Gedächtnisverlust weitermachen. Genau das kann ein Team, dessen Verständnis in der Spec liegt. Wer das nicht aushält und lieber Fake-Fortschritt erzwingt, hat ein Prioritätenproblem, kein Mini-Team-Problem.
Was Organisationen ändern müssen
Der Eingriff ist klein, die Wirkung groß.
Die Fachlichkeit gehört näher an die Umsetzung, in den laufenden Loop statt in eine spätere Abnahme.
Teams müssen fokussierter werden. Wer gleichzeitig in vier Kontexten steckt, findet in keinem einen schnellen Loop.
Das Review verschiebt sich. Wenn Agenten mehr Code erzeugen, reicht es nicht mehr, den Code zu lesen. Wichtiger wird, ob die Entscheidungen stimmen, fachlich, architektonisch, am Produkt.
Und die Spec ändert ihren Charakter. Kein Übergabedokument mehr, sondern das laufende Gedächtnis des Teams.
Und natürlich brauchen Mini-Teams Leitplanken: Architektur, Security, gemeinsame Standards, Austausch zwischen Teams. Sonst entstehen viele schnelle Inseln, die später teuer zusammenwachsen.
Aber ohne diese kleinen, direkten Einheiten bleibt agentische Softwareentwicklung ein individueller Produktivitätstrick.
Die eigentliche Veränderung ist nicht, dass wir bessere Agenten bekommen. Die eigentliche Veränderung ist, dass sich die kleinste sinnvolle Arbeitseinheit verschiebt.
Nicht Abteilung. Nicht Projektteam. Nicht Lone Wolf.
Sondern ein fokussiertes Mini-Team, das mit Agenten gemeinsam schneller verstehen, bauen und lernen kann.