O que permanece com o desenvolvedor de software quando a AI escreve código?

A AI escreve código, e vai escrever cada vez mais. Não faz sentido competir com ela em quem digita uma função mais rápido; essa disputa já acabou. Por isso acho que “a AI vai substituir o desenvolvedor de software?” é uma pergunta mal feita. A pergunta que me interessa é outra: que parte do trabalho sobra para quem desenvolve, e como alguém aprende a fazer essa parte.

Este texto é de opinião, mas começa pelos dados, inclusive os que pesam contra mim.

O melhor argumento do outro lado

Em 2023, pesquisadores do GitHub e do MIT fizeram um experimento controlado: dois grupos de desenvolvedores implementaram o mesmo servidor HTTP em JavaScript, um deles com o GitHub Copilot. O grupo com a ferramenta terminou 55,8% mais rápido. Numa tarefa bem delimitada, com enunciado claro, a AI acelera muito.

O dado de emprego é mais incômodo. Brynjolfsson, Chandar e Chen, do Stanford Digital Economy Lab, acompanham folhas de pagamento da ADP no estudo Canaries in the Coal Mine?. Na versão de agosto de 2026, eles não encontram deslocamento amplo de empregos na economia. Mas o emprego de trabalhadores de 22 a 25 anos nas ocupações mais expostas à AI, entre elas desenvolvimento de software, está 19% abaixo de onde estaria se tivesse acompanhado o dos colegas menos expostos. Os próprios autores tratam esses números como descritivos, não como prova de causa.

Juntos, esses dados dizem algo que não dá para descartar: a AI já faz parte do trabalho de implementação, e a mudança parece pesar mais sobre quem está começando.

Onde o ganho diminui

Em julho de 2025, o METR publicou um estudo randomizado com desenvolvedores experientes trabalhando em repositórios open source que eles conheciam bem, em tarefas reais. Com AI, as tarefas levaram 19% mais tempo. Os participantes acreditavam estar mais rápidos.

Esse número precisa de cuidado. Em fevereiro de 2026, o próprio METR mudou o desenho do experimento, reconheceu problemas de seleção que tornam os dados mais recentes pouco confiáveis e disse que, no início de 2026, os desenvolvedores provavelmente já estavam sendo acelerados pelas ferramentas. Ou seja: o resultado de 2025 não vale como retrato de hoje, e não o uso como prova de que a AI deixa alguém mais lento. Uso como sinal de algo que reconheço no meu trabalho: quando a tarefa depende de contexto, de convenções do projeto e de decisões que não estão escritas, o tempo que a AI economiza na digitação volta como leitura, revisão e correção.

A pesquisa de 2025 do Stack Overflow aponta na mesma direção: 46% dos desenvolvedores desconfiam da precisão das ferramentas de AI, contra 33% que confiam. Os mais experientes são os mais cautelosos. O relatório DORA de 2025 descreve a AI como um amplificador: ela reforça as práticas que o time já tem, boas ou ruins.

O que eu penso: fundamentos decidem o que entra no prompt

Para mim, a AI é como um assistente mais inteligente do que eu em muita coisa. Ela me deixa mais produtivo. Mas ela responde ao que eu peço, e eu só peço bem o que eu entendo.

Um exemplo de integração, que é a minha área: um fluxo grava um pedido no banco e publica um evento para outros sistemas. Pedir “grave o pedido e publique o evento” gera código que funciona na demonstração. O problema aparece quando o banco confirma o pedido e a publicação do evento falha: o pedido existe e ninguém fica sabendo. Um outbox resolve essa parte, gravando o evento na mesma transação do pedido para publicá-lo depois. Aí vem o retry, e com ele a chance de o evento chegar duas vezes; por isso o consumidor precisa ser idempotente. São três mecanismos para três falhas diferentes. Quem os conhece sabe pedir a solução certa e sabe recusar a errada. Quem não conhece nem percebe que a pergunta existe. O Renato Augusto, num vídeo sobre esse tema, resume bem: a AI já sabe, mas você não sabe. E “boas práticas” não é um tempero que se acrescenta ao prompt; toda escolha de design é um trade-off que alguém precisa assumir.

É por isso que não vejo fundamento como algo opcional. Ele é o que me diz o que pedir e o que me faz desconfiar de uma resposta que parece certa.

O que eu penso: o custo aparece na manutenção

A segunda parte da minha posição é sobre revisão. Confiar sem revisar parece economia até o dia em que o código precisa mudar ou quebra. Aí ninguém sabe o que foi feito nem por quê.

Tenho um caso meu. Construí um orquestrador de issues do Linear, feito quase inteiro por AI sob a minha direção. Quando uma issue mudava de estado no Linear, um webhook avisava o orquestrador, que criava um worktree isolado no Orca e colocava um LLM para implementar a tarefa. Terminada a implementação, outro LLM revisava o que o primeiro tinha feito. Conforme o que o Orca devolvia, o orquestrador movia a issue no Linear: para revisão humana, de volta para correção ou para bloqueada. Os webhooks cuidavam da conversa entre o orquestrador e o Linear, e entre o Linear e o Slack, então eu acompanhava tudo sem abrir o terminal. No meio disso havia um Cloudflare Worker e containers Docker.

Eu sei arquitetura e sabia exatamente o que estava pedindo. Mas conheço pouco de Python, a linguagem em que ele foi escrito.

O fluxo funcionava: eu tinha rodado execuções de ponta a ponta com sucesso. Mesmo assim, pedi duas revisões independentes do código a outra AI. A primeira encontrou oito problemas. A segunda, feita depois das correções, encontrou mais, entre eles um token que vazava para o ambiente de um subprocesso, uma escrita de arquivo que seguia links simbólicos e uma aprovação que podia ficar presa para sempre. Depois disso, o projeto chegou a 565 testes automatizados. Todos usavam dublês, versões falsas do Linear, do Orca e dos outros serviços: provavam que a lógica estava certa, mas nenhum conversava com os sistemas de verdade. Eu não teria achado aqueles defeitos sozinho, porque não domino a linguagem. A verificação ficou nas mãos de outra AI.

Acabei congelando o projeto e trocando por um ambiente mais simples. O fundamento de arquitetura me permitiu dirigir a construção e decidir parar. A falta de fundamento na linguagem me impediu de manter o que eu mesmo tinha pedido. O custo de manutenção não é tudo ou nada: é barato enquanto o problema é o que você pediu, e fica caro quando o defeito está numa decisão que ninguém tomou conscientemente.

Contei outro caso, menor, em Quando a AI escreve o código, o trabalho do engenheiro muda de lugar: uma resposta 200 plausível para um cliente inativo, numa regra que o requisito não tinha fechado.

A parte desconfortável

Minha posição tem um ponto fraco, e os dados de Stanford apontam para ele. Os números não provam que a AI causou a queda de emprego entre os mais jovens. Mas levantam uma preocupação que eu tenho: se a AI automatiza justamente a tarefa bem delimitada, com enunciado claro, que era o trabalho de quem estava começando, o risco não é o fim da profissão. É o estreitamento do caminho de entrada. Eu aprendi fundamentos implementando coisas pequenas, errando e corrigindo. Se essas tarefas ficam com a AI, onde a próxima pessoa aprende o que eu estou dizendo que é essencial?

Não tenho uma resposta completa, e o período observado é curto. Mas não acho honesto dizer “é só aprender fundamentos” sem admitir que o lugar onde se aprendia pode estar encolhendo.

O que eu faria com isso

Se você está começando, eu não gastaria energia tentando ser mais rápido que a AI. Gastaria aprendendo o que ela não decide por você: especificar o problema, escrever o teste que pode contrariar a solução, ler um diff e explicar por que ele está certo. Use a AI para aprender também, perguntando por que, não só pedindo o código.

Se você lidera um time, o trabalho de entrada precisa ser desenhado de propósito. Dar a um júnior uma tarefa que a AI resolve sozinha não ensina nada. Dar a ele a revisão, a pergunta que o requisito não respondeu e a responsabilidade de explicar a mudança ensina.

A AI escreve código. O trabalho sempre foi decidir o que o código deve fazer e responder por ele. Essa parte continua com a gente, desde que alguém ainda saiba fazê-la.