Warum der Builder Loop das Fließband ablöst

TL;DR: AI macht PMs, Designer und Engineers nicht in jedem Kontext austauschbar. Aber sie senkt die Übersetzungskosten zwischen ihnen so stark, dass mehr frühe Produktarbeit von einem Loop Owner verantwortet werden kann: jemand, der vom Kundenproblem über den Prototyp und, wenn das Risiko beherrschbar ist, bis zur ausgelieferten Änderung alles selbst durchläuft. An der Edge ist diese Person zunehmend ein Builder. Im Kern zählen Spezialisierung und Governance weiterhin.

---

Das Fließband-Modell in der Softwareentwicklung — PM spezifiziert, Designer gestaltet, Engineer baut — sah auf dem Whiteboard effizient aus. In vielen Fällen war es das auch. Spezialisierung ermöglichte Tiefe, ohne dass eine Person den ganzen Loop tragen musste. Aber jede Übergabe erhob drei versteckte Gebühren:

Latenz. Wartezeit zwischen Kundenerkenntnis und funktionierendem Artefakt. Ein PM bemerkte am Montag ein Muster in Support-Tickets. Das PRD landete Donnerstag. Design startete im nächsten Sprint. Engineering lieferte sechs Wochen später. Bis dahin war die Erkenntnis veraltet.

Entropie. Kontext geht verloren oder wird verzerrt. Ein Feature, das als „Nutzer finden verzögerte Bestellungen nicht" begann, kam beim Engineer als Jira-Ticket mit 14 Akzeptanzkriterien und einem Mockup an, das das Datenmodell der API nicht berücksichtigte.

Diffuse Verantwortung. Niemand war voll für das Ergebnis verantwortlich. Als ein Feature kaputt ausgeliefert wurde, schob der PM es auf die Spec, der Designer auf das Mockup, der Engineer auf die Timeline. Alle waren teilweise verantwortlich — was bedeutete, dass niemand voll verantwortlich war. Die Retrospektive erzeugte Action Items. Die Action Items landeten auf einer Confluence-Seite. Sechs Monate später wiederholte sich derselbe Fehler mit einem anderen Feature, weil niemand den Fix end-to-end verantwortete.

Das war teuer. Aber lange Zeit war es immer noch billiger, mehr des Loops in einer Person zu bündeln. Die erste funktionierende Version war langsam und spezialistenlastig genug, dass die Koordinationssteuer akzeptabel wirkte.

Diese Abwägung änderte sich zuerst an der Edge.

Das bedeutet nicht, dass eine Person eine ganze Produktorganisation ersetzt. Es bedeutet, dass sich die kleinste sinnvolle Einheit früher Produktarbeit verändert. Dort, wo Arbeit nah am Kunden ist, reversibel bleibt, einen geringen Schadensradius hat und günstig getestet werden kann, schlägt Loop Ownership heute oft dokumentenlastige Übergaben. Sobald Arbeit eng an Core-Systeme gekoppelt, schwer rückgängig zu machen oder stark von Compliance und Zuverlässigkeit geprägt ist, gewinnt Spezialisierung wieder. Ignoriert man diese Grenze, wird das Argument schnell unsauber.

Die Übersetzungskosten kollabierten zuerst an der Edge

Ich sehe das in meiner eigenen Arbeit. Was früher separate Zyklen für Framing, Interaction Design und Implementierung brauchte, passiert jetzt oft in einer Session. Ich skizziere den Flow, baue die iOS- oder Web-Oberfläche und bekomme Tage früher Kundenreaktionen. Die Hälfte der Zeit debugge ich auch, was die AI falsch gemacht hat: eine Komponentenhierarchie die nicht zum Datenfluss passt, oder ein API-Call zu einem Endpoint der noch nicht existiert. Aber Debugging mit Prototyping-Geschwindigkeit ist ein anderes Spiel als sechs Sprints auf das erste testbare Artefakt zu warten. Ich habe auch Dinge ausgeliefert, die ein Designer in der Mockup-Phase abgefangen hätte. Das ist der Preis dafür, den vollen Loop zu besitzen. Befriedigender und erschöpfender, als die Arbeit auf drei Rollen aufzuteilen. Niemand zum Beschuldigen, niemand auf den man wartet. Ich brauche weniger Übersetzungsschleifen, bevor ich Signal bekomme.

Ein PM bei Chime schreibt eine Produktanforderung in Markdown, öffnet ein Terminal und tippt claude. Zwanzig Minuten später ist die Anforderung ein laufender Prototyp. Er teilt eine Bildschirmaufnahme in Slack. Das Team hört auf, über die Spec zu debattieren und diskutiert Verfeinerungen an etwas, das man anklicken kann.

Der eigentliche Gewinn ist hier nicht Coding-Speed. Es ist Entscheidungskompression. Die Konversation hat sich verschoben: von abstrakter Verhandlung („Sollen wir einen Filter oder eine Sortierung hinzufügen?") zu konkreter Bewertung („Klick den Filter — löst er das Problem?"). Dieser Shift — vom Debattieren von Specs zum Kritisieren eines ersten Durchgangs — passiert, wenn der Übersetzungsschritt günstiger wird.

Ein Produktmanager in Prag ohne Programmierhintergrund hat eine iOS-App im App Store veröffentlicht. Über sechs Monate baute er 13 Projekte mit Claude Code: eine native App für Eltern, ein Web-Admin-Tool, ein ML-Modell und ein internes Tool, das dem Management seines Unternehmens half, eine Ressourcenallokationsentscheidung zu treffen. „Es gab nie einen Mangel an Ideen zum Bauen", schrieb er. „Nur die Hürde, mit dem Bauen anzufangen."

In einem anderen Unternehmen baute ein nicht-technischer PM drei funktionierende Prototypen, automatisierte seine Wettbewerbsanalyse und generierte ein PRD aus verstreuten Meeting-Notizen — alles ohne eine einzige Zeile Code zu schreiben. Sein Kollege lieferte einen Feature-Prototyp in 45 Minuten. Die Schätzung des Dev-Teams war zwei Wochen gewesen.

Diese Beispiele beweisen nicht, dass jetzt jeder PM Produktionssoftware verantworten sollte. Sie beweisen etwas Schmaleres und Wichtigeres: Nicht-Spezialisten kommen heute zu einem testbaren Artefakt, ohne erst durch eine volle Queue zu müssen. Das schwächt den wirtschaftlichen Fall für schwere Upfront-Übergaben in früher, risikoarmer Arbeit.

Wenn AI mehr von der Übersetzung von Absicht zu funktionierender Software übernimmt, verlieren einige der Übergaben, die separate Rollen rechtfertigten, einen Teil ihrer wirtschaftlichen Berechtigung. Der PM muss nicht immer eine Spec schreiben, damit ein Designer sie interpretiert, damit ein Engineer sie implementiert, bevor überhaupt jemand reagieren kann. In mehr Fällen beginnt das erste Gespräch mit einem Prototyp statt mit einem Dokument.

Was knapp wurde

Ein großer Grund, warum das Fließband Bestand hatte, war die Knappheit spezialisierter Implementierungszeit. AI hat die Form dieser Knappheit verändert.

Das heißt nicht, dass Implementierung kostenlos oder in jeder Domäne gelöst ist. Es bedeutet, dass erste funktionierende Versionen in vielen Kontexten reichlicher werden, während Systemverantwortung knapp bleibt.

Boris Cherny, der Claude Code bei Anthropic gebaut hat, formuliert die Richtung zugespitzt: „Heute ist Coding praktisch gelöst. Wir werden anfangen zu sehen, dass der Titel ‚Software Engineer' verschwindet. Es wird einfach ‚Builder' oder ‚Product Manager' sein."

Das ist überzeichnet. Engineering verschwindet nicht. Aber wenn Tools den Output pro Engineer deutlich erhöhen, verschiebt sich knappe Arbeit trotzdem: weg von roher Implementierung, hin zu Urteilsvermögen, Verfeinerung und Integrationsqualität.

Der Engpass ist seltener „Können wir eine erste funktionierende Version erzeugen?" und häufiger „Sollten wir das bauen, wie weit sollten wir gehen, und unter welchen Constraints?" Die echte Hebelwirkung verschiebt sich zu Problemauswahl, Experimentdesign, Produktgeschmack, Architekturgrenzen und operativem Urteilsvermögen.

Laut internen Daten von Atlassian sehen Teams, die ein „Product Engineer"-Modell einführen, deutlich höhere Feature-Adoptionsraten. Das beweist nicht, dass eine zusammengelegte Rolle immer gewinnt. Es ist Evidenz dafür, dass Kundenkontext und Implementierungskontext sich verstärken, wenn sie näher zusammensitzen.

Das Organigramm holt auf

Der Endzustand ist nicht festgelegt. Aber Unternehmen experimentieren klar mit Wegen, Queue-and-Handoff-Arbeit im ersten Durchgang zu reduzieren.

LinkedIn hat ein „Full Stack Builder"-Programm gestartet, das Mitarbeitende — unabhängig vom Jobtitel — trainiert, Skills aufzunehmen, die traditionell auf Teams verteilt waren. Das Problem, das sie lösen, ist nicht nur eine Trainingslücke. Es ist ein Koordinationsengpass: zu viele Entscheidungen in der Warteschlange, zu viel Fläche pro Pod, zu viele Übergaben zwischen Leuten, die jeweils nur ein Fragment des Kontexts halten. Aneesh Raman, LinkedIns Chief Economic Opportunity Officer: „Der Full Stack Builder nimmt das, was als Fließband zwischen Design, Product und Engineering Tage oder Wochen gedauert hätte, und gibt es einem Individuum mit diesen Tools."

Walmart hat dedizierte „Agent Builder"-Rollen geschaffen. Jede intern besetzt: sowohl technische als auch nicht-technische Mitarbeitende. Nicht von außen eingestellt. Von innen befördert. Der interessante Teil: Die knappe Kompetenz war nicht ML-Forschung oder Prompt Engineering. Es war Domänenkontext, operatives Verständnis und die Fähigkeit, repetitive Workflows zu identifizieren, die Automatisierung lohnen. Die Leute, die den Problemen am nächsten waren, stellten sich als die besten Builder heraus.

Meta-PMs nennen sich auf LinkedIn „AI Builders", obwohl ihre offiziellen Titel unverändert sind. Diese Selbstbezeichnung ist kein Beweis für ein Organigramm. Aber sie ist ein Signal dafür, dass sich Verhalten schneller verändert als Titel. Wenn PMs anfangen, Artefakte direkt zu shippen, hört die PM/Eng-Grenze auf, nur eine Planungsgrenze zu sein, und wird stärker zu einer Governance-Grenze. Jeremie Guedj, ein Meta-Produktmanager: „Bauen war immer meine Leidenschaft. AI gab mir die Fähigkeit, Ideen in echte, funktionierende Apps zu verwandeln. Das hat alles verändert."

Der Übergang von Software Engineer zu Product Manager ist inzwischen der dritthäufigste Karrierepfad in das Produktmanagement und macht fast 10% der Karrierewechsel aus. Der Titel „Product Engineer" tauchte dieses Jahr in über 50 Stellenausschreibungen auf: Leute, die User-Interviews führen, Prototypen validieren und Features end-to-end verantworten. Nichts davon entscheidet die endgültige Organisationsform. Es zeigt aber Nachfrage nach Menschen, die mehr vom Loop spannen. Sal Khan, auf dem Leading With AI Summit im März: „Die Leute, die einfach nur auf die Spec warten... die werden es schwer haben. Aber die Leute, die sagen: ‚Ich gehe zum Kunden, und ich kann es bauen' — die werden es großartig machen."

Nichts davon stand auf irgendeiner Roadmap. Leute haben einfach angefangen zu bauen, weil Warten sich schlimmer anfühlte als Ausprobieren. Das sind Signale, keine finale Taxonomie. Titel laufen Verhalten hinterher. Die relevante Veränderung ist nicht, ob jeder „Builder" heißt. Es ist, dass mehr vom Loop bei einer Person liegen kann, während Safeguards in geteilte Systeme, Reviews und Plattform-Teams wandern.

Was der Builder tatsächlich ist

Der Builder bedeutet nicht „jeder lernt React." Das verfehlt den Punkt.

Der Builder besitzt mehr vom Loop: Kundenproblem, Hypothese, Prototyp, Test und, wenn der Edge-Test besteht, auch die Auslieferung. Er wartet nicht darauf, dass jemand anderes sein Denken in Software übersetzt. Er nutzt AI, um die Lücke zwischen Absicht und Artefakt zu schließen.

Eine einfache Regel hilft. Builder-Loops funktionieren am besten, wenn vier Bedingungen größtenteils erfüllt sind:

• Die Änderung ist reversibel.
• Die Auswirkungen bleiben lokal.
• Die Arbeit ist nur locker an Core-Systeme gekoppelt.
• Compliance-, Security- und Zuverlässigkeitsanforderungen bleiben beherrschbar.

Wenn diese Bedingungen nicht gelten, sollten Spezialisten früher einsteigen.

Coding differenziert weniger als früher. Diese Skills differenzieren mehr als je zuvor:

Problemdefinition. Wissen, welcher Kundenschmerz es wert ist, dafür zu bauen. Das war schon immer der Kern-Job des PMs. Jetzt ist es jedermanns Job, weil jeder auf die Antwort handeln kann.

Constraints und Architektur. Wissen, wo die Grenzen sind. Was das System verkraftet, was der Nutzer toleriert, wo Governance greift. Das unterscheidet einen Builder von jemandem, der einen Prototyp vibe-codet und ihn als fertig erklärt. Vibe-coding as Leverage bedeutet die Disziplin von Constraints, Architekturgrenzen und Iteration — nicht einfach „AI schreibt meinen Code."

Qualitätsurteil. Wissen, ob das Ergebnis stimmt. Nicht „Ist der Code sauber" — löst die Lösung tatsächlich das Problem? Hält sie unter echter Nutzung stand?

Und dann die Kostenfrage: Ist die Lösung die Komplexität wert, die sie einführt? Ein Builder, der schnell shippen kann, aber die Wartungskosten des Gelieferten nicht einschätzen kann, erzeugt nur Schulden mit höherer Geschwindigkeit.

Shipping. Vor echten Nutzern. Nicht Staging.

Deshalb kaufe ich die Karikatur nicht ab, dass „jeder zum Generalisten wird." In der Praxis fasse ich Framing, Design und Implementierung in einem Workflow zusammen, um schneller Signal zu bekommen. Spezialisten zählen weiterhin. Sie steigen nur an anderen Punkten ein: Tiefe, Governance, Systemqualität und Skalierung — nicht bei jedem ersten Durchgang.

Was kaputtgeht

Ich habe drei Arten beobachtet, wie das schiefgeht.

Prototyp-Sicherheit kann Produktionsrealität überschätzen. Derselbe Workflow, der dir schnell einen überzeugenden Demo-Moment liefert, kann genau die Dinge verdecken, die später in Produktion brechen: Berechtigungen, Fehlerpfade, Analytics, Datenqualität, Rollback-Pfade, Wartung. „Es funktioniert" im Prototyp ist nicht dieselbe Aussage wie „es ist sicher zu betreiben."

Lokale Geschwindigkeit kann globales Chaos erzeugen. AI macht jeden Builder schneller darin, Änderungen zu erzeugen. Aber schnellere lokale Änderungen können das System langsamer in der Weiterentwicklung machen, wenn niemand auf Kohärenz achtet. Die Kosten, Code zu produzieren, sind gesunken. Die Kosten, Systeme zu verstehen, weiterzuentwickeln und zu betreiben, nicht. Ein Builder, der drei Features in einer Woche shippt, ohne darüber nachzudenken, wie sie mit dem bestehenden System interagieren, erzeugt nur technische Schulden mit höherer Geschwindigkeit.

Review verschiebt sich, es verschwindet nicht. Die Reibung der Triade existierte nicht aus bürokratischen Gründen. PM drängte auf Geschwindigkeit. Designer drängte auf Usability. Engineer drängte auf Stabilität. Drei konkurrierende Prioritäten hielten sich gegenseitig ehrlich. Der Builder verliert diese eingebaute Spannung. Aber sie verschwindet nicht. Sie muss in Plattform-Constraints, Code-Review-Standards, Observability, Security-Policies und wiederverwendbare Primitives re-kodiert werden. Ohne Disziplin ist der Default, welchen Bias man auch mitbringt — meistens Shipping-Speed auf Kosten von Randfällen und Systemresilienz. Das ist der Punkt, an dem Vibe-coding as Leverage am meisten zählt: Constraints sind keine Bürokratie. Sie sind die Reibung, die verhindert, dass der Builder schnell shippt und alles kaputt macht.

Neue Produkte, Greenfield-Oberflächen, Workflow-Automatisierung, interne Tools, eng abgegrenzte Loops: diese transformieren sich zuerst. Tiefe Core-Systeme mit Jahren akkumulierter Entscheidungen, Compliance-Anforderungen und teamübergreifenden Abhängigkeiten bewegen sich langsamer. Die gewinnende Organisationsform ist nicht „jeder vibe-codet alles." Es sind Builder, die den Weg vom Problem über den Prototyp bis zum validierten ersten Durchgang verantworten, während Plattform-Engineers Constraints, Primitives, Observability, Security und Systemkohärenz verantworten.

AI senkt die Übersetzungskosten an der Edge, nicht den Bedarf an Kohärenz im Kern.

Die Builder-Diagnostik

Bewerte deine eigene Loop Ownership. Jedes unnötige „Nein" ist eine Übergabe. Jede unnötige Übergabe ist ein Übersetzungsschritt, der Latenz, Entropie und diffuse Verantwortung erzeugt. Manche Übergaben sind tragend. Das Ziel ist nicht null Übergaben. Das Ziel sind weniger vermeidbare.

Geschwindigkeit:

• Kannst du von Kundenerkenntnis zu funktionierendem Prototyp kommen, ohne auf ein anderes Team zu warten?
• Wenn du ein Problem findest, kannst du noch am selben Tag eine Lösung testen?

Ownership:

• Sprichst du mit Kunden UND baust das Produkt, oder machst du eines und übergibst an jemanden, der das andere macht?
• Wenn der Prototyp kaputtgeht, weißt du warum, oder brauchst du jemanden, der es dir erklärt?

Shipping-Autonomie:

• Kannst du vor echten Nutzern shippen, ohne einen Deployment-Prozess der drei andere Leute involviert?

Grenztest:

• Ist die Änderung reversibel, wenn etwas schiefläuft?
• Bleiben die Auswirkungen lokal?
• Ist sie nur locker an Core-Systeme gekoppelt?
• Bleiben Compliance-, Security- und Zuverlässigkeitsanforderungen beherrschbar?

Das Fließband hatte einen guten Lauf. Aber die Übersetzungssteuer, die es rechtfertigte, kollabiert am schnellsten in den Teilen des Systems, die dem Kunden am nächsten sind. Was entsteht, ist nicht das Ende der Spezialisierung. Es ist eine andere Aufteilung: Builder besitzen die schnellen Loops an der Edge; Plattform-, Security-, Daten- und Design-System-Teams besitzen Kohärenz im Kern.

Wenn du IC bist: Baue Loop Ownership auf. Die knappe Kompetenz ist nicht Syntax — es ist die Fähigkeit, vom Kundenproblem zur getesteten Änderung zu kommen, ohne unnötig zu warten.

Wenn du ein Team leitest: Das ist die härteste Transition. Du musst unnötige Übergaben entfernen, ohne das Review zu entfernen, das echte Probleme abgefangen hat. Finde heraus, welche Reibung bürokratisch war und welche tragend. Dann kodiere die tragende Reibung in Plattform-Constraints, CI-Checks und Design-System-Regeln, damit sie überlebt, auch wenn sich das Organigramm ändert.

Für Organisationsleiter ist der Rahmen einfacher: Trenne Edge-Autonomie von Core-Governance. Lass Builder die Loops besitzen, die den Edge-Test bestehen. Lass Plattform-Engineers, Design-Systeme und Security die Kohärenz verantworten.