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 fue sacrosanta. Había que planificar antes de que alguien tocara el teclado, porque el costo de hacer las cosas mal podía ser tan agotador, especialmente para las nuevas empresas, que hacerlo bien era la única estrategia razonable.

La implementación era costosa, el tiempo de ingeniería era corto y cambiar de dirección una vez que el equipo se comprometía con un enfoque podía demorar meses.

Toda la maquinaria del desarrollo de software moderno, las hojas de ruta, las estructuras de prioridades, los rituales de planificación trimestral, surgieron de la respuesta a esa singular realidad económica.

Este hecho ya no es cierto y la mayoría de las empresas de ingeniería no se han dado cuenta.

Las herramientas de codificación de IA han desglosado el costo de convertir una idea en software funcional. Lo que antes tomaba semanas implementar ahora puede explorarse en horas.

Puede pedirle a un agente que cree un prototipo de tres enfoques competitivos durante la noche y descarte los dos que no funcionan cuando se despierta por la mañana.

Puede desafiar una suposición con una demostración funcional en lugar de una presentación de diapositivas. La economía ha cambiado: la planificación y los procesos solían ser más baratos que construir, y ahora los edificios son más baratos que las reuniones que se celebran para decidir qué construir o cómo construirlo.

Cambia todo acerca de cómo trabajan los equipos de ingeniería. No existe un plan perfecto, e incluso si lo hubiera, el tiempo que lleva crear uno significa que ya estás perdido para alguien que acaba de empezar a construir.

En Synthesia decidimos probar este concepto de la forma más directa. 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, pasamos la mayor parte del tiempo analizando, debatiendo y priorizando salas. El objetivo era surgir con un plan que fuera suficiente para justificar el costo de implementación.

Durante nuestra reunión más reciente, invertimos el orden. Reemplazamos los primeros dos días de planificación con hackatones. 200 personas de ingeniería, productos, diseño, asuntos legales, investigación y talento forman 70 equipos y se construyen en 28 horas.

El resumen era simple: tomar una idea, desarrollarla y convertir el resultado en un vídeo de demostración de dos minutos. Sin especificaciones detalladas ni planificación adicional: simplemente cree.

Lo que pasó nos sorprendió.

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

Los ingenieros realizaron una reinvención completa del producto, de principio a fin, centrándose en la interactividad, la narrativa ramificada y la narración multiencarnada.

No fue un caso atípico; En los 70 equipos, surgió el mismo patrón: cuando le das a las personas concentración y eliminas la fricción, pueden moverse mucho más rápido de lo que nadie esperaba.

La lección que aprendimos de este experimento es que la pena de muerte ya no es un elemento disuasivo, sino un juicio.

Esto puede ser contrario al supuesto operativo con el que la mayoría de los líderes de ingeniería han estado trabajando durante toda su carrera. Hemos pasado años creando organizaciones optimizadas para el rendimiento de ejecución: cuántas funciones se envían, cuántos puntos de la historia se completan, qué tan rápido se reduce el trabajo pendiente.

Pero cuando la construcción se vuelve más barata, la barrera avanza hacia arriba. Lo difícil ya no es escribir el código. En cambio, se trata de saber qué código se debe escribir primero.

Cuando digo justicia, me refiero a cuatro cosas específicas. En primer lugar, la capacidad de ayudar a los gerentes de producto a resolver rápidamente los problemas correctos de los clientes, lo que requiere distinguir entre lo que es intelectualmente interesante y lo que realmente importa para los usuarios y la empresa.

En segundo lugar, definir qué significa "genial" antes de comenzar, porque si no puedes articular ese valor, no lo sabrás cuando lo veas.

En tercer lugar, se trata de saber cuándo algo es lo suficientemente bueno para presentárselo al usuario, no perfecto, no pulido, sólo lo suficientemente bueno para aprender. Y por último, poder acabar con las ideas rápidamente.

Cuando puedes probar muchas cosas en paralelo, en lugar de enamorarte del primer intento, la habilidad más valiosa es dejar de lado las que no funcionan porque cuestan demasiado.

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

La forma en que pensamos sobre los roles de ingeniería tiene implicaciones reales. Estamos pasando de creadores a orquestadores. Los agentes de IA ahora pueden impulsar gran parte del proceso de desarrollo de un extremo a otro.

El trabajo del ingeniero consiste cada vez más en elegir los problemas correctos, revisar los resultados e iterar a gran velocidad. Los sistemas guiados dedican menos tiempo a escribir cada línea y más tiempo a escribir líneas por usted.

Algunas personas encuentran esto amenazante. Creo que es todo lo contrario. La parte tediosa de la ingeniería, el texto repetitivo, el cableado repetitivo, el trabajo que nunca fue realmente interesante, es el primero en automatizarse.

Lo que queda es el trabajo al que los ingenieros siempre desearían poder dedicar más tiempo: comprender profundamente el problema, diseñar soluciones elegantes, tomar decisiones difíciles sobre qué construir y qué desechar. La artesanía se destila hasta su esencia.

En Synthesia nos hacemos responsables de estos cambios. Realizamos un seguimiento del uso semanal de herramientas de codificación de IA como Cloud Code y Codex, y medimos la rapidez con la que los equipos pueden pasar de la idea al prototipo y a los comentarios de los usuarios. La métrica que importa ahora es la velocidad del ciclo de aprendizaje, no la cantidad de código producido.

La dirección en la que nos dirigimos es lo que yo llamaría desarrollo en modo automático: un circuito cerrado desde el prototipo hasta las pruebas de usuario, el refinamiento y el envío. Lo ágil está siendo reemplazado por algo aún más rápido, algo en lo que la brecha entre tener una intuición y probarla con la realidad se reduce a casi nada.

Entonces, la pregunta importante para todo líder de ingeniería que lea esto es "¿Podemos construirlo?" Esa pregunta ha sido respondida. Puedes crear casi cualquier cosa con un equipo pequeño y las herramientas adecuadas, con una rapidez sorprendente.

Ahora la pregunta es: ¿qué deberías construir? ¿Y tienes un juicio que saber?