Dejé de escribir prompts perfectos y empecé a escribir bucles

El creador de Claude Code contó hace poco que ha cambiado de oficio sin cambiar de trabajo: ha dejado de escribir prompts sueltos y ahora escribe bucles. Un agente que no recorre una rama fija, sino que decide su siguiente acción en cada vuelta y se detiene cuando cumple una meta que se puede verificar. La frase que me interesó no fue la técnica, sino la consecuencia: el cuello de botella se desplaza. Deja de estar en redactar el prompt perfecto y pasa a estar en tener criterio para definir la meta y decidir cuánto gastar en llegar a ella.

Podría haberme quedado en la teoría del vídeo. Preferí construirlo sobre mi propio sistema, en abierto, en un fin de semana. Lo que sigue es lo que hay funcionando, con sus datos y sus grietas.

Una primitiva, no un truco

Lo primero fue no repetir el patrón en cada agente. Escribí una pieza reutilizable, runVerifiedLoop: un bucle con tope de intentos, validación explícita (un esquema o una rúbrica) y estado guardado en disco. Dos reglas duras. Sin validación automática, no se lanza. Y nunca ilimitado: si no converge en N intentos, para y lo dice. Un agente que puede girar sin fin no es autonomía, es una factura abierta.

Sobre esa primitiva corren hoy tres agentes reales. El curador del radar, que cuando su salida no valida se autocorrige en lugar de fallar al primer intento. Un versionador semanal, que redacta la narrativa de progreso de la semana y la valida antes de guardarla. Y el generador de borradores, que es donde la idea se pone más interesante.

El juez sube el suelo, no sustituye el criterio

Cuando genero un borrador, un segundo modelo lo puntúa de 0 a 10 contra mi propia rúbrica de marca. Si no llega al umbral, no lo descarta sin más: devuelve el porqué, y el escritor reescribe con esa crítica delante. Hasta pasar o agotar los intentos. Después, siempre, revisión humana.

Conviene ser honesto con lo que esto es y lo que no es. El juez no tiene buen gusto; tiene una rúbrica. Sube el suelo de calidad y elimina los borradores flojos antes de que lleguen a mí, pero no decide por mí. El criterio sigue siendo el cuello de botella, que era justo lo que anunciaba el vídeo.

Lo que antes era una caja negra

Cada bucle deja rastro: intentos, motivo de parada, tokens y coste equivalente. Con eso puedo decir algo que antes no sabía. Un borrador me sale en torno a 0,54 USD equivalentes, porque lleva dos pasadas de modelo, escritor y juez. El radar, unos 0,22. No son cifras grandes, pero el valor no está en la cantidad: está en que existen. Automatizar sin medir el coste es delegar a ciegas.

Y una lección que no aparece en ningún vídeo. Añadí una alerta que me avisa si un agente falla, después de descubrir que uno llevaba seis días roto en silencio. Un agente autónomo sin observabilidad no es autónomo: solo tarda más en avisarte de que algo va mal. Lo cuento porque build-in-public sirve para poco si solo enseñas lo que salió bien.

La traducción a la empresa

Aquí es donde esto deja de ser un experimento de fin de semana. Automatizar no es encadenar pasos A, B, C fijos y confiar en que el mundo no cambie entre medias. Es definir con precisión qué significa “hecho”, la meta verificable, y cuánto estás dispuesto a gastar en alcanzarla. El prompt deja de ser el arte. El criterio y el coste pasan a serlo.

Ese es, casi literalmente, el trabajo de diseñar una organización agéntica. No se trata de qué modelo usas, sino de si tu empresa sabe expresar sus metas de forma que una máquina pueda saber cuándo las ha cumplido, y de si tiene el criterio para juzgar el resultado y la disposición a pagar por él. Muchas organizaciones aún no saben articular qué significa “bien hecho” para un humano. Pronto tendrán que saber articularlo también para una máquina.