Warum Software-Fabriken scheitern: Das Licht wieder einschalten

Dies ist Teil zwei von Warum Softwarefabriken scheitern

Die Vortragsversion dieses Beitrags ist live auf YouTube: https://www.youtube.com/watch?v=Ib5GBkD555M

Das Licht wieder anschalten

In Teil 1 bin ich tief darauf eingegangen, warum man Modellen nicht vertrauen kann, die Codequalität über Zeit zu erhalten. Warum keine noch so ausgefeilte Harness-Entwicklung oder Tokenmaxxing ein Problem des Modelltrainings und der Benchmarks lösen wird. Warum „Modell als Richter" für Codequalität nicht so gut funktioniert, wie manche Leute einem weismachen wollen.

Im Moment bist du der Richter – also bringen wir das Code-Review zurück.

Wir werden das Gleiche annehmen, was wir schon vor KI gemacht haben, nämlich ein bisschen Vorabplanung, um die Wahrscheinlichkeit eines langen und schwierigen Reviews zu verringern.

Wir werden Hebelwirkung finden, und wir werden KI nutzen, um dabei zu helfen, und zwar in 4 Phasen:

• Produktanforderungen
• Systemarchitektur
• Programmentwurf
• Vertikale Scheiben

Produkt-Review

Alles beginnt mit einem Produkt-Review: einem kurzen Dokument, das festlegt, was wir bauen und warum. Das Ziel ist es, zwei Sätze oder eine lange Sprachnotiz zu nehmen und daraus etwas halbstrukturiertes zu machen.

Zuerst stimmen wir uns auf das zu lösende Problem ab – die tatsächlichen Benutzerprobleme, in den Worten des Benutzers. Zweitens, wie Erfolg aussieht – was wir nach dem Ausliefern lesen können, um zu entscheiden, ob die Sache es wert war, gebaut zu werden. Idealerweise ist das ein Benutzerergebnis wie „kann XYZ-Workflow in kürzerer Zeit erledigen" oder „erreicht Onboarding-Meilenstein ABC früher". Manchmal ist es niedriger, wie eine Fehlerrate oder eine Latenzzahl, manchmal nur „die Support-Tickets zu X hören auf."

Wir versuchen, dies ziemlich im Produktbereich zu verankern, nicht im Technischen. Als jemand, der mit einem Fuß in der Produktwelt und einem Fuß in der Technik lebt, ertappe ich mich oft dabei, hier in die technischen Details abzudriften. Wenn das passiert, versuche ich, es einfach für spätere Phasen zu notieren und mich darauf zu konzentrieren, was der Benutzer tatsächlich erlebt. Wenn technische Entscheidungen Produktentscheidungen blockieren, halten wir fest, was wir haben, und gehen zur Architektur über oder machen mehr Prototypen-Forschung zur Machbarkeit

Und da es hier meistens darum geht, was der Benutzer sieht, beschreibe ich es nicht – ich erstelle einen Mockup. Ein grobes HTML-Mockup des tatsächlichen Bildschirms beendet eine Diskussion, die drei Absätze nur verlängern würden.

Hier ist ein echtes in Arbeit – das Dokument legt die Funktion mit einer JSON-Gliederung fest, dann zwei grobe HTML-Mockups der tatsächlichen Bildschirme:

https://x.com/dexhorthy/status/2078592010852982977

Natürlich bekommt nicht alles ein Produkt-Review. Eine kleine Textänderung, ein einmaliges Skript, ein Bug mit offensichtlicher Reproduktion – das werfen wir immer noch direkt dem Agenten zu. Das ist für Änderungen gedacht, bei denen ein Missverständnis des Agenten teuer ist.

Für dieses und alle Dokumente in der Serie führen wir autor-opt-in Reviews durch. Wenn du während des Reviews Zeit sparen willst, wählst du die Person aus, die den PR reviewen würde, und gehst die Produkt-/Technikspezifikationen mit ihr durch, entweder asynchron über Dokumentkommentare (wir dogfooden humanlayer dafür, aber du kannst das genauso gut in GitHub/Notion/Plannotator usw. machen).

Systemarchitektur

Sobald das Produkt-Review abgeschlossen ist, machen wir die Systemarchitektur. Das ist nicht besonders neu und selbst Vibe-Coder schwören inzwischen darauf.

Wenn du während des Reviews Zeit sparen willst, wählst du die Person aus, die den PR reviewen würde, und gehst die Produkt-/Technikspezifikationen mit ihr durch, bevor du zum Codieren kommst.

In dieser Phase stimmen wir uns darauf ab, wie die Dienste, Endpunkte, Schemata, Warteschlangen und Speicher miteinander kommunizieren, ohne auf die Details des Programmentwurfs einzugehen. Um die Kommunikationsbandbreite zwischen Mensch und Agent zu maximieren, nutzen wir hier stark Visualisierungen – zum Beispiel Sequenzdiagramme:

Vertrags-/Endpunktformen:

Datenmodelle und Transformationen:

Mermaid ist hier in Ordnung, aber es kann manchmal übertrieben sein und dich manchmal in eine falsche Sicherheit wiegen, dass ihr abgestimmt seid. Architektur ist ziemlich wirkungsvoll und es gibt eine Menge potenziell schlechter Modell-Ticks, die du in dieser Phase abwehren kannst. Aber sie ist nicht ausreichend, um qualitativ hochwertigen Code zu produzieren. Dafür brauchen wir den Programmentwurf.

Programmentwurf

Nach der Architektur machen wir etwas, das meiner Meinung nach beim agentischen Codieren sträflich vernachlässigt wird: Programmentwurf.

Die meisten Leute nehmen an, dass das Modell, sobald die Architektur stimmt, einfach loslegen kann. Du kannst das machen, aber was du zurückbekommst, könnte dir nicht gefallen.

Aber was ich gut funktionieren sehe, ist, dass wir, bevor jemand (Mensch oder Agent) die Implementierung schreibt, eine Ebene unter die Architektur gehen in die Form des Codes: die Typen, die Methodensignaturen, das Programm-Layout und die Call-Stacks.

Die erste Version unseres Programmentwurf-Skills war schlecht. Sie war schwer zu lesen, sie war anstrengend. Wir haben Mermaid ausprobiert, das seinen Platz hat, aber was wir eigentlich lieben, sind leichte Visualisierungen in Pseudocode:

Call-Stack-Bäume für jede Orchestrierungs- oder Kontrollflussänderung. Verwende Diff-Syntax, wenn der interessante Teil die Änderung ist:

Dillon Mulroy spricht darüber, Call-Graphen als Teil seines Planungsprozesses zu verwenden, und ich denke, das ist genau richtig.

Dateibaum-Diffs – damit du den Überblick über das Layout deiner Codebasis behältst und weißt, wo was liegt

Typen und Methodensignaturen für die wichtigsten neuen Funktionen – das Zeug, das zu intern für ein Architekturdokument ist, aber bei dem ein Agent trotzdem Fehler machen könnte

Keines davon dauert lange zu erstellen (das Modell entwirft sie, du diskutierst mit ihm), und jedes einzelne ist eine Entscheidung, die du sonst implizit während des Code-Reviews treffen würdest – zum teuersten Zeitpunkt, um deine Meinung zu ändern.

Vertikale Scheiben

Als nächstes lieben wir das, was ich „vertikale Scheiben" nenne – Matt Pocock und ich hatten einen

Chat über vertikale Scheiben oder „Tracer Bullets" in einem Live-Stream im Januar 2026 - das wird auch als Tracer Bullets bezeichnet

Modelle lieben, was ich „horizontale Pläne" nenne – Dinge in Stack-Reihenfolge erledigen:

1. Datenbank-Migrationen
2. Service-Schicht
3. API
4. Frontend

In der Praxis bedeutet das, dass es keine wirkliche Möglichkeit gibt, die Lösung während der Arbeit zu „berühren". Du kannst Dinge mit Code testen, aber für so ziemlich jede Funktion, die ich je gebaut habe, war das Lesen der Tests ein Anfang, aber etwas in einem Browser aufzurufen oder es während der Arbeit mit curl zu testen, war immer ein häufiger Teil des Workflows.

Vor KI war es selten, dass jemand 2000+ Zeilen Code oder auch nur 500 Zeilen Code geschrieben hat, ohne irgendetwas auf dem Weg zu überprüfen.

Es hat eine Weile gedauert, bis mir der Unterschied zu dem aufgefallen ist, was ich gewohnt war – als ich vor KI Code geschrieben habe, habe ich immer in der Mitte angefangen und mich nach außen gearbeitet. Vage:

1. API-Vertrag erstellen und Mock-Daten bereitstellen, mit curl testen
2. Frontend zum Konsumieren der Mock-Daten erstellen, im Browser iterieren und verfeinern
3. API mit der Service-Schicht verbinden (Dienste liefern Mock-Daten/-Verhalten)
4. Datenbank-Migrationen hinzufügen, Dienste mit der Datenbank verbinden
5. Eine Menge Geschäftslogik hinzufügen
6. Eine Menge Fehlerbehandlung hinzufügen

Und ich würde bei jedem Schritt testen/iterieren/verfeinern.

Wenn mir der Code sehr wichtig ist oder ich skeptisch bin, ob das Modell in diesem Teil der Codebasis gute Arbeit leisten kann, überprüfe ich den Code bei jedem Schritt. 100-200 Zeilen zu überprüfen und neu zu steuern, ist viel billiger

hier würde ich. Die meisten Grenzmodelle werden ohne menschliche Steuerung keinen solchen Plan entwerfen, und es ist schwer, ihn pro Codebasis oder sogar pro Aufgabe zu verallgemeinern, daher bleibe ich hier lieber im Loop. Vertrau mir. Wenn ich das Denken auslagern könnte, würde ich es tun.

30 Minuten Planung sparen Stunden an Review

Und so haben wir einige Schritte, bei denen ich argumentieren würde, dass Menschen im Loop sein müssen, wenn du ein nahezu menschliches Qualitätsniveau halten willst, ohne dich über Berge von Schrottcode zu beugen und ihn im Nachhinein aufzuräumen. (d.h. du willst tatsächlich schnell sein)

1. Produktdesign
2. Systemarchitektur
3. Programmentwurf
4. Vertikale Scheiben

Offensichtlich machen wir diesen gesamten Prozess nicht für alles, was wir ausliefern (siehe den Nebenquest unten). Ich würde schätzen, dass die Verteilung ungefähr so ist:

• ~40% der Aufgaben werden auf einen Schlag oder mit 1-2 Runden leichtem Feedback erledigt
• für mittlere Aufgaben machen wir Produkt-/Systemdesign in einem einzigen Planungsdokument und machen uns nicht die Mühe, die Arbeit in Phasen aufzuteilen
• für große Dinge machen wir alle Schritte. Wir überspringen den Produktteil für Dinge, bei denen das keinen Sinn ergibt, wie große Refactorings.

Und in den meisten Fällen schicke ich ein Modell los, um 1-3 Scheiben auf einmal zu machen, und überprüfe den Code während der Arbeit. Es ist viel einfacher, frühzeitig umzusteuern, sei es bei den Interna oder der tatsächlichen Funktionalität, als auf der anderen Seite von 2000+ Codezeilen zu landen, ohne eine Ahnung zu haben, was kaputt ist.

Du hast wahrscheinlich das Gefühl, zu viele Pull Requests zu haben

Du hast nicht zu viele PRs. Du hast zu viele schlechte PRs.

Wir haben alle schon viele PRs reviewed, die Nacharbeit brauchten, und das schon lange vor KI.

Aber ein großartiger PR ist eine Freude zu reviewen. Du scrollst durch jede Datei, der Code ist sauber, er folgt all deinen Entscheidungen/Diskussionen/erkämpften Meinungen darüber, wie Software sein sollte.

Wenn ein Pull Request andererseits auch nur 20% Nacharbeit erfordert (und das ist großzügig, ich würde sagen, die meisten KI-Ein-Schuss-PRs tendieren eher zu 50%), ist das sowohl eine intellektuelle Belastung als auch eine emotionale Belastung für den Einreicher und den Reviewer. (Selbst wenn der Einreicher eine KI ist, hat wahrscheinlich jemand diese Arbeit angestoßen oder das KI-Ergebnis aufpoliert oder kümmert sich zumindest um das Ergebnis).

Um dir Zeit zu ersparen (wir sind fast am Ende), habe ich in einem Nebenquest mehr darüber geredet:

„wo die Zeit bleibt"

Eine Theorie der Beschränkungen (Ausgabe 2026)

Es ist leicht, ein wenig enttäuscht zu sein von der Kernthese hier: „im Moment müssen wir den Code lesen".

Ich war ziemlich aufgeregt über eine Welt, in der wir einfach Dinge anfordern, die Modelle kochen lassen, den Code nicht lesen und wunderschöne Produktionssoftware bekommen könnten, die sich im Laufe der Zeit weiterentwickelt und nicht den Bach runtergeht.

Aber was ich hier versucht habe, so gut wie möglich darzulegen, sind nichts als Beschränkungen. Modelle sind gut in einigen Dingen, in anderen nicht so gut. Wie optimierst du deinen Prozess im Lichte dieser Beschränkungen?

Modelle sind gut in einigen Dingen, in anderen nicht so gut. Wie optimierst du deinen Prozess im Lichte dieser Beschränkungen?

Es ist möglich, dass du zu sehr damit beschäftigt bist, 10-100x schneller zu arbeiten und dir einzureden, dass Codequalität keine Rolle mehr spielt, während du die Beschränkungen annehmen und 2-3x schneller und sicherer arbeiten könntest.

Meine abschließende Empfehlung ist im Grunde:

1. Lerne die Beschränkungen gut kennen, entwickle Intuition, indem du viel mit Modellen arbeitest
2. Optimiere Systeme innerhalb des Rahmens dieser Beschränkungen
3. Suche Hebelwirkung
4. Lies den verdammten Code

Das war's. Wenn du für den Pitch bleiben willst, scroll einfach weiter. Ich hoffe, das hilft dir, eine Katastrophe zu vermeiden, oder dass du zumindest Spaß an den niedlichen kleinen Animationen hattest.

Danke fürs Lesen

-dex

PS Wir sind besessen davon

Wir bauen humanlayer.com, eine agentische IDE und Kollaborationsplattform, die dir hilft, 2-3x schneller zu arbeiten, während du ein menschliches (oder ziemlich nahe am menschlichen) Niveau der Codequalität beibehältst.

Wir bauen auf zwei Ideen hin: „Bausteine für deine Softwarefabrik" und „bessere Verifizierer für Softwarewartbarkeit" (vielleicht sogar bessere Modelle).

HumanLayer ist kostenlos für kleine Teams mit bis zu 3 Personen, und wenn du Hilfe beim Einstieg brauchst, kannst du in unserem Discord vorbeischauen oder uns eine Nachricht an founders@humanlayer.dev schicken.

Ein kurzer Dank an @calvinfo für die Inspiration, an meinen Co-Founder @0xBlacklight, an @swyx und das Team von @aiDotEngineer dafür, dass sie mir einen Raum gegeben haben, diese Ideen zu erforschen, und an all unsere unglaublichen Kunden, Investoren, Freunde und Familie, die uns anfeuern.

Wenn du mehr erfahren willst, ich höre im Grunde nicht auf, darüber zu reden, also findest du unten alle Links aus diesem Beitrag sowie einige andere Projektionen des Materials in Podcasts, lange Whiteboard-Formate usw.

PPS Weitere Ressourcen

Podcasts und Artikel:

• Dex und Gergely sprechen über Context Engineering und Softwarefabriken bei The Pragmatic Engineer - Juli 2026
• Dex und Matt Pocock sprechen über zeitlose KI-Coding-Tipps (und Ralph Loops) - Januar 2026

AI That Works Folgen:

• Benchmarks beweisen nichts
• Produktspezifikationen für KI-Codierung
• Lerntests für besseren Backpressure
• Anwendung der 12-Factor-Agents-Prinzipien auf KI-Codierung

Links aus diesem Beitrag:

• Warum Softwarefabriken scheitern – Keynote AI Engineer World's Fair 2026
• StrongDMs Softwarefabrik ohne Licht
• OpenAI: Harness Engineering (Feb. 2026)
• Ryan Lopopolo über Symphony (Vortrag, Apr. 2026)
• Mario auf der AI Engineer Europe: „Pi in einer Welt von Schrott bauen"
• FT: Amazon-Ausfälle durch Coding-Agenten-Pannen
• Matt Pocock: Codebasen fallen auseinander
• Faros AI: Der KI-Beschleunigungs-Peitschenhieb-Bericht
• Advanced Context Engineering for Coding Agents (Vortrag 25.08.)
• No Vibes Allowed (Vortrag 25.11.)
• Everything We Got Wrong About RPI (Vortrag 26.03.)
• Awesome-RLVR - Reinforcement-Learning-Ressourcen
• Advanced Context Engineering for Coding Agents (Ausarbeitung)
• 12-Factor Agents
• Addy Osmani über Vibe-Coding vs. Wartung
• NATO Software Engineering Conference, 1968
• DoD DevSecOps Reference Design (PDF)
• Ramps Coding-Agenten-Plattform
• Stripe: Minions, One-Shot-End-to-End-Coding-Agenten
• WorkOS: Project Horizon
• Brex (Latent Space)
• Dan Shapiro: Die fünf Stufen zur Softwarefabrik
• Simon Willison über StrongDMs Softwarefabrik
• „Den Ozean abkochen"
• Schrotflinten-Operation (refactoring.guru)
• John Ousterhout — Eine Philosophie des Softwaredesigns
• Robert C. Martin — Clean Code
• Martin Fowler — Refactoring
• aider
• cline
• codebuff
• SWE-Agent Paper (2024)
• OpenAI Codex Vortrag (Nov.)
• Calvin French-Owen — AI Council Vortrag
• SWE-bench Multilingual (Datensatz)
• AIE Worlds Fair 2026 - Die große Loops-Debatte („Der Hype überholt die Disziplin")
• SWE-Marathon (Abundant AI)
• DeepSWE (Datacurve)
• Frontier Code (Cognition)
• Mutationstests (Wikipedia)
• Dillon Mulroy über Call-Graphen in der Planung
• Dex × Matt Pocock: vertikale Scheiben / Tracer Bullets (Livestream, Jan. 2026)
• „Die harte Arbeit des Denkens kann nicht ausgelagert werden" (Jake Nations)