15 Jahre lang habe ich Entwicklungszeit rationiert. Dann haben wir eine AI Software Factory gebaut.

Über den Autor: Peter Dyllick-Brenzinger ist Co-Founder und CPTO von beatsquares. Er baut die Werkzeuge, mit denen Kommunikatoren und Redaktionen als Nächstes arbeiten werden. Davor war er mehr als zehn Jahre in der Produktleitung bei BILD, WELT und SPRYLAB. LinkedIn

So sieht eine AI Software Factory an einem Dienstagnachmittag wirklich aus

Fünfzehn Jahre lang bestand mein Job in der Produktleitung – bei BILD, WELT, PURPLE – im Grunde aus einem: Enttäuschungen managen.

Man kennt’s. Ein Backlog voller wirklich guter Ideen und eine begrenzte Zahl an Entwicklerinnen und Entwicklern. Roadmaps, Priorisierungsmatrizen und Quartalsplanungen sind, ohne den Jargon, nur gesellschaftlich akzeptierte Wege zu entscheiden, was man nicht baut.

In letzter Zeit ist diese Grenze bei beatsquares aber einfach verschwunden. Wir haben nicht massenhaft eingestellt. Wir haben nur geändert, wie die Arbeit erledigt wird. Heute liefert unser Team aus vier Leuten mehr als die Teams mit zwölf oder vierzehn Personen, die ich früher geführt habe.

Das ist eine persönliche Beobachtung, keine begutachtete Studie. Aber der Wandel ist so deutlich, dass ich aufschreiben wollte, was da eigentlich passiert. Wenn du ein Produkt- oder Tech-Team leitest, gerade in Medien oder Verlagen, siehst du hier, wie es aussieht, wenn man die Tastatur an eine AI Software Factory übergibt.

Das Spektrum von „KI-Coding“

Der Begriff „AI Software Factory“ hat Anfang dieses Jahres an Fahrt aufgenommen, nachdem Justin McCarthy, CTO von StrongDM, ihr Setup beschrieben hat. Sein Team arbeitet nach zwei ziemlich radikalen Regeln: Menschen schreiben keinen Code, und Menschen reviewen keinen Code. Agenten nehmen Spezifikationen, schreiben den Code und finden völlig selbstständig zu einer Lösung.

Dan Shapiro hat dafür ein hilfreiches Modell entwickelt. Die oberste Stufe nennt er „Dark Software Factory“, weil Menschen dort weitgehend aus dem Spiel sind. Eine Stufe darunter agieren Menschen als Manager, während Agenten die schwere Arbeit machen. Das interne Team von OpenAI, das in fünf Monaten rund eine Million Zeilen Code erzeugt hat, ohne eine davon von Hand zu schreiben, fasst seinen Ansatz treffend zusammen: „Humans steer. Agents execute.“ Menschen steuern, Agenten führen aus.

Wir stehen ungefähr auf dieser mittleren Stufe. Agenten schreiben den Code, erzeugen die Tests und machen die Reviews. Menschen entscheiden, was gebaut wird, diskutieren mit dem Agenten über den Ansatz und drücken auf Merge.

Ein echtes Beispiel: ein Feature, drei Stunden

Am 6. Oktober erwähnte eine Product Ownerin für Newsletter bei einem unserer Kunden in einem Call, dass ihr Morgen-Newsletter einen neuen Autor hat. Der Autorenblock im System erlaubte nur fünf Namen, und alle fünf Plätze waren belegt.

Weil viele Kunden dieses Problem haben oder haben werden, habe ich Claude am nächsten Tag gebeten, aus dem Call-Transkript ein Ticket zu schreiben. Das Ticket erklärte, warum es wichtig ist, welche Sonderfälle es gibt und, ganz entscheidend, was wir bewusst nicht machen. Ich habe den Entwurf überarbeitet und in Linear in die Spalte „To Do“ geschoben.

Am 7. Oktober um 11:08 Uhr hat mein Kollege Yaser das Ticket übernommen und kurz eine „Grill me“-Session mit Claude Code gemacht. Danach legte der Agent los. Um 12:59 Uhr hatte er einen Pull Request mit etwa 800 Zeilen neuem Code eröffnet, inklusive E2E-Test. Um 13:22 Uhr widersprach unser automatischer Review-Agent und markierte zwei schwere und sieben kleinere Probleme. Der Coding-Agent behob sie, und um 14:06 Uhr hat Yaser gemerged. Unsere stündliche Deploy-Pipeline an Werktagen hat es von dort in Produktion gebracht.

Die menschliche Arbeit an diesem Nachmittag war gering, aber es war die einzige Arbeit, die wirklich zählte. Ich musste verstehen, was die Kundin braucht. Ich musste den Umfang festlegen: Limit auf zwanzig anheben, ab mehr als fünf ein Dropdown, und den kombinierten Autorenblock vorerst ignorieren. Und Yaser musste entscheiden, dass es bereit für den Merge ist. Das war alles.

Das Modell ist ein Gehirn im Tank, der Harness ist der Körper

Die wichtigste Lektion bisher: Das KI-Modell selbst ist der uninteressanteste Teil des Stacks.

Unsere Entwickler arbeiten kaum noch in einer IDE, und sie nutzen nicht einfach Copilot zur Autovervollständigung. Die Arbeit passiert in einem Chat mit dem Agenten. Aber ein Chat funktioniert nur, wenn man einen robusten „Harness“ darum gebaut hat.

Birgitta Böckeler von Thoughtworks definiert den Harness als alles im System außer dem Modell: die Leitplanken, die den Agenten steuern, bevor er handelt, und die Sensoren, die seine Arbeit danach prüfen. Anthropic hat über ähnliche Muster geschrieben, mit denen lang laufende Agenten auf Kurs bleiben.

In unserem Setup übernimmt der Harness einen großen Teil der Arbeit:

• Tickets werden automatisch aus Meeting-Transkripten und Slack-Threads entworfen.
• Agenten schreiben den Anwendungscode zusammen mit End-to-End-Tests.
• Jeder Pull Request durchläuft ein gründliches automatisches Review, das den Merge bei schweren Problemen schlicht blockiert.
• Deploys laufen an Werktagen stündlich.
• Release Notes und Doku-Updates werden nach jedem Deploy automatisch erstellt und veröffentlicht.

Wir optimieren auf Prozessstabilität, nicht auf reine Geschwindigkeit. Modelle ändern sich alle paar Monate. Was im März Spitzentechnik war, ist im September Standard. Der Harness sorgt dafür, dass das Ergebnis verlässlich bleibt, wenn sich die Intelligenz darunter verändert.

KI repariert keine kaputten Leitungen

Ich will hier ein bisschen Spielverderber sein, denn um KI-Coding-Tools gibt es gerade viel Hype.

Bei uns kamen die Agenten zuletzt. Bevor wir überhaupt an KI gedacht haben, hatten wir moderne Entwicklungsumgebungen, solide CI/CD-Pipelines, automatisierte Tests und schnelle Deployments. Das sind die Grundfähigkeiten, die die DORA-Forschung seit Jahren mit Elite-Teams verbindet.

Der DORA-Report 2025 hat fast 5.000 Tech-Fachleute befragt. Ergebnis: 90 % nutzen KI bei der Arbeit, aber es gibt einen Haken. KI-Nutzung geht mit höherem Durchsatz einher, aber weiterhin mit geringerer Stabilität. Die Autoren bringen es auf den Punkt: „AI doesn't fix a team; it amplifies what's already there.“ KI repariert kein Team, sie verstärkt, was schon da ist.

Wenn deine Deployments manuelle Eingriffe brauchen und deine Testabdeckung dünn ist, bringt ein Agent an der Tastatur nur schlechten Code schneller in Produktion. Repariere zuerst die Leitungen.

„Wird dann nicht einfach das Code Review zum Engpass?“

Das ist meist die erste Frage, die ich von anderen Engineering Leads bekomme, und sie ist berechtigt. Die Daten stützen die Sorge.

Faros AI hat im vergangenen Jahr Telemetriedaten von über 10.000 Entwicklern ausgewertet. Teams mit hoher KI-Nutzung haben 98 % mehr Pull Requests gemerged. Aber die Review-Zeit stieg um 91 %, die Bugs pro Entwickler nahmen zu, und auf Unternehmensebene gab es keine nennenswerte Verbesserung. Ähnlich fand eine METR-Studie von 2025, dass erfahrene Open-Source-Entwickler mit KI-Tools sogar 19 % langsamer waren. (Fairerweise: In KI-Zeitrechnung ist eine Studie vom letzten Jahr praktisch ein archäologisches Fundstück.)

Wer Entwicklern einfach KI-Tools gibt und den menschlichen Review-Prozess unverändert lässt, ertränkt seine Senior Engineers in Pull Requests.

Unsere Lösung war, das Review selbst zum Teil der Factory zu machen. Wir hatten genau das Problem, das Faros AI überall gefunden hat: Code Reviews waren der neue Engpass. Vor acht Wochen haben wir das Code Review für jeden PR vollständig automatisiert. Seitdem zeigt unser Monitoring mit Oh Dear 100 % Uptime, und Nutzer haben keine Bugs gemeldet, während wir täglich Features ausliefern. Die Qualität ist wirklich besser als alles, was ich vorher gesehen habe, selbst mit sehr erfahrenen Teams. Acht Wochen mit einem kleinen Team an einer Codebasis reichen nicht, um einen allgemeinen Sieg zu erklären. Aber sie zeigen, dass der Review-Engpass ein Designproblem ist, das man im Harness lösen kann.

Der Engpass verschwindet nicht, er wandert

Knappheit geht nie wirklich weg, sie zieht nur um. Bei uns ist der neue Engpass Erkenntnis.

Wir können Software heute viel schneller bauen, als wir herausfinden, was wir bauen sollten. Die Grenze liegt jetzt vollständig bei User Research, Product Discovery und UX-Tests. Andrew Ng hat genau auf diese Verschiebung hingewiesen: Produktmanagement werde zum limitierenden Faktor, und manche Teams verschieben ihr Verhältnis von Engineers zu PMs von 8 zu 1 in Richtung 1 zu 1.

Für Produktleute ist das eine ziemlich aufregende Entwicklung. Man verbringt weniger Zeit damit, Entwicklungskapazität zu rationieren und um Story Points zu verhandeln, und mehr Zeit damit, mit Nutzern zu sprechen und Designs zu testen. Das Handwerk des Produktmanagements bekommt endlich Luft.

Wo man anfängt

Wenn du überlegst, wie du dein eigenes Team umstellst, ist mein Rat: in Schritten. Kauf nicht einfach ein paar KI-Lizenzen und sag allen, sie sollen schneller coden.

Automatisiere zuerst deine Delivery-Pipeline (übrigens: Dabei kann KI helfen). Bau den Harness. Wenn dieses Fundament steht, verlagere die eigentliche Programmierarbeit in den Chat mit Agenten. Automatisiere das Code Review, wenn alles andere automatisiert ist und stabil läuft.

Bei beatsquares haben wir dieselben Automatisierungs-Loops auf redaktionelle Arbeit und Kommunikation übertragen. Wir nehmen Artikel, Unternehmensnachrichten und Kampagnen, und das System macht daraus Newsletter, Podcasts und Social Posts. Menschen bearbeiten und geben das Ergebnis frei. Das funktioniert sehr gut für Verlage und Kommunikationsteams in Unternehmen.

Wenn du sehen möchtest, wie diese Loops in deiner Redaktion oder deinem Team aussehen könnten, buch gern eine Demo. Oder wir unterhalten uns einfach darüber.

Quellen

1. Justin McCarthy, StrongDM: Software Factory, 6. Februar 2026
2. Dan Shapiro: The Five Levels: From Spicy Autocomplete to the Software Factory, 28. Januar 2026
3. Ryan Lopopolo, OpenAI: Harness engineering, 11. Februar 2026
4. Birgitta Böckeler, Thoughtworks: Harness engineering for coding agent users, 2. April 2026
5. Anthropic: Effective harnesses for long-running agents, 26. November 2025
6. Google Cloud / DORA: Announcing the 2025 DORA report, 23. September 2025
7. Faros AI: The AI Productivity Paradox, 23. Juli 2025
8. METR: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 10. Juli 2025
9. METR: Uplift study design update, 24. Februar 2026
10. Andrew Ng: The Batch, Ausgabe 349, 17. April 2026