Agente CLI não se adota por decreto

Imagine uma cena bem comum para os próximos meses.

A empresa libera um agente no terminal. Pode ser Copilot CLI, Claude Code, Codex ou alguma variação interna. Alguém manda uma mensagem no Slack, faz uma demo bonita, mostra o agente abrindo um PR e pronto: "agora o time tem IA no fluxo de desenvolvimento".

Na semana seguinte, acontece o de sempre. Uma pessoa usa todo dia e não conta direito o que está fazendo. Duas testam uma vez, acham legal, esquecem. Outra trava na hora de deixar o agente mexer no repositório. O gestor olha para o painel de licenças e tenta descobrir se aquilo virou produtividade ou só mais um custo recorrente.

Esse é o ponto: agente CLI não se adota por decreto. Ele entra no trabalho quando o uso fica visível, copiável e revisável.

O primeiro uso não é a adoção

Instalar a ferramenta é a parte fácil. O primeiro comando também.

A adoção real começa quando alguém volta para a ferramenta na segunda e na terceira tarefa. E isso quase nunca acontece porque um documento interno disse "usem IA". Acontece porque um dev vê outro dev resolvendo um atrito real: gerar testes chatos, investigar uma falha de build, separar um refactor pequeno, revisar uma migração repetitiva.

O detalhe social importa mais do que parece. Se o uso bom fica escondido na máquina de uma pessoa, o resto do time não aprende o padrão. Se o uso ruim vira fofoca de corredor, ninguém aprende o limite. Nos dois casos, a ferramenta vira uma caixa preta.

Um rollout minimamente saudável precisa responder perguntas simples:

que tipo de tarefa vale delegar?
que tipo de tarefa ainda é melhor fazer na mão?
qual comando, permissão ou contexto foi usado?
quanto trabalho sobrou na revisão?
o agente economizou tempo ou só empurrou trabalho para o code review?

Sem isso, "usar agente" vira uma opinião. Cada pessoa mede do seu jeito.

PR mesclado é sinal, não veredito

Existe uma tentação forte de medir agente por volume: mais PRs, mais commits, mais linhas, mais tarefas fechadas.

Eu entendo a vontade. Volume é fácil de contar. O problema é que volume não é a mesma coisa que valor.

Um PR pequeno que remove um bug antigo pode valer mais do que cinco PRs que mexem em arquivo periférico. Um agente pode abrir um diff grande que compila, passa lint e ainda assim piora a manutenção. E, do outro lado, ele pode economizar uma tarde inteira em uma tarefa tediosa que ninguém queria pegar.

Então dá para olhar PR mesclado? Dá. Só não dá para tratar isso como placar final.

Eu começaria olhando para um conjunto mais honesto:

uso repetido por pessoa, não só ativação de licença;
tipo de tarefa delegada;
tempo entre a saída do agente e a revisão humana;
quantidade de mudanças descartadas;
custo por tentativa longa;
builds, Actions, APIs e pipelines acionados pelo fluxo;
exemplos internos que o time conseguiu copiar.

Esse último ponto parece menor, mas não é. Um bom exemplo interno vale mais do que uma palestra genérica sobre IA. Ele mostra o tamanho da tarefa, o contexto passado ao agente, o diff final e o que precisou ser corrigido.

Comece por tarefas pequenas e auditáveis

O pior rollout é liberar o agente direto no trabalho mais ambíguo: "refatora essa área", "melhora a arquitetura", "faz a feature".

Isso pode funcionar com alguém experiente pilotando de perto. Para adoção de time, costuma ser amplo demais.

Prefira tarefas com borda clara:

escrever testes para um comportamento já entendido;
atualizar uma documentação técnica curta;
separar uma mudança mecânica em commits menores;
reproduzir um bug com passos explícitos;
comparar alternativas de biblioteca e montar uma nota;
preparar variações de assets ou exemplos visuais para uma issue de produto.

Repare que essas tarefas não são "menores" no sentido de irrelevantes. Elas são boas porque deixam recibo.

Se o time está explorando interface gerada por IA, por exemplo, o agente pode levantar referências, organizar casos e comparar padrões a partir de uma curadoria como recursos de Generative UI. O resultado ainda precisa de leitura humana, mas a tarefa tem começo, fim e critério de revisão.

Em um fluxo de produto com imagem, outro exemplo pequeno é pedir ao agente para montar um checklist de publicação e deixar a etapa visual explícita: gerar o texto, apontar os tamanhos necessários e depois preparar o asset em uma ferramenta local como Resize Image for Instagram. Não é sobre transformar o agente em designer. É sobre escolher uma tarefa onde o resultado pode ser conferido sem fé.

Esse tipo de exemplo ajuda porque o time consegue discutir o processo. Não a magia.

Custo precisa aparecer cedo

Agente no terminal tem uma característica meio traiçoeira: ele parece uma conversa, mas pode virar infraestrutura.

Ele chama ferramenta. Lê arquivo. Roda teste. Aciona build. Tenta de novo. Gera diff. Pede mais contexto. E, dependendo do produto, tudo isso entra em algum modelo de cobrança por uso, limite de request, fila de CI ou tempo de máquina.

Se ninguém olha isso no começo, o custo só aparece quando já virou hábito.

Não precisa criar um comitê para cada prompt. Mas vale ter um painel simples, ou até uma nota semanal:

quais tarefas consumiram mais?
quais tentativas longas foram jogadas fora?
quais comandos o agente rodou sem necessidade?
quais pipelines foram acionados por engano?
que tipo de tarefa deu retorno claro?

O objetivo não é assustar o time. É tirar o custo da névoa.

Quando custo fica invisível, a conversa vira moralista: "IA ajuda" contra "IA atrapalha". Quando custo aparece junto do resultado, a conversa melhora: "essa tarefa vale delegar", "essa aqui ainda não", "esse limite precisa ser menor".

Revisão humana não é cerimônia

Tem gente que fala de revisão humana como se fosse um detalhe burocrático. Para agente de código, é o centro do acordo.

O agente pode escrever código rápido, mas quem assume a manutenção é o time. Então o diff precisa contar uma história que um humano consiga revisar:

por que essa mudança existe?
qual arquivo foi tocado?
quais testes cobrem o comportamento?
que parte foi tentativa descartada?
quais permissões ou ferramentas foram usadas?

Se a resposta fica espalhada em terminal, prompt perdido e memória local, o review vira arqueologia. Ninguém merece.

Um jeito simples de começar é exigir um pequeno recibo junto do PR quando houver agente envolvido. Nada teatral. Algo como:

tarefa delegada;
comando ou modo usado;
arquivos principais tocados;
testes rodados;
ponto que o autor revisou com mais cuidado.

Isso não resolve tudo, mas muda a qualidade da conversa. O reviewer deixa de perguntar "foi IA?" e passa a perguntar "o processo foi bom o suficiente para eu confiar neste diff?".

Controle demais também atrapalha

Claro que dá para errar para o outro lado.

Se cada uso do agente exige aprovação, formulário, política e reunião, ninguém vai experimentar nada. O time perde justamente a parte que poderia descobrir: onde a ferramenta ajuda de verdade no fluxo local.

O equilíbrio que eu gosto é pequeno e observável:

escolha duas ou três tarefas de baixo risco;
combine limites de permissão e custo;
peça recibos curtos;
compartilhe exemplos bons e ruins;
revise o processo no fim da semana.

Sem grande manifesto. Sem fingir que a ferramenta é só autocomplete. Sem jogar um agente com shell dentro do repositório e torcer.

O rollout bom parece chato de propósito

Um agente CLI bom some um pouco no trabalho. Ele resolve atrito, deixa rastro, aceita revisão e não obriga o time a acreditar em mágica.

Por isso eu desconfio de rollout que começa com anúncio grande e pouca prática. A pergunta não é "qual agente vamos adotar?". A pergunta é mais pé no chão:

O time consegue ver, copiar, medir e corrigir o uso real?

Se a resposta for não, ainda não existe adoção. Existe só acesso à ferramenta.

Comece menor. Escolha tarefas com borda. Mostre exemplos. Conte custo. Revise o diff. Depois aumente a ambição.

Agente CLI não precisa nascer como política enorme. Precisa nascer como uma prática que o time consegue ajustar sem perder a confiança no código.