Dois anos atrás eu abria um arquivo, escrevia uma função, testava, quebrava, consertava. Sozinho, linha por linha. Hoje eu abro o terminal, escrevo um parágrafo explicando o problema, e um agente sai escrevendo código enquanto eu tomo café. Não é exagero: mudou o verbo do meu trabalho. Antes eu "escrevia código". Agora eu "reviso decisões". E essa mudança de verbo é o assunto deste post.
Contexto primeiro, código depois
O erro mais comum que ainda vejo — e que eu mesmo cometia — é pedir código antes de explicar o problema. "Cria uma função que valida CPF" gera código genérico, sem saber se é para um formulário, uma API, um batch job. O resultado funciona, mas não serve.
O que muda o jogo é inverter a ordem: primeiro você descreve o contexto. Qual é a regra de negócio, quais são as restrições, o que já existe no repositório, o que não pode quebrar. Só depois vem o pedido de implementação. Isso parece óbvio, mas é raro na prática porque dá trabalho escrever um bom parágrafo de contexto quando parece mais rápido só "jogar o prompt".
- Descreva o problema de negócio, não a solução técnica que você já imaginou.
- Cite arquivos, padrões e convenções existentes no projeto.
- Deixe claro o que não pode mudar — isso evita refatorações não pedidas.
Commit como save point, não como cerimônia
Outra coisa que mudou de verdade: a frequência dos commits. Eu costumava fazer commits grandes, no fim do dia, com mensagens tipo "ajustes diversos". Isso não funciona mais quando um agente pode reescrever meio módulo em trinta segundos.
Hoje eu faço commit a cada passo pequeno que funciona. Não é disciplina de boy scout, é sobrevivência: se o agente entrar numa direção ruim daqui a dez minutos, eu quero poder voltar exatamente para o ponto anterior sem perder o que já estava certo. Commit virou o botão de "salvar jogo", não um marco histórico.
- Commite antes de pedir uma mudança arriscada, não só depois.
- Mensagens curtas e descritivas bastam — o objetivo é navegação, não documentação.
git diffantes de aceitar qualquer coisa grande vira hábito, não exceção.
De um agente a uma equipe de agentes
No começo, era um agente, uma tarefa, um resultado. Você pedia, ele respondia, fim. Isso ainda existe, mas já não é o cenário mais interessante. O que mudou em 2026 é a duração e a coordenação: agentes que ficam trabalhando por dezenas de iterações numa mesma sessão, ajustando o próprio plano conforme encontram problemas — sem eu precisar reformular o prompt a cada erro.
E mais: agora é comum orquestrar vários agentes ao mesmo tempo, cada um com um pedaço isolado do trabalho. Um cuida do backend, outro escreve os testes, outro faz a revisão de segurança. Ferramentas como Claude Code e Codex já suportam esse padrão de subagentes trabalhando em paralelo, com um agente "líder" decidindo como dividir o problema. Isso parece luxo, mas na prática é a única forma de lidar com tarefas grandes sem estourar o contexto de um único agente.
A parte que exige mais maturidade do time é decidir o que dividir. Tarefas independentes — front separado de back, testes separados de implementação — se prestam bem a isso. Tarefas acopladas, onde um agente precisa saber exatamente o que o outro decidiu, geram conflito e retrabalho. Isso é decisão de arquitetura, não de prompt.
Os limites que ninguém resolveu ainda
Dito isso, não virou mágica. Existem limites reais que continuam travando o fluxo, e vale nomear com honestidade:
- Contexto ainda é finito. Repositórios grandes não cabem inteiros na cabeça do agente. Ele erra por não saber que aquela função já existe em outro lugar, ou que aquele padrão foi abandonado há dois meses.
- Segurança exige atenção redobrada. Um agente com acesso a shell, a credenciais, a produção, é uma superfície de ataque nova. Dar permissão de escrita irrestrita para um agente autônomo sem sandboxing é pedir problema.
- Revisão humana continua sendo o gargalo — e está certo que seja. A geração de código ficou rápida, mas ler, entender e aprovar um diff continua sendo trabalho humano. Isso não é um bug do processo, é o ponto onde a responsabilidade fica com alguém.
Quem trata revisão de código como etapa burocrática está se enganando. É o único lugar onde alguém pergunta "isso realmente resolve o problema, ou só parece resolver?" — pergunta que nenhum agente faz sozinho.
O que eu recomendo na prática
Se você está construindo esse fluxo no seu time, aqui vai o que tem funcionado para mim:
- Escreva o contexto antes do pedido — invista tempo na descrição do problema, não na engenharia do prompt perfeito.
- Commit pequeno e frequente. Trate cada commit como um checkpoint que você pode restaurar sem culpa.
- Divida tarefas grandes em partes independentes antes de acionar múltiplos agentes — a orquestração só ajuda quando as partes não se pisam.
- Restrinja o acesso do agente ao mínimo necessário: sandbox, permissões explícitas, nada de credenciais de produção soltas.
- Nunca pule a revisão humana em código que vai para produção, mesmo quando o agente "parece confiante".
No fim, a ferramenta mudou, mas a responsabilidade não. Quem assina o commit ainda é você.