A codificação autônoma está evoluindo de prompts melhores para sistemas de controle melhores. A mudança importante é que engenheiros estão aprendendo a envolver agentes em metas, avaliadores, loops e artefatos que permitem que eles continuem trabalhando depois que o humano para de digitar.
Isso é importante porque a maior parte do trabalho sério de engenharia abrange horizontes longos: requisitos ambíguos, restrições ocultas, falhas parciais, contexto em mudança e verificação repetida. A nova fronteira é projetar o sistema em torno do agente para que ele possa planejar, executar, verificar seu trabalho, se recuperar de erros e continuar progredindo sem orientação humana constante.
Este artigo é baseado em uma sessão da DAIR.AI Academy sobre agentes de codificação autônomos de longa duração, onde eu abordei o modo Claude Code /goal, o comando mais novo Claude Code /loop, verificadores, artefatos e padrões de orquestração na prática. Escrito em colaboração com Codex e Claude Code.
De Prompts a Design de Metas
A ideia central por trás de recursos como o /goal do Claude Code é simples. Um agente de codificação continua sendo o executor, mas o humano não interage mais com ele em turnos. Em vez disso, o humano especifica o estado final desejado, as evidências necessárias para provar o sucesso, as restrições que não devem ser violadas e, quando possível, o número de turnos e o orçamento.
Essa meta funciona mais como um contrato do que como um prompt mais longo. Uma meta fraca dá ao modelo espaço para parar cedo, tomar atalhos ou redefinir o sucesso de uma forma que parece plausível na transcrição, mas falha no sistema real. Uma meta forte dá ao agente um alvo contra o qual ele pode se medir repetidamente.
O julgamento de engenharia ainda é importante aqui. As melhores metas codificam conhecimento de domínio que o modelo de outra forma adivinharia. Para um experimento de pesquisa, isso pode significar uma pontuação alvo em um benchmark, uma avaliação de validação retida, uma curva de perda necessária e uma regra de que o resultado deve superar uma linha de base inicial. Para uma tarefa de UI, pode significar uma captura de tela de referência, restrições concretas de layout e uma etapa de verificação no navegador. O modelo pode executar, mas o humano ainda define o que "pronto" realmente significa.
O Avaliador Torna-se um Componente de Primeira Classe
Agentes de longa duração precisam de um segundo papel além da meta. Esse avaliador pode ser outro agente de codificação, um LLM-como-juiz, um script, um conjunto de testes, um harness de benchmark ou uma mistura de todos eles. A principal escolha de design é combinar o avaliador com a tarefa. Quando o sucesso é claro, verificações determinísticas são melhores. Verificações de tipo, testes unitários, regras de lint, testes de integração e scripts de benchmark devem ser usados sempre que puderem expressar a condição claramente.
Quando o sucesso é difuso, um avaliador agente se torna útil. Um script pode dizer se os testes passam, mas não consegue decidir facilmente se um relatório de pesquisa gerado é coerente, se uma implementação segue fielmente um artigo ou se uma UI corresponde a uma intenção de design. É aqui que o avaliador se beneficia de linguagem, julgamento e, às vezes, visão.
O padrão prático usa verificações determinísticas como base e a avaliação do agente como revisão de nível superior. Essa combinação reduz o sucesso alucinado enquanto ainda permite autonomia em tarefas que não se encaixam perfeitamente em uma asserção de teste.
Verificadores Definem o Limite da Confiança
O ponto mais profundo é que a autonomia só funciona quando o sistema tem um verificador confiável. Um agente de codificação pode gerar um plano, implementar uma funcionalidade e explicar por que acredita que o trabalho está completo, mas essa explicação não deve ser tratada como evidência. A evidência vem de uma verificação externa da qual o agente não pode se esquivar facilmente.
Para código, o verificador pode ser um conjunto de testes, verificador de tipos, benchmark, execução no navegador, comparação de capturas de tela ou script reproduzível. Para trabalho de pesquisa, pode ser uma avaliação de validação retida, uma tabela reproduzida, uma curva de perda ou uma pontuação de benchmark que melhora em relação à linha de base. Para trabalho de design, pode ser uma captura de tela de referência mais uma etapa de revisão visual. O verificador é o que transforma um agente de longa duração de um gerador de texto confiante em um sistema que pode ser confiável com mais tempo.
A maioria dos atalhos aparece nesse limite. Se o verificador é vago, o modelo geralmente satisfaz a interpretação mais fácil da tarefa. Se o verificador é muito restrito, o modelo pode se adaptar excessivamente a ele e perder a intenção mais ampla. Um bom fluxo de trabalho autônomo, portanto, precisa de verificação em camadas, com verificações determinísticas baratas capturando falhas básicas e uma revisão de nível superior capturando falhas pesadas de julgamento. Alguns dos modelos de fronteira já podem atingir algum nível de verificação, mas, com base na minha pesquisa, ainda há um problema evidente de OOD (fora da distribuição), onde, se a tarefa de verificação que você atribui ao agente estiver fora da distribuição de treinamento, os modelos têm dificuldade significativa.
Verificadores ainda são uma área de pesquisa em aberto, mas prevejo que mais empresas começarão a fazer enormes investimentos nessa área. O conceito de verificadores ajustados (fine-tuned) também está em alta demanda no ambiente empresarial.
Loops Tornam a Autonomia Durável
Uma meta dá direção ao agente, mas um loop mantém o trabalho vivo. Essa distinção é importante porque os modelos geralmente param antes que a tarefa real seja concluída. Eles podem atingir um limite de turnos, perder a confiança, esgotar o contexto ou decidir que uma solução parcial é suficiente.
O loop é o sistema de controle externo. Ele acorda, inspeciona o progresso, executa verificações, compara o resultado com a meta e envia o agente de volta com a próxima instrução quando a meta não foi atingida. Em sua forma mais simples, este é o padrão de loop estilo Ralph com um agente de codificação e uma condição determinística. Em uma forma mais flexível, o loop inclui um agente avaliador que pode raciocinar sobre o progresso e decidir o que deve acontecer a seguir.
A autonomia de longa duração funciona como um esforço repetido sob supervisão de uma camada de controle, não como um ato contínuo de inteligência. O agente ainda pode falhar, mas o loop dá ao sistema uma maneira de perceber a falha e continuar, em vez de declarar silenciosamente a vitória.
Planejamento é Onde a Expertise Entra
Um dos temas mais fortes da sessão foi que o planejamento continua sendo crítico. Você pode pedir a um modelo de fronteira para gerar um plano, mas ainda precisa inspecioná-lo, desafiar suposições e tornar os critérios de sucesso mais nítidos antes de entregar a tarefa a um loop autônomo.
Isso leva a uma divisão útil do trabalho. Um modelo de planejamento mais forte pode ajudar a definir a meta, identificar restrições faltantes e estruturar a avaliação. Um modelo de execução diferente pode então executar a implementação assim que o plano estiver claro. Na prática, isso significa que os engenheiros devem parar de pensar em "o modelo" como uma escolha única. A escolha do modelo se torna uma decisão de arquitetura.
Alguns modelos são melhores planejadores. Alguns são melhores executores. Alguns são avaliadores mais baratos. Alguns são melhores em revisão baseada em visão. Um bom orquestrador permite que você troque essas funções em vez de esperar que um único fornecedor forneça a interface de agente de codificação perfeita.
Artefatos Visuais Tornam-se Superfícies de Controle
Transcrições de terminal não escalam quando muitos agentes estão em execução. Depois que você tem várias sessões trabalhando em paralelo, o texto bruto se torna uma interface pobre para entender o progresso.
Artefatos ao vivo são importantes porque um painel com curvas de perda, pontuações de benchmark, estados de tarefas, capturas de tela, estimativas de custo e decisões recentes dá ao humano uma maneira muito melhor de supervisionar a autonomia. O artefato se torna a superfície de controle para decidir quando intervir, em vez de um relatório gerado após o fato.
O padrão mais útil é separar o armazenamento da apresentação. Markdown ou um cofre podem armazenar evidências duráveis, logs, notas, planos e resultados. Artefatos HTML podem renderizar esse estado em algo visual e interativo. O agente pode pesquisar o Markdown, enquanto o humano pode monitorar o artefato.
Para trabalho de UI e produto, as dicas visuais são especialmente poderosas. Uma captura de tela de referência pode comunicar a intenção do design com mais precisão do que a prosa, e um avaliador com capacidade de visão pode comparar a implementação com essa referência. Isso reduz o modo de falha comum em que o agente implementa tecnicamente o componente solicitado, mas erra no espaçamento, hierarquia, alinhamento ou sensação do produto.
Mineração de Sessões Transforma Uso em Memória
Outra percepção importante é que as sessões passadas do agente são uma fonte rica de dados de fluxo de trabalho. Se um agente falha repetidamente da mesma forma, esquece de executar a mesma verificação, usa o caminho errado ou repete o mesmo comando quebrado, esse padrão não deve permanecer enterrado em logs.
A mineração de sessões transforma essas transcrições em regras operacionais. Um agente pode escanear os últimos trinta dias de trabalho, encontrar modos de falha recorrentes e propor atualizações para as instruções do projeto, aprendizados do cofre ou regras do agente. É assim que uma equipe pode melhorar gradualmente seu harness sem lembrar manualmente de cada erro.
O objetivo é tornar o ambiente local mais inteligente sem treinar um modelo do zero. Uma pequena regra em um arquivo de instrução do agente pode evitar falhas repetidas em sessões futuras, especialmente quando a regra é específica para o projeto.
Um Modelo Operacional Prático
Para engenheiros de IA, o fluxo de trabalho emergente se parece com isto.
- Comece com um subconjunto pequeno e barato antes de lançar a execução autônoma completa.
- Escreva uma meta com critérios de sucesso mensuráveis, restrições explícitas e um orçamento de turnos ou tempo (quando possível).
- Separe o executor do avaliador para que a implementação e o julgamento não sejam condensados em uma única função.
- Defina verificadores externos antes que o loop de longa duração comece.
- Use verificações determinísticas sempre que possível, depois adicione revisão do agente para critérios difusos.
- Exija artefatos de prova, como logs, capturas de tela, curvas de benchmark ou arquivos alterados.
- Mine sessões passadas e promova lições repetidas em instruções do projeto.
Essa é a diferença entre usar um agente de codificação e projetar um sistema de codificação autônomo. Um te dá uma conversa. O outro te dá um harness.
O Que Ainda Quebra
Nada disso remove os problemas difíceis. Agentes ainda tomam atalhos. Eles ainda param cedo. Eles ainda superestimam a conclusão. Eles ainda produzem planos confiantes, mas fracos, especialmente em artigos recentes, benchmarks desconhecidos ou sistemas fora de sua distribuição de treinamento.
Confiar mais neles não resolverá isso. Sistemas de controle melhores resolverão. Metas, loops, avaliadores, verificações determinísticas, artefatos visuais e memória de sessão são todas formas de tornar a autonomia observável e corrigível.
A direção é clara. O futuro dos agentes de codificação depende de uma melhor orquestração em torno de modelos mais capazes, onde os engenheiros projetam as condições sob as quais os agentes podem operar com segurança por horas ou dias e ainda produzir trabalho que possa ser verificado.
