A IA Sabe Escrever Seu Codigo. Ela Nao Sabe Fazer Seu Trabalho.

Eu chamo meu time de engenheiros, nao de programadores. Sempre fiz isso. Nao foi uma decisao consciente no inicio. So parecia certo. Engenheiros resolvem problemas. Programadores escrevem codigo. A diferenca costumava parecer semantica.

Nao parece mais.

O Trabalho Nunca Foi o Codigo

Algumas semanas atras, alguns engenheiros do meu time comecaram a liderar um esforco pra construir ferramentas internas de documentacao. O objetivo: tornar nossa documentacao utilizavel pra pessoas nao-tecnicas. Product managers, times de suporte, stakeholders que precisam entender o que construimos sem ler codigo-fonte.

A parte interessante e onde o trabalho realmente estava. Nao era no codigo. Era nas conversas antes do codigo. Entender quem le essa documentacao e por que. Descobrir o que "utilizavel" sequer significa pra alguem que nao pensa em APIs. Definir o escopo pra nao construir demais. Escrever uma spec clara pra que a intencao sobreviva a implementacao.

O codigo veio por ultimo. E sinceramente, essa foi a parte que a IA fez bem.

Isso e o que eu continuo vendo: os engenheiros que estao crescendo mais rapido agora nao sao os que escrevem mais codigo. Sao os que estao ficando melhores em tudo que vem antes dele. Especificacoes. Tickets que realmente dizem o que precisa acontecer. Conversas sobre produto onde perguntam "por que estamos construindo isso?" em vez de pular direto pro "como."

Os Dados Dizem a Mesma Coisa

Tem um estudo do METR que testou desenvolvedores experientes de open source em tarefas reais dos seus proprios repositorios. Os que usaram IA levaram 19% mais tempo pra terminar. Mas aqui esta a virada: esses mesmos desenvolvedores acreditavam que eram 20% mais rapidos. Uma diferenca de 40 pontos percentuais entre percepcao e realidade.

O relatorio da Faros AI analisou mais de 10.000 desenvolvedores em mais de 1.200 times. Desenvolvedores usando IA fizeram merge de 98% mais pull requests. O tempo de review de PR subiu 91%. O tamanho dos PRs aumentou 154%. E no nivel organizacional? Nenhum ganho mensuravel de performance.

O relatorio DORA 2025 do Google nao encontrou correlacao significativa entre adocao de IA e melhorias nas quatro metricas-chave de entrega. O enquadramento deles e o que ficou comigo: IA e um multiplicador das condicoes existentes. Ela torna times bons melhores. Ela expoe disfuncao nos que estao com dificuldades.

Mais codigo nao e mais valor. Nunca foi. A IA so tornou isso impossivel de ignorar.

As Velhas Ideias Sao a Nova Alavanca

Uma coisa que me surpreendeu. Os conceitos que discutimos ha anos, TDD, BDD, principios SOLID, clean architecture, tudo aquilo que metade da industria trata como academico ou ultrapassado. Sao exatamente o que faz a IA produzir codigo bom em vez de codigo plausivel.

Um programador pede pra IA "me faz uma pagina de login." Um engenheiro pede pra IA construir uma pagina de login com responsabilidade unica em mente, com unidades testaveis, com casos extremos definidos na spec. Mesma ferramenta. Resultado completamente diferente.

E aqui esta a parte desconfortavel de admitir: a IA e na verdade melhor em seguir esses principios do que a maioria de nos jamais foi. Sabiamos sobre SOLID. Falamos sobre TDD. Mas cortamos caminho sob pressao de prazo, pulamos os testes quando a feature parecia simples, deixamos a abstracao crescer ate estar errada. A IA nao tem esses impulsos. Se voce da restricoes claras, ela segue.

A distancia entre saber e fazer sempre foi o problema da engenharia de software. Tinhamos os principios. So nao aplicavamos consistentemente. A IA nao tem essa distancia. Mas ela precisa que voce defina as restricoes. Ela precisa que voce saiba como e o bom. Esse e o trabalho.

A Parte Honesta

Eu nao tenho metricas limpas pra nada disso. Nao consigo mostrar um dashboard dizendo "a IA tornou meu time 37% mais eficiente." Ninguem consegue, e eu desconfiaria de qualquer um que diga o contrario.

O que eu consigo ver e uma mudanca em como as pessoas abordam o trabalho. Engenheiros que costumavam pular direto pro codigo agora estao gastando mais tempo em specs. Conversas sobre o produto estao ficando mais afiadas. O projeto de ferramentas de documentacao nao comecou com um pull request. Comecou com uma pergunta: "Pra quem isso realmente e?"

Isso nao e algo que eu consigo colocar numa planilha. Mas eu confio no que estou vendo mais do que confiaria numa metrica inventada. E sinceramente, acho que os gestores que estao fingindo que ja entenderam tudo sao os que estao tomando as decisoes mais perigosas agora. Estao otimizando pra numeros que nao significam o que eles acham que significam.

O estudo do METR mostrou que desenvolvedores sentiam que eram mais rapidos enquanto eram mais lentos. Isso nao e so um achado de pesquisa. E um alerta pra qualquer pessoa medindo adocao de IA so pelo feeling, inclusive eu. Estou ciente de que posso estar na mesma armadilha. A diferenca e que nao estou fingindo o contrario.

O Que Nao Mudou

O trabalho nao mudou. Essa e a parte que as pessoas erram.

Engenheiros sempre foram responsaveis por transformar ambiguidade em clareza. Por entender o problema antes de pular pra solucao. Por fazer trade-offs que sobrevivem ao contato com producao. Por comunicar atraves da distancia entre o que stakeholders querem e o que sistemas conseguem fazer.

So passamos os ultimos vinte anos fingindo que o trabalho era escrever codigo, porque essa era a parte mais visivel. Agora que a IA escreve o codigo, nao tem mais onde se esconder. Os engenheiros que ja estavam fazendo o trabalho de verdade mal perceberam a mudanca. Os que estavam se apoiando na producao de codigo como substituto pro pensamento sao os que estao sentindo o chao se mover.

Eu chamo meu time de engenheiros porque e isso que o trabalho exige. Sempre exigiu. So paramos de conseguir fingir o contrario.