Artesanía Jul 31, 2026 at 22:2015Añadir a favoritos

La CTO de Thoughtworks plante la pregunta que la métrica « funciones/semana » evita: cuando la ejecución se vuelve gratuita, no se crean desarrolladores más rápidos, se crean directores de orquesta, y a nadie los forma.
Rachel Laycock, CTO de Thoughtworks, publica el 31 de julio de 2026 en « Rachel's ramblings » (martinfowler.com) una entrada — « The Conductor Developer » — que reformula lo que dos años de IA generativa han modificado en la profesión. El marco que rechaza: « iremos más rápido». El que propone: el recurso escaso ha cambiado, y con él, el rol.
Observa a ingenieros que ejecutan entre 8 y 12 agentes simultáneamente. El trabajo visible ya no es el teclado, sino la orquestación: qué agente, en qué rama, qué prompt, qué revisión. La comparación que plantea es directa: la del director de orquesta, que no toca ningún instrumento pero tiene la partitura completa en mente. Así formula el desplazamiento: la experiencia no ha desaparecido, simplemente se aplica en otro lugar y con mucha más frecuencia, porque la ejecución se ha vuelto rápida.
Es un desplazamiento de cuello de botella, no una reducción de exigencias. Si la parte de «escribir código» ya no es dominante en el flujo, no es gratis: «decidir, enmarcar, revisar, mantener el sistema» se convierte en la restricción vinculante. Laycock no teoriza: describe un estado ya instalado en los mejores, y deja abierta la pregunta: ¿cómo rediseñamos las carreras de ingeniero cuando la atención humana se convierte en el recurso escaso?
Tres trayectorias plausibles en 12-24 meses. (1) Consolidación mediante herramientas: los mejores devs construyen arneses que distribuyen la atención (colas de agentes, listas de verificación, compuertas). (2) Fatiga y burn-out silencioso: orquestar 10 agentes es un modo «presidencia de sesión» de 8 h/día, muy distinto al flow. (3) Redefinición de roles: los arquitectos ganan, los mid-level deben elegir entre ascender a conductor o descender a especialista-instrumentista.
Dos gestos concretos, extraídos de la tesis: dejar de medir la productividad en features/semana (métrica de compositor, no de director de orquesta); formar en gestión de carga cognitiva como antes se formaba en clean code hace diez años.
El principal, que Laycock nombra sin responder: las carreras no han sido diseñadas para esto. Sabemos promover a un buen ejecutante a arquitecto; aún no sabemos fabricar, a nivel de escuela o junior, a un director de orquesta.
Los post-mortems de equipos 100 % nativos en agentes más allá de las demos, y las primeras ofertas de empleo que listan explícitamente «orquestación de N agentes» como responsabilidad —no como buzzword.
Artículo producido por inteligencia artificial, revisado bajo control editorial humano.
Inicia sesión para unirte a la conversación.
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