A maioria das conversas sobre desenvolvimento de software autônomo começa com agentes escrevendo código. Um agente pega uma issue, implementa uma funcionalidade, abre um pull request. A demo funciona. As pessoas ficam animadas.
Antes que qualquer entrega autônoma funcione de forma confiável, alguém precisa projetar o sistema de engenharia no qual a autonomia irá operar. A estrutura do projeto, as escolhas tecnológicas, os limites arquiteturais, a direção de design, as convenções de engenharia, os mecanismos de validação, os papéis especializados, os limites de aprovação. Nada disso deve surgir de uma coleção de agentes independentes adivinhando em paralelo.
Minha abordagem começa com uma divisão diferente de responsabilidades. Humanos projetam o sistema de engenharia. Agentes especializados executam o trabalho. Loops assíncronos orquestram quando esse trabalho acontece e o que vem a seguir.
O objetivo não é remover os humanos do desenvolvimento de software. É concentrar o envolvimento humano nas decisões que exigem julgamento, contexto e compreensão do produto, enquanto se constrói um ambiente onde mais da execução possa continuar por conta própria.
Estes são os seis passos que sigo toda vez que inicio um projeto que deve eventualmente rodar sem que eu esteja observando.
Passo 1: o humano projeta o sistema de engenharia
Quando inicio um projeto, não peço a um agente autônomo que invente suas fundações. Eu decido as partes importantes primeiro: como o repositório deve ser organizado, quais tecnologias usar, como funcionam os principais limites arquiteturais, qual é a direção de design, quais convenções de engenharia devem ser seguidas e onde a autonomia deve parar. Essas decisões se tornam a base de tudo que vem depois. Então eu uso o opencode-onboard para codificá-las no repositório.
/make-engineer cria os engenheiros de IA especialistas que o projeto precisa. Frontend, backend, infraestrutura, testes, segurança, dados, mobile, tudo o que o produto exigir. Estes não são agentes genéricos com rótulos diferentes. Cada um tem uma especialização definida, um conjunto de habilidades e um lugar claro dentro do fluxo de trabalho de engenharia.
/make-architecture captura a estrutura técnica e os limites em ARCHITECTURE.md. /make-design captura a linguagem visual, tokens de design e padrões de componentes em DESIGN.md. /make-guardrails converte todas essas decisões em regras concretas que todo agente deve respeitar. Limites arquiteturais, convenções de nomenclatura, expectativas de teste, estilo de código, restrições de segurança, práticas de Git. Elas deixam de ser conhecimento detido apenas pelo desenvolvedor original e se tornam parte do ambiente operacional.
O repositório acaba contendo mais do que documentação. Ele contém uma organização de engenharia codificada e uma fonte de verdade compartilhada para cada agente que trabalhará dentro dele. O humano define o sistema primeiro. Só então a execução autônoma se torna útil.
Passo 2: a fundação interativa vem antes da autonomia
Assim que o sistema de engenharia é definido, construo a fundação inicial do projeto de forma interativa.
Normalmente, uso /plan-quick e /plan-apply neste ponto. /plan-quick analisa um objetivo focado e o transforma em uma sequência concreta e ordenada de tarefas. É intencionalmente mais leve do que um fluxo de especificação completo. Eu o uso quando o trabalho está claro e quero avançar rapidamente sem perder visibilidade ou controle. /plan-apply implementa essas tarefas e verifica o resultado.
É assim que estabeleço a infraestrutura básica do projeto. Estrutura do repositório, esqueleto da aplicação, configuração do banco de dados, fundações de autenticação, sistema de design, infraestrutura de testes, configuração de CI/CD, fundações de implantação.
Os estágios iniciais de um projeto contêm decisões que afetam tudo o que é construído depois. Uma abstração fraca, uma estrutura de pastas inconsistente, uma estratégia de testes pouco clara. Qualquer uma delas pode ser reproduzida centenas de vezes assim que agentes autônomos começarem a trabalhar. Já vi isso acontecer. Não é bonito.
Por esse motivo, esta fase permanece rápida e assistida por IA, mas supervisionada.
O propósito não é maximizar a autonomia o mais cedo possível. O propósito é tornar o projeto estável, compreensível e previsível o suficiente para que a autonomia possa operar com segurança dentro dele.
Passo 3: o envolvimento humano se torna uma política do projeto
Depois que as fundações estão prontas, decido quanta autonomia o sistema de entrega deve ter.
Esta não é uma escolha binária entre desenvolvimento manual e automação total. O envolvimento humano pode existir em diferentes pontos do ciclo de vida, e a configuração correta depende do projeto.
Um projeto totalmente supervisionado pode exigir que um humano refine a issue, aprove o plano de implementação, revise o pull request, aprove o merge e autorize a implantação.
Um projeto parcialmente autônomo pode deixar a IA refinar e implementar, enquanto humanos respondem a perguntas não resolvidas, revisam pull requests importantes ou mantêm o controle sobre o merge final.
Um projeto altamente autônomo pode deixar o sistema refinar, implementar, revisar e mesclar mudanças automaticamente quando as salvaguardas, testes e verificações de qualidade necessárias passarem.
Um novo produto com requisitos instáveis precisa de mais participação humana do que uma ferramenta interna madura. Um sistema regulado exige portas de aprovação explícitas que seriam desnecessárias para um pequeno experimento. E o mesmo projeto pode se tornar mais autônomo ao longo do tempo, à medida que sua arquitetura, testes e mecanismos de entrega amadurecem.
O ponto importante é que a autonomia é definida intencionalmente. Refinamento de issue, resolução de perguntas, aprovação de plano, revisão de pull request, aprovação de merge, aprovação de implantação. Estas não são interrupções acidentais. São portas configuráveis no sistema de engenharia.
Cada projeto escolhe um nível diferente de autonomia, e esses limites evoluem com ele.
Passo 4: ideias se tornam itens de backlog duráveis
O console interativo ainda é o lugar onde investigo ideias.
Quando uma ideia está incompleta, uso o /plan-explore. Este não é um comando de implementação. É um processo de exploração colaborativa. O agente examina o repositório, mapeia componentes relevantes, identifica padrões existentes, desafia suposições, rastreia dependências, considera riscos e ajuda a determinar o que realmente deve ser construído.
Muitos problemas de desenvolvimento inicialmente parecem tarefas de codificação, mas são, na verdade, problemas de entendimento. Enviar uma ideia pouco clara diretamente para um fluxo de implementação autônomo geralmente produz uma implementação pouco clara. A exploração dá à ideia estrutura suficiente para se tornar acionável sem se comprometer prematuramente com uma solução.
Assim que a direção está clara, uso o /ops-backlog para criar um item de trabalho estruturado no GitHub, Azure DevOps ou Jira. O item de trabalho se torna a transferência durável entre o pensamento interativo e a execução assíncrona. Ele pode conter o contexto, escopo, critérios de aceitação, riscos, perguntas não resolvidas e dependências necessários para os próximos estágios do fluxo.
Neste ponto, o backlog não é mais apenas um lugar onde as tarefas são armazenadas. Ele se torna a camada de coordenação compartilhada entre humanos, agentes e loops.
Humanos criam ideias, respondem perguntas e tomam decisões. Loops observam os estados das issues e selecionam trabalhos elegíveis. Agentes recebem tarefas focadas com o contexto necessário para executá-las.
O backlog transforma uma conversa interativa em trabalho durável que continua após essa conversa terminar.
Passo 5: loop-task orquestra o trabalho assíncrono
Assim que o projeto, engenheiros, salvaguardas, backlog e política de aprovação estão prontos, configuro o loop-task dentro de uma máquina local ou VM.
O loop-task executa os loops de orquestração externos. Esses loops inspecionam continuamente o backlog, identificam trabalhos elegíveis, invocam o fluxo de engenharia apropriado e atualizam o estado de cada issue.
Um loop de refinamento pode selecionar uma nova issue, investigá-la, melhorar sua especificação e adicionar perguntas quando informações estiverem faltando. Quando uma decisão humana é necessária, a issue entra em um estado de espera. Uma pessoa responde quando disponível, e o loop retoma quando a informação aparece.
Assim que a issue está clara o suficiente, ela passa para um estado pronto para implementar. O loop de implementação a pega e invoca o fluxo de engenharia autônomo.
Um loop de revisão pode inspecionar o feedback de pull requests, coordenar correções, reexecutar o fluxo de trabalho necessário e mover a mudança de volta para a aceitação. Um loop de conclusão pode mesclar o trabalho aceito, fechar a issue relacionada e permitir que o próximo item elegível entre no sistema.
Os loops não precisam se comunicar diretamente entre si. Eles coordenam por meio de estados de backlog duráveis. Uma issue típica passa por um ciclo de vida como este:
Nova, Refinando, Aguardando respostas, Pronta para implementar, Implementando, Pull request, Revisando, Concluída.
Os humanos podem entrar no processo sempre que a política do projeto exigir, mas o sistema não depende de alguém monitorando continuamente um terminal. Mesmo quando o desenvolvedor está offline, a VM continua verificando o backlog e movendo o trabalho elegível adiante.
Esta é a distinção no centro da engenharia de loops:
Agentes executam o trabalho. Loops decidem quando o trabalho existe, quando deve começar, qual fluxo de trabalho deve executá-lo e o que acontece em seguida.
Passo 6: /plan-goal executa uma issue do início ao fim
Quando o loop de implementação encontra uma issue que está pronta, ele invoca o /plan-goal.
Este comando não é responsável por decidir a direção do produto ou inventar a arquitetura do projeto. Essas decisões já foram tomadas e codificadas no repositório. Sua responsabilidade é executar um item de trabalho suficientemente refinado dentro do sistema de engenharia existente.
/plan-goal lê a issue, explora as partes relevantes do código-fonte, cria uma proposta OpenSpec, gera tarefas estruturadas, identifica lacunas de especificação ou teste, seleciona os engenheiros especialistas apropriados, atribui níveis de modelo, calcula dependências e organiza o trabalho de implementação em ondas de execução paralelas.
Tarefas que são independentes e modificam áreas separadas do repositório podem ser atribuídas a diferentes engenheiros simultaneamente. Tarefas que dependem de trabalhos anteriores ou que tocam nos mesmos arquivos são executadas na ordem necessária.
O agente líder coordena o trabalho, coleta cada resultado, cria commits focados, executa testes, linting, verificação de tipos e builds. Ele para em vez de enviar a mudança quando a verificação não pode ser concluída com sucesso.
Quando a implementação é válida, o branch é enviado e um pull request é criado com o contexto e as evidências necessárias.
A política de projeto configurada então determina o que acontece a seguir. Um humano pode revisar o pull request. Outro sistema de IA pode realizar a revisão. Um projeto altamente autônomo pode mesclar automaticamente quando todas as verificações exigidas passam. Em outros projetos, a decisão final permanece explicitamente humana.
Isso revela as duas camadas de orquestração no sistema. loop-task é a camada de orquestração externa. Ela gerencia o ciclo de vida do backlog e decide quando refinamento, implementação, revisão ou conclusão devem ocorrer. /plan-goal e os outros comandos do opencode-onboard formam o fluxo de engenharia interno. Eles sabem como explorar, planejar, atribuir, implementar, verificar e entregar uma mudança específica.
Um sistema que sobrevive à conversa
Uma das limitações do desenvolvimento baseado em prompts é que muito estado vive dentro de uma conversa temporária.
A arquitetura precisa ser explicada novamente. Decisões anteriores são esquecidas. Uma implementação interrompida é difícil de retomar. Um desenvolvedor precisa permanecer presente para decidir o que o agente deve fazer após cada etapa.
Este fluxo de trabalho move esse estado para sistemas duráveis. O repositório contém a arquitetura, regras de design, engenheiros e salvaguardas. O OpenSpec contém a mudança planejada e suas tarefas. O Git contém o histórico de implementação e pontos de recuperação. O backlog contém o estado de entrega e as decisões humanas. A máquina local ou VM fornece o ambiente persistente onde os loops continuam rodando.
O resultado não é um único agente autônomo tentando se comportar como uma organização de software inteira. É um sistema coordenado no qual diferentes componentes têm diferentes responsabilidades.
Humanos definem direção, restrições e limites de responsabilidade. Agentes especializados executam trabalho de engenharia focado. Loops coordenam o ciclo de vida de forma assíncrona. O backlog os conecta.
A mudança mais importante não é que os agentes podem gerar mais código. A mudança maior é de interações isoladas de IA para sistemas de engenharia persistentes.
Em vez de explicar o repositório antes de cada tarefa, o projeto carrega sua própria arquitetura e salvaguardas. Em vez de pedir a um agente genérico que implemente tudo, o trabalho é atribuído a especialistas. Em vez de decidir manualmente o que deve acontecer após cada etapa, loops reagem a estados de fluxo de trabalho duráveis. Em vez de manter todo o processo dentro de uma conversa, o progresso sobrevive em issues, especificações, commits, pull requests e estado local.
O papel humano não desaparece. Ele se move em direção ao projeto do ambiente no qual a execução autônoma pode operar.
Esse é o modelo que estou construindo atualmente: um SDLC de IA projetado por humanos, onde o desenvolvedor estabelece primeiro o ambiente de engenharia e os limites de autonomia, e então loops assíncronos coordenam agentes especializados por meio de um ciclo de entrega orientado por backlog.
Do zero até loops rodando sozinhos. Seis passos, cada um construindo sobre o anterior, cada um movendo um pouco mais de estado para fora da conversa e para dentro de sistemas que não esquecem.
PS: Você pode encontrar o loop-task, opencode-onboard e o restante dessas ferramentas em ckgrafico.com
