Outro dia estava numa conversa com uns engenheiros que tinham acabado de instalar o Claude Code e estavam dando os primeiros passos com os modelos mais avançados. Aquela fase em que a ferramenta ainda impressiona de verdade, você joga uma tarefa que ia te custar a tarde inteira e ela volta pronta em três minutos. No meio da conversa a pergunta apareceu do jeito que sempre aparece, metade brincadeira, metade sincera: se a IA já faz isso, nosso trabalho acabou?
Não acabou. Ele mudou de perspectiva.
Aqui eu não quero entrar na discussão de como as empresas estão subsidiando o custo do token como estratégia de aquisição, e que essa conta vai chegar em algum momento. Isso rende outro texto, e provavelmente um texto chato. Quero olhar o outro lado da moeda: um futuro não tão distante em que o preço do token esteja perto de zero. E acredite, isso vai acontecer logo. Basta parar de olhar só pro marketing da OpenAI e da Anthropic e prestar atenção no que os modelos chineses vêm fazendo em open source. Quando inferência virar commodity barata, aí sim a profissão acabou?
Também não. Mas a resposta boa pra essa pergunta é mais chata do que "sempre foi assim", então vou tentar chegar nela com calma.
Sessenta anos ouvindo a mesma promessa
COBOL ia acabar com os programadores porque gerente ia escrever o próprio relatório em inglês estruturado. Ferramentas CASE iam acabar com os programadores porque o diagrama viraria código. 4GL, UML executável, geração de código a partir de modelo, no-code, low-code. Cada onda dessas veio com um case de sucesso legítimo e uma previsão furada montada em cima dele. Estamos na sétima ou oitava rodada da mesma aposta.
O Brooks é a referência óbvia pra explicar por que essas ondas quebram sempre no mesmo lugar. Complexidade acidental é o atrito da máquina: escrever, compilar, buildar, refatorar, lembrar a sintaxe. Complexidade essencial é entender o domínio, decidir o que modelar, onde fica a fronteira, o que pode ser eventualmente consistente e o que precisa ser transacional porque tem Bacen do outro lado. As ferramentas atacaram o acidental com sucesso. O essencial nunca foi problema de ferramenta.
Só que citar Brooks e sair andando é preguiçoso, e ele mesmo não fica tão bem quanto a gente finge. A previsão dele era que nenhum avanço isolado daria dez vezes de produtividade em uma década. Isolado, ok, ninguém deu. Mas compilador otimizador, garbage collector, linguagem de alto nível, gerenciador de pacote e ambiente gerenciado empilhados ao longo de trinta anos passaram longe de dez vezes só se você medir muito mal. O argumento sobrevive de forma mais fraca do que costuma ser vendido.
E o argumento histórico tem um problema pior, que é ser indutivo. Seis ondas falharam, logo a sétima falha, é o mesmo raciocínio que o peru faz até o dia vinte e quatro de dezembro. Pode ser que dessa vez seja diferente. Eu acho que não é, e vou tentar defender isso com algo mais sólido que estatística de fracasso alheio.
Onde o trabalho foi parar
Antes de falar do que a ferramenta faz, vale mapear qual é o tamanho do terreno. Peguei emprestada de um texto do Ashpreet Bedi uma divisão em cinco camadas que achei útil pra isso, e vou usar o cenário mais extremo que existe, aquele em que o agente é literalmente o produto e a lógica de negócio inteira virou modelo decidindo em runtime. Software agêntico atravessa engenharia de agente, de dados, de segurança, de interface e de infraestrutura. Vale a leitura dele pro detalhe. O que me interessa é o tipo de decisão que aparece em cada uma.
Na camada do agente você define modelo, instrução, ferramenta, handoff, gerenciamento de contexto e observabilidade. Comportamento determinístico onde der, observável onde não der. Agente que você não consegue instrumentar é agente que você não consegue operar às três da manhã quando o alerta toca.
Dados é a camada mais subestimada de todas. Seu agente é tão bom quanto o contexto que ele alcança, e contexto é dado embaixo do capô, com os problemas de sempre: schema, indexação, consistência, ciclo de vida, custo de leitura. Vector store não te isenta de modelagem. Agente com contexto ruim é demo bonita que morre no segundo cliente.
Segurança é onde a ilusão de que o prompt resolve fica mais escancarada. A capacidade do agente é definida pelas ferramentas que você entrega pra ele, então a permissão precisa morar na ferramenta e na credencial. Leitura restrita se garante com role sem GRANT de escrita, porque parâmetro de sessão o próprio agente desliga com um SET se ele executa SQL arbitrário. Escrever "você não deve alterar dados" no system prompt é decoração. E isole os requests: contexto de um usuário aparecendo na resposta do outro é vazamento de dados com nome, sobrenome e artigo de LGPD, ainda mais se o dado for saldo, chave PIX ou linha de razão contábil.
Interface e infra eu junto porque doem juntas. Antes era uma API e um cliente; agora são REST, Slack, MCP, terminal e chat, cada superfície com o próprio sistema de identidade, e user ID do Slack não tem nada a ver com user ID do seu produto. Sua policy precisa valer igual em todas elas, porque o agente não faz ideia de onde veio a chamada. Embaixo disso roda a infra de sempre, quase idêntica a qualquer serviço que você já opera, com três diferenças previsíveis: request de agente demora muito mais e derruba seu timeout de ingress, resposta faz streaming e conexão longa muda o drain no k8s, e agente bom é proativo, então volta job agendado e execução em background. Nada que assuste quem já rodou worker de conciliação.
Conta comigo aí. Das cinco camadas, uma virou geração de token. As outras quatro continuam existindo com os mesmos padrões de vinte anos atrás e as mesmas formas de errar, e quase tudo nelas é decisão: qual fronteira, qual schema, quem pode escrever onde, o que pode falhar sem derrubar o resto.
Aí vem a objeção óbvia, que é a que eu mesmo faria lendo isso: e daí? Eu posso construir essas quatro camadas com agente também. Escrevo a migration com agente, o manifesto do k8s com agente, a policy de acesso com agente. O trabalho não sumiu, ele só foi delegado um nível acima.
E é verdade, faço isso todo dia. Só que aí o negócio fica engraçado, porque seu pipeline de desenvolvimento virou um sistema agêntico com as mesmas cinco camadas, agora com credencial de repositório e acesso ao CI. Você não fugiu do problema, você instanciou ele de novo, dessa vez dentro de casa e com permissão de escrita.
Delegar geração é fácil e barato. Delegar a aceitação daquilo é outra conversa, e é onde a coisa realmente trava.
O que fica caro quando o token fica de graça
Custo não desaparece, ele migra. Quando gerar código custa perto de zero, o gargalo passa a ser confiar no código gerado. Revisar, testar, entender consequência de segunda ordem, garantir que a mudança não quebrou a conciliação que roda às duas da manhã. Tempo de humano competente não barateia junto com inferência. Ele fica relativamente mais caro, porque tudo em volta barateou.
Isso tem uma consequência desconfortável: a quantidade de código que seu time consegue produzir por semana já não é o limite há algum tempo. O limite é quanto seu time consegue verificar com segurança por semana. Se você aumenta a produção em dez vezes sem mexer na capacidade de verificação, você não ganhou dez vezes de throughput, você criou uma fila.
Podemos colocar um agente revisando a saída de outro. Também faço isso, ajuda a pegar bobagem óbvia. O problema é que erro de modelo é correlacionado. Gerador e verificador treinaram na mesma internet, herdaram os mesmos pontos cegos e erram juntos justamente onde errar sai mais caro. Dois modelos concordando parece confirmação e é uma amostra só. Você subiu a confiança sem ter subido a evidência.
Existe ainda a parte que nenhuma arquitetura resolve. Quando o pagamento duplica em produção e alguém precisa explicar o que aconteceu, quem responde é uma pessoa com nome e CPF. Aceitação carrega responsabilidade, e responsabilidade não delega pra processo estocástico. Você automatiza o quanto quiser do caminho até o aceite. O aceite continua sendo assinatura de gente.
Isso sozinho não protege ninguém de corte de time, e seria desonesto vender assim. Uma pessoa responsável consegue assinar em cima de muito mais output do que conseguia cinco anos atrás. O que define quanto é a capacidade de verificação, e capacidade de verificação é gente que entende o sistema. Quem corta abaixo desse ponto não descobre no headcount, descobre na fila alguns meses depois.
Verificar bem exige entender o sistema inteiro, e entender o sistema inteiro é a coisa que continua morando na cabeça de gente. O contexto técnico das decisões antigas que ninguém documentou. O contexto de negócio do que aquele sistema precisa garantir e pra quem ele responde. Você não consegue aprovar um PR com convicção sem isso, por mais bonito que o diff esteja.
Se você é a pessoa que decide, essa é a parte acionável do texto. Investir em geração sem investir em verificação é apertar o acelerador olhando pro velocímetro errado. Isso quer dizer coisas concretas e sem glamour: eval e teste de fronteira de permissão rodando no CI, revisão tratada como atividade de primeira classe, com tempo alocado no planejamento igual qualquer entrega, observabilidade que responde o que aconteceu em produção sem alguém precisar adivinhar, e documentação de decisão arquitetural, que virou o insumo que alimenta tanto o humano quanto o agente.
E os juniores
A pergunta que mais aparece depois dessa conversa é o que acontece com quem está entrando agora, já que a tarefa de treino clássica, escrever o CRUD, virou autocomplete.
A gente já fez essa transição antes. Até uns cinquenta anos atrás, todo livro de matemática e engenharia vinha com tábuas de logaritmo nas últimas páginas, e o estudante passava horas aprendendo a interpolar valor à mão. A calculadora tornou aquele procedimento inútil da noite pro dia. A matemática não acabou, o engenheiro não acabou, e ninguém hoje sente falta de calcular log na mão. O que ficou foi o mais importante: entender o que a função faz, quando ela se aplica, por que aquela curva tem aquele formato e o que significa o resultado que apareceu no visor.
Aqui não vai ser tão diferente. A camada de abstração subiu de novo, e o que a gente precisa formar em quem está chegando é o racional. O procedimento a ferramenta faz. Modelagem, leitura de sistema legado, noção de consistência, por que aquele lock existe, o que acontece com a conciliação quando o job falha no meio.
E tem uma armadilha real nesse paralelo, que eu prefiro admitir do que esconder. Quem nunca fez o procedimento à mão às vezes perde o faro pra perceber que o resultado no visor está absurdo. Ordem de grandeza errada, sinal trocado. Essa é justamente a intuição que o júnior de hoje precisa desenvolver por outro caminho, porque ele não vai desenvolver escrevendo boilerplate por dois anos. Ele desenvolve lendo, quebrando de propósito e sendo obrigado a explicar o porquê antes de aprovar. O que sobra pra gente é transformar a revisão de código em ferramenta de formação, que é o que ela deveria ter sido esse tempo todo.
Foi mais ou menos isso que eu respondi pra aquela galera na conversa, e é mais ou menos o meu entendimento e o meu uso dessas ferramentas hoje. Não quero fazer previsão aqui, esse texto inteiro é sobre como previsão nessa área costuma envelhecer mal, inclusive a do Brooks. Mas se eu fosse apostar, apostaria nisso: quando o token custar zero, escrever código vira a parte barata, e confiar no que foi escrito continua caro.
E se der tudo errado, tranquilo, já comecei minha criação de tilápias. Comer todo mundo ainda vai precisar.
