A medida que los modelos subyacentes son más capaces, nuestra relación con la IA pasa de usarla como asistente de programación puntual a construir fábricas de software que crean funcionalidades por nosotros. Cuando hablamos de una fábrica de software, nos referimos al entorno completo que rodea al modelo: especificaciones estructuradas, capacidades personalizadas de los agentes, comités de revisión automatizados y controles deterministas de CI que convierten de manera fiable los requisitos en software funcional. Estamos convirtiendo a los agentes en miembros de pleno derecho del equipo.
Invertimos mucho en la alineación inicial y mucho en la revisión humana al final. La parte intermedia —la escritura efectiva del código— se reduce de días a horas.
El nuevo cuello de botella: la corrección y la revisión
Si escribir código ya no es el cuello de botella, ¿cuál lo es? Cuando un agente puede ejecutarse durante toda la noche, la limitación pasa completamente a ser la carga de revisión y la corrección.
Si el resultado es demasiado grande, el equipo se atasca cambiando constantemente de contexto. Si el resultado es de baja calidad, pasamos demasiado tiempo modificándolo. Dejar un agente ejecutándose durante toda la noche en una compilación probabilística para descubrir después que construyó algo equivocado consume nuestro recurso más limitado: el tiempo humano. Para mantener la velocidad, el resultado del agente debe tener un tamaño adecuado y ser correcto en gran medida.
Si el equipo dedica días a perfeccionar los resultados del agente, la solución no es esforzarse más en la revisión humana del código, sino mejorar la fábrica. Para proteger el tiempo humano, incorporamos una revisión rigurosa directamente en el ciclo de perfeccionamiento:
- El Consejo de Agentes: Ya no se asigna a una persona la revisión de una solicitud de incorporación de cambios hasta que esta haya superado un ciclo de revisión automatizada con varios agentes que comprueba el cumplimiento de las especificaciones, la corrección y la seguridad.
- Experiencia sénior codificada: Hicimos que los agentes analizaran meses de comentarios históricos sobre solicitudes de incorporación de cambios realizados por nuestros expertos en el ámbito. Ahora, una habilidad personalizada revisa la funcionalidad con exactamente el mismo criterio que los miembros sénior de nuestro equipo.
- Orquestación inteligente: Usamos modelos más potentes como coordinadores y modelos menos potentes para tareas más sencillas, ejecutando varios agentes en paralelo para gestionar eficazmente la pesada carga de revisión.
- Orquestación inteligente: Usamos modelos más potentes como coordinadores y modelos menos potentes para tareas más sencillas, ejecutando varios agentes en paralelo para gestionar eficazmente la considerable carga de revisión.
Como resultado, el enfoque del equipo cambia. En lugar de limitarnos a escribir código para funcionalidades, también dedicamos tiempo a mejorar continuamente la fábrica que construye el código: perfeccionamos las instrucciones de los agentes, desarrollamos nuevas habilidades y usamos evaluaciones para verificar rigurosamente la calidad.
Alineación: el proceso de «interrogatorio»
Si quieres alcanzar un 90 % de corrección en el primer intento, no puedes plantearle a un agente un problema impreciso. Los agentes no pueden leerte la mente; los detalles no especificados se convierten en suposiciones implícitas.
Para evitarlo, apostamos firmemente por el «interrogatorio» (un guiño a Matt Pocock, quien popularizó el término). Es un proceso intenso e iterativo de descubrimiento en el que el agente interroga al equipo para sacar a la luz requisitos ocultos, casos extremos y restricciones arquitectónicas. Sacamos el conocimiento de nuestras cabezas y lo ponemos por escrito antes de escribir una sola línea de código.
Combinamos el rigor de un diseño exhaustivo desde el principio con los rápidos ciclos de retroalimentación de Agile: cuando la fase de construcción se comprime hasta durar horas, el coste de iterar sobre una especificación se desploma.
Esta necesidad de alineación inicial se está extendiendo hacia las fases anteriores. Como escribir código ya no es el principal cuello de botella, el coste de iniciar un proyecto con información poco clara se amplifica por el retrabajo de los agentes. Ahora, el equipo de producto utiliza sesiones con agentes desde la concepción para interrogar a las partes interesadas, convertir las incógnitas desconocidas en conocidas y lograr una alineación profunda antes incluso de que comience la ingeniería.
Estructura: balas trazadoras verticales
Una vez consolidada la alineación, estructuramos la ejecución mediante segmentos verticales. Aunque no es un concepto totalmente nuevo, lo habitual para nosotros ha sido construir horizontalmente e integrar después. En un flujo de trabajo agéntico, la división vertical se vuelve fundamental.
En lugar de construir componentes horizontales, desarrollamos funcionalidades completamente terminadas de principio a fin. Un segmento vertical atraviesa todas las partes del sistema, desde las pruebas unitarias hasta la CLI.
Esto es crucial porque permite al agente probar su propio trabajo. El agente no se limita a escribir código: ejecuta la aplicación desplegada e interactúa con ella como lo haría un usuario. El agente es el ciclo de retroalimentación. Al experimentar el sistema de primera mano, descubre qué funciona y realiza iteraciones hasta que la funcionalidad funcione según lo previsto. Cuando los miembros del equipo humano revisan finalmente el producto, podemos experimentarlo y verificarlo exactamente de la misma manera.
Fricción y adaptación
Avanzar rápido como desarrollador en solitario es una cosa, pero operar software financiero empresarial a escala es otra. No estamos delegando la comprensión en nuestros agentes; estamos delegando el trabajo pesado. Queremos eliminar la capa intermedia para poder centrarnos en crear soluciones y tomar decisiones.
Para que esto funcione en un equipo más grande, tenemos que adaptarnos continuamente:
- Límites estrictos de WIP en lugar de paralelización: ejecutar varios segmentos simultáneamente no funciona. Cuando los agentes encuentran problemas, sugieren o realizan mejoras de forma autónoma en nuestra fábrica. Trabajar en partes paralelas significa que los agentes construyen sobre la misma base defectuosa y no aprovechan los aprendizajes de los demás. Un límite estricto de WIP de uno garantiza que el siguiente segmento se beneficie de las últimas actualizaciones del entorno. Es un «flujo de una sola pieza»: hacer una cosa de principio a fin es más rápido que hacer muchas cosas a la vez.
- Revisiones en grupo en lugar de entregas individuales: que los ingenieros que trabajan solos revisen los resultados de los agentes da lugar a un ciclo lento de consultas a expertos en el dominio. Nos adaptamos pasando a las revisiones en grupo: organizamos una llamada, revisamos juntos la PR y redactamos comentarios prácticos para que el agente los corrija.
- Agentes para comprender: seguimos leyendo y revisando cada línea, pero también aprovechamos los agentes para generar artefactos HTML y documentos de una página que explican conceptos de alto nivel y ayudan a las personas a adentrarse en nuevos dominios.
- Dimensionamiento adecuado de las tareas: al principio dividimos los backends en segmentos grandes, pero pronto nos dimos cuenta de que a menudo son demasiado grandes para asimilarlos de forma eficiente durante la noche. Pasamos a dimensionar las tareas adecuadamente y las dividimos en bloques más pequeños y concretos. No existe una solución universal; ajustamos continuamente los límites basándonos en las lecciones de los segmentos anteriores.
La estrategia es la adaptación continua
Estas adaptaciones funcionan. A medida que dimensionamos adecuadamente las tareas, pasamos a las revisiones en grupo y aplicamos límites estrictos de WIP, el ritmo aumenta y disminuye la carga de revisión. La trayectoria se vuelve clara: construir la fábrica es el resultado natural del proceso de aprendizaje, seguido de un marcado aumento de la velocidad una vez que el ciclo de perfeccionamiento empieza a funcionar.
La conclusión más importante es que debemos tratar la «fábrica de software» como un producto de primer nivel. Seguimos en proceso de validación, pero nuestros esfuerzos están pasando de escribir código de funcionalidades a mejorar el sistema que lo escribe.
No sabemos exactamente cómo será la fábrica de software de Strike dentro de tres o seis meses, y ese es precisamente el objetivo. El entorno agéntico cambia rápidamente, y tratar de predecir su forma exacta es una batalla perdida. Nuestro trabajo consiste en adaptarnos a él: incorporar nuevas herramientas, ajustar nuestros flujos de trabajo y definir continuamente nuestra propia forma de construir. La estrategia no es un proceso inamovible; la estrategia es la adaptación continua.
