Em 2024, "engenheiro de prompt" era o cargo do momento. Salário alto, sem exigência de diploma, matéria em toda revista de negócios. Hoje, dois anos depois, a função praticamente sumiu dos anúncios de vaga.

Não sumiu porque a habilidade deixou de importar. Sumiu porque ela virou pressuposto. Saber escrever um bom prompt hoje é como saber usar Excel ou montar um slide: útil, esperado, e ninguém contrata alguém só por isso.

Essa é a coisa mais importante que aconteceu com a carreira em tecnologia nos últimos dois anos, e quase ninguém tirou a conclusão certa dela. A conclusão não é "a IA acabou com os empregos". É outra, mais desconfortável: toda habilidade que a IA torna fácil deixa de valer dinheiro exatamente por ficar fácil. E isso vale para a próxima também.

Este post é sobre o que sobra. Vou mostrar os números reais do mercado, explicar por que saber usar IA parou de ser diferencial, detalhar as sete competências que passaram a decidir contratação, dar o caminho para quem está entrando agora que a escada perdeu os primeiros degraus, e fechar com sete previsões datadas que eu volto para corrigir em público.

• O mercado não encolheu, ele subiu de degrau. As vagas júnior caíram cerca de 40% desde 2022, enquanto 44% das empresas dizem que querem ampliar o time de TI.

• Usar IA virou o piso, não o teto. A prova é o cargo de engenheiro de prompt ter durado dois anos.

• A IA não distribui competência, ela amplifica a que já existe. Quem sabe julgar entrega mais; quem não sabe, produz o erro mais rápido.

• Existe um paradoxo medido: quanto mais o desenvolvedor confia na ferramenta, pior é o código que ele entrega.

• O que virou escasso é julgamento: revisar, decidir, arquitetar, proteger, calcular custo, entender o negócio e assumir a consequência.

• A distância entre júnior e sênior hoje é de 2,3 vezes o salário, e ela está aumentando, não diminuindo.

Parte 1: o diagnóstico, com os números na mesa

Antes de qualquer conselho, o retrato. Ele é contraditório de propósito, porque a realidade é contraditória:

O lado que assusta

• As vagas para desenvolvedor júnior caíram cerca de 40% desde 2022, com queda de aproximadamente 20% só em 2025.

• O Stanford AI Index de 2026 registrou queda de quase 20% no emprego de desenvolvedores de software entre 22 e 25 anos desde 2024.

• 37% dos empregadores declararam que prefeririam usar IA a contratar um recém-formado.

• No Brasil, estudo do FGV Ibre aponta que a automação já reduziu em quase 5% a chance de contratação de profissionais de 18 a 29 anos.

O lado que ninguém coloca na mesma frase

• 44% das empresas pretendem ampliar as equipes de TI até o fim de 2026, segundo o Guia Salarial 2026 da Robert Half, feito com 500 gestores de contratação e 1.000 profissionais.

• Segurança da informação lidera a demanda, apontada por 36% das empresas.

• Nuvem, engenharia de dados e desenvolvimento com IA seguem com procura elevada.

A síntese

Junte as duas listas e você tem a única leitura que explica as duas ao mesmo tempo: o mercado não encolheu, ele perdeu os primeiros degraus da escada.

O trabalho que a IA absorveu foi justamente o trabalho de entrada: escrever a função simples, traduzir o requisito óbvio, corrigir o erro de sintaxe, montar o CRUD. Esse trabalho tinha uma função dupla que ninguém percebia: além de entregar valor, ele formava gente. Era ali que o júnior aprendia a errar barato.

A escada continua existindo de cima. O que sumiu foi o degrau em que se subia.

A IA não substituiu o programador. Ela substituiu o primeiro emprego do programador, que é uma coisa bem pior de resolver.

E o que isso significa em dinheiro

Pelas faixas do Guia Salarial 2026, para desenvolvedor full-stack no Brasil:

Nível	Faixa mensal	Salto para o próximo
Júnior	R$ 6.050 a R$ 8.750	+72% até pleno
Pleno	R$ 9.550 a R$ 15.900	+31% até sênior
Sênior	R$ 12.450 a R$ 20.950	2,3x o júnior

Repare no formato desses números: o maior salto da carreira é o primeiro, de júnior para pleno, com 72%. É exatamente o salto que ficou mais difícil de dar, porque ele dependia de acumular repetição em tarefas que hoje a IA faz. Quem resolve esse degrau resolve o problema inteiro.

Parte 2: por que saber usar IA parou de ser diferencial

A commoditização é matemática, não opinião

Uma habilidade vale dinheiro quando é escassa. Ferramenta de IA boa está a uma assinatura de distância de qualquer pessoa no planeta, e a curva de aprendizado dela é de dias, não de anos. Qualquer coisa que se aprende em dias e que todo mundo tem acesso não sustenta salário, por definição.

O cargo de engenheiro de prompt é a demonstração empírica disso: nasceu, virou febre e virou pressuposto em 24 meses. A próxima habilidade "quente" de IA vai percorrer o mesmo caminho, provavelmente mais rápido.

O paradoxo da confiança

Este é o achado mais instrutivo de todos, e ele deveria estar colado no monitor de todo desenvolvedor.

Um estudo de Stanford pediu a 47 desenvolvedores que resolvessem cinco tarefas de programação segura, metade com assistência de IA. Quem usou IA produziu código significativamente menos seguro em quatro das cinco tarefas. Até aí, esperado. O achado forte veio depois: os desenvolvedores que geraram o código mais inseguro avaliaram sua confiança na ferramenta em 4 de 5, enquanto os que produziram o código mais seguro deram nota 1,5.

Ou seja: a variável que previu a qualidade não foi a experiência nem a ferramenta. Foi o grau de desconfiança. Quanto mais a pessoa confiava, menos revisava, e pior era o resultado.

E isso conversa com o volume do problema: auditorias encontram falhas de segurança em uma fatia enorme do código gerado por IA, com números que variam conforme a metodologia, da ordem de 45% num levantamento da Veracode e de 62% em outro da Cloud Security Alliance. Um estudo acadêmico da Universidade de Nova York analisou mais de 1.600 programas e encontrou falhas em cerca de 40%, chegando a 50% em linguagens como C.

As metodologias diferem e os números não são comparáveis entre si, mas a direção é a mesma em todos: é muito código com problema, e ele entra rápido. Escrevi sobre o lado prático disso em cibersegurança para desenvolvedores.

A velocidade que às vezes não existe

Em 2025, a METR fez um experimento controlado e aleatorizado com 16 desenvolvedores experientes em 246 tarefas reais nos próprios repositórios, todos grandes e maduros. O resultado: eles ficaram 19% mais lentos com IA, enquanto acreditavam ter ficado 20% mais rápidos.

Preciso ser justo com esse dado, porque ele é frequentemente mal usado. O estudo rodou com modelos de 2025, que envelheceram muito, e o cenário escolhido é praticamente o pior caso para IA: repositório enorme que o desenvolvedor conhece profundamente, onde o conhecimento local vale mais que a sugestão genérica. Não leia isso como "IA atrapalha", porque em código novo e em domínio desconhecido a aceleração é real e grande.

Leia como outra coisa, que continua válida hoje: a percepção de velocidade é um péssimo instrumento de medida. A sensação de estar produzindo não é a mesma coisa que estar produzindo, e quem não mede confunde as duas.

A conclusão que junta tudo

A IA é um multiplicador, e multiplicador precisa de um número para multiplicar. Ela não transforma quem não sabe julgar em alguém que sabe. Ela apenas faz com que essa pessoa produza o erro em escala e com aparência profissional, que é a pior combinação possível.

É por isso que o mercado parou de pagar por "sei usar IA" e passou a pagar por "sei quando a IA está errada".

Parte 3: as sete competências que decidem contratação agora

Aqui está o núcleo do post. Para cada uma: o que é, por que a IA não cobre, como treinar de verdade, e como provar numa entrevista. Porque ter a competência e não conseguir demonstrar dá no mesmo que não ter.

1. Julgamento técnico: saber dizer não ao código que veio pronto

O que é: olhar para 60 linhas que apareceram em dois segundos e responder três perguntas: isso está correto, isso é seguro, e isso é o que este sistema precisa. As três são diferentes.

Por que a IA não cobre: o modelo otimiza para plausibilidade. Ele produz código que parece certo, e "parece certo" é exatamente o que engana revisor apressado.

Como treinar: inverta o fluxo. Antes de aceitar qualquer sugestão, escreva em uma linha o que você espera que ela faça e quais casos de borda existem. Depois compare. Faça isso por 30 dias e você desenvolve o reflexo. Melhor ainda: peça à IA para gerar a solução, e depois peça para ela criticar a própria solução como se fosse um revisor sênior hostil. As duas respostas juntas ensinam mais que qualquer curso.

Como provar: na entrevista, quando mostrarem um trecho de código, comece pelos casos de borda e pelo que quebra, não pelo que funciona. Isso separa candidato em dez segundos.

2. Depuração de sistema, não de função

O que é: o bug que importa hoje não está dentro de uma função. Ele está entre três serviços, num timeout mal configurado, numa condição de corrida que só aparece com carga, num cache que serve dado velho.

Por que a IA não cobre: falta contexto de execução. O modelo não vê o seu log de produção, a sua latência de rede às 14h de segunda, nem o comportamento do seu banco sob concorrência.

Como treinar: pare de depurar por tentativa. Formule hipótese, defina qual observação a confirmaria ou a derrubaria, e só então mexa. Aprenda a ler log, métrica e trace de verdade. E provoque falha de propósito em ambiente de teste: derrube o banco, adicione 3 segundos de latência, estoure a memória. Você aprende mais em uma tarde disso do que em um mês de tutorial.

Como provar: tenha na ponta da língua uma história de bug difícil, contada na ordem certa: sintoma, hipóteses descartadas, como você isolou, causa raiz, e o que você mudou para que não voltasse. Essa última parte é a que quase ninguém conta e é a que mais impressiona.

3. Arquitetura e o custo da decisão

O que é: escolher entre opções que estão todas tecnicamente corretas, sabendo qual delas você vai pagar daqui a dois anos. Monólito ou serviços, fila ou chamada direta, banco relacional ou documento, construir ou contratar.

Por que a IA não cobre: ela responde muito bem "quais são as opções" e muito mal "qual delas serve para esta empresa, com este time, este orçamento e este prazo". Decisão de arquitetura é sobre restrição, e a restrição está fora do código.

Como treinar: escreva ADRs, que são registros de decisão de arquitetura. Uma página: contexto, opções consideradas, decisão, consequências aceitas. Faça isso mesmo em projeto pessoal. Seis meses depois, releia e veja o que envelheceu. Esse ciclo de feedback é o que constrói senso arquitetural, e é o que quase ninguém faz.

Como provar: leve um ADR real para a entrevista. Um documento em que você descreve uma decisão sua e, principalmente, o que você abriu mão ao tomá-la, vale mais que dez repositórios.

4. Segurança como comportamento padrão

O que é: tratar entrada como hostil, secret como radioativo e permissão como padrão negado. Não é a área de segurança, é a sua postura ao escrever qualquer coisa.

Por que a IA não cobre: porque, como vimos, ela é parte relevante do problema. Modelo treinado em código público reproduz padrões inseguros que estão no código público.

Por que vale dinheiro: é a área apontada por 36% das empresas como prioridade de contratação, o maior índice do levantamento.

Como treinar: comece pelo básico bem feito, que já coloca você acima da média: validação de entrada, consulta parametrizada, gestão de secret fora do código, princípio do menor privilégio, dependência atualizada. Rode um verificador de segredo no pre-commit. Leia o OWASP Top 10 e, para cada item, encontre uma ocorrência no seu próprio código. Você vai encontrar.

Como provar: conte uma vulnerabilidade que você achou e corrigiu, de preferência sua. Admitir a própria falha e mostrar a correção comunica maturidade que nenhum certificado comunica.

5. Engenharia de custo

O que é: a competência mais nova da lista e a que menos gente tem. Saber quanto custa rodar o que você escreveu: consulta ao banco, chamada de API, armazenamento, e agora também token de modelo. Software que funciona e é caro demais é software que vai ser desligado.

Por que a IA não cobre: o modelo não conhece a sua fatura. Ele otimiza para funcionar, não para caber no orçamento.

Por que virou crítico: aplicações com IA embutida trocaram uma estrutura de custo previsível por uma variável, que cresce com o uso. Quem não modela isso descobre na fatura.

Como treinar: pegue uma funcionalidade que você mantém e calcule o custo dela por mil execuções. Consulta, tráfego, armazenamento, token. Quase ninguém sabe esse número, e quem sabe conversa de igual para igual com quem decide orçamento. Escrevi sobre essa lógica em gerenciar um SaaS é equilibrar funcionalidade e custo.

Como provar: diga uma frase que quase nenhum candidato diz: "reduzi o custo dessa rotina de X para Y por mês, mudando Z". Isso muda o tom da entrevista inteira.

6. Domínio do negócio

O que é: entender o problema que o software resolve, com o vocabulário de quem vive dele. Regra fiscal, protocolo assistencial, malha logística, legislação trabalhista.

Por que a IA não cobre: ela sabe a teoria pública do domínio e não sabe a exceção específica da sua empresa, que é justamente onde mora a complexidade e o dinheiro.

Por que é a barreira mais forte: um desenvolvedor genérico compete com todos os desenvolvedores genéricos do mundo, e agora também com a ferramenta. Um desenvolvedor que entende de emissão fiscal, de escala de plantão hospitalar ou de conciliação de pagamento compete com um punhado de pessoas.

Como treinar: escolha um domínio e vá fundo por 12 meses. Leia a legislação, converse com quem opera, entenda por que a regra estranha existe. É lento e é a vantagem mais durável que existe, porque não dá para copiar em um fim de semana.

Como provar: use o vocabulário certo. Quando você fala "CRT", "interjornada" ou "chargeback" naturalmente, o entrevistador sabe que você esteve lá.

7. Comunicação escrita e propriedade do resultado

O que é: escrever de forma que uma decisão sobreviva sem você na sala, e assumir a consequência do que você entregou, inclusive quando dá errado.

Por que virou mais importante e não menos: este é o ponto contraintuitivo. Como a IA escreve texto bem, muita gente concluiu que escrever perdeu valor. Aconteceu o contrário: quando qualquer um produz texto correto, o que passa a valer é ter algo verdadeiro para dizer, com contexto que só quem participou tem. Documento genérico agora custa zero e vale zero.

Como treinar: escreva o resumo da sua semana em cinco linhas, para alguém que não é técnico. Faça isso toda sexta. Em três meses você vai perceber a diferença na sua clareza de pensamento, porque escrever mal quase sempre é sintoma de pensar confuso.

Como provar: propriedade se demonstra com uma frase: "essa decisão foi minha, deu errado por este motivo, e foi isso que eu mudei depois". Candidato que nunca errou em nada está mentindo ou nunca decidiu nada.

Parte 4: como entrar, se a escada perdeu os primeiros degraus

Esta é a parte que mais me pedem e que menos gente escreve, porque não tem resposta fácil. O que existe são caminhos que ainda funcionam:

Entre por manutenção, não por criação

Todo mundo quer construir o novo. Mas é em sistema antigo, mal documentado e em produção que a IA ajuda menos e que a empresa mais sofre. Vaga de sustentação, suporte técnico de segundo nível e migração de legado continuam abrindo, atraem menos concorrência e ensinam depuração de verdade. É o degrau que sobrou, e ele leva para o mesmo lugar.

Construa algo em produção com usuário de verdade

Portfólio com cinco projetos de tutorial hoje vale praticamente nada, porque qualquer pessoa gera isso numa tarde. Um sistema pequeno, no ar, com dez usuários reais, vale mais que trinta repositórios. Não pela complexidade do código, mas porque com usuário real aparecem as coisas que não se aprende sozinho: alguém usando errado, dado inconsistente, o servidor caindo às 3h, o pedido de mudança que quebra sua arquitetura bonita.

E leve o número junto: quantos usuários, quanto custa por mês, qual o tempo de resposta, quantas vezes caiu. Isso é conversa de profissional.

Escolha o nicho antes de escolher a linguagem

A pergunta "aprendo Python ou Java?" ficou pequena. A pergunta boa é "em qual setor eu quero ser a pessoa que entende de tecnologia?". Saúde, fiscal, logística, educação, jurídico, indústria. A linguagem você troca em três meses; o domínio leva anos e por isso protege.

Revise código dos outros

É o treino mais subestimado que existe. Abra projetos de código aberto e leia pull requests, principalmente os que foram rejeitados e o motivo. Você aprende julgamento observando julgamento, que é a única forma conhecida de aprender isso.

Prove julgamento, não velocidade

O mercado está cheio de gente que entrega rápido. Está vazio de gente em quem se confia sem revisar duas vezes. Em toda oportunidade de mostrar trabalho, mostre a decisão e o descarte, não só o resultado.

Parte 5: sete previsões, com placar público

Mesma regra do outro post de previsões: cada uma tem data de verificação e grau de confiança, e quando a data chegar eu volto aqui e marco acerto ou erro. O erro fica registrado, não é apagado.

Placar em 10/09/2026: 0 verificadas, 7 em aberto.

1. "Engenheiro de prompt" some quase por completo dos anúncios até dezembro de 2027

Confiança: 85%. A trajetória já está desenhada, e o padrão histórico de cargos que nascem de uma ferramenta é sempre esse: viram atributo de outras funções.

2. Pedir "conhecimento em IA" na vaga vira maioria e depois desaparece do texto

Confiança: 70%. Verificação: dezembro de 2028. Mesmo caminho de "conhecimento em internet" nos anos 2000: primeiro é destaque, depois é obrigatório, depois some porque virou pressuposto. Quando sumir do anúncio, terá vencido de vez.

3. A vaga júnior não volta ao patamar de 2022 até o fim de 2027

Confiança: 80%. O trabalho que sustentava aquele volume foi absorvido, e empresa não recria posto por nostalgia. O que deve aparecer é outra coisa: posições de entrada com outro desenho, mais próximas de operação e revisão do que de produção de código.

4. Consolida-se um papel de revisão e curadoria de código gerado, com outro nome

Confiança: 60%. Verificação: dezembro de 2027. A conta não fecha: se a geração de código multiplicou e a capacidade de revisão não acompanhou, alguém vai ser contratado para fechar essa lacuna. Coloquei só 60% porque é bem possível que isso não vire cargo, e sim mais uma exigência empilhada em quem já está lá.

5. Segurança de aplicação segue como a área de maior demanda relativa em 2027

Confiança: 75%. Já lidera com 36%, e o volume de código gerado sem revisão adequada só aumenta a superfície de ataque. A demanda acompanha o estrago.

6. Custo por funcionalidade vira métrica de engenharia em empresa média até 2028

Confiança: 65%. Enquanto o custo de infraestrutura era previsível, dava para ignorar. Com consumo variável de modelo dentro do produto, para de dar. Quem souber responder "quanto custa rodar isso" vai ter vantagem antes de a métrica virar padrão.

7. A distância salarial entre júnior e sênior aumenta, não diminui

Confiança: 70%. Verificação: guia salarial de 2028. Escassez se concentrou no topo e a oferta se acumulou na base. Enquanto isso durar, o prêmio por senioridade cresce.

A previsão que eu gostaria de errar

A número 3. Um mercado que não forma gente nova está queimando o próprio estoque de senioridade futura, e isso cobra a conta por volta de 2030, quando os seniores de hoje começarem a sair e não houver fila atrás. Se eu estiver errado nessa, é a melhor notícia da lista.

Parte 6: o que eu procuro quando avalio alguém

Falo aqui do meu lado da mesa, como quem contrata, avalia e trabalha com desenvolvedor há bastante tempo. Três coisas, em ordem:

1. Como a pessoa reage ao não saber. É o melhor sinal que existe. Quem inventa resposta é risco. Quem diz "não sei, mas eu descobriria assim" já demonstrou o método inteiro.

2. Se a pessoa pergunta sobre o negócio antes de perguntar sobre a stack. Quem quer saber quem usa, quantos são e o que dói, está pensando em resolver problema. Quem só pergunta qual framework, está pensando em currículo.

3. Se ela consegue explicar uma decisão técnica para alguém que não é técnico. Sem jargão e sem soberba. Quem não consegue, geralmente não entendeu tão bem quanto acha.

Nenhuma dessas três é sobre IA. E nenhuma delas ficou menos importante nos últimos dois anos; todas ficaram mais.

Do lado de quem contrata, a régua completa está em como contratar um programador sem se arrepender.

Parte 7: o erro de leitura mais comum

Alguém vai terminar este post e concluir "então é melhor não usar IA". Seria a conclusão exatamente errada.

Quem não usa fica para trás em velocidade, e velocidade continua importando. O ponto é outro e é mais sutil:

• Use a IA para ampliar alcance, entrando em tecnologia nova, entendendo código alheio, escrevendo o rascunho, cobrindo teste.

• Não use para pular o entendimento. Todo trecho que entra no seu sistema sem você saber explicar é dívida que vence no pior momento possível.

• Mantenha o músculo. Resolva alguma coisa sem ajuda com regularidade, do mesmo jeito que quem usa GPS todo dia deveria, de vez em quando, tentar chegar sozinho.

A regra que eu uso, e que funciona: se eu não consigo explicar o que aquele código faz, ele não entra. Não importa se funcionou no teste.

O resumo em uma frase

Saber usar IA te coloca na fila. O que decide a vaga é o que você faz quando ela erra, e ela erra bastante, com uma confiança impressionante.

Volto neste post em dezembro de 2027 para a primeira verificação do placar.

Perguntas frequentes

Saber usar IA ainda é diferencial em TI?

Não é mais diferencial, é pré-requisito. A prova mais clara é o cargo de engenheiro de prompt, que virou febre em 2024 e praticamente sumiu dos anúncios dois anos depois, porque a habilidade foi absorvida como atributo esperado de qualquer função. O que diferencia hoje é saber avaliar o que a IA produz.

A IA vai substituir programadores?

O que os dados mostram até agora não é substituição do programador, e sim do trabalho de entrada da profissão: as vagas júnior caíram cerca de 40% desde 2022 e o Stanford AI Index de 2026 registrou queda de quase 20% no emprego de desenvolvedores entre 22 e 25 anos desde 2024. Ao mesmo tempo, 44% das empresas dizem que querem ampliar o time de TI. O mercado se deslocou para cima, não desapareceu.

O que estudar em tecnologia em 2027 para não ficar obsoleto?

Sete frentes, nesta ordem de retorno: julgamento técnico para revisar código, depuração de sistemas distribuídos, arquitetura com foco em consequência de longo prazo, segurança como comportamento padrão, engenharia de custo (incluindo custo de token), domínio profundo de um setor específico, e comunicação escrita com propriedade sobre o resultado. Nenhuma delas se aprende em um fim de semana, e é exatamente por isso que elas sustentam salário.

Como um júnior consegue a primeira vaga hoje?

Quatro caminhos que ainda funcionam: entrar por manutenção e sustentação de sistema legado, onde a concorrência é menor e a IA ajuda menos; colocar um sistema pequeno em produção com usuários reais, o que vale mais que trinta projetos de tutorial; escolher um domínio de negócio antes de escolher a linguagem; e treinar julgamento revisando código de outras pessoas em projetos abertos.

É verdade que a IA deixa o desenvolvedor mais lento?

Em um cenário específico, sim. Um experimento controlado da METR em 2025 mediu desenvolvedores experientes 19% mais lentos com IA em repositórios grandes que eles conheciam a fundo, enquanto acreditavam estar 20% mais rápidos. É importante ler isso com cuidado: os modelos eram de 2025 e o cenário é o pior caso possível para a ferramenta. Em código novo e domínio desconhecido, a aceleração é real. A lição que permanece é que a sensação de produtividade não é medida de produtividade.

Código gerado por IA é inseguro?

Com frequência preocupante. Levantamentos apontam falhas de segurança em cerca de 45% do código gerado segundo a Veracode e em 62% segundo a Cloud Security Alliance, e um estudo da Universidade de Nova York encontrou falhas em cerca de 40% de mais de 1.600 programas analisados. As metodologias são diferentes e os números não se comparam diretamente, mas todos apontam na mesma direção. O agravante é comportamental: um estudo de Stanford mostrou que quanto maior a confiança do desenvolvedor na ferramenta, menos ele revisa e pior é o resultado.

Qual é o salário de desenvolvedor no Brasil em 2026?

Pelo Guia Salarial 2026 da Robert Half, para full-stack: júnior de R$ 6.050 a R$ 8.750, pleno de R$ 9.550 a R$ 15.900 e sênior de R$ 12.450 a R$ 20.950. O detalhe que importa para quem está planejando carreira é que o maior salto é o primeiro, de júnior para pleno, com cerca de 72%, e é justamente o degrau que ficou mais difícil de subir.

Vale a pena se especializar em um nicho de negócio?

É provavelmente a vantagem mais durável disponível hoje. Um desenvolvedor genérico compete com todos os desenvolvedores genéricos e também com a ferramenta. Quem entende profundamente de emissão fiscal, de escala hospitalar ou de conciliação de pagamento compete com pouquíssimas pessoas, porque esse conhecimento envolve exceções específicas que não estão na documentação pública e não se copiam em um fim de semana.

Devo parar de usar IA para não perder a prática?

Não. Quem não usa perde em velocidade, e velocidade continua contando. O equilíbrio é usar para ampliar alcance, como entrar em tecnologia nova ou entender código alheio, e não usar para pular o entendimento. Uma regra prática que funciona: se você não consegue explicar o que o código faz, ele não entra no sistema, mesmo que tenha passado no teste.

Os dados citados vêm do Stanford AI Index 2026, do Guia Salarial 2026 da Robert Half, de estudo do FGV Ibre sobre automação e contratação, do experimento controlado da METR de 2025 e de levantamentos de segurança da Veracode, da Cloud Security Alliance e da Universidade de Nova York. Metodologias diferentes não são comparáveis entre si, e indiquei isso onde é relevante. As previsões são minhas e estão sujeitas a verificação pública nas datas indicadas. Última atualização: 10 de setembro de 2026.