O modo automático do agente precisa de um orçamento por tarefa

Imagine um ticket pequeno: extrair uma função repetida sem mudar o comportamento. Você deixa o agente no modo automático, ele tenta ajustar o código algumas vezes e entrega um diff com cara de pronto.

O painel mostra o consumo. Ainda falta conferir se a mudança está certa e quanto trabalho manual será necessário para aceitá-la. Uma tentativa barata pode terminar em uma revisão demorada; uma tentativa mais cara pode entregar algo que você consegue verificar rápido. Também pode só custar mais.

Eu começaria pelo ticket, não pelo seletor de modelos: qual é a entrega, quanto essa investigação pode consumir e quando alguém precisa decidir se vale continuar?

Automático não significa orçamento fechado

A seleção automática do Copilot tem os níveis efficiency, balance e intelligence, que mudam a preferência entre custo, qualidade e tempo de resposta. Os três usam o mesmo conjunto de modelos disponíveis, e a escolha acontece por prompt. Mesmo em intelligence, uma tarefa simples pode ir para um modelo pequeno.

A cobrança depende do modelo efetivamente escolhido, não do nome do nível. O recurso está em distribuição gradual no VS Code, no Copilot CLI e no app do Copilot; não dá para presumir que já esteja disponível para todo mundo.

Isso ajuda a reduzir escolhas manuais. Mas escolher uma preferência de roteamento não define quanto o seu ticket pode gastar. E receber uma resposta não comprova que a tarefa foi concluída.

Vale separar essas decisões:

A preferência de roteamento orienta a escolha do modelo.
O orçamento define os limites da execução.
O critério de aceite define o que você precisa verificar na entrega.

Se você só configura a primeira, as outras continuam em aberto.

Escreva o aceite antes de escolher o nível

"Melhore essa parte do código" deixa muita coisa para o agente decidir. Para uma refatoração local, um pedido mais útil seria: extrair a lógica repetida, preservar a API pública, não adicionar dependências e manter os testes relevantes passando.

Antes de executar, registre também onde ele pode mexer, o que ainda é incerto e quem vai revisar. Um bug com reprodução conhecida é diferente de um erro intermitente que você ainda não conseguiu reproduzir.

A criticidade merece uma decisão própria. Uma mudança em autenticação pode ser curta e continuar exigindo revisão especializada. Escolher mais raciocínio não autoriza acesso a credenciais, merge ou deploy.

O aceite precisa acompanhar o risco da mudança. Em uma tarefa simples, testes e revisão do diff podem bastar. Em uma área sensível, testes passando ainda podem deixar regras de negócio ou riscos de segurança sem cobertura.

Uma matriz para começar, sem promessa de desempenho

Se os níveis estiverem disponíveis no seu ambiente, dá para usá-los como hipótese inicial:

Documentação de uma função, com o comportamento já definido: experimentar efficiency.
Refatoração local, com contratos e testes existentes: experimentar balance.
Bug intermitente, com diagnóstico ainda incerto: avaliar intelligence e reservar tempo para investigar.
Revisão de segurança: exigir avaliação especializada e aprovação humana, independentemente do nível.

Essa é uma proposta de trabalho, não uma recomendação oficial nem um resultado de benchmark. O contexto do repositório, as ferramentas disponíveis e a dificuldade da tarefa podem mudar a escolha.

Um nível econômico pode reduzir o custo de cada tentativa e aumentar o retrabalho. Um nível mais forte pode custar mais sem melhorar uma alteração mecânica. A matriz serve para você formular uma hipótese e conferir o que aconteceu, em vez de tratar o nome do nível como garantia.

Defina os limites da execução

O orçamento por tarefa precisa fazer parte do fluxo que inicia e acompanha o agente. É uma política proposta aqui para o seu trabalho, não uma função de limite financeiro atribuída ao seletor do Copilot.

Defina o gasto permitido, a duração máxima e o número de tentativas antes de começar. Depois, confira quais desses limites o executor realmente consegue aplicar.

Um alerta não interrompe uma execução. Uma estimativa não é gasto confirmado. Se a ferramenta só mostra o consumo depois, você não tem um teto financeiro garantido durante a tarefa. Limitar tempo e tentativas ajuda a conter uma execução, mas não assegura um valor máximo na conta.

Ao alcançar um limite, interrompa novas tentativas, preserve o diff, os resultados dos testes e as hipóteses que ainda precisam de investigação. A pessoa responsável pode decidir continuar, reduzir o escopo ou assumir o diagnóstico. Subir de nível e reiniciar sem autorização contorna o limite que você acabou de definir.

Interromper também tem custo: uma investigação útil pode ficar pela metade. Por isso, o trabalho parcial precisa ficar acessível, com a pendência explícita, sem marcar o ticket como concluído.

Para um próximo ticket, este poderia ser um registro simples. É um exemplo ilustrativo de planejamento, sem resultados preenchidos e sem relação com o formato de uma API:

Tarefa: extrair a lógica repetida de uma função, sem alterar sua API pública.

Base: registrar o commit inicial antes da execução.

Preferência inicial: balance.

Aceite: testes relevantes passando, comportamento preservado e diff revisado pela pessoa responsável.

Limites: gasto previamente aprovado, no máximo 15 minutos e duas tentativas. Registrar quais limites são aplicados automaticamente e quais dependem de acompanhamento.

Encerramento: parar ao alcançar um limite ou cumprir o aceite; pedir autorização para continuar ou ampliar o escopo.

Depois da execução, acrescente os modelos efetivos por etapa, quando essa informação estiver disponível, o gasto ou consumo registrado, as tentativas, o tempo de execução e o tempo de revisão. Se uma informação não estiver disponível, registre "não informado". Não preencha o modelo com um palpite baseado no nível escolhido.

Compare o custo do piloto, incluindo as falhas

Uma comparação útil liga o consumo ao resultado que passou pelo aceite. Para isso, escolha um conjunto pequeno de tarefas representativas e mantenha ferramentas, permissões, instruções e critérios de aceite consistentes entre as alternativas.

Em cada comparação da mesma tarefa, comece pelo mesmo commit-base. Não entregue a uma alternativa o repositório já corrigido pela outra. O roteamento automático pode escolher modelos diferentes ao longo da tarefa; registre essas escolhas quando a ferramenta as expuser. Quando ela não mostrar essa informação, você estará comparando a preferência e o fluxo disponíveis, sem conseguir atribuir o resultado a um modelo específico.

Inclua no gasto do piloto as execuções rejeitadas, bloqueadas ou interrompidas. Olhar só para as que passaram faz uma opção cheia de retrabalho parecer econômica. Registre também quantas tarefas foram aceitas e quais ficaram pendentes: esse contexto precisa acompanhar qualquer indicador de custo por tarefa aceita.

Se nenhuma tarefa foi aceita, não apresente esse indicador nem declare um vencedor. Você tem um piloto sem entrega aceita, e as falhas precisam ser examinadas antes de outra rodada.

Mantenha o tempo humano separado do gasto da ferramenta. Anote quanto foi necessário para revisar, corrigir manualmente e verificar o resultado. Sem uma regra explícita para converter tempo em dinheiro, esses registros não devem virar um único valor chamado "custo total".

Uma amostra pequena ajuda a escolher o próximo piloto. Não prova que um nível é superior em qualquer repositório, e um teste incompleto não transforma código errado em entrega correta.

Comece no próximo ticket

Escolha uma alteração pequena, sem dados sensíveis e com um aceite que você consiga reproduzir. Escreva os limites, execute e confira a entrega. Se houver retrabalho, registre-o antes de ajustar a preferência para a próxima tarefa.

Não é preciso montar uma plataforma de roteamento para começar. Um ticket bem definido e um registro curto já ajudam a perceber quando o modo automático está economizando decisões e quando está apenas acumulando tentativas.

Antes de ativá-lo, deixe escrito o contrato da tarefa. Assim, você sabe o que aceitar, o que ficou pendente e quem pode autorizar a continuação.