Cuando cuento que una flota de agentes construye mi producto, la pregunta que viene después es siempre la misma: ¿y cuando se equivoca? Es la pregunta correcta. La respuesta no es que no se equivoque —se equivoca, y a veces con una seguridad admirable—, sino que entre su error y mi producción hay cuatro capas. Ninguna de las cuatro es un prompt.
Las ordeno de más barata a más cara, que es también de más determinista a más humana. Esa dirección no es casual: cada capa existe para que la siguiente reciba menos trabajo.
01 · El contrato
Antes de que un agente toque nada, escribo tres cosas: qué ficheros e interfaces puede tocar, qué queda explícitamente fuera, y cómo se verifica de punta a punta que funciona. Tres campos. Se tarda dos minutos.
Lo que hace que el contrato funcione no es su longitud —tuve versiones de ocho campos y eran peores— sino que el tercer campo sea ejecutable. «Que quede bien» no es una verificación. «Este test pasa de rojo a verde» sí. La diferencia es que la segunda se puede comprobar sin mí, y una verificación que me necesita a mí no es una capa de seguridad: es una reunión.
El segundo campo, el de qué queda fuera, parece el relleno y es el que más veces me ha salvado. Un agente sin límite explícito no se detiene en el borde de tu intención: arregla de paso tres cosas que no le pediste, y de repente estás revisando un diff de cuarenta ficheros para una corrección de una línea.
02 · La puerta
Cada trabajo pasa por una clasificación binaria antes de empezar: lo puede hacer el agente, o requiere una persona. Dos estados. Autenticación, pagos, la base de datos, los secretos y las migraciones caen siempre del lado humano, y no porque un modelo no sepa escribir una migración —sabe— sino porque el coste de equivocarse ahí no es un bug, es una llamada a alguien para decirle que sus datos ya no están.
La tentación permanente es añadir un tercer estado. «Depende», «con supervisión ligera», «casi seguro». No lo hagas. Una puerta con tres estados es una puerta que se negocia consigo misma a las once de la noche de un viernes, y la que negocia eres tú, cansada, con ganas de terminar. La rigidez es la función, no el efecto secundario.
03 · La PR
El agente implementa, abre una pull request y se detiene. No hace merge. Nunca. Es la única regla del sistema que no tiene excepciones, ni siquiera para cambios triviales, porque una excepción para lo trivial es un criterio de trivialidad, y ese criterio lo acaba aplicando el agente.
Aquí tengo que ser honesta, porque la versión bonita de esta frase es mentira. A este volumen no leo cada diff línea a línea. Decir que sí sería exactamente el tipo de afirmación que este artículo intenta desmontar. Lo que reviso son los recibos: que la integración continua esté verde, que el contrato de verificación aparezca en el historial pasando de rojo a verde, que la revisión automática no haya levantado nada. Si a una PR le falta un recibo, entonces sí la leo entera.
La distinción importa. No estoy afirmando que lo he leído todo. Estoy afirmando que todo lo que entra viene acompañado de con qué comprobarlo. Y lo que compra esta capa no es la perfección: es que la degradación se manifieste como «una PR que rechazo» en lugar de como código malo en producción. Ese cambio de forma es lo que convierte «revertimos si empeora» en una frase con sentido en vez de en un deseo.
04 · La regresión de comportamiento
Las tres primeras capas asumen algo que nadie comprueba: que el agente de hoy es tan bueno como el de la semana pasada. No tiene por qué serlo. Cambias una regla del sistema, actualizas el modelo, reescribes una instrucción para aclararla y la empeoras. Nada de eso rompe un test —el código sigue compilando— y sin embargo el trabajo sale peor.
La cuarta capa vigila eso. Congelas un conjunto de trabajos ya resueltos, cambias las reglas, le pides al agente que los vuelva a resolver desde cero y compruebas si los tests que escribió siguen pasando. Regresión, pero del comportamiento del modelo en vez de del código.
Esa capa hoy no está corriendo. Está escrita, tiene su metodología documentada y su decisión de arquitectura registrada, y no ha producido ni una sola ejecución con resultado. Podría no contártelo: el artículo se titula «las cuatro capas» y cuatro suena mejor que tres y media. Pero entonces sería justo el humo del que intento distinguirme.
«Un sistema de seguridad que no puedes comprobar no es un sistema de seguridad. Es una intención.»
Por eso el modo más autónomo de mi sistema sigue apagado. No porque las tres primeras capas no funcionen: porque la prueba que me avisaría de que han dejado de funcionar todavía no existe. Encenderlo igualmente sería tener tres capas y llamarlas cuatro, que es la forma más común de accidente en cualquier sistema con redundancia —creer que tienes una reserva que en realidad nunca se conectó.
Ninguna de las cuatro capas es inteligente. Son un contrato, una clasificación de dos estados, un botón que el agente no puede pulsar y un examen repetido. Es el mismo instinto que traigo de la ingeniería civil, donde aprendí que no diseñas el puente para el día bueno. Lo diseñas para el día en que el material no es el que pediste, y sigue de pie.
Si la IA también está reescribiendo tu trabajo, sígueme
…o si necesitas a alguien que la gobierne en tu producto, trabaja conmigo.