La mayoría de las conversaciones sobre desarrollo de software autónomo comienzan con agentes escribiendo código. Un agente toma un issue, 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 tiene que diseñar el sistema de ingeniería en el que operará la autonomía. La estructura del repositorio, las opciones 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 de responsabilidades diferente. 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 juicio, 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 empiezo un proyecto que está destinado a funcionar eventualmente sin que yo lo esté mirando.
Paso 1: el humano diseña el sistema de ingeniería
Cuando empiezo un proyecto, no le pido a un agente autónomo que invente sus cimientos.
Decido primero las partes importantes: cómo debería estar organizado 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, testing, seguridad, datos, móvil, lo que sea 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 testing, estilo de código, restricciones de seguridad, prácticas de Git. Dejan de ser conocimiento que solo posee el desarrollador original y se convierten en 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 que el sistema de ingeniería está definido, 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 está 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 testing, configuración de CI/CD, fundamentos de despliegue.
Las primeras etapas 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 testing poco clara. Cualquiera de ellas puede reproducirse 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 más adelante.
Paso 3: la participación humana se convierte en una política del proyecto
Después de que los cimientos están listos, decido cuánta autonomía debe tener el sistema de entrega.
Esto no es una elección binaria entre desarrollo manual y automatización completa. La participación humana puede existir en diferentes puntos del ciclo de vida, y la configuración correcta depende del proyecto.
Un proyecto totalmente supervisado podría requerir que un humano refine el issue, 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 barreras de protección, 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 issues, resolución de preguntas, aprobación de planes, revisión de pull requests, aprobación de fusiones, aprobación de despliegues. 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 duraderos del backlog
La consola interactiva sigue siendo el lugar donde investigo ideas.
Cuando una idea está incompleta, uso /plan-explore. 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, desafía suposiciones, rastrea dependencias, considera riesgos y ayuda a determinar qué se debería construir realmente.
Muchos problemas de desarrollo parecen inicialmente 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 está 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 necesarios 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 issues 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 barreras de protección, el backlog y la política de aprobación están listos, configuro loop-task dentro de una máquina local o una 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 issue.
Un bucle de refinamiento puede seleccionar un issue nuevo, investigarlo, mejorar su especificación y agregar preguntas cuando falta información. Cuando se requiere una decisión humana, el issue 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 issue está lo suficientemente claro, pasa a un estado listo para implementar. El bucle de implementación lo recoge 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 issue relacionado y permitir que el siguiente elemento elegible entre al sistema.
Los bucles no necesitan comunicarse directamente entre sí. Se coordinan a través de estados duraderos del backlog. Un issue típico avanza a través de un ciclo de vida como este:
Nuevo, Refinando, Esperando respuestas, Listo para implementar, Implementando, Pull request, Revisando, Hecho.
Los humanos pueden entrar en el proceso siempre que la política del proyecto lo requiera, pero el sistema no depende de que alguien esté mirando una terminal continuamente. Incluso cuando el desarrollador está desconectado, la VM sigue verificando el backlog y moviendo el trabajo elegible hacia adelante.
Esta es la distinción en el centro 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 issue de principio a fin
Cuando el bucle de implementación encuentra un issue 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 están codificadas en el repositorio. Su responsabilidad es ejecutar un elemento de trabajo suficientemente refinado dentro del sistema de ingeniería existente.
/plan-goal lee el issue, explora las partes relevantes del código base, crea una propuesta OpenSpec, genera tareas estructuradas, identifica brechas de especificación o testing, 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 líder coordina el trabajo, recopila cada resultado, crea commits enfocados, ejecuta pruebas, linting, type checks y compilaciones. 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, la rama se sube 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 fusionar automáticamente cuando todas las comprobaciones requeridas pasan. 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. Ellos 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 barreras de protección. 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 la VM proporcionan el entorno persistente donde los bucles continúan ejecutándose.
El resultado no es un único agente autónomo que intenta comportarse como toda una organización de software. 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 de IA a sistemas de ingeniería persistentes.
En lugar de explicar el repositorio antes de cada tarea, el proyecto lleva su propia arquitectura y barreras de protección. En lugar de pedirle a un agente genérico que implemente todo, el trabajo se asigna a especialistas. En lugar de decidir manualmente qué debe suceder después de cada paso, los bucles reaccionan a estados de flujo de trabajo duraderos. En lugar de mantener todo el proceso dentro de una conversación, el progreso perdura en issues, 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 funcionando 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
