Ocho meses y cuatro tipos de herramientas me enseñaron que un agente que dice haber terminado no es evidencia de que en verdad terminó.
Empecé el año pegando código en una ventana de chat, igual que la mayoría. Para cuando publiqué la primera versión pública de Cosmo este fin de semana, ya tenía una cola de tareas de desarrollo corriendo contra un repositorio real durante toda la noche, sin supervisión, con un contenedor Docker como único juez de si algo de eso realmente funcionaba. Este es el camino entre esos dos puntos, y por qué el segundo necesitó su propia herramienta.
Los chats de Gemini y Claude fueron donde aprendí que estos modelos podían escribir código que funcionaba, no solo autocompletar una línea. Pero ese flujo de trabajo tenía un techo claro. Yo era la capa de transporte. Copiar el archivo al chat, copiar la respuesta de vuelta, ejecutarla yo mismo, pegar el error si algo fallaba. El modelo nunca tocó mi sistema de archivos, nunca ejecutó un comando, nunca vio el estado real de mi proyecto más allá de lo que yo decidía pegar. Cada iteración tenía a un humano haciendo la parte que una computadora hace mejor.
Ese techo fue lo que hizo obvio el siguiente paso. El cuello de botella no era la capacidad del modelo para escribir código. Era el muro entre el modelo y mi máquina.
Gemini CLI, la CLI de Claude Code, OpenCode, las extensiones de Claude y Cline para VS Code. Pasé por la mayoría de esa generación de herramientas en unos pocos meses. Lo que tenían en común importaba más que lo que las diferenciaba. El modelo ahora podía leer un archivo por sí mismo, editarlo, ejecutar un comando de shell, ver el resultado, y decidir qué hacer después sin que yo tuviera que transmitir nada.
Darle manos al agente cambió más mi forma de trabajar que cualquier salto en la calidad de los modelos. Una tarea que antes eran veinte idas y vueltas de copiar y pegar se convirtió en un prompt y una espera. Pero también trajo un problema que antes no existía. Cuando un humano ejecuta cada paso, un error se detecta de inmediato, porque es el humano quien lo está escribiendo. Cuando el agente ejecuta el paso, un paso con errores puede ejecutarse, producir un resultado que parece correcto, y ser reportado como un éxito antes de que alguien lo revise de cerca. Ese problema es el que terminó resolviendo Cosmo.
El siguiente paso combinó esas manos con un entorno construido a su alrededor: la app de escritorio de Claude Code, Codex, o Cursor. Están construidos con el agente como el usuario principal del entorno y el humano revisando en lugar de escribir. Los cambios abarcan varios archivos, las tareas duran más, y más del ciclo ocurre sin que uno esté presente.
El problema de la confiar en el agente se noto más aquí, y no mejoró. Cuanta más autonomía le da una herramienta al agente, más se termina dependiendo de su propio relato de lo que pasó. El relato de un agente sobre su propio éxito no es un testigo neutral. Tiene, por estructura, todo el incentivo para reportar la tarea como terminada. Tramos más largos sin supervisión solo significaban más distancia entre “el agente dice que terminó” y “yo lo comprobé”.
En algún punto de todo esto me dejé de preguntar “qué agente” y empecé a preguntar “qué proceso”. Un agente con más autonomía no ayuda si la tarea sobre la que es autónomo es vaga. Pasé por una serie de frameworks y skills construidos alrededor de esto (get-shit-done, superpowers, conductor, entre otros), cada uno tratando de resolver el mismo problema desde un ángulo distinto: darle al agente un spec del cual partir en lugar de una conversación para improvisar, dividir el trabajo en pasos lo bastante pequeños para revisar, y hacer que el proceso mismo sea algo que se puede iterar, no solo el código que produce.
Ahí fue también donde encontré OpenSpec, y esa es la pieza que se quedó. Su modelo de propose → apply → archive me dio algo que la era de chats y CLIs nunca tuvo. Un cambio existe como un artefacto escrito antes de que se toque una sola línea de código, así que puedo leerlo y rechazarlo antes de que el agente empiece, y deja un registro de qué se decidió y por qué una vez terminado. Empecé a ejecutar ese ciclo a mano, cada noche, contra mi propio stack: escribir un spec, y dejar que el agente proponga, revise, aplique, archive, y repita.
Hacer ese mismo ciclo de cuatro pasos a mano, cada noche, durante semanas, es exactamente el tipo de procedimiento repetitivo que debería automatizarse. Eso fue lo que me empujó a diseñar mi propio flujo de trabajo alrededor de esto, en lugar de seguir ejecutando yo mismo los pasos de OpenSpec.
Cosmo es en lo que se convirtió ese flujo de trabajo una vez que dejó de ser un hábito personal y se volvió una herramienta. Toma una cola de cambios de OpenSpec y los procesa contra un repositorio objetivo durante la noche, cada tarea en su propio git worktree, pasando por proponer, implementar, validar y hacer merge, en ese orden. Nada llega a mi rama de integración solo porque el agente lo diga.
Esa última parte es la razón entera por la que existe el proyecto. Un agente que trabaja toda la noche te va a decir que terminó, sea o no cierto. Cosmo no se queda con su palabra. Un build real de Docker, una suite de pruebas real y una ejecución real de Playwright tienen que pasar antes de que nada se fusione, las ediciones a archivos de prueba quedan bloqueadas antes de que puedan ocurrir, y una prueba e2e inestable se vuelve a ejecutar por su cuenta antes de que se le crea, en lugar de agotar en silencio el presupuesto de reintentos de una tarea. El worktree de cada tarea también se borra entre ejecuciones, así que nada que una tarea anterior haya dejado a medias pasa a la siguiente.
Nada de esto es exótico. Es la misma disciplina que habría querido imponerme a mano cada noche si hubiera seguido haciendo esto manualmente, solo que ahora corre sola, a las 2 de la madrugada, para no tener que estar despierto para eso.
Por ahora existe un pre-release (v0.1.1, Apache-2.0, 562 pruebas pasando), y es honesta sobre lo que todavía no está probado. Un solo harness (Claude Code), probado sobre todo contra una plantilla de proyecto solo de frontend, con una suscripción Pro. El código y ambos README, en inglés y en español, son públicos si quieres ver cómo está construido el gate en realidad, o señalar dónde se va a romper a una escala que todavía no he alcanzado.
Hace ocho meses era una capa de transporte entre una ventana de chat y mi propio sistema de archivos. Ahora escribo un spec antes de la cena y leo los merge del agente con el café. Ni el modelo volviéndose más inteligente ni las herramientas volviéndose más autónomas resolvieron el problema real por sí solos. Lo que lo resolvió fue negarme a que “el agente dice que terminó” contara como terminado, y construir una cola que verifica en lugar de preguntar.
Lo que sigue es la misma regla puesta a prueba contra casos más difíciles: un segundo harness, para que la interfaz de adaptador tenga que demostrar que de verdad es agnóstica y no que solo está diseñada para parecerlo; un repositorio brownfield en lugar de los repositorios greenfield contra los que se ha ejecutado hasta ahora; y una pequeña webapp para poder ver una ejecución sin tener que abrir una terminal.
Repositorio: github.com/mauendara/cosmo