Passei meses construindo uma estrutura agnóstica de modelo para fazer trabalho de software real com agentes de codificação. No final, os recursos importaram muito menos do que eu esperava. O que realmente importou foram algumas ideias que mudaram a forma como penso sobre construir com agentes, em vez de apenas dar instruções a eles.
Estas são as ideias que têm mais peso. As três primeiras mudaram genuinamente meu modelo mental. O restante são coisas práticas que você pode começar a usar quase imediatamente.
1. Congele os critérios de aceitação antes do agente começar
E coloque-os em um lugar que ele não possa editar.
Esta é provavelmente a maior mudança para mim. Parece óbvio em retrospecto, mas não percebi o quão importante era até vê-la em ação.
Se os critérios de aceitação podem mudar depois que o trabalho existe, eles vão lentamente se deslocar em direção ao que foi produzido. O agente não está sendo desonesto, ele está simplesmente julgando o trabalho contra um alvo que ainda pode se mover. Se as balizas são móveis, elas eventualmente se moverão.
Isso não é um problema de instrução, é um problema estrutural, então a solução também precisa ser estrutural.
Escreva os critérios de aceitação primeiro. Armazene-os fora do espaço de trabalho editável e bloqueie automaticamente qualquer tentativa de editá-los. Agora o agente está trabalhando em direção a um contrato que não pode renegociar. A tarefa não está concluída porque o agente diz que sim. Está concluída porque satisfaz o contrato original.
2. Ninguém deveria avaliar o próprio trabalho
O modelo que escreveu o código é o pior juiz possível para decidir se ele está correto. Quando termina, já se convenceu de que a solução faz sentido.
Então, divida as responsabilidades.
Deixe que scripts determinísticos verifiquem tudo que é mecânico. Um script não pode inventar um código de saída bem-sucedido. Trate o modelo de codificação como um engenheiro, não como o revisor. Em seguida, entregue o resultado a um revisor de contexto novo, um que nunca viu o código sendo escrito, para julgar o design, a intenção e a qualidade geral.
Essa separação simples pega muito mais problemas do que eu esperava, e é surpreendentemente barata de implementar.
3. Aplicação é fácil. Calibragem é a parte difícil.
Essa percepção mudou a forma como pensei sobre toda a estrutura.
A maioria dos sistemas de agente, incluindo versões anteriores do meu, trata cada tarefa de forma mais ou menos igual. A correção de um erro de digitação de uma linha passa pelo mesmo processo que uma grande reformulação arquitetural. Isso é ou uma perda de tempo ou arriscado demais.
A chave é o esforço proporcional.
Primeiro, classifique o trabalho. É uma pequena mudança da qual nada depende, ou uma infraestrutura central da qual tudo depende? É lógica de negócios ou código utilitário genérico?
Então, deixe essa classificação decidir quanta revisão ele recebe, qual modelo deve lidar com ele e quanta autonomia é permitida.
Colocar a aplicação em prática é fácil. Fazer o esforço corresponder é onde o valor realmente começa a se acumular.
A Camada Prática
Depois que essas ideias maiores estavam em vigor, algumas práticas menores se pagaram quase imediatamente.
- Coloque suas regras na estrutura, não na instrução. Uma instrução que diz "não faça edições no repositório principal" é apenas um conselho. A mesma regra aplicada como uma chamada de ferramenta bloqueada se torna impossível de ignorar. As regras importantes não devem depender da escolha do modelo de se comportar.
- Mantenha o estado fora da conversa e use um trabalhador novo para cada tarefa. Armazene registros de tarefas externamente, use árvores de trabalho isoladas e processe as mudanças através de uma fila de mesclagem. Uma vez que o estado está fora do chat, os limites de contexto deixam de ser sua maior restrição. As tarefas se tornam paralelas, retomáveis e muito mais fáceis de raciocinar.
- Revisão entre provedores é melhor que revisão do mesmo provedor. Modelos podem ser mais tolerantes com o próprio trabalho do que com o de outros. Usar um modelo de um provedor diferente é uma forma simples e eficaz de reduzir esse viés.
Por que os princípios funcionam
Nenhuma dessas ideias depende de um modelo específico. Elas são sobre engenharia de estrutura. Protocolos, verificação, pipelines de revisão e separação de responsabilidades.
O modelo no topo dos benchmarks continuará mudando.
Mas os princípios provavelmente não mudarão.
O valor duradouro não está no modelo, e não está nos recursos. Está no arcabouço que você constrói ao redor deles.
