La IA aceleró la escritura de código, pero trasladó el cuello de botella

Con trabajo manual, la unidad era una modificación que yo mismo escribía. Con Copilot, seguía conduciendo línea por línea, pero completaba más rápido. Con un chat, podía delegar una explicación o un fragmento y después trasladarlo al repositorio.

Los agentes cambiaron algo más profundo. Ya no delego solamente texto: puedo delegar una misión acotada dentro de un repositorio, con acceso al código, herramientas para verificarlo y una condición de finalización. Incluso puedo hacer que varias investigaciones avancen al mismo tiempo.

Eso aumenta la superficie que puedo cubrir, pero también separa producción de comprensión. Que exista un diff, una batería de tests o una respuesta convincente no significa que yo haya tomado todavía una buena decisión.

Un pedido ambiguo hecho a una persona suele abrir una conversación. El mismo pedido enviado a varios agentes puede producir varias interpretaciones completas antes de que yo note que la pregunta estaba mal formulada.

Por eso empecé a invertir más tiempo en especificaciones, criterios de aceptación y límites. Qué sistema es la fuente de verdad. Qué se puede modificar. Qué debe permanecer intacto. Cómo se demuestra que el resultado funciona. Qué decisión requiere volver a una persona.

La especificación no necesita describir cada línea. Su trabajo es reducir el espacio de respuestas plausibles pero equivocadas. Cuanto más barata se vuelve la implementación, más caro resulta descubrir tarde que resolvimos con precisión el problema incorrecto.

Los agentes son muy buenos para separar investigaciones independientes: recorrer repositorios, comparar alternativas, ejecutar pruebas o preparar cambios aislados. El problema aparece cuando dos tareas comparten supuestos, archivos o una decisión de arquitectura que todavía no está cerrada.

Ahí el paralelismo puede producir velocidad local y conflicto global. Dos ramas pueden estar verdes por separado y seguir siendo incompatibles. Un agente puede optimizar una pieza mientras otro cambia el contrato que esa pieza daba por estable.

Aprendí a trabajar por olas: primero resolver las decisiones que bloquean el resto; después abrir tareas verdaderamente independientes; finalmente integrar de manera deliberada. Más agentes no siempre reducen el tiempo. A veces sólo permiten equivocarse en paralelo.

Cuando el volumen de cambios crece, una revisión puramente línea por línea deja huecos. Necesito comprobar también la intención, las fuentes usadas, los caminos que quedaron fuera y la evidencia producida por el propio trabajo.

En la auditoría de infraestructura, por ejemplo, los agentes hicieron viable recorrer inventarios, probar endpoints y contrastar proveedores. Mi trabajo no desapareció: tuve que definir el universo, prohibir cambios sobre producción, separar datos verificados de estimaciones y pedir una explicación cuando el primer corte de 106 proyectos terminó convirtiéndose en 113.

El resultado correcto no era un reporte largo. Era una cadena que permitiera volver desde una conclusión hasta su evidencia y distinguir qué seguía necesitando criterio humano.

Si producir un cambio es barato, descartar un cambio malo también debería serlo. Para eso necesito gates que no dependan de recordar una checklist distinta en cada entrega: tipos, lint, tests, builds, revisión visual, controles de seguridad y verificación después del deploy cuando corresponde.

Un check verde no demuestra que el producto sea correcto. Pero una secuencia de controles bien elegida reduce la cantidad de dudas que tienen que resolverse con atención humana. El objetivo no es automatizar el juicio, sino reservarlo para las decisiones que realmente lo necesitan.

También cambió mi relación con el rollback. Cuando el sistema puede generar otra versión rápidamente, reconocer que una dirección no sirve deja de ser una derrota costosa. Lo peligroso es integrar por inercia sólo porque ya existe una implementación convincente.

Una parte creciente de mi trabajo ya no consiste en escribir la solución final. Consiste en definir el terreno donde una solución puede construirse sin perder coherencia: specs, ADRs, reglas compartidas, ownership, criterios de aceptación y mecanismos de revisión.

Eso puede verse como menos producción porque no siempre termina en un commit funcional. En realidad es lo que permite que la producción de varios agentes y personas llegue al mismo sistema sin convertir la velocidad en entropía.

El cambio también exige una habilidad incómoda: frenar. Si aparecen demasiados resultados para revisar bien, lanzar otro agente no aumenta la capacidad. Sólo agranda la cola.

Puedo reconstruir etapas de mi trabajo manual, con Copilot, con ChatGPT y con agentes. También puedo contar commits, sesiones, pull requests o worktrees. Ninguna de esas comparaciones es un experimento controlado: cambiaron los proyectos, mi experiencia, mis responsabilidades y la complejidad de lo que estaba construyendo.

Por eso no puedo sostener que los agentes me hicieron una cantidad exacta de veces más productivo. Sí puedo sostener algo más útil: ahora puedo explorar y producir muchas más alternativas, y eso desplazó una proporción mayor del trabajo hacia la dirección y la verificación.

La métrica que me interesa ya no es cuánto código apareció. Es cuánto tiempo pasa desde una pregunta hasta una decisión defendible y cuánto del resultado puedo integrar sin crear una deuda que todavía no entiendo.

Cuando escribir código era caro, producir más podía parecer casi siempre una ventaja. Cuando producir se vuelve abundante, la escasez cambia de lugar.

Ahora lo escaso es el contexto bien elegido, una especificación que elimine ambigüedad, una revisión capaz de detectar conflictos y el criterio para decidir qué no integrar. La ingeniería sigue estando ahí; simplemente dejó de coincidir tanto con el acto de tipear.

La diferencia no la hará quien pueda generar la mayor cantidad de cambios. La hará quien pueda convertir esa capacidad en un sistema que conserve dirección, evidencia y responsabilidad mientras se mueve más rápido.