Construir una aplicación con agentes

En el primer capítulo comprobé que alguien pagaría por mi aplicación: cuatro técnicos pagaron una plaza de fundador de 29 euros por un portal donde sus clientes abren avisos y ven en qué estado están. Con ese dinero cobrado y ocho semanas de plazo para entregarla, tocaba construirla. Este capítulo cubre las cinco semanas de tardes y algún sábado que tardé en tenerla completa en mi máquina, y las dos lecciones que más me han costado: que un agente sin plan se pierde, y que lo que te cuenta que ha hecho no siempre es lo que ha hecho.

La promesa de esta fase es la clásica del vibe coding: describes la aplicación, el agente la programa entera y tú te dedicas a otra cosa. Un agente como Claude Code no es un chat que te da trozos de código para copiar: trabaja sobre los archivos de tu ordenador, crea carpetas, escribe, ejecuta y comprueba. Con permiso, puede encadenar pasos un buen rato sin que toques nada.

Así que lo hice tal cual. Una tarde abrí una carpeta vacía en la estación de trabajo, escribí la descripción de la aplicación en un solo mensaje y le di permiso para aceptar sus propios cambios sin preguntarme. Me fui a cenar.

Al volver, me quedé con la boca abierta. En unas tres horas de trabajo suyo había una aplicación que arrancaba: pantalla de entrada, alta de avisos, una lista y hasta un diseño decente.

Los dos días siguientes le fui pidiendo lo que faltaba, cada cosa en una conversación nueva: los adjuntos, los estados, los correos y, sobre todo, lo que distingue esta aplicación de una herramienta para mí solo: que cada técnico tenga su cuenta y que los técnicos no se vean entre sí.

Hacia el tercer día el proyecto tenía unos sesenta ficheros y el agente ya no se acordaba de lo que había decidido él mismo:

• Montó un segundo sistema de inicio de sesión para los técnicos, en paralelo al de los clientes.
• Cambió el nombre de un campo de la base de datos en una parte del código y no en otra, y la lista dejó de mostrar el estado.
• Rehízo dos veces la separación entre técnicos, cada vez de una forma distinta.

No es torpeza. Un agente trabaja con lo que tiene delante en cada conversación, y si no hay un sitio donde esté escrito qué se decidió, vuelve a decidir desde cero cada vez. Es el problema del contexto del que hablé en los problemas de trabajar con agentes. Y yo no tenía nada escrito ni historial al que volver. Con unas seis horas metidas, lo tiré todo y empecé de nuevo.

El segundo arranque fue más lento y mucho más aburrido:

Requisitos por escrito. Un fichero de texto dentro del proyecto con lo que hace la aplicación, lo que no hace, quién ve qué y las decisiones tomadas, incluida la que me pidieron los fundadores: que el cliente pueda abrir avisos con un enlace personal, sin contraseña. El agente lo lee al empezar cada sesión y lo actualiza cuando decidimos algo. Cómo escribo ese fichero lo cuento en Cómo le explico un proyecto a Claude Code.

Un plan por fases. Seis fases que no se empiezan hasta cerrar la anterior: cuentas de técnico; clientes y acceso; avisos y estados; comentarios y adjuntos; correos; y suscripción y pagos. Cada una con su lista de lo que tiene que funcionar.

Un repositorio con historial desde el primer minuto. Un repositorio guarda cada cambio del proyecto, de forma que puedes ver qué cambió y volver atrás. Uso git, con una copia en el servidor de datos de casa.

Tecnología aburrida. Le pedí opciones y me quedé con la más conocida de las que propuso: Python con Django, SQLite mientras la hacía en mi máquina y PostgreSQL en el servidor. Cuanto más conocida es una herramienta, más ha visto el modelo y menos se inventa.

Preparar todo eso me llevó unas cuatro horas, y fueron las mejor invertidas del reto.

Con el plan, las primeras fases fueron bien. Cuentas de técnico en tres tardes; clientes y avisos en cuatro más. Y aquí caí en la segunda promesa, la de «ya no hace falta leer el código». No soy programador: leo código como leo italiano, entiendo la idea y me pierdo en los detalles. Y el agente, al terminar cada tarea, me dejaba un resumen muy bien escrito. ¿Para qué pelearme con el código?

Trabajaba así: pedía una tarea, leía el resumen, probaba por encima y aceptaba. Un resumen de aquellos días: «He añadido la comprobación para que cada técnico solo vea los avisos de sus propios clientes». Entré como un técnico de prueba y en la lista solo salían los suyos. Aceptado.

Una semana después, probando con dos técnicos de prueba a la vez, uno en cada navegador, copié por despiste la dirección de un aviso del técnico A en la ventana del técnico B. Y se abrió. El técnico B veía el aviso de un cliente del técnico A, con su descripción y su captura.

El agente había puesto el filtro en la lista, que es lo que yo había probado, pero no en la página de cada aviso. Cada aviso tenía un número en la dirección, y cambiando el número se veía cualquiera. Es un fallo tan conocido que tiene nombre en la jerga de la seguridad web, y es de los más frecuentes. Y en esos días el agente había construido los comentarios y los adjuntos copiando la misma forma de trabajar, así que eran tres agujeros en vez de uno.

En una aplicación de pago, esto no es un fallo cualquiera: es un técnico viendo los problemas de los clientes de su competencia, que a veces llevan contraseñas en la captura. Por suerte todo eran datos de prueba. Arreglarlo y comprobar que no quedaba ninguna página con el mismo problema me llevó unas cinco horas.

No creo que el agente mintiera. El resumen describía lo que pretendía hacer, y lo que pretendía era correcto. Lo que un resumen no te enseña es la distancia entre intención y resultado, porque lo escribe el mismo que hizo el cambio.

Desde ese día reviso de otra forma. No me he vuelto programador, pero he aprendido a revisar código con IA sin engañarme:

• Cambios pequeños. Una pantalla, una regla, un arreglo. Si sale grande, le pido que lo parta.
• Las diferencias, no el resumen. Leo qué líneas se quitaron y cuáles se pusieron. No entiendo cada línea, pero veo si ha tocado ficheros que no tenían que ver con lo pedido.
• Que explique cada cambio, fichero por fichero, como a alguien que no programa. Más de una vez, al explicarlo, ha encontrado su propio error.
• Dos técnicos y un cliente de prueba. Toda pantalla nueva la pruebo con los tres, cambiando también el número de la dirección.
• Un segundo agente. Para lo delicado, abro una sesión nueva, sin el historial, y le pido que revise el cambio buscando fallos de seguridad. No arrastra el apego del que escribió el código.

Con la revisión en pequeño lo nuevo entraba mejor, pero apareció otro problema: arreglar una cosa y que se rompiera otra. Una tarde entera persiguiendo el mismo fallo en círculo entre adjuntos, correos y estados. Lo cuento aparte en Cuando el agente rompe lo que ya funcionaba. La salida fue la de siempre: pruebas automáticas que el agente ejecuta antes de dar nada por terminado, cambios guardados en pasos pequeños y volver atrás sin pena. Al cerrar la construcción había 31 pruebas que se ejecutan en unos quince segundos.

La última fase, la de la suscripción y los pagos, quedó hecha en mi máquina, con la pasarela en modo de prueba. Su revisión de verdad, que dio un susto, llegó con el paso a producción.

¿Se construye una aplicación de pago con agentes? Sí: el agente escribe más rápido que yo y, casi siempre, bien. Lo que no hace solo es sostener un proyecto que crece, ni decirte dónde está ese «casi». Sin requisitos, plan e historial se pierde; sin revisión, te cuela un agujero con un resumen impecable.

Las cuentas de estas cinco semanas: 48 horas: 6 del primer intento, 4 de preparar el segundo, 12 pidiendo y esperando, 15 revisando y probando, y 11 arreglando. Es decir, más de la mitad del tiempo se fue en revisar y arreglar. Dinero nuevo: cero. Dos veces me quedé sin cupo de la suscripción en plena tarde y tuve que esperar a que se renovara.

Del presupuesto de 60 horas que me puse en el primer capítulo, ya llevaba 48, y la aplicación todavía no había salido de casa.