A maioria das conversas sobre desenvolvimento autônomo de software 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 vai 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 tentando adivinhar 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 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 pretende, eventualmente, funcionar sem que eu esteja monitorando.
Passo 1: o humano projeta o sistema de engenharia
Quando começo um projeto, não peço a um agente autônomo que invente suas bases.
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.
O /make-engineer cria os engenheiros de IA especializados que o projeto precisa. Frontend, backend, infraestrutura, testes, segurança, dados, mobile, qualquer coisa que o produto demandar. 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.
O /make-architecture captura a estrutura técnica e os limites no ARCHITECTURE.md. O /make-design captura a linguagem visual, os tokens de design e os padrões de componentes no DESIGN.md. O /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 restrito ao 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 todo 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 base interativa vem antes da autonomia
Assim que o sistema de engenharia está definido, eu construo a base inicial do projeto de forma interativa.
Normalmente, uso o /plan-quick e o /plan-apply neste ponto. O /plan-quick analisa um objetivo focado e o transforma em uma sequência concreta e ordenada de tarefas. Ele é 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. O /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, bases de autenticação, sistema de design, infraestrutura de teste, configuração de CI/CD, bases de deploy.
Os estágios iniciais de um projeto contêm decisões que afetam tudo que é construído depois. Uma abstração fraca, uma estrutura de pastas inconsistente, uma estratégia de teste pouco clara. Qualquer uma delas pode ser reproduzida centenas de vezes quando os agentes autônomos começam a trabalhar. Já vi isso acontecer. Não é bonito.
Por esse motivo, esta fase permanece rápida e assistida por IA, mas supervisionada.
O objetivo não é maximizar a autonomia o mais cedo possível. O objetivo é tornar o projeto estável, compreensível e previsível o suficiente para que a autonomia possa operar com segurança dentro dele mais tarde.
Passo 3: o envolvimento humano se torna uma política do projeto
Depois que as bases 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 o deploy.
Um projeto parcialmente autônomo pode permitir que a IA refine e implemente, 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 permitir que o sistema refine, implemente, revise e mescle alterações automaticamente quando as proteções, testes e verificações de qualidade exigidas forem aprovadas.
Um novo produto com requisitos instáveis precisa de mais participação humana do que uma ferramenta interna madura. Um sistema regulamentado 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 dúvidas, aprovação de plano, revisão de pull request, aprovação de merge, aprovação de deploy. 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 duráveis no backlog
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 parecem inicialmente tarefas de codificação, mas são, na verdade, problemas de entendimento. Enviar uma ideia pouco clara diretamente para um fluxo de trabalho de implementação autônoma 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, o escopo, os critérios de aceitação, os riscos, as perguntas não resolvidas e as dependências necessárias para as próximas etapas do fluxo de trabalho.
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 o fim dessa conversa.
Passo 5: loop-task orquestra o trabalho assíncrono
Assim que o projeto, os engenheiros, as proteções, o backlog e a 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 trabalho 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 é retomado quando a informação aparece.
Assim que a issue está clara o suficiente, ela entra em um estado pronto para implementar. O loop de implementação a pega e invoca o fluxo de trabalho de engenharia autônomo.
Um loop de revisão pode inspecionar o feedback do pull request, coordenar correções, reexecutar o fluxo de trabalho necessário e mover a alteração de volta em direção à 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 se coordenam por meio de estados duráveis do backlog. Uma issue típica percorre 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 um terminal continuamente. Mesmo quando o desenvolvedor está offline, a VM continua verificando o backlog e movendo o trabalho elegível para frente.
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 a seguir.
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.
O /plan-goal lê a issue, explora as partes relevantes da base de código, 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 paralela.
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 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 alteração 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 forem aprovadas. Em outros projetos, a decisão final permanece explicitamente humana.
Isso revela as duas camadas de orquestração no sistema. O loop-task é a camada de orquestração externa. Ele gerencia o ciclo de vida do backlog e decide quando o refinamento, a implementação, a revisão ou a conclusão devem ocorrer. O /plan-goal e os outros comandos do opencode-onboard formam o fluxo de trabalho de engenharia interno. Eles entendem como explorar, planejar, atribuir, implementar, verificar e entregar uma alteração 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, as regras de design, os engenheiros e as proteções. O OpenSpec contém a alteração planejada e suas tarefas. O Git contém o histórico de implementação e os 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 responsabilidades diferentes.
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 proteções. Em vez de pedir a um agente genérico para implementar tudo, o trabalho é atribuído a especialistas. Em vez de decidir manualmente o que deve acontecer após cada etapa, os 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 do humano não desaparece. Ele se move em direção ao design 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 vida de entrega orientado por backlog.
Do zero até loops rodando por conta própria. 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, o opencode-onboard e o restante dessas ferramentas em ckgrafico.com
