El gran aumento de la velocidad de escritura de software ya no es el único desafío para los equipos de desarrollo. A medida que herramientas como Cursor pasan de ofrecer sugerencias de código dentro del entorno de desarrollo a ejecutar tareas completas a partir de especificaciones y tickets, el problema puede pasar a ser la capacidad de la organización para determinar qué merece la pena construir, probarlo, desplegarlo de forma segura y después operarlo y mantenerlo.
Este es el eje de la presentación de Hannah Foxwell titulada «Reinventar el equipo de desarrollo», que se centra más en el impacto de la programación agéntica sobre las personas y los procesos que en las propias capacidades de los agentes. Foxwell basa su planteamiento en tres pilares que, en su opinión, siguen siendo importantes por mucho que se aceleren las herramientas.
De la falta de velocidad al exceso de capacidad
Foxwell describe un recorrido que comenzó con equipos que lanzaban software dos veces al año y que después, mediante Agile, la computación en la nube, DevOps y la entrega continua, llegó a varios despliegues diarios. Considera que lo que antes se presentaba como un objetivo lejano —la alta velocidad— empieza a convertirse en una realidad que las organizaciones todavía no saben cómo aprovechar.
En el modelo de programación agéntica, los agentes pueden descomponer especificaciones, escribir código y pruebas, y después ayudar en el despliegue y la supervisión. Pero esta capacidad puede crear una presión inversa sobre la gestión de producto: los equipos de desarrollo pueden ejecutar el trabajo más rápido de lo que la organización puede proporcionar requisitos claros y cualificados. Por ello, Foxwell no considera que la solución sea aceptar todas las ideas o solicitudes, ya que eso puede conducir a productos sobredimensionados y poco enfocados.
Primer pilar: construir lo que merece la pena construir
Foxwell subraya que el código no es el objetivo, sino un medio para resolver un problema real del usuario. Al reducirse el coste de probar ideas, resulta preferible crear prototipos y probarlos con los usuarios antes de convertirlos en un compromiso a largo plazo dentro del producto.
Entre los patrones que presenta el artículo se encuentra el «director de producto que programa prototipos», para acortar la distancia entre la idea y la prueba, o el emparejamiento de un director de producto con un desarrollador cuando la idea supera las capacidades del prototipado rápido. También señala el papel del ingeniero de campo, un ingeniero que trabaja cerca del cliente y está facultado para resolver sus problemas, así como el del «ingeniero de producto», que participa en la definición del producto porque lo utiliza o está cerca de sus usuarios.
Foxwell presenta experimentos para replantear el tamaño y la proporción de los equipos. En lugar del modelo de un equipo formado por entre seis y ocho desarrolladores y un director de producto, algunas organizaciones prueban con equipos más pequeños, mientras que Andrew Ng propuso un modelo inverso con dos directores de producto por cada desarrollador capaz de coordinar una flota de agentes. Estos modelos no se presentan como reglas fijas, sino como experimentos que reflejan el cambio del punto de estrangulamiento: de la capacidad de desarrollo a la claridad de los requisitos y la velocidad de las decisiones.
En cambio, el artículo advierte contra prácticas como lanzar una funcionalidad y pasar inmediatamente a otra tarea sin revisar su uso, aceptar todas las solicitudes de los clientes o tomar la opinión del responsable mejor remunerado como criterio de prioridad. En un entorno en el que escribir software se vuelve más rápido, la investigación de usuarios, la experiencia de uso y la capacidad de verificar el valor pueden convertirse en factores de diferenciación más importantes que la propia velocidad de ejecución.
Segundo pilar: la velocidad necesita seguridad
El aumento del volumen de cambios requiere una ruta de producción capaz de seguirle el ritmo. Foxwell advierte de que las brechas en la cobertura de pruebas y los pasos manuales pueden convertir la ruta de despliegue en un cuello de botella, haciendo que los cambios se acumulen antes de llegar a los usuarios.
Por ello, el artículo vincula la velocidad con las pruebas automatizadas y señala ejemplos del uso de agentes para crear pruebas continuas y ayudar a los equipos a abordar la deuda técnica, migrar desde plataformas antiguas y reestructurar bases de código. La idea no es añadir inteligencia artificial a un proceso lento, sino rediseñar el camino hacia producción para que soporte la nueva tasa de cambio.
Foxwell insiste en que la fiabilidad y la seguridad no son concesiones aceptables a cambio de velocidad. Propone apoyarse en indicadores, objetivos de nivel de servicio y presupuestos de error, junto con una política escrita que determine qué hará la organización cuando se supere el nivel de fallos aceptable; por ejemplo, ralentizar las versiones o dirigir recursos a la fiabilidad y la resiliencia.
También considera que los despliegues graduales, las banderas de funcionalidades, las pruebas A/B y los despliegues blue-green ayudan a gestionar numerosos cambios sin exponer a todos los usuarios a ellos de una sola vez. Asimismo, replantea el papel de los equipos de ingeniería de fiabilidad de sitios y de las plataformas internas, considerándolos funciones consultivas y habilitadoras que proporcionan una ruta segura y despejada para los equipos de desarrollo.
¿Qué cambia en la práctica?
La conclusión editorial de la presentación es que los agentes, por sí solos, no demuestran que los equipos de desarrollo vayan a hacerse más pequeños ni que los puestos de trabajo vayan a desaparecer. Lo que sí está claro es que los puntos de estrangulamiento se desplazarán: de la producción de código a la elección de problemas, la validación del valor, la ampliación de las pruebas, el control de la fiabilidad y la toma rápida de decisiones.
La pregunta abierta es si las organizaciones utilizarán la nueva capacidad para construir mejores productos y probar sus ideas, o si responderán acumulando más funcionalidades. Además, las nuevas proporciones entre desarrolladores, directores de producto, equipos de plataformas y equipos de fiabilidad siguen siendo experimentos, no resultados demostrados. Por ello, adoptar la programación agéntica exige medir su impacto en la calidad del producto, los incidentes y la experiencia del usuario, en lugar de limitarse al número de líneas o a la velocidad de las versiones.