Una de las preguntas que más me interesan al trabajar con agentes de IA no es cuánto código pueden generar, sino cuánto trabajo estamos dispuestos a dejarles hacer sin intervenir.
La respuesta fácil sería pensar que la autonomía debería aumentar conforme mejoran los modelos. Si un agente escribe mejores tests, entiende repositorios más grandes y comete menos errores, parece razonable supervisarlo cada vez menos.
Pero creo que falta una variable importante en ese razonamiento: el contexto en el que estamos introduciendo el cambio.
No necesitamos el mismo nivel de confianza para construir un prototipo que para modificar un sistema con años de historia, usuarios reales y datos que no podemos permitirnos perder. Tampoco necesitamos las mismas evidencias para cambiar el aspecto de un botón que para modificar una regla de facturación.
La autonomía, por tanto, probablemente no sea una propiedad del agente.
Es una decisión de ingeniería.
Y depende tanto de lo que el agente es capaz de hacer como de las consecuencias que tendría equivocarse.
MVP y POC no son producción
Hay una distinción que frecuentemente desaparece cuando hablamos de IA.
No es lo mismo construir un POC que modificar un sistema que lleva cinco años funcionando.
Un proof of concept intenta responder una pregunta:
¿Podemos técnicamente hacer esto?
En ese contexto, el código puede ser descartable, la arquitectura provisional y la cobertura de tests mínima. Incluso puede ser perfectamente razonable construir prácticamente todo mediante prompting si lo único que necesitamos es obtener una respuesta.
Un MVP persigue algo diferente: validar una hipótesis de producto con el menor coste posible.
Aquí ya habrá usuarios y necesitaremos cierto nivel de calidad, pero el aprendizaje sigue siendo prioritario. Podemos permitirnos decisiones reversibles e incluso aceptar deuda conscientemente si eso nos ayuda a descubrir antes si el problema merece realmente una solución.
Un producto establecido juega con otras reglas.
Tiene usuarios, datos, contratos, integraciones, incidentes anteriores y decisiones que quizá nadie documentó. También contiene comportamientos de los que alguien depende aunque ninguna especificación los mencione.
Cuando modificamos ese tipo de sistema, la pregunta empieza a cambiar.
Ya no basta con saber:
¿Puede la IA implementar esta funcionalidad?
También tenemos que preguntarnos:
¿Podemos introducir este cambio sin romper expectativas, restricciones o comportamientos relevantes que ya existen?
La capacidad técnica del agente puede ser exactamente la misma en ambos casos.
La autonomía que le concedemos probablemente no debería serlo.
En greenfield podemos asumir. En legacy debemos descubrir
Cuando construimos algo desde cero tenemos una ventaja considerable: gran parte del comportamiento todavía puede decidirse.
Si un agente propone una estructura razonable, cumple nuestros criterios y la decisión es fácilmente reversible, probablemente podamos avanzar sin investigar demasiado.
En legacy ocurre algo distinto.
El código contiene conocimiento, pero no contiene todo el conocimiento del sistema. Parte de él vive en usuarios, incidencias, tickets antiguos, bases de datos, procesos operativos y excepciones que fueron apareciendo durante años.
A veces encontramos una condición aparentemente absurda y la primera reacción es eliminarla.
Después descubrimos que existe porque en 2021 ocurrió algo que nadie quiere volver a vivir.
El diseño puede quedar más limpio al borrarla y, al mismo tiempo, producción puede dejar de comportarse como alguien esperaba.
Ese tipo de situaciones me parecen especialmente relevantes cuando trabajamos con agentes. Un modelo puede analizar perfectamente lo que está delante de él y aun así no tener acceso a la razón por la que algo terminó siendo así.
Por eso creo que una de las habilidades importantes del desarrollador que trabaja con IA será distinguir cuándo puede asumir y cuándo necesita investigar.
Nuestra experiencia previa gana valor precisamente aquí. Haber visto fallar sistemas, conocer las invariantes de un dominio o saber qué partes suelen esconder excepciones nos ayuda a decidir dónde podemos delegar y dónde conviene detenernos antes de cambiar nada.
La cuestión no es desconfiar del agente.
Es reconocer cuándo el sistema sabe cosas que todavía nosotros —y el agente— no sabemos.
El desarrollador del futuro no debería ser un auditor de código generado
También existe un extremo contrario que no parece demasiado sostenible.
Si nuestros agentes pueden producir diez veces más código pero necesitamos leer exhaustivamente cada línea antes de aceptarla, gran parte de la ganancia desaparece. El cuello de botella simplemente se ha desplazado.
Eso no significa que debamos dejar de revisar.
Significa que necesitamos más formas de obtener confianza que la lectura manual de cada detalle de implementación.
Una práctica de ingeniería madura debería intentar transformar parte de sus reglas implícitas en controles explícitos.
Los tests son el ejemplo evidente, pero no el único. Podemos apoyarnos en el compilador, los tipos, análisis estático, contratos, checks arquitectónicos, observabilidad, escenarios de aceptación o evaluaciones específicas del dominio.
Incluso podemos utilizar agentes independientes para revisar algunas propiedades del trabajo realizado por otros agentes.
La cuestión interesante no es acumular herramientas, sino preguntarnos qué propiedades importantes podemos comprobar automáticamente.
Si nunca aceptamos una determinada dependencia entre dos módulos, quizá esa regla no debería vivir únicamente en la cabeza de quien conoce la arquitectura.
Si una operación tiene que ser idempotente, podemos probar esa propiedad.
Si determinados datos nunca deberían quedar en un estado inconsistente, podemos intentar expresar esa invariante de una forma que el sistema pueda comprobar.
Cada regla que conseguimos sacar de nuestra memoria y convertir en una comprobación automática aumenta el espacio en el que podemos delegar con cierta seguridad.
Eso permite ampliar la autonomía de los agentes sin aumentar nuestra supervisión en la misma proporción.
Pero existe un límite importante:
los guardarraíles solo pueden protegernos frente a aquello que hemos pensado en comprobar.
Que los tests estén verdes no significa necesariamente que el software sea correcto
Este problema se vuelve especialmente interesante cuando la misma IA puede participar en todo el proceso.
Puede ayudarnos a escribir la especificación, generar la implementación, producir los tests y posteriormente revisar el resultado.
A primera vista parece un ciclo extraordinariamente completo.
También puede ser un ciclo extraordinariamente coherente alrededor de una interpretación equivocada.
Si la especificación parte de una comprensión incorrecta del problema y los tests se derivan de esa misma interpretación, la implementación puede satisfacer perfectamente todos los criterios que hemos definido.
Los tests estarán verdes.
El software seguirá estando mal.
Esto no es realmente un problema exclusivo de la IA. Los equipos humanos también podemos construir durante meses exactamente aquello que habíamos especificado y descubrir después que no era lo que necesitábamos.
La IA simplemente puede reducir mucho el tiempo necesario para llegar al mismo error.
Por eso necesitamos fuentes de feedback que sean suficientemente independientes del proceso de generación.
A veces será otro agente con un contexto distinto. En otras ocasiones será una prueba de aceptación escrita previamente, una restricción del dominio, telemetría de producción o una conversación con un usuario.
Y habrá situaciones donde la única manera de descubrir si algo es correcto sea poner una versión pequeña delante de la realidad y observar qué ocurre.
La consistencia interna es necesaria, pero no siempre suficiente.
La autonomía debería ser proporcional al riesgo
Quizá una forma más útil de pensar en todo esto sea abandonar la idea de encontrar un nivel universal de autonomía para los agentes.
No parece tener demasiado sentido decidir que en una organización “los agentes pueden implementar funcionalidades completas” o que “todo código generado debe revisarse línea por línea”.
El contexto cambia demasiado.
Un prototipo desechable puede admitir una autonomía enorme.
Un cambio pequeño y reversible en una aplicación interna quizá también.
Modificar la autorización de acceso a datos sensibles, una migración irreversible o una regla que afecta a facturación pertenece a otra categoría.
En esos casos probablemente queramos más contexto, más evidencias independientes, mejores mecanismos de rollback y quizá también más intervención humana.
Lo interesante es que esto no exige necesariamente utilizar menos IA.
Podemos utilizarla precisamente para aumentar nuestras garantías: explorar escenarios, generar casos límite, revisar invariantes, comparar alternativas o buscar efectos secundarios que no habíamos considerado.
La cuestión es ajustar la forma en que delegamos al riesgo que estamos asumiendo.
Conclusión
A medida que los agentes sean capaces de hacer más trabajo por sí mismos, será tentador convertir su nivel de autonomía en una medida de madurez.
No creo que sea una buena métrica.
Un sistema donde el agente puede trabajar durante horas sin intervención humana no es necesariamente más avanzado que otro donde existen varios puntos de control.
La pregunta relevante es qué riesgo estamos asumiendo y qué evidencia tenemos para confiar en el resultado.
En algunos contextos esa evidencia será muy pequeña. En otros necesitaremos tests, invariantes, observabilidad, revisión independiente o feedback real de usuarios antes de sentirnos cómodos.
La capacidad del agente importa, pero no decide por sí sola cuánto deberíamos delegar.
Esa decisión sigue siendo nuestra.
Y quizá ahí esté una parte importante del trabajo que nos queda como ingenieros: diseñar sistemas donde podamos conceder cada vez más autonomía sin tener que conceder, al mismo tiempo, cada vez más confianza ciega.