Suas Certificações São Inúteis na Era da IA

“Professor, pra quê isso? Eu não uso fórmula de Bhaskara pra comer, pra beber nem pra trabalhar. Isso é inútil. Não faz o menor sentido ficar calculando essas coisas.”

A sala inteira riu. O professor ajeitou os óculos, deu aquele meio sorriso que só professor veterano tem, e disse algo que eu não entendi na hora: “Você não está aprendendo a fórmula. Você está aprendendo a pensar.”

Eu era esse aluno. Tinha uns 15 anos, achava matemática uma perda de tempo colossal, e estava convicto de que o mundo real não tinha nada a ver com equações de segundo grau. Vinte e poucos anos depois, escrevo código todo dia com inteligência artificial ao meu lado, e finalmente entendi o que aquele professor quis dizer.

Ele estava certo. E essa reflexão nunca foi tão urgente quanto agora.

O Dia em Que Percebi Que Bhaskara Não Era Sobre Bhaskara

Aconteceu enquanto eu depurava um problema de arquitetura num sistema distribuído. Precisava decidir entre duas abordagens de cache, cada uma com trade-offs diferentes de consistência e latência. Nenhuma ferramenta de IA ia resolver aquilo pra mim. Nenhum framework tinha a resposta pronta. O que eu precisava era decompor o problema em partes menores, analisar variáveis, pesar consequências e escolher a solução menos pior.

Sabe o que isso é? Exatamente o que meu professor tentou me ensinar com Bhaskara.

A fórmula nunca foi sobre a fórmula. Era um pretexto, um veículo para treinar o cérebro a fazer algo que nenhuma ferramenta substitui: raciocínio abstrato. Pegar um problema complexo, identificar as variáveis, isolar o que importa e chegar numa resposta fundamentada. Isso é pensamento computacional na essência, muito antes de qualquer linha de código.

Edsger Dijkstra, um dos pais da ciência da computação, resumiu isso décadas atrás com uma frase que me persegue:

“Computer science is not about machines, in the same way that astronomy is not about telescopes.”

Edsger W. Dijkstra

Ciência da computação não é sobre máquinas. Não é sobre linguagens. Não é sobre frameworks. É sobre pensar. E pensar é o que o professor de matemática tentava me ensinar naquela sala de aula barulhenta.

A Corrida Que Não Tem Linha de Chegada

Se você é desenvolvedor, provavelmente já viveu esse ciclo: aprender React, depois Vue, depois Svelte, depois Next.js, depois o framework do mês. Tirar certificação AWS, que vale dois anos. Depois a da Azure. Depois a do GCP. Quando a terceira certificação chega, a primeira já expirou.

É exaustivo. E é, com todo respeito ao esforço envolvido, correr atrás do vento.

O livro de Eclesiastes (independente de crença) tem uma observação que me acompanha: “Observei tudo o que se faz debaixo do sol, e tudo é vaidade e correr atrás do vento.” Quando li isso pela primeira vez, não pensei em tecnologia. Hoje, penso toda semana.

Se você não é da área: Frameworks são “esqueletos” prontos de código que facilitam construir aplicações. React, Vue e Svelte são frameworks para interfaces web. Cada um tem sua filosofia e comunidade, e novos aparecem com frequência.

O problema não é aprender coisas novas. Aprender é fundamental. O problema é confundir ferramenta com fundamento. Saber React não é um fundamento. Saber como componentes se comunicam num sistema reativo, isso é um fundamento. A diferença parece sutil, mas muda tudo.

Veja o que envelhece e o que permanece:

O que envelhece	O que permanece
jQuery (quem lembra?)	Manipulação do DOM e eventos
AngularJS 1.x	Padrões de arquitetura MVC/MVVM
Certificação específica de cloud	Design de sistemas distribuídos
A sintaxe do Python 2	Algoritmos e estruturas de dados
O framework CSS do momento	Fundamentos de layout e tipografia
A API do momento	Protocolos HTTP, TCP/IP, REST

As ferramentas da coluna da esquerda tiveram seu momento. Brilharam, dominaram conferências, geraram milhares de vagas. E passaram. Os fundamentos da coluna da direita existem há décadas e continuam sendo a base de tudo que construímos.

A IA Mudou as Regras do Jogo

Aqui é onde a história fica interessante. Com Claude, GPT, Copilot e dezenas de outras ferramentas, qualquer pessoa hoje pode gerar código funcional em qualquer linguagem, em qualquer framework. Eu mesmo construí um software inteiro de 60 mil linhas em 9 dias usando IA como copiloto. Se a IA escreve código em React, Python, Rust ou Go com a mesma facilidade, qual o valor de “saber” uma linguagem específica?

A resposta é: cada vez menos.

O valor migrou. Não está mais em saber digitar useState de memória ou lembrar a sintaxe de um decorator em Python. Está em saber o que construir, por que construir, e como avaliar se o que foi construído faz sentido.

E aqui entra um dado que me fez repensar muita coisa. A organização METR (Model Evaluation & Threat Research) conduziu um estudo controlado em 2025 com 16 desenvolvedores experientes, gente com média de 5 anos de experiência em repositórios open-source maduros, com mais de um milhão de linhas de código. O resultado?

Desenvolvedores com IA ficaram 19% mais lentos.

Sim, mais lentos. Não mais rápidos. E o mais revelador: antes do experimento, os próprios devs estimaram que a IA os tornaria 24% mais rápidos. Depois do experimento, ainda achavam que tinham sido 20% mais rápidos. A percepção era completamente desconectada da realidade.

Se você não é da área: Um estudo controlado (RCT) divide participantes em dois grupos aleatoriamente (um usa a ferramenta, outro não) pra medir o impacto real, sem viés de confirmação.

Por que isso acontece? Porque o gargalo do desenvolvimento de software nunca foi digitar código. Sempre foi pensar no problema. A IA gera código rápido, mas o tempo gasto revisando, entendendo, refatorando e debugando esse código frequentemente excede o tempo que o desenvolvedor gastaria escrevendo do zero.

A pesquisa do Stack Overflow Developer Survey de 2025 reforça o quadro: 84% dos desenvolvedores usam ou planejam usar IA no dia a dia. Mas a confiança nos resultados despencou, de 40% em 2024 para apenas 29% em 2025. E 45% dos devs dizem que debugar código gerado por IA consome tempo demais.

A mensagem é clara: a IA é uma ferramenta poderosa, mas sem fundamentos sólidos pra guiá-la, ela é uma máquina de gerar dívida técnica em velocidade industrial.

Ninguém Vai Perder o Emprego (Mas Muita Gente Vai Tropeçar)

Vou ser direto: ninguém vai perder o emprego por causa da IA. Quem vai perder é quem fechar os olhos pra mudança.

Essa distinção é crucial. A cada revolução tecnológica (da prensa de Gutenberg à revolução industrial, dos mainframes ao cloud computing) o padrão se repete. A tecnologia não elimina profissionais. Ela elimina mentalidades. Quem se adapta, prospera. Quem se agarra ao que conhece e se recusa a evoluir, fica pra trás.

O Stack Overflow 2025 trouxe um dado revelador: 77% dos desenvolvedores dizem que “vibe coding” não faz parte do trabalho profissional. “Vibe coding”, gerar software puramente a partir de prompts sem entender o que está sendo gerado, é percebido pela vasta maioria como insuficiente para trabalho sério.

Se você não é da área: “Vibe coding” é um termo recente que descreve a prática de pedir à IA pra gerar código completo sem realmente entender o que ela produziu. É como pedir a um arquiteto pra projetar sua casa usando apenas emojis… pode até sair algo, mas você moraria nela?

A IA é um amplificador. Ela amplifica tanto a competência quanto a incompetência. Um desenvolvedor com fundamentos sólidos, que entende algoritmos, arquitetura, trade-offs e design de sistemas, usa a IA como uma alavanca que multiplica sua capacidade. Um desenvolvedor sem fundamentos? Gera lixo mais rápido.

O relatório DORA (DevOps Research and Assessment) confirma o padrão: a cada 25% de aumento na adoção de IA pelas equipes, observou-se uma queda de 1,5% na velocidade de entrega e 7,2% na estabilidade dos sistemas. Não porque a IA é ruim, mas porque equipes sem maturidade técnica usam IA como atalho, e atalhos em engenharia de software têm um preço que sempre chega.

O Que Estudar Quando Tudo Muda o Tempo Todo

Se ferramentas mudam a cada seis meses e a IA pode gerar código em qualquer linguagem, o que vale a pena estudar? Essa é a pergunta de milhões. E a resposta é mais simples do que parece: estude o que não muda.

1. Pensamento Computacional

Decomposição de problemas, abstração, reconhecimento de padrões e design de algoritmos. Jeannette Wing, da Columbia University, cunhou o termo “pensamento computacional” em 2006 num artigo seminal na Communications of the ACM. A tese dela era simples e poderosa: pensar como um cientista da computação é uma habilidade universal, tão fundamental quanto ler, escrever e contar. Vinte anos depois, essa tese se tornou profecia.

2. Estruturas de Dados e Algoritmos

A gramática eterna da computação. Não importa se você programa em JavaScript, Rust ou pede pra IA programar em Haskell, por baixo de tudo, existem árvores, grafos, filas, hash maps. Entender essas estruturas não é “decorar”, é entender o vocabulário fundamental de como computadores resolvem problemas.

Donald Knuth dedicou a vida inteira a isso com “The Art of Computer Programming”. O livro está sendo escrito desde 1962 e continua relevante porque algoritmos não têm prazo de validade.

3. Design de Sistemas

Entender trade-offs entre consistência e disponibilidade. Saber quando usar cache e quando cache é veneno. Projetar para escala sem over-engineering. Isso requer uma maturidade que nenhuma certificação de 40 horas consegue dar. Vem com estudo profundo e experiência prática.

4. Matemática Discreta e Lógica

Lógica proposicional, teoria dos grafos, probabilidade, combinatória. Parece acadêmico demais? Todo sistema de recomendação, todo algoritmo de roteamento, toda árvore de decisão que a IA usa internamente se apoia nisso. Entender a matemática por trás é entender os limites e possibilidades da própria IA.

5. Comunicação e Escrita

Um bom prompt é, na essência, um problema bem definido. E definir bem um problema é uma habilidade de comunicação. Desenvolvedores que escrevem bem, que documentam com clareza, que articulam requisitos com precisão, esses são os que extraem o máximo da IA. Porque a IA precisa de clareza, e clareza vem de quem sabe pensar e se expressar.

6. Domínio de Negócio

Nenhuma IA sabe que o seu cliente de e-commerce tem uma regra fiscal específica pra produtos importados que chegam pela zona franca de Manaus. Conhecimento de domínio, entender o problema real que o software resolve, é insubstituível e intransferível. E quanto mais a IA commoditiza o “como fazer”, mais valioso se torna o “o que fazer e por quê”.

Dijkstra tinha outra frase certeira sobre isso:

“It is not the task of the University to offer what society asks for, but to give what society needs.”

Edsger W. Dijkstra (EWD 1305, 2000)

A sociedade pede “ensinem React”. A universidade deveria dar “ensinem a pensar em sistemas”. São coisas muito diferentes.

A Parábola do Construtor e do Operador de Betoneira

Imagine dois pedreiros. O primeiro estudou engenharia civil: entende fundações, resistência de materiais, distribuição de carga. O segundo aprendeu apenas a operar a betoneira. Os dois constroem paredes. Quando a obra usa a mesma betoneira, ambos parecem igualmente competentes.

Agora troque a betoneira por um modelo novo, com controles diferentes.

O engenheiro se adapta em uma hora, porque ele entende os princípios, a máquina é só um detalhe. O operador fica perdido. Precisa de um curso novo, uma certificação nova, um treinamento novo. E quando a próxima betoneira chegar? O mesmo ciclo.

No desenvolvimento de software, a IA é a betoneira mais potente que já existiu. Ela faz o concreto mais rápido, na quantidade que você quiser, no formato que você pedir. Mas ela não sabe onde colocar a fundação. Não sabe calcular a carga. Não sabe que o terreno é instável.

O operador de betoneira vira commodity. O engenheiro se torna indispensável.

E sabe o que é cruel? O aluno que questionava Bhaskara na sala de aula estava sendo treinado pelo professor pra ser engenheiro. Mas ele queria ser operador de betoneira. Queria algo prático, imediato, útil “pra comer e beber”. E é compreensível: a pressão do mercado, o imediatismo, a ansiedade de “preciso aprender o que dá emprego AGORA”.

Mas o mercado de agora não é o mercado de daqui a dois anos. E os fundamentos que o professor ensinava são os mesmos há séculos.

A Tese: Ferramentas São Meios, Não Fins

Se eu pudesse resumir tudo numa frase seria esta: na era da IA, fundamentos deixaram de ser diferenciais e se tornaram pré-requisitos.

Antes da IA, você podia ter uma carreira sólida sendo “o cara do React” ou “a especialista em AWS”. A ferramenta era o diferencial. Agora que a IA nivela a capacidade de usar qualquer ferramenta, o que sobra? O pensamento. A capacidade de entender problemas. A habilidade de fazer as perguntas certas.

Isso não é teoria. É o que estou vivendo no dia a dia. Quando peço ao Claude pra implementar algo complexo, a qualidade do resultado depende diretamente da qualidade da minha especificação. E a qualidade da minha especificação depende de eu entender o problema profundamente, não de eu saber a sintaxe de uma linguagem.

Correr atrás de certificações, empilhar frameworks no currículo, ficar ansioso com cada ferramenta nova que aparece no Hacker News, tudo isso é a versão moderna de decorar a fórmula de Bhaskara sem entender o que ela significa. Você pode até passar na prova. Mas quando o problema real aparecer, vai estar perdido.

Conclusão: O Professor Estava Certo

Volto àquela sala de aula. O professor de óculos, o aluno rindo, a classe inteira achando matemática uma tortura inútil.

O professor não estava ensinando uma fórmula. Estava plantando uma semente de raciocínio que demoraria anos pra germinar. Ele sabia (porque bons professores sempre sabem) que o valor não estava no conteúdo, mas na disciplina de pensar.

Hoje, com uma inteligência artificial que escreve código, gera textos, cria imagens e analisa dados, o que nos resta de genuinamente humano no trabalho de desenvolvimento é exatamente isso: a capacidade de pensar, questionar, decidir e criar com propósito.

A IA não vai tirar seu emprego. Mas ela vai tornar impossível se esconder atrás de ferramentas que você domina no piloto automático. O jogo agora é outro. É mais profundo. E ironicamente, é o jogo que aquele professor tentava nos ensinar.

Invista em fundamentos. Estude o que não muda. Aprenda a pensar antes de aprender a usar.

E da próxima vez que alguém te perguntar qual framework estudar, responda: estude Bhaskara.

Referências e Fontes

METR - Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - arxiv.org/abs/2507.09089
Stack Overflow - Developer Survey 2025 - survey.stackoverflow.co/2025
DORA - State of DevOps Report - dora.dev
Wing, J.M. - Computational Thinking (2006) - Communications of the ACM, Vol. 49, No. 3
Dijkstra, E.W. - On the Cruelty of Really Teaching Computer Science (EWD1036) - cs.utexas.edu/~EWD
Dijkstra, E.W. - EWD 1305: Answers to questions from students of Software Engineering (2000)
Knuth, D. - The Art of Computer Programming - cs.stanford.edu/~knuth/taocp.html
MIT Technology Review - AI coding is now everywhere. But not everyone is convinced. (Dez 2025) - technologyreview.com
METR - Updated Developer Productivity Experiment (Fev 2026) - metr.org