El cuello de botella de la ingeniería de software ya no es el código.

      Durante la mayor parte de la historia del software, la planificación era sagrada. Tenías que planificar antes de que alguien tocara un teclado, porque el costo de construir lo incorrecto podía ser tan punitivo, especialmente para las startups, que hacerlo bien desde el principio era la única estrategia racional.

      La implementación era cara, el tiempo de ingeniería era escaso y cambiar de dirección una vez que el equipo se había comprometido con un enfoque podía retrasarte meses.

      Todo el aparato del desarrollo moderno de software, las hojas de ruta, los marcos de priorización, los rituales de planificación trimestral, surgió como respuesta a ese único hecho económico.

      Ese hecho ya no es cierto, y la mayoría de las organizaciones de ingeniería no se han puesto al día.

      Las herramientas de codificación de IA han colapsado el costo de convertir una idea en software funcional. Lo que solía llevar semanas de implementación ahora se puede explorar en horas.

      Puedes pedirle a un agente que prototipe tres enfoques competidores durante la noche y desechar los dos que no se sostienen cuando te despiertas por la mañana.

      Puedes desafiar una suposición con una demostración funcional en lugar de una presentación. La economía se ha invertido: la planificación y el proceso solían ser más baratos que construir, y ahora construir es más barato que las reuniones que tendrías para decidir qué construir o cómo hacerlo.

      Esto cambia todo sobre cómo deberían operar los equipos de ingeniería. Ya no existe un plan perfecto, y aunque lo hubiera, el tiempo que llevaría producir uno significa que ya has perdido ante alguien que acaba de empezar a construir.

      En Synthesia, decidimos probar esta idea de la manera más directa posible. Cada trimestre, nuestros equipos de producto, ingeniería e I+D se reúnen en Londres para planificar los próximos tres meses de trabajo.

      Históricamente, pasábamos la mayor parte de ese tiempo en salas analizando, debatiendo y priorizando. El objetivo era salir con un plan que fuera lo suficientemente bueno como para justificar el costo de implementación.

      Durante nuestra reunión más reciente, invertimos la secuencia. Reemplazamos los primeros dos días de planificación con un hackathon. 200 personas de ingeniería, producto, diseño, legal, investigación y talento formaron 70 equipos y construyeron durante 28 horas seguidas.

      El breve fue simple: toma una idea, constrúyela, convierte el resultado en un video de demostración de dos minutos. Sin especificaciones detalladas, sin sobre-planificación, solo construir.

      Lo que sucedió nos sorprendió.

      Uno de los equipos ganadores, un grupo de cinco ingenieros, reconstruyó completamente nuestro editor de video desde cero. El editor de video proporciona una interfaz similar a PowerPoint donde los usuarios de nuestra plataforma crean videos con avatares de IA.

      Los ingenieros entregaron una reimaginación completa del producto de principio a fin, centrada en la interactividad, narrativas ramificadas y narración con múltiples avatares.

      Esto no fue un caso aislado; en todos los 70 equipos, surgió el mismo patrón: cuando le das a las personas enfoque y eliminas la fricción, pueden moverse mucho más rápido de lo que cualquiera esperaba.

      La lección que sacamos de este experimento es que la ejecución ya no es la limitación, el juicio lo es.

      Esto podría contradecir la suposición operativa con la que la mayoría de los líderes de ingeniería han estado trabajando durante toda su carrera. Hemos pasado años construyendo organizaciones optimizadas para el rendimiento de ejecución: cuántas funciones se enviaron, cuántos puntos de historia se completaron, cuán rápido se reduce el backlog.

      Pero cuando construir se vuelve barato, el cuello de botella se desplaza hacia arriba. La parte difícil ya no es escribir el código. En cambio, se trata de saber qué código vale la pena escribir en primer lugar.

      Cuando digo juicio, me refiero a cuatro cosas específicas. Primero, la capacidad de ayudar a los gerentes de producto a abordar el problema del cliente correcto más rápido, lo que requiere distinguir entre lo que es intelectualmente interesante y lo que realmente importa a los usuarios y al negocio.

      En segundo lugar, definir cómo se ve lo "genial" antes de comenzar, porque si no puedes articular ese estándar, no lo reconocerás cuando lo veas.

      En tercer lugar, se trata de saber cuándo algo es lo suficientemente bueno para ponerlo frente a un usuario, no perfecto, no pulido, solo suficiente para aprender de ello. Y finalmente, ser capaz de matar ideas rápidamente.

      Cuando puedes probar muchas cosas en paralelo, la habilidad más valiosa se convierte en dejar ir las que no están funcionando, en lugar de enamorarte de tu primer intento porque cuesta tanto producirlo.

      Los mejores equipos de ingeniería en los próximos años no ganarán por la producción de código, ganarán por el gusto.

      Esto tiene implicaciones reales sobre cómo pensamos en el rol de la ingeniería en sí. Estamos pasando de ser constructores a ser orquestadores. Los agentes de IA ahora pueden ejecutar grandes partes del proceso de desarrollo de principio a fin.

      El trabajo del ingeniero se convierte cada vez más en elegir los problemas correctos, revisar los resultados e iterar a gran velocidad. Menos tiempo escribiendo cada línea y más tiempo dirigiendo sistemas que escriben líneas por ti.

      A algunas personas les resulta amenazante. Yo creo que es lo contrario. Las partes tediosas de la ingeniería, el boilerplate, el cableado repetitivo, el trabajo que nunca fue realmente la parte interesante, eso es lo que se automatiza primero.

      Lo que queda es el trabajo en el que los ingenieros siempre han deseado poder pasar más tiempo: entender el problema en profundidad, diseñar soluciones elegantes, tomar las decisiones difíciles sobre qué construir y qué desechar. La artesanía se destila a su esencia.

      Nos estamos responsabilizando por este cambio en Synthesia. Estamos rastreando el uso semana a semana de herramientas de codificación de IA como Claude Code y Codex, y estamos midiendo cuán rápido los equipos pueden pasar de la idea al prototipo y a la retroalimentación del usuario. La métrica que importa ahora es la velocidad del ciclo de aprendizaje, no el volumen de código producido.

      La dirección hacia la que nos dirigimos es lo que yo llamaría desarrollo en modo automático: ciclos ajustados desde el prototipo hasta las pruebas de usuario, hasta el envío y la refinación. Agile está siendo reemplazado por algo aún más rápido, algo donde la brecha entre tener una idea y probarla contra la realidad se reduce a casi nada.

      Así que la pregunta que importa para cada líder de ingeniería que lee esto ya no es "¿podemos construir esto?" Esa pregunta ya ha sido respondida. Puedes construir casi cualquier cosa, de manera notablemente rápida, con un pequeño equipo y las herramientas adecuadas.

      La pregunta ahora es: ¿qué deberías construir? ¿Y tienes el juicio para saberlo?