Handwerk Jul 31, 2026 at 22:2015Zu Lesezeichen hinzufügen

Die CTO von Thoughtworks stellt die Frage, die das Maß „Features/Woche“ vermeidet: Wenn die Ausführung kostenlos wird, schafft man keine schnelleren Entwickler, sondern Dirigenten – und niemand bildet sie aus.
Rachel Laycock, CTO von Thoughtworks, veröffentlicht am 31. Juli 2026 in „Rachel's ramblings“ (martinfowler.com) einen Beitrag – „The Conductor Developer“ – der neu formuliert, was zwei Jahre generative KI am Berufsbild verändert haben. Die von ihr abgelehnte Einordnung: „Wir werden schneller.“ Die von ihr vorgeschlagene: Die knappe Ressource hat sich verändert – und damit auch die Rolle.
Sie beobachtet Ingenieure, die gleichzeitig 8 bis 12 Agenten laufen lassen. Die sichtbare Arbeit ist nicht mehr die Tastatur, sondern die Orchestrierung: Welcher Agent, auf welchem Branch, mit welchem Prompt, welche Überprüfung. Der Vergleich, den sie zieht, ist direkt – der eines Dirigenten, der kein Instrument spielt, aber die gesamte Partitur im Kopf behält. Sie formuliert die Verschiebung so: Das Fachwissen ist nicht verschwunden, es wird nur woanders und viel häufiger eingesetzt, weil die Ausführung schneller geworden ist.
Es ist eine Verschiebung des Engpasses, kein Absenken der Anforderungen. Wenn der Teil „Code schreiben“ nicht mehr dominant im Workflow ist, ist das nicht umsonst: „Entscheiden, rahmen, prüfen, das System zusammenhalten“ wird zur bindenden Einschränkung. Laycock theoretisiert nicht – sie beschreibt einen Zustand, der bei den Besten bereits Realität ist, und lässt die Frage offen: Wie gestalten wir die Karrieren von Ingenieuren neu, wenn die menschliche Aufmerksamkeit zur knappen Ressource wird?
Drei plausible Entwicklungen innerhalb von 12–24 Monaten. (1) Konsolidierung durch Tooling: Die besten Entwickler bauen Rahmenwerke, die Aufmerksamkeit verteilen (Agenten-Queues, Checklisten, Gates). (2) Stille Erschöpfung und Burn-out: 10 Agenten zu orchestrieren, ist ein Modus „Vorsitzender einer Sitzung“ 8 h/Tag – sehr unterschiedlich zum Flow. (3) Neudefinition der Rollen: Architekten gewinnen, Mid-Level-Entwickler müssen sich entscheiden, ob sie zum Dirigenten aufsteigen oder zum spezialisierten „Instrumentenspieler“ werden.
Zwei konkrete Handlungsempfehlungen aus der These: Aufhören, Produktivität in Features/Woche zu messen (eine Metrik für Komponisten, nicht für Dirigenten); Schulungen zur kognitiven Lastensteuerung einführen – so wie man vor zehn Jahren Clean Code gelehrt hat.
Das Hauptrisiko, das Laycock benennt, ohne es zu beantworten: Karrieren wurden nicht für das konzipiert. Man weiß, wie man einen guten Ausführenden zum Architekten befördert; man weiß noch nicht, wie man auf Schulebene oder für Junioren einen Dirigenten formt.
Die Post-Mortems von Teams, die zu 100 % agentenbasiert arbeiten – jenseits von Demos – und die ersten Stellenausschreibungen, die explizit „Orchestrierung von N Agenten“ als Verantwortung auflisten – nicht als Buzzword.
Artikel von künstlicher Intelligenz erstellt, unter menschlicher redaktioneller Kontrolle geprüft.
Melden Sie sich an, um an der Diskussion teilzunehmen.
Isn’t the orchestrator role just outsourcing complexity to another person’s plate? The system might be efficient, but who fixes the bigger problem of over-optimizing for parallel work without building better foundations?
Orchestration sounds like a Band-Aid solution. If parallel execution is truly effortless, shouldn’t we question why we’re still measuring productivity by output rather than impact?
True effortless parallelism is rare; usually it just masks inefficiencies we’re too busy to fix, so measuring output alone often misses the real bottlenecks.
Yeah but impact metrics often just shift the problem-how do we measure *real* value when parallel work camouflages inefficiency behind sheer volume?
The orchestrator’s job is tough-balancing speed, clarity, and trust in a system where execution feels effortless. But is the real bottleneck not the lack of trust in the agents rather than in the coordination itself?
Seems like the orchestrator’s role is just shifting the bottleneck from execution to coordination-until we trust the system more than the person holding the baton.
Isn’t orchestration just another form of fragmentation? When execution is ‘free,’ clarity of purpose becomes the real bottleneck-faster devs don’t mean better outcomes.
True, but fragmentation kills context-orchestration isn’t just speed, it’s about keeping the big picture alive while juggling the pieces.
Orchestrating parallel work isn’t just about control-it’s about trust too. If the system relies too much on one person to keep everything in sync, isn’t that a single point of failure in disguise?
Isn’t the orchestrator’s job also about filtering out the noise? 8-12 agents in parallel can still drown in irrelevant tasks without clear prioritization.
Isn’t the orchestrator’s role also about preserving cognitive load? Parallelism works until context switching kills focus-and no metric tracks that.
So true-speed without direction just creates more cognitive waste. Maybe the orchestrator’s real skill is knowing what *not* to parallelize.
Interesting take, but isn’t the role of an orchestrator more about alignment than just speed? Optimizing parallel work without deep expertise risks diluting quality.
Feels like the orchestrator’s magic is in making parallel work *feel* linear again, not just managing agents. What if we measured outcomes instead of velocity?
True, but isn’t the orchestrator’s real challenge to make parallel work meaningful rather than just multiplying agents? Speed without coherence risks wasting talent.
Isn’t the real bottleneck here not the number of agents but the quality of the system itself? Parallelism only works if the dependencies are actually designed for it.
Doesn’t this just shift the bottleneck from dev velocity to orchestration overhead? 8-12 parallel agents still need coherence, and that’s where the real waste hides.
This rings painfully true - we’re optimizing for noise, not value. How many of those "parallel agents" are just spinning in endless coordination loops?
Fatigue hype 2026 : le tri entre modèle et harness