Ahora tengo un becario que escribe el código que yo diseño.”

Últimamente me la he pasado escribiendo menos código. En donde estoy han optado por usar agentes de IA para escribir código. Y me ha pasado algo curioso.

Todos estamos entregando más rápido. Yo también he pasado a terminar mis tareas mucho más rápido que antes. Pero sigo siendo más lento que el resto.

Y hay otra cosa que me llama la atención: ellos suelen terminarse sus tokens. Yo rara vez llego a ese punto.

Los que me conocen saben que he sido bastante crítico con la generación de código mediante inteligencia artificial. No porque crea que la IA no pueda programar, si no por qué ha sido entrenada con repositorios que no siempre tienen o siguen estándares de código.

Mi dilema no es ese, es saber que ambigüedades dejaremos resolver, para que una IA lo resuelva según el entrenamiento, y tome una decisión basada en la estadística , no basada a nuestras necesidades reales.

Hace poco leí una frase que me gustó mucho: la IA es solamente una herramienta y la persona sigue teniendo la última palabra.

Supongo que es en eso en la que radica la diferencia en cómo he terminado usando agentes. Me funciona mejor tratarlos como juniors; A un junior no le entregaría jamás un problema ambiguo de negocio y le diría: “resuélvelo”, primero intentaría entender qué necesitamos, discutiría con él el requerimiento, dejaría que me hiciera preguntas, que encontrara contradicciones, que cuestionara mis supuestos y que me ayudara a encontrar cosas que quizá yo no había visto.

Con los agentes hago prácticamente lo mismo: soy yo quien comienza definiendo el requerimiento; después, utilizo agentes para revisarlo conmigo.

A partir de ahí, vamos refinando qué queremos hacer y qué no, cómo se comporta actualmente el sistema, cómo debería comportarse, qué decisiones de arquitectura ya están tomadas, qué restricciones existen, qué casos de uso tenemos, qué esperamos probar y, sobre todo, qué cosas todavía no sabemos.

El resultado termina siendo algo que nosotros llamamos un Hard Spec: una especificación suficientemente cerrada para que el siguiente problema ya no sea descubrir qué hay que construir, sino construirlo.

Entonces sí. Lo mando a escribir código. Pero tampoco le digo simplemente “implementa esto”.

Hay reglas para escribir ese código. Hay reglas de arquitectura. Hay contratos que no puede cambiar por su cuenta. Hay tests que describen el comportamiento esperado. Y si durante la implementación descubre que la especificación no funciona, no tiene autorización para inventarse una solución y seguir adelante. Porque ahí vuelvo a entrar a revisar el problema encontrado.

Con el tiempo esto se nos ha ido convirtiendo en una especie de mini fábrica de software con dos líneas de producción.

En una línea intentamos transformar una necesidad, una idea o incluso una hipótesis en algo implementable.

Ahí hacemos discovery, discutimos requerimientos, revisamos el sistema existente, cuestionamos supuestos, tomamos decisiones, definimos arquitectura, casos de uso, comportamiento y pruebas. El producto de esa línea no es código. Es una especificación.

En la segunda línea tomamos esa especificación y la transformamos en software. Ahí sí entran implementación, tests, revisión, integración y evidencia de que lo construido corresponde con lo que habíamos definido. Y algo que para mí es importante: los agentes trabajan en las dos líneas. No solamente escriben código.

Un agente puede hacer discovery. Otro puede revisar lo que encontró. Otro puede cuestionar una decisión de arquitectura. Otro puede convertir decisiones ya tomadas en una especificación. Otro implementarla. Y otro revisar la implementación.

Últimamente hemos empezado también a trabajar con Oh My Pi y, curiosamente, en lugar de cambiar mi forma de trabajar, he terminado adaptándolo a esta misma filosofía, teniendo agentes especializados, con roles dentro de una pequeña fábrica: uno investiga, otro analiza, otro ayuda con project management, otro trabaja especificaciones, otro implementa y otro revisa.

Pero las decisiones importantes siguen teniendo gates. Y esos gates recaen en mi. Tal vez por eso sigo siendo más lento que algunos de mis compañeros.

Y probablemente por eso tampoco me termino mis tokens. Porque no estoy intentando obtener la mayor cantidad posible de código de un agente. Estoy intentando que haga una parte muy concreta del trabajo, dentro de un proceso en el que cada etapa tiene una responsabilidad.

No sé si esta sea la mejor manera de trabajar con agentes. Apenas estoy descubriendo qué funciona y qué no.

Cada vez importa más saber qué estamos construyendo, por qué lo estamos construyendo, cuáles son las restricciones y cómo vamos a demostrar que lo que produjo realmente es correcto.

Al final, la IA sigue siendo una herramienta, y tener la última palabra implica también hacerse responsable de ella.