La mayoría de las conversaciones sobre desarrollo de software autónomo comienzan con agentes escribiendo código. Un agente toma un problema, implementa una funcionalidad, abre un pull request. La demo funciona. La gente se entusiasma.
Antes de que cualquier entrega autónoma pueda funcionar de manera confiable, alguien debe diseñar el sistema de ingeniería dentro del cual operará la autonomía. La estructura del proyecto, las decisiones tecnológicas, los límites arquitectónicos, la dirección de diseño, las convenciones de ingeniería, los mecanismos de validación, los roles especializados, los límites de aprobación. Nada de eso debería surgir de una colección de agentes independientes adivinando en paralelo.
Mi enfoque comienza con una división diferente de responsabilidades. Los humanos diseñan el sistema de ingeniería. Los agentes especializados ejecutan el trabajo. Los bucles asíncronos orquestan cuándo ocurre ese trabajo y qué viene después.
El objetivo no es eliminar a los humanos del desarrollo de software. Es concentrar la participación humana en las decisiones que requieren criterio, contexto y comprensión del producto, mientras se construye un entorno donde más de la ejecución pueda continuar por sí sola.
Estos son los seis pasos que sigo cada vez que inicio un proyecto que está destinado a funcionar eventualmente sin que yo lo supervise.
Paso 1: el humano diseña el sistema de ingeniería
Cuando comienzo un proyecto, no le pido a un agente autónomo que invente sus bases.
Primero decido las partes importantes: cómo debe organizarse el repositorio, qué tecnologías usar, cómo funcionan los principales límites arquitectónicos, cuál es la dirección de diseño, qué convenciones de ingeniería deben seguirse y dónde debe detenerse la autonomía. Estas decisiones se convierten en la base de todo lo que viene después.
Luego uso opencode-onboard para codificarlas en el repositorio.
/make-engineer crea los ingenieros de IA especializados que el proyecto necesita. Frontend, backend, infraestructura, pruebas, seguridad, datos, móvil, lo que el producto demande. No son agentes genéricos con etiquetas diferentes. Cada uno tiene una especialización definida, un conjunto de habilidades y un lugar claro dentro del flujo de trabajo de ingeniería.
/make-architecture captura la estructura técnica y los límites en ARCHITECTURE.md. /make-design captura el lenguaje visual, los tokens de diseño y los patrones de componentes en DESIGN.md. /make-guardrails convierte todas esas decisiones en reglas concretas que cada agente debe respetar. Límites arquitectónicos, convenciones de nomenclatura, expectativas de pruebas, estilo de código, restricciones de seguridad, prácticas de Git. Dejan de ser conocimiento que solo posee el desarrollador original y pasan a formar parte del entorno operativo.
El repositorio termina conteniendo más que documentación. Contiene una organización de ingeniería codificada y una fuente de verdad compartida para cada agente que trabajará dentro de él.
El humano define primero el sistema. Solo entonces la ejecución autónoma se vuelve útil.
Paso 2: la base interactiva viene antes que la autonomía
Una vez definido el sistema de ingeniería, construyo la base inicial del proyecto de forma interactiva.
Normalmente uso /plan-quick y /plan-apply en este punto. /plan-quick analiza un objetivo enfocado y lo convierte en una secuencia concreta y ordenada de tareas. Es intencionalmente más ligero que un flujo de especificación completo. Lo uso cuando el trabajo es claro y quiero avanzar rápido sin perder visibilidad ni control. /plan-apply implementa esas tareas y verifica el resultado.
Así es como establezco la infraestructura básica del proyecto. Estructura del repositorio, esqueleto de la aplicación, configuración de la base de datos, fundamentos de autenticación, sistema de diseño, infraestructura de pruebas, configuración de CI/CD, bases de despliegue.
Las etapas tempranas de un proyecto contienen decisiones que afectan todo lo que se construye después. Una abstracción débil, una estructura de carpetas inconsistente, una estrategia de pruebas poco clara. Cualquiera de ellas puede ser reproducida cientos de veces una vez que los agentes autónomos comienzan a trabajar. Lo he visto pasar. No es bonito.
Por esa razón, esta fase se mantiene rápida y asistida por IA, pero supervisada.
El propósito no es maximizar la autonomía lo antes posible. El propósito es hacer que el proyecto sea lo suficientemente estable, comprensible y predecible para que la autonomía pueda operar de manera segura dentro de él.
Paso 3: la participación humana se convierte en una política del proyecto
Después de que las bases están listas, decido cuánta autonomía debe tener el sistema de entrega.
Esto no es una elección binaria entre desarrollo manual y automatización total. La participación humana puede existir en diferentes puntos del ciclo de vida, y la configuración correcta depende del proyecto.
Un proyecto completamente supervisado podría requerir que un humano refine el problema, apruebe el plan de implementación, revise el pull request, apruebe la fusión y autorice el despliegue.
Un proyecto parcialmente autónomo podría permitir que la IA refine e implemente, mientras que los humanos responden preguntas no resueltas, revisan pull requests importantes o retienen el control sobre la fusión final.
Un proyecto altamente autónomo podría permitir que el sistema refine, implemente, revise y fusione cambios automáticamente cuando se cumplan las directrices, pruebas y controles de calidad requeridos.
Un producto nuevo con requisitos inestables necesita más participación humana que una herramienta interna madura. Un sistema regulado requiere puertas de aprobación explícitas que serían innecesarias para un pequeño experimento. Y el mismo proyecto puede volverse más autónomo con el tiempo a medida que su arquitectura, pruebas y mecanismos de entrega maduran.
El punto importante es que la autonomía se define intencionalmente. Refinamiento de problemas, resolución de preguntas, aprobación del plan, revisión de pull requests, aprobación de fusión, aprobación de despliegue. Estas no son interrupciones accidentales. Son puertas configurables en el sistema de ingeniería.
Cada proyecto elige un nivel diferente de autonomía, y esos límites evolucionan con él.
Paso 4: las ideas se convierten en elementos de backlog duraderos
La consola interactiva sigue siendo el lugar donde investigo ideas.
Cuando una idea está incompleta, uso /plan-explore. Este no es un comando de implementación. Es un proceso de exploración colaborativa. El agente examina el repositorio, mapea los componentes relevantes, identifica patrones existentes, cuestiona suposiciones, rastrea dependencias, considera riesgos y ayuda a determinar qué debería construirse realmente.
Muchos problemas de desarrollo inicialmente parecen tareas de codificación, pero en realidad son problemas de comprensión. Enviar una idea poco clara directamente a un flujo de trabajo de implementación autónoma generalmente produce una implementación poco clara. La exploración le da a la idea la estructura suficiente para volverse accionable sin comprometerse prematuramente con una solución.
Una vez que la dirección es clara, uso /ops-backlog para crear un elemento de trabajo estructurado en GitHub, Azure DevOps o Jira. El elemento de trabajo se convierte en la transferencia duradera entre el pensamiento interactivo y la ejecución asíncrona. Puede contener el contexto, alcance, criterios de aceptación, riesgos, preguntas no resueltas y dependencias necesarias para las siguientes etapas del flujo de trabajo.
En este punto, el backlog ya no es solo un lugar donde se almacenan tareas. Se convierte en la capa de coordinación compartida entre humanos, agentes y bucles.
Los humanos crean ideas, responden preguntas y toman decisiones. Los bucles observan los estados de los problemas y seleccionan el trabajo elegible. Los agentes reciben tareas enfocadas con el contexto necesario para ejecutarlas.
El backlog transforma una conversación interactiva en trabajo duradero que continúa después de que esa conversación termina.
Paso 5: loop-task orquesta el trabajo asíncrono
Una vez que el proyecto, los ingenieros, las directrices, el backlog y la política de aprobación están listos, configuro loop-task en una máquina local o VM.
loop-task ejecuta los bucles de orquestación externos. Estos bucles inspeccionan continuamente el backlog, identifican trabajo elegible, invocan el flujo de trabajo de ingeniería apropiado y actualizan el estado de cada problema.
Un bucle de refinamiento puede seleccionar un nuevo problema, investigarlo, mejorar su especificación y agregar preguntas cuando falta información. Cuando se requiere una decisión humana, el problema pasa a un estado de espera. Una persona responde cuando está disponible, y el bucle se reanuda cuando aparece la información.
Una vez que el problema está lo suficientemente claro, pasa a un estado listo para implementar. El bucle de implementación lo toma e invoca el flujo de trabajo de ingeniería autónomo.
Un bucle de revisión puede inspeccionar los comentarios del pull request, coordinar correcciones, volver a ejecutar el flujo de trabajo necesario y mover el cambio hacia la aceptación. Un bucle de finalización puede fusionar el trabajo aceptado, cerrar el problema relacionado y permitir que el siguiente elemento elegible ingrese al sistema.
Los bucles no necesitan comunicarse directamente entre sí. Se coordinan a través de estados de backlog duraderos. Un problema típico se mueve a través de un ciclo de vida como este:
Nuevo, Refinando, Esperando respuestas, Listo para implementar, Implementando, Pull request, Revisando, Terminado.
Los humanos pueden ingresar al proceso cada vez que la política del proyecto lo requiera, pero el sistema no depende de que alguien esté observando continuamente una terminal. Incluso cuando el desarrollador está desconectado, la VM sigue revisando el backlog y moviendo el trabajo elegible hacia adelante.
Esta es la distinción central de la ingeniería de bucles:
Los agentes ejecutan el trabajo. Los bucles deciden cuándo existe trabajo, cuándo debe comenzar, qué flujo de trabajo debe ejecutarlo y qué sucede después.
Paso 6: /plan-goal ejecuta un problema de principio a fin
Cuando el bucle de implementación encuentra un problema que está listo, invoca /plan-goal.
Este comando no es responsable de decidir la dirección del producto ni de inventar la arquitectura del proyecto. Esas decisiones ya se han tomado y se han codificado en el repositorio. Su responsabilidad es ejecutar un elemento de trabajo suficientemente refinado dentro del sistema de ingeniería existente.
/plan-goal lee el problema, explora las partes relevantes del código base, crea una propuesta OpenSpec, genera tareas estructuradas, identifica brechas de especificación o pruebas, selecciona los ingenieros especializados apropiados, asigna niveles de modelo, calcula dependencias y organiza el trabajo de implementación en oleadas de ejecución paralela.
Las tareas que son independientes y modifican áreas separadas del repositorio pueden asignarse a diferentes ingenieros simultáneamente. Las tareas que dependen de trabajo anterior o tocan los mismos archivos se ejecutan en el orden requerido.
El agente principal coordina el trabajo, recopila cada resultado, crea commits enfocados, ejecuta pruebas, linting, verificaciones de tipos y compilación. Se detiene en lugar de enviar el cambio cuando la verificación no se puede completar con éxito.
Cuando la implementación es válida, se envía la rama y se crea un pull request con el contexto y la evidencia necesarios.
La política del proyecto configurada determina entonces qué sucede a continuación. Un humano puede revisar el pull request. Otro sistema de IA puede realizar la revisión. Un proyecto altamente autónomo puede fusionarse automáticamente cuando se cumplen todas las verificaciones requeridas. En otros proyectos, la decisión final sigue siendo explícitamente humana.
Esto revela las dos capas de orquestación en el sistema. loop-task es la capa de orquestación externa. Gestiona el ciclo de vida del backlog y decide cuándo deben ocurrir el refinamiento, la implementación, la revisión o la finalización. /plan-goal y los demás comandos de opencode-onboard forman el flujo de trabajo de ingeniería interno. Entienden cómo explorar, planificar, asignar, implementar, verificar y entregar un cambio específico.
Un sistema que sobrevive a la conversación
Una de las limitaciones del desarrollo basado en prompts es que demasiado estado vive dentro de una conversación temporal.
La arquitectura tiene que explicarse de nuevo. Las decisiones anteriores se olvidan. Una implementación interrumpida es difícil de reanudar. Un desarrollador debe permanecer presente para decidir qué debe hacer el agente después de cada paso.
Este flujo de trabajo mueve ese estado a sistemas duraderos. El repositorio contiene la arquitectura, las reglas de diseño, los ingenieros y las directrices. OpenSpec contiene el cambio planificado y sus tareas. Git contiene el historial de implementación y los puntos de recuperación. El backlog contiene el estado de entrega y las decisiones humanas. La máquina local o VM proporciona el entorno persistente donde los bucles continúan ejecutándose.
El resultado no es un solo agente autónomo que intenta comportarse como una organización de software completa. Es un sistema coordinado en el que diferentes componentes tienen diferentes responsabilidades.
Los humanos definen la dirección, las restricciones y los límites de responsabilidad. Los agentes especializados ejecutan trabajo de ingeniería enfocado. Los bucles coordinan el ciclo de vida de forma asíncrona. El backlog los conecta.
El cambio más importante no es que los agentes puedan generar más código. El cambio más grande es pasar de interacciones aisladas con IA a sistemas de ingeniería persistentes.
En lugar de explicar el repositorio antes de cada tarea, el proyecto lleva su propia arquitectura y directrices. En lugar de pedirle a un agente genérico que implemente todo, el trabajo se asigna a especialistas. En lugar de decidir manualmente qué debería suceder después de cada paso, los bucles reaccionan a estados de trabajo duraderos. En lugar de mantener todo el proceso dentro de una conversación, el progreso perdura en problemas, especificaciones, commits, pull requests y estado local.
El rol humano no desaparece. Se mueve hacia el diseño del entorno en el que se permite operar la ejecución autónoma.
Ese es el modelo que estoy construyendo actualmente: un SDLC de IA diseñado por humanos donde el desarrollador establece primero el entorno de ingeniería y los límites de autonomía, luego los bucles asíncronos coordinan agentes especializados a través de un ciclo de vida de entrega impulsado por el backlog.
Desde cero hasta bucles ejecutándose por sí solos. Seis pasos, cada uno construyendo sobre el anterior, cada uno moviendo un poco más de estado fuera de la conversación y hacia sistemas que no olvidan.
PD: Puedes encontrar loop-task, opencode-onboard y el resto de estas herramientas en ckgrafico.com
