Agentes de IA e o trabalho de quem escreve software

Durante uns dois anos, a discussão sobre IA na engenharia foi sobre autocomplete: a ferramenta sugere, você aceita ou não. O modelo é um estagiário rápido que nunca fica ofendido. Esse enquadramento já está obsoleto.

O que mudou não foi a qualidade da sugestão. Foi a unidade de trabalho. Antes, o modelo escrevia uma função e você colava. Agora ele recebe uma tarefa — "corrija este bug de conciliação", "migre este endpoint" — abre arquivos, roda testes, descobre que o problema estava em outro lugar e volta com um diff. O trabalho deixou de ser digitar e passou a ser definir e revisar.

O gargalo se mudou de lugar

Quando a execução fica barata, o custo se desloca para a verificação. É a lei mais subestimada desta fase: a velocidade de produção passa a ser limitada pela velocidade de revisão.

Consequências práticas que já aparecem em times reais:

• Diffs grandes ficam mais caros do que nunca. Um PR de 900 linhas "que passou nos testes" é praticamente irrevisável.
• Especificação virou código. Se o problema está mal descrito, o agente preenche a lacuna com a interpretação mais provável — não com a correta.
• O teste deixou de ser burocracia e virou o contrato. Quando você não confia no executor, você confia no verificador.

Nada disso é sobre ferramenta. É sobre mudar o formato do trabalho.

A pergunta deixou de ser "o modelo escreve bem?" e passou a ser "eu consigo auditar o que ele escreveu mais rápido do que faria sozinho?". Se a resposta for não, o ganho é negativo — mesmo com o código certo.

O que não muda

Três coisas continuam sendo integralmente suas:

1. Julgamento de contexto. O agente sabe o que está no repositório. Ele não sabe que a área de faturamento congela toda sexta, nem que o cliente X tem um contrato que permite exceção.
2. Decisão de trade-off. Escolher entre três soluções corretas exige saber o que a empresa vai precisar em dois anos. Isso não está em nenhum prompt.
3. Responsabilidade. Quando algo quebra em produção, o nome no commit é humano — e deveria continuar sendo.

O risco real não é ser substituído. É se tornar alguém que aprova sem entender, porque revisar dá mais trabalho do que fazer.

Onde eu apostaria tempo agora

Se você trabalha com software e quer se posicionar bem nos próximos dois anos, a ordem de prioridade que faz sentido para mim é esta:

• Escrever melhor. Descrição de problema, critério de aceite, decisão registrada. Isso era "soft skill"; virou infraestrutura.
• Investir em testes e observabilidade. Quanto mais barato executar, mais caro é errar sem perceber.
• Reduzir o escopo dos lotes. Entregas pequenas continuam sendo a melhor proteção contra revisões impossíveis.
• Aprender a fazer perguntas de auditoria. Não "está certo?", mas "como você sabe?", "o que quebra se eu mudar isso?".

O ganho de produtividade é real, mas ele não vem de graça: vem de reorganizar o processo em volta do novo gargalo. Times que só colocam o agente no fluxo antigo produzem mais código e revisam pior — o que, no fim, é produzir mais dívida.

---

Este texto é uma opinião sobre como o trabalho técnico está se reorganizando. Se você discorda, ótimo — é o tipo de discordância que vale discutir em público.