El cuello de botella nunca fue escribir código

La IA no solo hizo que escribir código fuera más rápido: movió el cuello de botella por completo. Los equipos que aprendan a ejecutar agentes en paralelo resultarán irreconocibles para los que aún esperan un diff a la vez.

La primera versión de mi ciclo de desarrollo con IA era simple. Pedirle al asistente que hiciera la tarea A. Esperar. Revisar el diff. Pasar a la tarea B. El asistente era un compañero de programación en pareja más rápido. Seguía siendo una pareja. Seguía siendo una cosa a la vez.

Ese modelo duró unos tres meses. No es como trabajo ahora.

Lo que hago ahora es ejecutar múltiples asistentes de IA de codificación en paralelo contra la misma base de código, cada uno en su propio worktree de git, cada uno en su propia rama, cada uno trabajando en un problema diferente al mismo tiempo. En un momento dado hay entre cinco y diez ramas activas a través de los repositorios. Distintos agentes empujando en distintas partes del motor simultáneamente. Yo reviso y fusiono en lugar de escribir y esperar.

El cambio en mi trabajo es el post.

Cómo se ve un fin de semana real

Un fin de semana de mediados de marzo. A través de los cinco repositorios, aterrizaron 112 commits entre el desayuno del sábado y la cena del domingo. 66 tenían a una IA como autor de registro. 47 los tenía yo. El resto fueron fusiones y limpiezas impulsadas por revisión.

El trabajo no fue un proyecto. Fueron cinco. Ports a WASM para nueve géneros. Integración del renderizador Metal de iOS. Un ejecutor de paquetes de contenido con veintiún assets a través de un pipeline de siete etapas. Etapas cinco a siete del género de batalla de cartas. Optimizaciones de rendimiento para el build web. Todo eso ocurrió a lo largo de los mismos dos días en ramas paralelas que aterrizaron durante cada tarde y noche.

Ningún humano solo escribe 112 commits en un fin de semana desde un escritorio de mesa de cocina. Ningún humano solo puede sostener cinco flujos de trabajo paralelos en una sola cabeza y escribir el código para cada uno de ellos. El modelo que tenía tres meses antes no podría haber producido este fin de semana.

El modelo que tengo ahora sí.

El cuello de botella se mueve

Cuando el trabajo es secuencial, el cuello de botella es escribir código. La siguiente línea de código no existe hasta que alguien la escribe. La IA hizo que esa línea fuera más rápida. No cambió cuál paso era lento.

Cuando el trabajo es paralelo, el cuello de botella es la selección. Cuatro agentes regresan con cuatro diffs. Dos de ellos son buenos. Uno va en la dirección correcta pero necesita trabajo. Uno no debería haberse escrito. El paso lento es decidir cuál es cuál y fusionar los dos que sobreviven.

Ese es un trabajo completamente distinto del que me entrené para hacer. Menos escribir. Más clasificar. Menos síntesis. Más selección.

La forma del fin de semana:

• Sábado por la mañana: enmarcado. Qué cuatro problemas merecen cuatro intentos paralelos. Cuál es el criterio de éxito para cada uno. Cuál es la forma aproximada de una respuesta aceptable.
• A lo largo de ambos días: verificación puntual. ¿Van los agentes por buen camino? ¿Alguno produjo con confianza algo equivocado en los primeros treinta minutos? ¿Alguien está atascado?
• Al final de la tarde, ambos días: revisión y fusión. Los diffs llegan. Leo cada uno con el criterio de éxito en mente. Fusiono los que aciertan. Vuelvo a intentar o cierro los que no. Capturo lo que los intentos fallidos me enseñaron sobre el problema.
• Final del domingo: anoto qué envió el fin de semana y cuáles son los próximos cuatro problemas.

Se parece más a ser tech lead de un equipo de cuatro que a ser un IC senior con un copiloto. Usa músculos distintos. Los que usa son inusualmente transferibles entre dominios.

Dónde esto se combina con los archivos .raku

Los archivos de experiencia que ejecuta nuestro motor son archivos .raku: JSON, versionados por esquema, validables, revisables como código. El formato se diseñó pensando en este flujo de trabajo de agentes en paralelo.

Cuando un agente edita un archivo .raku, el diff aparece de la misma forma que un diff de código. Un segundo agente puede revisar el trabajo del primero. Puedo ejecutar un tercer agente para verificar a ambos. La decisión de fusión es mía. Todo el conjunto encaja dentro de la misma disciplina de pull request que uso para el runtime.

Si .raku hubiera sido un asset binario, nada de esto funcionaría. La elección del formato y la elección del flujo de trabajo son consecuencia de la misma decisión arquitectónica: las experiencias son código, el trabajo de desarrollo es revisión de código, los agentes participan en el ciclo porque el ciclo acepta código.

El formato de archivo es estructural. Es lo que permite que el equipo escale a través de agentes en lugar de contrataciones.

Qué funciona en la práctica

Tres patrones en los que me he asentado.

Uno: emparejar agentes en un problema. Cuando algo no es trivial, dos asistentes con entrenamiento distinto tienden a discrepar de forma productiva. Los ejecuto en ramas separadas con el mismo prompt, luego comparo sus respuestas. Los desacuerdos son donde va la atención real de revisión.

Dos: dedicar un agente a la revisión. Mantengo a uno de los cuatro asistentes en un rol exclusivo de revisión cualquier día dado. Nunca escribe el primer borrador. Solo critica los diffs que producen los demás. El costo de ejecutar un revisor dedicado es bajo. La tasa de detección de bugs es significativa.

Tres: mantener el contexto del agente acotado. Un solo agente en una sola rama en un solo problema es rápido. Un solo agente en un problema extenso con cinco horas de contexto se desvía y produce trabajo de menor calidad. La solución es dividir los problemas en piezas más pequeñas y rotar el contexto con frecuencia.

Qué se rompe

Siendo honesto sobre lo que no funciona.

La sobrecarga de coordinación es real. Dos agentes en el mismo archivo al mismo tiempo producen conflictos de fusión que tengo que resolver. El costo es pequeño por conflicto pero se acumula. Mitigación: mantener a los agentes en archivos distintos cuando sea posible, y aceptar que el paso de convergencia es parte del flujo de trabajo.

La fatiga de revisión es real. Revisar cuatro diffs al final de cada día es más difícil que revisar cuatro diffs secuenciales a lo largo de cuatro días. Las decisiones son más densas. Corto la jornada laboral más temprano en los días de agentes en paralelo que cuando el trabajo era secuencial.

La tentación de conservarlo todo es real. Cuando dos agentes producen algo razonable, el movimiento perezoso es fusionar ambos. El movimiento disciplinado es elegir uno. Fusionar ambos contamina la base de código con dos formas de hacer lo mismo, lo que cuesta más de lo que habría costado simplemente reintentar con el perdedor.

La deriva de contexto en sesiones paralelas de larga duración es real. Una rama que ha estado abierta un día acumula suposiciones que el agente hizo sobre la base de código en el momento en que empezó. Para el anochecer, esas suposiciones pueden estar obsoletas. La solución es ramas de vida corta, sin piedad.

No todo se paraleliza. Las refactorizaciones transversales con invariantes sutiles quieren un solo pase cuidadoso, no cuatro intentos paralelos. La habilidad está en saber qué problemas se dividen limpiamente y cuáles no. Algunos días siguen siendo días secuenciales.

Qué significa esto para los líderes de ingeniería

Si tu equipo está ejecutando el modelo secuencial con IA atornillada encima, el siguiente paso no es “usar un mejor modelo.” Es “usar múltiples agentes a la vez.” El techo de capacidad es más alto. El techo de habilidad también es más alto, y mueve el rol senior de la producción al enmarcado, la validación y la selección. Esa es la misma dirección de viaje que veo en cualquier otra disciplina que esté ejecutando bien la IA ahora mismo.

Los equipos que descifren los flujos de trabajo de agentes en paralelo durante los próximos dos años resultarán irreconocibles para los equipos que todavía ejecutan el modelo secuencial. La forma del trabajo es lo que cambia. No la herramienta.

112 commits a lo largo de dos días. Cerrando la laptop el domingo con la mayoría de ellos en verde.