A IA vai matar a profissão de programador?

Antes de qualquer análise: o medo é legítimo e a informação que você recebeu é ruim.

Se você chegou aqui, é bem provável que uma dessas frases tenha passado pela sua cabeça esta semana:

Se alguma delas é sua, continue lendo. A resposta que eu tenho não é “calma, vai dar tudo certo” — é te mostrar o que de fato aconteceu, porque medo com informação é uma coisa completamente diferente de medo sem.

E informação é justamente o que está faltando. Você está no meio de um barulho absurdo: de um lado, gente vendendo que programador acabou; do outro, gente fingindo que nada mudou. As duas posições são confortáveis para quem fala e inúteis para quem precisa decidir a própria carreira.

Mudou muita coisa. E dá para atravessar — mas só se a gente olhar direito para o que aconteceu.

Comecei em 2009, aos dezesseis anos. De lá para cá, em várias empresas, o papel do júnior sempre foi o mesmo: executor.

O estagiário, por lei, é estudante — está ali para aprender. O júnior é o primeiro cargo formal, e o objetivo dele nunca foi aprender a teoria bruta. Era aprender a aplicar a teoria.

Só que na prática ninguém entregava uma funcionalidade inteira para um júnior. Ele não tinha essa capacidade — e todo mundo sabia. Então ele pegava o que sobrava:

O júnior nunca foi dono de uma entrega. Ele era dono de pedaços dela — pequenos, isolados, supervisionados.

E ele não era avaliado pelo que sabia. Era avaliado pelo que entregava: rápido, funcionando, sem quebrar o que já estava de pé. Ninguém sentava com ele para perguntar por que aquilo estava sendo feito daquele jeito.

A formação acompanhava isso, e acompanhava no mesmo tom: um pouco de HTML e CSS para montar a tela; uma linguagem, o suficiente para escrever a regra; banco de dados, o bastante para buscar e gravar; uns comandos de terminal; um framework, para não reinventar a roda. Tudo no básico, tudo aprendido na hora em que a necessidade aparecia.

E o porquê? O porquê ficava para depois. Por que esta estrutura e não outra. Por que este banco. Por que guardar isso numa memória de acesso rápido. Que risco a gente está correndo aqui. Que diferença isso faz no fim do mês para quem paga a conta. Nada disso era cobrado dele no começo — e quase nunca chegava por estudo. Chegava por cicatriz, anos depois, quando alguma coisa quebrou feio o bastante para ensinar.

A indústria inteira ensinou o como primeiro e deixou o porquê para a experiência ensinar.

Por isso existia o “júnior Java” que só via Java. O “júnior JavaScript” que só via tela. Especialização por tecnologia, não por problema — a ponto de alguém saber coisa avançada de web e travar numa consulta simples de banco quando o negócio perguntava “como está aquele pedido?”.

A IA faz o como. Rápido, barato, a qualquer hora, sem cansar.

E o profissional que foi treinado para ser bom no como — porque era só isso que se esperava dele — se viu sem chão. Não é fragilidade emocional. É leitura correta da realidade.

Mas o golpe não veio de onde você está pensando. Não é que a IA programa melhor que você. É que o vão onde o cargo morava deixou de existir.

Para entender o tamanho disso, olhe o caminho inteiro que uma ideia percorria até virar um sistema de verdade — e o que sobrou dele:

Repare que dos quatro passos só um sumiu — e sumiu inteiro. Colocar um sistema no ar deixou de ser o difícil: hoje isso vem pronto, documentado e praticamente de graça em qualquer nuvem moderna. A ponte que o júnior era deixou de ser necessária para atravessar.

O que continua exigindo alguém que entende é tudo que vem depois que o sistema entra no ar: aguentar movimento de verdade, não deixar informação vazar, custar o que pode custar, e continuar de pé quando o negócio mudar de ideia — que é o que o negócio sempre faz.

Sim. E que bom. Hoje uma pessoa que nunca escreveu uma linha na vida descreve o que quer, a IA escreve, e aquilo aparece funcionando na tela dela.

Eu não tenho nenhuma vontade de defender o contrário. Ser difícil nunca foi qualidade. A barreira que existia não protegia ninguém — atrasava gente boa, cheia de ideia, que passava a vida achando que aquilo não era para ela. Programar deixar de ser clube fechado é uma das melhores coisas que já aconteceram com essa área, e eu ganho com isso tanto quanto você.

Só que essa é metade da pergunta. A metade que decide carreira é a outra:

Qualquer um vai fazer um sistema que continua de pé depois que a primeira versão dá certo?

Que aguenta o dia em que entram dez mil pessoas em vez de dez. Que não deixa vazar o dado do cliente. Que no fim do mês custa o que a empresa pode pagar, e não três vezes isso. Que ainda dá para mudar daqui a dois anos, quando o negócio mudar de ideia — que é o que o negócio sempre faz.

Aí é não. Não para a pessoa de negócio, e também não para o júnior — nem um nem outro sabe fazer essa segunda parte hoje. Os dois delegam ela. Comparar os dois em qualidade de engenharia é pergunta errada.

E a melhor forma de mostrar isso não é discutindo. É contando uma história pequena, que acontece toda semana.

Esse exemplo desenha a linha, e ela é mais nítida do que parece.

Até a primeira versão, a IA é impressionante — e eu digo isso sem nenhuma ressalva. Não tem dado real lá dentro, não tem gente usando, e cada ajuste que você pede não tem compromisso nenhum com o que já está guardado. Não gostou? Joga fora e faz de novo. Nesse território ela é mais rápida e mais caprichada do que qualquer um de nós era há três anos.

Depois que o sistema está rodando, a conversa vira outra. Agora existe dado real lá dentro, e ele precisa continuar inteiro. Quando uma regra muda, o que já estava guardado tem que continuar valendo. Um exemplo de uma linha só: um campo era opcional e passou a ser obrigatório — o que acontece com as duas mil pessoas que já estão na base sem ele? Essa resposta não está no código novo. Está no dado velho, e alguém tem que decidir o que fazer com ele.

E por que a IA não resolve isso sozinha? Não é falta de capacidade — capacidade ela tem. É que, no modo automático, ela não vai gastar um processamento infinito varrendo o seu sistema inteiro atrás de tudo que aquela mudança pode afetar. Ela não lê e guarda o seu projeto todo na cabeça, por maior que seja a quantidade de texto que ela consegue segurar de uma vez. Isso não é defeito de uma marca nem má vontade: é limite de tecnologia e de custo, hoje, em todas elas.

Ela faz um trabalho excelente para quem sabe apontar onde olhar. Para quem não sabe, ela faz exatamente o que foi pedido — que é uma coisa bem diferente.

E que fique claro o que eu não estou dizendo. Não estou dizendo que essa segunda parte é reservada para quem já está dentro. Qualquer pessoa pode aprender — inclusive a Rita, se um dia ela quiser.

O que eu estou dizendo é outra coisa: fazer funcionar e fazer durar sempre foram duas habilidades diferentes. Antes, a primeira era difícil o bastante para ocupar a carreira inteira de alguém, e acabava escondendo a segunda atrás dela. A IA tirou a primeira do caminho. O que apareceu atrás não é um muro: é o trabalho que sempre esteve ali — e que agora dá para começar a aprender bem mais cedo.

É aqui que quase todo mundo erra a análise — dos dois lados. O que mudou foi até onde quem não programa chega sozinho. E o que a pessoa de negócio ganhou foi direção e velocidade — não segurança, não capacidade de crescer, não facilidade de mudar depois.

Então onde entra você? Numa coisa só, e ela é enorme: saber para onde a IA deve ir.

Para explicar isso eu uso uma pergunta que não tem nada a ver com software — e é justamente por isso que ela funciona.

toque na imagem para ampliar

Quase certamente você escolheu o avião. E escolheu sem ser engenheiro aeronáutico — porque entende para que ele serve e em que contexto, não porque sabe projetar turbina.

No terreno técnico a pessoa de negócio não consegue fazer essa escolha. Ela não tem como perceber que a IA pegou um caminho que funciona hoje e desmonta na escala, ou que resolve o caso e vaza dado. Não é falta de inteligência. É falta de repertório.

E tem um segundo tipo de saber em jogo aqui, que vem ainda mais cedo que a escolha. Para explicar esse eu troco de metáfora.

Você vai levantar uma casa. Não sabe calcular viga nem dimensionar fundação — e tudo bem, isso vem depois. Mas tem coisa que precisa estar na sua cabeça antes da primeira pá.

Que o terreno precisa ser estudado antes de qualquer coisa, porque nem todo chão aguenta o que você quer pôr em cima. Que a fundação sustenta tudo o que vem depois dela. Que a estrutura tem que ser calculada por alguém. Que água e esgoto passam por dentro da parede — e que a fiação também — e que os dois se decidem antes de a parede subir.

Você não precisa saber fazer nenhuma dessas coisas. Precisa saber que elas existem, e em que ordem elas entram. Quem não sabe descobre tarde, e descobrir tarde é caro: quebra parede pronta para passar cano, refaz o que já estava de pé, estoura o orçamento e o prazo.

Software funciona igual. Não saber montar uma memória de acesso rápido é um problema pequeno — você aprende, consulta, delega. Não saber que ela existe, e não desconfiar de que aquele ponto do sistema ia precisar de uma, é outra coisa completamente diferente. Ninguém vai te avisar do que você não sabe que está faltando — muito menos a IA, que responde bem à pergunta que você faz e não à que você deveria ter feito.

O como você aprende no caminho. O que precisa existir tem que estar no seu mapa desde o primeiro dia.

Antes: construir primeiro, entender depois. Agora: entender primeiro, construir depois.

A lógica antiga fazia sentido no mundo antigo. Construir era caro, lento e difícil, então quem sabia construir valia ouro — e passava a carreira resolvendo tudo com a única ferramenta que dominava. Se você só sabe fazer navio, todo problema vira travessia de navio.

A ordem inverteu. Não é que a técnica deixou de importar — é que ela deixou de ser a porta de entrada.

Um exemplo pequeno, do tipo que aparece na primeira semana de qualquer projeto. Você precisa guardar informação em algum lugar. A pergunta certa não é “qual banco de dados eu uso”. É “que tipo de informação é essa”.

Se é uma informação que precisa durar, ser consultada de várias formas e se relacionar com outras — o cadastro do cliente, o histórico de pedidos —, isso pede um banco de dados. Se é uma informação que só precisa ser lida muito rápido, muitas vezes, e pode ser jogada fora sem prejuízo nenhum — a cotação do dólar de agora, o carrinho de quem ainda está comprando —, isso pede uma memória de acesso rápido. Se é um arquivo grande, vídeo, documento, foto, isso pede um lugar próprio de guardar arquivo.

Três respostas diferentes para a mesma frase “preciso guardar dados”. E escolher errado aqui não dá erro na hora — o sistema sobe, funciona, e todo mundo comemora. Dá erro daqui a seis meses, com cliente dentro.

Nenhuma dessas três decisões exige que você domine a ferramenta. Exige que você saiba que as três categorias existem, e o que separa uma da outra.

Você não precisa dominar todas as tecnologias. Precisa saber que categorias de solução existem, e qual delas resolve cada problema. Quando o problema aparecer, aí sim você aprofunda a ferramenta.

Imagine uma represa segurando toneladas de água.

toque na imagem para ampliar

Com barragem bem calculada, aquilo vira energia para uma região inteira. Sem barragem — ou com uma barragem mal feita — a mesma água desce de uma vez e leva tudo pela frente: cidade, plantação, bicho, gente.

O problema nunca foi a quantidade de água. É a ausência de engenharia entre ela e o mundo.

Por isso eu não estou nem no time do “a IA vai resolver tudo”, nem no do “a IA vai destruir tudo”. Os dois olham para a água. Eu olho para a barragem.

Todo mundo que usa um agente de codificação virou tech lead de um time que não dorme.

Um exemplo pequeno e concreto: adicionar um campo “limite de crédito” na tela de clientes. Antes, isso passava pelo banco de dados, pelo código que roda no servidor, pela tela, pelos testes, pela revisão de outra pessoa e pela publicação. Cada etapa com as suas poucas horas. No total, uma tarde boa — às vezes dois dias. Para um campo.

Hoje esse mesmo campo sai numa fração disso. E não é um pedido de cada vez: são várias frentes andando ao mesmo tempo, porque nada impede você de pedir mais de uma coisa de uma vez.

O que sobrou para você é justamente o que a IA não faz sozinha: dizer qual é o objetivo, quebrar o trabalho em partes, dar contexto e exemplo, definir o que conta como “pronto”, conferir o que voltou e decidir se aquilo entra. O limite deixou de ser a sua digitação e passou a ser a qualidade da sua direção.

E o peso das coisas mudou junto. Conhecer cada detalhe de um framework específico continua útil, mas vale menos do que valia — é exatamente o tipo de coisa que a IA já cobre bem. Saber desenhar a estrutura do sistema, enxergar o que se ganha e o que se perde em cada escolha e desconfiar do que vai quebrar daqui a seis meses: isso vale muito mais do que valia, porque é o que ela não faz por você.

O erro passa. E a conta é minha — porque agora cada decisão minha orienta trabalho equivalente ao de um time inteiro.

Não importa se você é júnior, pleno, sênior ou arquiteto. Você delega, recebe algo que não escreveu, não domina por completo, não conferiu linha por linha — e responde por aquilo se der errado.

Isso assusta. Mas para de assustar quando você percebe que não é novo. É só novo para nós.

Pense em quem é dono de empresa, em quem é diretor. Essa gente nunca escreveu uma linha do que vende. Fecha contrato de milhões baseado em tecnologia que não sabe construir. Banca o desenvolvimento, vive das consequências das falhas, decide o rumo do barco — tudo isso sem nenhum domínio sobre a execução.

Como eles sobrevivem a isso há décadas? Gestão de risco. Trava, métrica, medição, limite, plano para quando der errado. Eles não controlam a execução; eles controlam a exposição.

E aqui vale uma justiça que quase ninguém faz: quando você olha da cadeira deles, o encantamento com a IA é racional. Eles sempre dependeram de um resultado que não conseguiam prever, vindo de pessoas cujo risco ninguém sabia medir. Aparece uma alternativa que trabalha vinte e quatro horas e responde igual toda vez. Claro que eles se animaram.

A boa notícia é que esse é um problema com décadas de solução acumulada. Você não vai inventar do zero. Vai aprender o que outra gente já resolveu — só que agora aplicado ao seu código.

Desenvolvimento de software é profissão prática. Isso não mudou. O que mudou é o que a prática significa.

Antes, portfólio era prova de domínio de ferramenta: “olha, eu sei React”. Agora é prova de entrega: “olha, isto aqui funciona e resolve um problema real”.

Então o estudo passa a ser assim: pegue um problema de negócio pequeno e entregue ponta a ponta. Depois pegue o mesmo problema e aumente a exigência até a arquitetura ser obrigada a mudar.

toque na imagem para ampliar

Repare que em nenhum degrau você entrega um pedaço. Você sempre entrega algo inteiro — o que cresce é a qualidade e o porte, não o escopo do seu pedacinho.

E aquelas matérias que todo mundo pulou na faculdade porque “não dava para ver na prática”? Elas eram o porquê. Você as ignorava porque não tinha como tangibilizar — e agora a IA tangibiliza:

Eram as matérias que todo mundo empurrava com a barriga, porque não dava para ver aquilo virando nada. Hoje são o que separa quem conduz a IA de quem só pede coisa para ela.

Nada disso exige voltar para a faculdade. Exige parar de pular o porquê.

É a mesma história da trigonometria na escola. Ninguém ignorava por burrice — ignorava porque não conseguia enxergar onde aquilo entraria num mundo que ainda não conhecia. A diferença é que agora dá para ver funcionando no mesmo dia: você pede, a coisa aparece na sua frente, e a pergunta “por que assim?” finalmente tem onde grudar.

Eu domino a técnica, e é dela que eu vivo. Só que não é ela que me diferencia — gente boa de técnica tem de sobra. O que é raro é explicar coisa complexa para quem não tem contexto nenhum.

Eu sou o cara que gosta do detalhe, que quer saber o que acontece atrás dos panos, que fica feliz otimizando. Mas o mundo real é maior que isso — o que a gente constrói é usado por gente, e negócio se faz de conversa humana.

Então eu ensino assim:

Como eu ensino, na prática

Paralelismo, prioridade e concorrência, sem uma linha de código

toque na imagem para ampliar

Uma fila, um caixa. Todo mundo espera. Abre um segundo caixa e a mesma fila é dividida entre os dois: a espera de cada pessoa cai pela metade, e nada no mercado mudou além disso. É a coisa mais óbvia do mundo, e é a primeira ideia.

Agora eu aumento a exigência. Nem todo mundo naquela fila aguenta esperar igual — tem idoso, tem grávida, tem gente com uma bolacha na mão e gente com o carrinho cheio. Se a ordem é a de chegada e ponto, a regra parece justa e o resultado é ruim justamente para quem menos aguenta. Então o mercado escreve outra regra na parede: essas pessoas passam na frente. Não é favor de quem está no caixa. É regra, decidida antes de a fila existir, e todo mundo sabe qual é.

E aí vem a terceira, que é a que ninguém vê chegando. Os dois caixas dividem uma balança só. Quem levou legume precisa passar por ela, e só uma pessoa pesa por vez. Na maior parte do tempo isso não atrapalha nada — cada caixa toca a sua fila sozinho. O problema só aparece quando os dois precisam pesar ao mesmo tempo: um usa, o outro para e espera. A fila que não tinha problema nenhum trava por causa de um aparelho no meio do corredor.

Daí sai a lição inteira, sem jargão: não adianta abrir mais caixas se o gargalo é a balança. Se pouca gente pesa legume, abrir caixa compensa muito. Se todo mundo pesa, você gastou dinheiro em caixa para a fila continuar parada no mesmo lugar.

Agora releia essas três histórias trocando “caixa” por thread, “a regra escrita na parede” por fila de prioridade e “balança” por lock em recurso compartilhado. É o mesmo texto. E você entendeu antes de saber o nome.

Nenhum jargão até o final. Nenhuma linha de código. E quando o nome técnico aparece, ele encaixa numa ideia que você já entendeu — em vez de ser um nome que você decora e esquece.

É esse método que eu uso para tudo. E é ele que eu quero usar para te levar do lugar onde você está até o lugar onde você decide sozinho.

Você não precisa de mais uma enxurrada de curso, roadmap e lista de tecnologia.

É exatamente isso que está te paralisando: informação demais, contexto nenhum, todo mundo gritando ao mesmo tempo. O que falta não é conteúdo — é alguém que tire o ruído e caminhe junto.

É o que eu faço. Não te jogo no mundo com uma lista. Eu te pego pela mão e a gente anda junto, o tempo que for preciso.

Se um dia você não precisar mais de mim, eu fiz o meu trabalho.