Antes de colocar agentes no seu repositório, desenhe as fronteiras

Existe um momento meio desconfortável quando você passa de "a IA me ajuda a escrever uma função" para "a IA pode abrir branch, mexer no repo e rodar comando".

No autocomplete, o estrago costuma ser pequeno. Você aceita ou recusa uma sugestão. No agente, a conversa muda. Ele pode ler arquivos, alterar vários pontos do projeto, acionar testes, tocar em configuração e, dependendo do setup, chegar perto de secrets que você não queria expor nem para um colega recém-chegado ao time.

É aí que a maturidade real começa.

Não acho que a pergunta mais importante hoje seja "qual agente escreve código melhor?". Essa discussão envelhece rápido. O ponto que separa um brinquedo bonito de uma ferramenta de produção é outro: até onde esse agente pode ir sem virar risco operacional?

Agente de código é infraestrutura

Quando um agente tem acesso ao seu repositório, ele deixa de ser só uma janela de chat. Ele vira uma peça do seu ambiente de desenvolvimento.

Isso parece detalhe semântico, mas muda tudo.

Você não daria acesso irrestrito ao banco de produção para um script novo só porque ele parece inteligente. Também não deveria dar acesso amplo ao agente só porque ele acerta bastante TypeScript.

O movimento do GitHub vai nessa direção. O Copilot cloud agent ganhou suporte mais flexível para secrets e variables específicos para agentes. A leitura prática disso é simples: o mercado está parando de tratar agente como usuário genérico e começando a separar credencial, escopo e contexto de execução.

Essa separação importa porque "a IA precisa de contexto" virou uma desculpa perigosa para entregar contexto demais.

Um agente talvez precise:

• ler a pasta do pacote em que está trabalhando;
• abrir uma branch temporária;
• rodar testes unitários;
• acessar variáveis falsas de ambiente;
• pedir aprovação antes de qualquer comando destrutivo.

Ele provavelmente não precisa:

• ler todos os secrets da organização;
• ter token com permissão de deploy;
• fazer push direto na branch principal;
• acessar arquivos pessoais do desenvolvedor;
• instalar dependências ou executar scripts sem log.

Essa lista parece óbvia quando está escrita. Na prática, muita gente começa pelo caminho inverso: dá acesso amplo primeiro e tenta arrumar a governança quando algo estranho aparece no diff.

Sandbox não é burocracia, é cinto de segurança

A OpenAI publicou um material interessante sobre como roda o Codex com segurança internamente. O que chama atenção não é uma promessa mágica do modelo. É a quantidade de controle em volta dele: sandbox, restrição de rede, aprovação humana para comandos sensíveis, auditoria e telemetria.

Isso é um sinal forte.

Se até quem constrói o modelo precisa de contenção pesada para operar agentes em escala, talvez o nosso projeto indie ou o repo da empresa também mereça uma camada mínima de fronteira.

Sandbox não serve só para impedir desastre. Serve para tornar o comportamento do agente observável. Quando tudo roda solto na máquina do dev, fica difícil responder perguntas básicas:

• que comando ele executou?
• quais arquivos ele leu?
• quais variáveis estavam disponíveis?
• ele tentou acessar a rede?
• o teste falhou porque o código está ruim ou porque o ambiente estava sujo?

Sem essas respostas, o agente vira uma caixa-preta simpática. E caixa-preta com permissão de escrita em repo nunca é uma boa combinação.

Secrets precisam ser desenhados para agentes

Um erro comum é tratar agente como se fosse apenas mais um desenvolvedor humano. Só que humanos têm contexto social, medo, memória de incidentes e uma boa dose de hesitação antes de colar um token em lugar errado.

Agentes não têm esse freio do mesmo jeito.

Por isso, a fronteira de secrets precisa ser explícita. Não basta falar "não vaze chave". O ambiente precisa tornar o vazamento difícil por padrão.

Na prática, eu começaria com algumas regras simples:

1. Use credenciais descartáveis para tarefas de agente.
2. Separe variáveis reais de variáveis de teste.
3. Evite expor secrets globais da organização.
4. Registre quais secrets cada agente pode ler.
5. Faça secret scanning em toda alteração gerada.

Perceba que isso não é um papo anti-IA. É exatamente o contrário. Quanto mais você quer usar agente de verdade, mais precisa desenhar o trilho onde ele roda.

Um exemplo pequeno: se o agente participa de uma esteira que valida assets de uma feature com imagens geradas por IA, ele não precisa ganhar permissão ampla no projeto inteiro só para chamar uma ferramenta específica. Para um caso bem delimitado de limpeza de imagens do Gemini, algo como Gemini Watermark Cleaner pode entrar como uma etapa isolada do fluxo, com arquivo de entrada, arquivo de saída e nada além disso. O valor está menos na ferramenta em si e mais no desenho: cada peça faz uma tarefa pequena, com permissão pequena.

Esse é o modelo mental.

CI virou parte da conversa, não etapa posterior

Outro sinal importante aparece nos próprios changelogs do GitHub: validação para agentes ficando mais rápida, incluindo ferramentas como CodeQL e secret scanning no fluxo do cloud agent.

Isso é bem menos glamouroso do que um vídeo de agente montando uma aplicação inteira em dois minutos. Mas é aqui que o uso sério mora.

Código gerado rápido cria dívida rápida. Se a sua esteira de revisão continua lenta, manual e frágil, o agente só acelera a bagunça.

O mínimo saudável é fazer o agente trabalhar junto com validação automatizada:

• teste unitário para o escopo alterado;
• lint e typecheck antes de abrir PR;
• secret scanning no diff;
• análise estática quando tocar em área sensível;
• resumo claro do que mudou e do que não foi testado.

Eu gosto de pensar nisso como uma regra simples: se a IA escreve mais rápido, a revisão precisa ficar mais automática, não mais relaxada.

Não dá para compensar geração acelerada com "depois alguém olha". Esse "alguém" normalmente é você, cansado, no fim do dia, tentando entender por que o agente mudou um arquivo de configuração que ninguém pediu.

O escopo bom é pequeno e chato

Existe uma tentação natural de pedir para o agente "resolver tudo". Refatorar o módulo inteiro. Modernizar o projeto. Corrigir todos os testes. Atualizar dependências. Melhorar performance.

Quase sempre, esse é o pior prompt operacional.

Agente funciona melhor quando a tarefa tem:

• fronteira de arquivos;
• critério de pronto;
• comandos permitidos;
• testes esperados;
• permissão clara para parar e reportar bloqueio.

Um pedido ruim:

Melhore a segurança do backend.

Um pedido bem mais seguro:

No diretório apps/api/src/auth, troque a validação manual de token pelo helper existente validateSession, sem alterar rotas públicas. Rode pnpm test auth e pare se precisar mexer em migrations.

O segundo pedido parece menos ambicioso, mas é o tipo de coisa que você consegue revisar. E revisão é o gargalo que muita gente ignora quando fala de agentes.

Um checklist antes de soltar o agente no repo

Antes de dar acesso de escrita a um agente, eu passaria por isso:

• Qual diretório ele pode editar?
• Ele pode acessar a internet?
• Quais comandos estão liberados?
• Ele pode instalar pacote?
• Ele pode ler secrets?
• Ele pode fazer commit?
• Quem aprova comandos destrutivos?
• Qual teste precisa passar?
• Onde ficam os logs da execução?
• Como eu revogo o acesso em um minuto?

Nada disso precisa virar uma plataforma interna gigante no primeiro dia. Para projeto pequeno, um README operacional, scripts bem definidos e uma sandbox local já mudam bastante o jogo.

O ponto é sair do "confia no agente" para "confia no ambiente".

O futuro do dev com IA parece mais DevOps do que prompt mágico

A parte curiosa dessa fase é que ela puxa o desenvolvedor para um lugar mais maduro.

No começo, parecia que o diferencial seria escrever o prompt mais bonito. Agora, cada vez mais, parece que o diferencial é saber desenhar sistemas onde agentes podem trabalhar sem quebrar tudo.

Isso envolve arquitetura, segurança, observabilidade, CI, revisão e um pouco de humildade. Porque agente bom ainda erra. E quando ele erra com acesso demais, o erro deixa de ser uma sugestão ruim e vira incidente.

Minha regra prática é: trate o agente como um estagiário muito rápido, sem medo e com acesso ao terminal.

Você não quer bloquear essa pessoa de fazer trabalho útil. Mas também não quer entregar a chave de produção no primeiro dia.

Desenhe as fronteiras. Dê uma tarefa pequena. Registre o que aconteceu. Rode validação. Revise o diff.

Depois aumente o escopo.

Esse caminho é menos chamativo do que vender a ideia de um robô que programa sozinho. Só que é o caminho que tem mais chance de sobreviver ao primeiro contato com um repositório real.