Wie Builder-Loops Produkt-Handoffs ablösen

TL;DR: AI macht PMs, Designer und Engineers nicht in jedem Kontext austauschbar. Sie senkt aber genug von den Übersetzungskosten zwischen ihnen, dass mehr frühe Produktarbeit von einer einzigen Person verantwortet werden kann: jemand, der vom Kundenproblem über den Prototyp bis zur — wo das Risiko es zulässt — ausgerollten Änderung läuft. Am Rand wird diese Person zunehmend zu einem Builder. Im Kern bleiben Spezialisierung und Governance wichtig.

---

Das Fließband-Modell in Software (PM spezifiziert, Designer entwirft, Engineer baut) wirkte auf dem Whiteboard effizient. Oft war es das auch. Spezialisierung erlaubte Teams, Tiefe zu kombinieren, ohne einer einzelnen Person den ganzen Loop aufzulasten. Aber jeder Handoff hatte drei versteckte Gebühren:

Latency. Wartezeit zwischen Kunden-Insight und funktionierendem Artefakt. Eine PM erkennt am Montag ein Muster in Support-Tickets. Das PRD landet am Donnerstag. Design startet im nächsten Sprint. Engineering shippt sechs Wochen später. Bis dahin ist das Insight kalt.

Entropy. Kontext, der in der Übersetzung verloren geht oder verzerrt wird. Ein Feature, das mit „User finden verspätete Bestellungen nicht” startet, erreicht den Engineer als Jira-Ticket mit 14 Acceptance Criteria und einem Mockup, das das Datenmodell der API ignoriert.

Diffuse Verantwortung. Niemand besitzt das Ergebnis vollständig. Wenn ein Feature kaputt geht, schiebt der PM es auf die Spec, der Designer auf das Mockup, der Engineer auf die Timeline. Alle sind ein bisschen verantwortlich, was bedeutet, dass niemand voll verantwortlich ist. Die Retro produziert Action Items. Die Action Items landen in einer Confluence-Seite. Sechs Monate später wiederholt sich derselbe Failure Mode mit einem anderen Feature, weil niemand den Fix end-to-end besessen hat.

Das war teuer. Aber lange war es immer noch billiger, als mehr von dem Loop in einer Person zu bündeln. First-Pass-Execution war langsam und Spezialisten-lastig genug, dass die Koordinationssteuer akzeptabel wirkte.

Dieser Tradeoff hat sich zuerst am Rand verändert.

Das heißt nicht, dass eine Person eine ganze Produktorganisation ersetzt. Es heißt, dass sich die Minimum Viable Unit früher Produktarbeit verändert. Wo Arbeit nah am Kunden, reversibel, mit kleinem Blast Radius und billig zu testen ist, schlägt Loop-Ownership inzwischen oft dokumentenlastige Handoffs. Sobald die Arbeit eng an Kernsysteme gekoppelt ist, schwer rückgängig zu machen oder schwer in Compliance und Reliability, gewinnt Spezialisierung weiter. Wer diese Grenze ignoriert, macht das Argument schnell unsauber.

Die Übersetzungskosten sind zuerst am Rand kollabiert

Ich sehe das in meiner eigenen Arbeit. Was früher getrennte Zyklen für Framing, Interaction Design und Implementation brauchte, passiert heute oft in einer Session. Ich skizziere den Flow, baue die iOS- oder Web-Oberfläche, hole Kundenreaktion Tage früher ab. Die Hälfte der Zeit debugge ich, was die AI falsch gemacht hat: eine Component-Hierarchy, die nicht zum Datenfluss passt, oder einen API-Call zu einem Endpoint, den es noch nicht gibt. Aber Debugging in Prototyp-Geschwindigkeit ist ein anderes Spiel, als sechs Sprints auf das erste testbare Artefakt zu warten. Ich habe auch Dinge geshippt, die ein Designer im Mockup-Stadium gefangen hätte. Das ist der Preis dafür, den vollen Loop zu besitzen. Befriedigender und anstrengender, als die Arbeit auf drei Rollen aufzuteilen. Niemand, dem man die Schuld geben kann, niemand, auf den man wartet. Ich brauche weniger Übersetzungsloops, bevor ich ein Signal bekomme.

Ein PM bei Chime schreibt ein Product Requirement in Markdown, öffnet ein Terminal und tippt claude. Zwanzig Minuten später ist das Requirement 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 echte Gewinn ist nicht Coding-Speed. Es ist Decision Compression. Das Gespräch wandert von abstrakter Verhandlung („sollen wir einen Filter oder ein Sort dazubauen?”) zu konkreter Bewertung („klick den Filter — löst er das Problem?”). Dieser Shift, von Spec-Debatten zu Kritik an einer ersten Version, ist das, was passiert, wenn der Übersetzungsschritt billiger wird.

Ein Product Manager in Prag, ohne Coding-Background, hat eine iOS-App im App Store veröffentlicht. Über sechs Monate hat er 13 Projekte mit Claude Code gebaut: eine native App für Eltern, ein Web-Admin-Tool, ein ML-Modell und ein internes Tool, das dem Management seines Unternehmens bei einer Resource-Allocation-Entscheidung half. „Ideen gab es nie zu wenig”, schrieb er. „Nur die Hürde, anzufangen.”

Bei einem anderen Unternehmen hat ein nicht-technischer PM drei lauffähige Prototypen gebaut, seine Competitive Analysis automatisiert und ein PRD aus verstreuten Meeting-Notes generiert, alles ohne eine einzige Zeile Code zu schreiben. Sein Kollege shippte einen Feature-Prototyp in 45 Minuten. Das Dev-Team hatte mit zwei Wochen geschätzt.

Diese Beispiele beweisen nicht, dass jeder PM Produktivsoftware besitzen sollte. Sie beweisen etwas Engeres und Wichtigeres: Nicht-Spezialisten kommen heute zu einem testbaren Artefakt, ohne auf eine volle Queue zu warten. Das schwächt die ökonomische Rechtfertigung für schwere Upfront-Handoffs in früher, risikoarmer Arbeit.

Wenn AI mehr von der Übersetzung zwischen Intention und funktionierender Software übernimmt, verlieren manche Handoffs, die getrennte Rollen rechtfertigten, einen Teil ihrer ökonomischen Begründung. Der PM muss nicht immer eine Spec schreiben, die ein Designer interpretiert, die ein Engineer implementiert, bevor irgendjemand reagieren kann. In mehr Fällen startet das erste Gespräch von einem Prototyp aus, nicht von einem Dokument.

Was knapp wurde

Ein großer Grund dafür, dass das Fließband überlebt hat: eine Idee in funktionierende Software zu verwandeln, brauchte knappe Spezialistenzeit. AI hat die Form dieser Knappheit verändert.

Das heißt nicht, dass Implementation gratis ist oder in jedem Bereich gelöst. Es heißt, dass First-Pass-Execution in vielen Kontexten reichlicher geworden ist, während System Ownership weiter knapp bleibt.

Boris Cherny, der Claude Code bei Anthropic gebaut hat, hat die Richtung blunt formuliert: „Heute ist Coding praktisch gelöst. Wir werden sehen, wie der Titel ‚Software Engineer’ verschwindet. Es wird einfach ‚Builder’ oder ‚Product Manager’ heißen.”

Das überzieht. Engineering verschwindet nicht. Aber wenn Tools den Output pro Engineer materiell erhöhen, ist die Implikation trotzdem signifikant: Mehr von der knappen Arbeit verschiebt sich von roher Implementation zu Judgment, Verfeinerung und Integrationsqualität.

Der Engpass ist seltener „können wir eine erste funktionierende Version produzieren?” und öfter „sollten wir das überhaupt bauen, wie weit sollten wir es treiben, und unter welchen Constraints?”. Der echte Hebel verschiebt sich zu Problem-Selection, Experiment-Design, Produkt-Geschmack, Architecture-Boundaries und Operational Judgment.

Atlassian berichtet, dass Teams mit einem „Product Engineer”-Modell 70% höhere Feature-Adoption-Rates sehen. Das ist kein Beweis, dass eine fusionierte Rolle immer gewinnt. Es ist Evidenz, dass sich Kundenkontext und Implementation-Kontext gegenseitig verstärken, wenn sie näher beieinander sitzen.

Das Organigramm zieht nach

Der Endzustand ist nicht entschieden. Aber Unternehmen experimentieren sichtbar mit Wegen, Queue-und-Handoff-Arbeit im ersten Durchgang zu reduzieren.

LinkedIn hat ein „Full Stack Builder”-Programm gestartet, das Mitarbeitende — unabhängig vom Jobtitel — in Skills trainiert, die traditionell auf verschiedene Teams verteilt waren. Das Problem ist nicht nur eine Trainingslücke. Es ist ein Koordinations-Engpass: zu viele wartende Entscheidungen, zu viel Fläche pro Pod, zu viele Handoffs zwischen Leuten, die je nur ein Fragment Kontext halten. Aneesh Raman, LinkedIns Chief Economic Opportunity Officer: „Der Full Stack Builder nimmt das, was Tage oder Wochen als Förderband zwischen Design, Product und Engineering gewesen wäre, und gibt es einer Einzelperson mit diesen Tools.”

Walmart hat dedizierte „Agent Builder”-Rollen geschaffen. Alle intern besetzt: technische und nicht-technische Mitarbeitende. Nicht von außen eingestellt. Intern befördert. Das Interessante: Der knappe Skill war nicht ML-Research oder Prompt-Engineering. Es war Domain-Kontext, operatives Verständnis und die Fähigkeit, repetitive Workflows zu identifizieren, die sich zu automatisieren lohnen. Die Leute, die den Problemen am nächsten waren, erwiesen sich als die besten Builder.

Meta-PMs nennen sich auf LinkedIn „AI Builder”, obwohl ihre offiziellen Titel unverändert sind. Selbst-Labeling ist kein Beweis für ein Organisationsmodell. Aber es ist ein Signal, dass sich Verhalten schneller verändert als Titel. Wenn PMs direkt Artefakte shippen, hört die PM/Eng-Grenze auf, nur eine Planungsgrenze zu sein, und wird mehr zu einer Governance-Grenze. Jeremie Guedj, Meta-Product-Manager: „Bauen war immer meine Leidenschaft. AI gab mir die Fähigkeit, Ideen in echte, funktionierende Apps zu verwandeln. Das hat alles verändert.”

Der Wechsel von Software Engineer zu Product Manager ist inzwischen der drittüblichste Karrierepfad ins Product Management, mit fast 10% aller Karrierewechsel. Der Titel „Product Engineer” tauchte dieses Jahr in über 50 Stellenanzeigen auf: Leute, die User-Interviews führen, Prototypen validieren und Features end-to-end besitzen. Nichts davon entscheidet das finale Organigramm. Es zeigt aber Nachfrage nach Leuten, die mehr vom Loop überspannen können. Sal Khan, beim Leading-With-AI-Summit im März: „Die Leute, die einfach nur auf die Spec warten… die werden Probleme bekommen. Aber die, die sagen ‚Ich gehe zum Kunden und kann es bauen’ — die werden glänzen.”

Nichts davon stand auf irgendeiner Roadmap. Die Leute haben einfach angefangen zu bauen, weil Warten sich schlechter anfühlte als Versuchen. Das sind Signale, keine finale Taxonomie. Titel hinken Verhalten hinterher. Die wichtige Änderung ist nicht, ob alle in „Builder” umbenannt werden. Es ist, dass mehr vom Loop bei einer Person sitzen kann, während mehr Safeguards in geteilten Systemen, Review und Platform-Teams landen.

Was der Builder tatsächlich ist

Der Builder ist nicht „alle lernen React”. Das verfehlt den Punkt.

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

Eine einfache Regel hilft hier. Builder-eigene Loops funktionieren am besten, wenn vier Bedingungen mehrheitlich erfüllt sind:

• Die Änderung ist reversibel.
• Der Blast Radius ist klein.
• Die Arbeit ist lose mit Kernsystemen gekoppelt.
• Compliance, Security und Reliability sind handhabbar.

Wenn diese Bedingungen nicht erfüllt sind, sollten Spezialisten früher einsteigen.

Coding ist weniger differenzierend als früher. Diese Skills sind differenzierender als je zuvor:

Problem Framing. Wissen, welcher Kundenschmerz das Bauen wert ist. Das war immer der Kernjob des PM. Jetzt ist es jedermanns Job, weil jeder auf die Antwort handeln kann.

Constraints und Architektur. Wissen, wo die Grenzen sind. Was das System verträgt, was die User toleriert, wo Governance greift. Das trennt einen Builder von jemandem, der einen Prototyp vibe-codet und es als fertig bezeichnet. Vibe-coding as Leverage heißt die Disziplin von Constraints, Architecture-Boundaries und Iteration — nicht nur „AI schreibt meinen Code”.

Quality Judgment. Wissen, ob der Output stimmt. Nicht „ist der Code sauber” — löst die Lösung das Problem tatsächlich? Hält sie unter echter Nutzung?

Und dann die Kostenfrage: Ist die Lösung die Komplexität wert, die sie einführt? Ein Builder, der schnell shippen, aber den Wartungsaufwand nicht bewerten kann, produziert nur Schulden in höherer Geschwindigkeit.

Shipping. Vor echten Usern. Nicht Staging.

Deshalb kaufe ich die Karikatur nicht, dass „alle Generalisten werden”. In der Praxis kollabiere ich Framing, Design und Implementation in einen Workflow, um früher ein Signal zu bekommen. Spezialisten zählen weiter. Sie steigen nur an anderen Stellen ein: Tiefe, Governance, Systemqualität und Skalierung, nicht in jedem ersten Durchgang.

Was kaputtgeht

Ich habe gesehen, wie das auf drei Arten schief läuft.

Prototype-Confidence überholt Production-Reality. Derselbe Workflow, der schnell zu einer überzeugenden Demo führt, kann genau die Teile verbergen, die in Produktion brechen: Permissions, Failure States, Analytics, Datenqualität, Rollback-Pfade, Wartung. „Es funktioniert” im Prototyp ist nicht dieselbe Aussage wie „es ist sicher zu betreiben”.

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

Review wandert, verschwindet nicht. Die Friction des Trios existierte nicht aus bürokratischen Gründen. PM drückte auf Speed. Designer drückte auf Usability. Engineer drückte auf Stability. Drei konkurrierende Prioritäten haben sich gegenseitig ehrlich gehalten. Der Builder verliert diese eingebaute Spannung. Aber sie verschwindet nicht. Sie muss in Platform-Constraints, Code-Review-Standards, Observability, Security-Policies und wiederverwendbare Primitives re-encoded werden. Ohne Disziplin wird der Default zu deinem eigenen Bias, meistens Shipping-Speed auf Kosten von Edge Cases und System-Resilience. Genau hier zählt Vibe-coding as Leverage am meisten: Constraints sind keine Bürokratie. Sie sind die Friction, die verhindert, dass der Builder schnell shippt und alles bricht.

Neue Produkte, Greenfield-Oberflächen, Workflow-Automatisierung, interne Tools, eng umrissene Loops: Diese transformieren zuerst. Tiefe Kernsysteme mit jahrelang angesammelten Entscheidungen, Compliance-Anforderungen und Cross-Team-Dependencies werden sich langsamer bewegen. Die Gewinner-Org-Form ist nicht „alle vibe-coden alles”. Es sind Builder, die Problem-zu-Prototyp-zu-validierter-erster-Version-Loops besitzen, während Platform-Engineers Constraints, Primitives, Observability, Security und System-Kohärenz besitzen.

AI lässt Übersetzungskosten am Rand kollabieren, nicht den Bedarf an Kohärenz im Kern.

Die Builder-Diagnose

Bewerte deinen eigenen Loop-Ownership. Jedes unnötige „Nein” ist ein Handoff. Jeder unnötige Handoff zahlt Latency, Entropy und diffuse Verantwortung. Manche Handoffs sind tragend. Das Ziel ist nicht null Handoffs. Das Ziel sind weniger vermeidbare.

Speed:

• Kommst du von Kunden-Insight zu laufendem Prototyp, ohne auf ein anderes Team zu warten?
• Wenn du ein Problem findest: Kannst du eine Lösung am selben Tag testen?

Ownership:

• Sprichst du mit Kunden UND baust das Produkt, oder machst du das eine und gibst an jemanden ab, der das andere macht?
• Wenn der Prototyp bricht: Weißt du warum, oder brauchst du jemanden, der es dir erklärt?

Shipping-Autonomie:

• Kannst du an echte User ausliefern, ohne einen Deployment-Prozess, der drei andere Leute involviert?

Boundary Check:

• Ist die Änderung reversibel, falls sie schiefgeht?
• Ist der Blast Radius klein?
• Ist sie lose an Kernsysteme gekoppelt?
• Sind Compliance-, Security- und Reliability-Anforderungen handhabbar?

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 sich abzeichnet, ist nicht das Ende von Spezialisierung. Es ist eine andere Aufteilung: Builder besitzen die schnellen Loops am Rand; Platform, Security, Data und Design-System-Teams besitzen Kohärenz im Kern.

Wenn du IC bist: Bau Loop-Ownership auf. Der knappe Skill ist nicht Syntax — es ist die Fähigkeit, vom Kundenproblem zu einer getesteten Änderung zu kommen, ohne unnötiges Warten.

Wenn du ein Team führst: Das ist der härteste Übergang. Du musst unnötige Handoffs entfernen, ohne den Review zu entfernen, der echte Probleme gefangen hat. Finde heraus, welche Friction bürokratisch war und welche tragend. Encode die tragende Friction dann in Platform-Constraints, CI-Checks und Design-System-Regeln, damit sie überlebt, auch wenn sich das Organigramm ändert.

Für Org-Leader ist der Frame simpler: Trenne Edge-Autonomie von Core-Governance. Lass Builder die Loops besitzen, die den Edge-Test bestehen. Lass Platform-Engineers, Design-Systems und Security Kohärenz besitzen.