O que a criação de um ambiente de desenvolvimento para IA realmente me ensinou

Passei meses construindo uma estrutura agnóstica de modelo para realizar trabalho real de software 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 comandos 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 local que ele não possa editar.

Esta é provavelmente a maior mudança para mim. Parece óbvio em retrospectiva, mas eu não percebi o quão importante era até ver em ação.

Se os critérios de aceitação podem mudar depois que o trabalho existe, eles vão gradualmente se deslocar para o 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 os objetivos são móveis, eles acabarão se movendo.

Isso não é um problema de comando, é 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.

Portanto, 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 captura muito mais problemas do que eu esperava, e é surpreendentemente barata de implementar.

3. Aplicar é fácil. Calibrar é a parte difícil.

Essa percepção mudou a forma como pensava sobre toda a estrutura.

A maioria dos sistemas de agentes, incluindo versões anteriores do meu, trata cada tarefa praticamente da mesma forma. 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 muito arriscado.

O segredo é 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 que essa classificação decida quanta revisão ela recebe, qual modelo deve lidar com ela 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 mostraram valiosas quase imediatamente.

• Coloque suas regras na estrutura, não no comando. Um comando 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 worker novo para cada tarefa. Armazene registros de tarefas externamente, use worktrees isoladas e processe as alterações através de uma fila de merge. Quando 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 seu próprio trabalho do que com o de outro. Usar um modelo de um provedor diferente é uma maneira 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.