Apresentação
Depois que o ChatGPT ficou popular, por volta de 2023, a inteligência artificial virou assunto em todo lugar e entrou em uma fase de muito entusiasmo, o famoso hype. Desde então, apareceram previsões de todo tipo, muitas delas exageradas e bem alarmistas.
O discurso começou assim:
A IA vai dominar o mundo em um mês
Depois virou isso:
A IA vai acabar com todos os empregos na semana que vem
Nesse período, cada novo modelo lançado virava notícia com manchetes do tipo: “A Skynet chegou: a AGI está aqui”.
Hoje já dá para entender melhor que a IA é uma ferramenta. Ela depende muito da habilidade de quem usa, e fatores como ganho real de eficiência importam mais do que apenas o número do modelo. Mesmo assim, nem todo mundo da área de tecnologia parece acompanhar essa mudança na conversa.
Assim como aconteceu quando a internet chegou, a IA ainda está em fase de descoberta. Todo mundo está testando, aprendendo e entendendo melhor o que essa ferramenta pode fazer.
-
Tem gente que escreve o prompt do jeito que vem à cabeça, sem revisar nem corrigir erros, e aceita tudo o que a IA responde como verdade absoluta.
-
Tem gente que usa o chat, no navegador ou no celular, e já entende melhor o que precisa fazer para conseguir boas respostas.
-
Também tem quem goste muito do tema, teste toda novidade que aparece, saiba o que são harness, MCP, engenharia de prompt, agentes e skills, e entre em qualquer masterclass que tenha IA no nome.
E tem eu. Quem sou eu? Sou uma profissional da área, sem apego a um método ou ferramenta específica. Eu conheço, testo e uso o que faz mais sentido para a minha rotina.
A IA é uma realidade sem volta. Não dá para continuar trabalhando sem se atualizar ou fingir que ela não existe. Mas também não faz sentido achar que ela agora manda, “pensa” e faz o seu trabalho por você.
Os dados
Em 2025, a METR conduziu um experimento controlado com pessoas desenvolvedoras experientes, que trabalhavam em repositórios mantidos por elas havia cerca de cinco anos. Antes de começar, elas estimavam que a IA reduziria o tempo das tarefas em 24%.
Ao final, ainda acreditavam em uma redução de 20%. Mas a medição revelou o oposto: as tarefas levaram 19% mais tempo para serem feitas.
Em 2026, a METR voltou ao assunto com um experimento maior: 57 pessoas, 143 repositórios e mais de 800 tarefas. No meio do caminho, ela encontrou um viés de seleção na amostra (ficou difícil recrutar quem topasse trabalhar sem IA, e isso distorce o grupo). O problema ainda não foi resolvido: a própria METR anunciou que está mudando o desenho do estudo e trata os números novos como uma evidência ainda fraca.
Por isso, os resultados vieram separados por grupo. Entre as pessoas recrutadas para o novo experimento, a estimativa foi de 4% de lentidão, com intervalo de confiança entre 15% mais lento e 9% mais rápido. Na prática, um efeito perto de neutro, sem uma tendência clara. Já entre as pessoas do estudo original que continuaram participando, a estimativa ficou em 18% de lentidão.
A leitura mais importante aqui não é “a IA não funciona”. É outra: o resultado não vem pronto dentro da ferramenta. Ele depende de quem conduz o trabalho, do que já estava organizado antes e da forma como o processo está estruturado.
A mesma ferramenta, no mesmo dia, pode acelerar uma pessoa e atrapalhar outra. O relatório DORA de 2025 chega a uma conclusão parecida por outro caminho: a IA não conserta uma organização; ela amplifica o que já existe dentro dela, e isso vale para os times também.
A IA não é uma pessoa ao seu lado, autorizada a assumir o comando. Ela se parece mais com a camada de automação de uma aeronave: trabalha sem cansar, é precisa dentro do que foi projetada para fazer e não enxerga nada além do que você informou. A responsabilidade pelo voo continua sendo sua.
Por falar em aviões, é nesse ponto que a história da aviação ajuda, porque ela já passou por uma transformação muito parecida.
O que a aviação pode ensinar sobre IA
Vamos deixar a IA de lado por um momento e olhar para a aviação. A história dela ajuda a explicar como vejo a fase atual da tecnologia.
Antes do avanço da computação, pilotar um avião comercial era uma atividade complexa e muito manual. Os cockpits antigos tinham muitos mostradores, alavancas e relógios, cada um ligado diretamente a um sensor ou a um sistema mecânico da aeronave.
Nos aviões clássicos de meados do século 20, o piloto não usava computadores para comandar a aeronave. Ele controlava o avião por meio de sistemas físicos conectados diretamente às suas partes.
Cabos e polias
Quando o piloto puxava o manche para subir, cabos de aço atravessavam a fuselagem e moviam fisicamente os estabilizadores na cauda. Era preciso força real nos braços, mais tarde aliviada por atuadores hidráulicos pesados, parecidos com a direção hidráulica de um carro antigo.
Instrumentos movidos por ar, não por código
Velocidade e altitude não dependiam de chips. Vinham do sistema pitot-estático: pequenos tubos levavam o ar externo até os mostradores, e a pressão fazia os ponteiros se moverem. Já os instrumentos de atitude, usados para mostrar se o avião estava nivelado, funcionavam, em boa parte dos aviões, com giroscópios a vácuo.
Uma bomba de sucção mantinha o giro, e ele sustentava a referência de horizonte. Eram sistemas diferentes, nenhum deles era digital.
O papel do engenheiro de voo
Como os pilotos precisavam voar, navegar em condições difíceis e falar com o controle de tráfego aéreo, acompanhar dezenas de sistemas era trabalho demais para apenas duas pessoas. Por isso, havia uma terceira cadeira na cabine de comando: a do engenheiro de voo.
Essa pessoa ficava diante de um grande painel lateral, cheio de interruptores e medidores, acompanhando o funcionamento da aeronave.
Com o avanço dos computadores, especialmente nas décadas de 1980 e 1990, muitas dessas tarefas passaram a ser feitas automaticamente. Sensores eletrônicos começaram a verificar pressão do óleo, combustível e outros sistemas o tempo todo.
Assim, o trabalho do engenheiro de voo foi substituído por software. Surgiu então a ideia de “Dark Cockpit”: se nenhuma luz de alerta está acesa, é porque os sistemas estão funcionando como deveriam.
A revolução da automação (o Glass Cockpit)
Com os microprocessadores, o cockpit ficou mais organizado e mudou bastante. Em vez de dezenas de relógios e mostradores separados, os aviões passaram a usar grandes telas multifuncionais, chamadas de Glass Cockpit.
A computação mudou a forma de voar principalmente em três pontos.
1. Sistemas de Gerenciamento de Voo (FMS)
O avião passou a contar com um sistema que ajuda a calcular a melhor rota, acompanhar o consumo de combustível e prever o horário de chegada. Com isso, muitos cálculos que antes eram feitos manualmente passaram a ser automatizados.
2. Fly-by-Wire
Em muitos aviões, os comandos deixaram de depender de cabos pesados. Quando o piloto move o manche ou joystick, ele envia um sinal elétrico para um computador. Esse computador interpreta o comando e aciona os sistemas do avião de forma controlada.
3. Proteção do Envelope de Voo
Os aviões modernos têm limites de segurança programados. Se o piloto tentar uma manobra que coloque a aeronave em risco, como perder sustentação ou ultrapassar seus limites físicos, os computadores ajudam a impedir que isso aconteça.
Hoje, os pilotos continuam sendo essenciais, mas passaram a atuar como gestores dos sistemas da aeronave. A tecnologia reuniu as informações em telas mais claras e permitiu que o próprio avião monitore muitos de seus sistemas, reduzindo a sobrecarga sobre a tripulação e ajudando a tornar a aviação comercial um dos meios de transporte mais seguros do mundo.
É aqui o ponto onde quero fazer minha analogia (comparação). O piloto não saiu do cockpit: mudou de função dentro dele. Deixou de operar recursos manuais e passou a gerenciar fluxos automatizados, decidindo quando deixar o sistema conduzir e quando assumir. Foi uma transformação de papel, não uma extinção.
Já o engenheiro de voo desapareceu como cargo. Entender exatamente por que isso aconteceu é importante, porque esse critério, e não o hype, ajuda a explicar o que pode mudar na tecnologia (na minha opinião).
O que a automação elimina e o que ela transforma
Ainda falando dos aviões: a cabine deles encolheu aos poucos, e cada etapa teve um motivo. A redução de cinco pessoas para duas não aconteceu de uma só vez.
Nos anos 1950, um voo comercial precisava de:
-
Piloto
-
Copiloto
-
Engenheiro de voo
-
Navegador
-
Radio-operador
Com a evolução das comunicações por voz, o radio-operador deixou de existir como cargo. Depois, sistemas modernos de navegação, como as unidades de navegação inercial, substituíram o navegador.
Mais tarde, a informatização das cabines, com monitoramento automático de motores, combustível e sistemas hidráulicos e elétricos, eliminou a função do engenheiro de voo.
A Flight Safety Foundation resume o resultado: a tecnologia de glass cockpit reduziu a tripulação de três para duas pessoas ao eliminar o segundo oficial, o engenheiro de voo. Também há registro de que, no início dos anos 1980, os Estados Unidos passaram a considerar segura a operação com dois pilotos, graças ao avanço da automação no cockpit e ao grande aumento da confiabilidade dos motores.
O engenheiro de voo não desapareceu por ser júnior, nem por ser caro, nem por não ser inteligente. Desapareceu porque o pacote de tarefas dele tinha quatro propriedades ao mesmo tempo.
As propriedades são:
-
A tarefa do engenheiro de voo é repetitiva? Sim, ela se repete com pequenas variações, voo após voo.
-
O estado pode ser observado por sensor? Existe uma medida objetiva que diz se está certo ou errado: como pressão, temperatura, nível.
-
O critério de sucesso é explícito? Alguém já escreveu qual é o valor aceitável, e não é preciso julgar caso a caso.
-
A tarefa decide algo? Ou ela observa, registra e reporta para quem decide?
O engenheiro de voo respondia sim, sim, sim e “apenas reporta”. Quatro sim nesses critérios indicam uma tarefa que a automação absorve.
O piloto respondia diferente. A tarefa dele não é repetitiva, porque cada aproximação tem vento, peso, tráfego e pista diferentes. O critério não é explícito o tempo todo: existe julgamento sobre arremeter ou continuar. Se os computadores falham, quem pilota deve assumir o avião por inteiro.
A pessoa que entra no avião confia em quem está no comando: confia que, diante de uma situação imprevisível, impossível de mapear ou transformar em algoritmo, haverá alguém com conhecimento técnico para avaliar o cenário, agir e conduzir a aeronave com segurança. Por isso, quem pilota foi promovido a gestor de sistemas.
Aplicando essa ideia na área de tecnologia
Agora vamos aplicar a mesma lógica à área de tecnologia. Em vez de perguntar se pessoas desenvolvedoras (devs), analistas de qualidade (QAs), suporte ou operação vão acabar, a pergunta mais útil é outra: quais partes do trabalho nessas funções são repetitivas, observáveis, têm critério explícito e não exigem decisão?
Quais partes dependem de julgamento, contexto, negociação, responsabilidade técnica e capacidade de assumir risco?
O que permanece essencial e se torna ainda mais importante
Continuam importantes as tarefas em que alguém precisa entender o problema, escolher o caminho e definir o que significa “funcionar bem”. Isso inclui decidir a arquitetura do sistema, organizar o domínio do problema, definir a estratégia de testes, combinar critérios de aceite, avaliar riscos e escolher entre prazo, custo, dívida técnica e segurança.
Também inclui conversar com quem pediu a funcionalidade para entender a necessidade real, porque muitas vezes o que a pessoa escreveu não explica exatamente o que ela queria resolver. Essas tarefas não são fáceis de automatizar porque não existe sempre uma resposta pronta ou um critério simples dizendo o que está certo. Elas exigem decisão.
Por isso, na comparação com a aviação, elas se parecem mais com o trabalho de quem pilota. A tendência é que esse tipo de responsabilidade aumente: com a IA fazendo mais partes repetitivas do trabalho, quem decide passa a decidir sobre mais coisas, em menos tempo.
O que muda
A melhor pergunta não é “essa profissão vai acabar?”. A pergunta mais útil é: quais partes do trabalho vão mudar? Quais tarefas vão perder espaço? E quais tarefas vão ficar mais importantes porque precisam de análise, decisão e responsabilidade?
Pessoa desenvolvedora
Para quem desenvolve software, uma parte do trabalho muda de foco. Em vez de apenas escrever código, a pessoa passa a precisar explicar muito bem o que deve ser construído, revisar o que a IA gerou e confirmar se aquilo realmente resolve o problema.
Tarefas simples e repetitivas, como criar telas ou APIs parecidas com outras já existentes, escrever código padrão, adaptar informações de um formato para outro ou criar testes óbvios, tendem a ser cada vez mais feitas com ajuda da IA.
O que ganha valor é outra parte do trabalho: entender a necessidade de quem pediu a mudança, transformar essa necessidade em uma orientação clara, avaliar se a solução faz sentido e verificar se ela funciona de verdade.
Em outras palavras, o trabalho continua sendo técnico, mas seu valor deixa de se concentrar na escrita do código e passa a se concentrar na capacidade de orientar, revisar e tomar decisões.
Na prática, escrever código, incluindo a sintaxe de métodos, funções e outros elementos, nunca concentrou todo o valor do trabalho em desenvolvimento e engenharia de software. Esses aspectos técnicos ganharam destaque nas comunidades de tecnologia por influenciarem o que realmente importa: A LÓGICA.
A IA direciona a atenção para a LÓGICA, o teste de mesa e a capacidade de criar soluções, reduzindo de vez a importância de “decorar” código como se fossem truques, mantras, receitas enfim. Decorar código não era uma prática correta nem sem IA, agora então isso não vale de nada.
Na área de tecnologia, é comum que pessoas desenvolvedoras defendam linguagens de programação, práticas de desenvolvimento e o próprio código que elas desenvolvem com a mesma paixão dedicada a times de futebol ou crenças religiosas. Para quem paga pela solução de um problema, porém, essas disputas pouco importam.
O essencial é que a solução funcione, seja segura e tenha e custe o mais barato possível. Se escolher o método X ou o método Y não afeta esses três pontos, essa discussão é irrelevante para os clientes.
No passado, pessoas desenvolvedoras costumavam usar a seguinte desculpa:
“Minha versão do código não é igual à sua; preciso atualizar.”
Então surgiram o git e plataformas como GitHub, GitLab e Bitbucket, e essa justificativa deixou de fazer sentido. Com isso, todas as pessoas, até as mais desorganizadas, precisaram se atualizar para trabalhar com Git nas empresas.
O desenvolvimento de software em equipe passou a exigir esse conhecimento, e até quem não gostava teve que aprender a versionar o próprio código. As pessoas desenvolvedoras não se adaptaram apenas por vontade própria; elas se adaptaram porque, do ponto de vista das equipes, das empresas e da gestão, o processo ficou muito melhor.
Saber Git se tornou um requisito para conseguir emprego.
Outra justificativa comum entre pessoas desenvolvedoras era a clássica:
“Na minha máquina funciona.”
Com a chegada do Docker, dos contêineres e da infraestrutura como serviço, essa desculpa também perdeu força. Impulsionadas pela computação em nuvem, as empresas passaram a incluir nos repositórios de seus projetos recursos como Dockerfile, YAML, Makefile e ferramentas semelhantes.
E, mais uma vez, essa adaptação não aconteceu por vontade própria. Para conseguir trabalho, as pessoas desenvolvedoras precisaram aprender ao menos o básico sobre esses recursos. Hoje acontece o mesmo: para usar bem a IA no desenvolvimento de software, é preciso ter conhecimentos sólidos sobre a fundação da computação, sobre LÓGICA.
QA
Para QA, a mudança também é grande. Se o trabalho for apenas pegar um caso de teste já escrito e transformar em um teste automático, essa parte tende a ser feita cada vez mais pela IA. Isso acontece porque é uma tarefa repetitiva, fácil de conferir e com pouco espaço para decisão.
Mas isso não quer dizer que QA perde importância. Na verdade, a parte mais importante de QA fica ainda mais valiosa: pensar como o sistema deve ser testado.
Isso inclui decidir o que precisa ser testado, perceber riscos que outras pessoas não viram, imaginar situações incomuns e mostrar, com evidências, que o sistema realmente faz o que promete. Essa parte exige experiência, atenção e bom julgamento.
Aqui existe um ponto importante. Se a IA consegue gerar código muito rápido, o maior problema deixa de ser produzir código. O maior problema passa a ser confiar no código produzido.
Alguém precisa testar, questionar, encontrar falhas e dizer se aquilo pode ir para produção com segurança. Esse é um tipo de trabalho que QA já conhece bem.
O que pode deixar de existir como cargo separado
Os cargos com mais risco são aqueles em que a maior parte do trabalho é feita de tarefas como estas:
-
Repetir testes manuais sempre do mesmo jeito, sem analisar o resultado com profundidade.
-
Transformar um caso de teste já escrito em automação, sem precisar decidir o que deve ser testado.
-
Pegar um requisito e apenas transformar em código padrão, sem discutir se a solução faz sentido.
-
Ficar olhando painéis para avisar sobre problemas que um alerta automático já consegue identificar melhor.
-
Criar documentação a partir de informações que já existem, sem revisar, organizar ou melhorar o conteúdo.
Se a maior parte do seu dia é ocupada por tarefas desse tipo, vale prestar atenção. Isso não quer dizer que sua carreira acabou. Quer dizer que você precisa se mover para atividades que exigem mais análise, decisão e responsabilidade.
O caminho é parecido com o do engenheiro de voo: você já conhece o sistema por dentro. Agora precisa usar esse conhecimento para interpretar problemas, tomar decisões e orientar melhor o uso da automação.
O que os dados mostram até agora
Ninguém sabe exatamente a velocidade dessa mudança. Mas já existem alguns dados úteis para entender o movimento.
O Anthropic Economic Index analisa como as pessoas estão usando IA na prática. Segundo esse levantamento, a maior parte do uso ainda acontece como colaboração entre pessoa e ferramenta. Em 52% das conversas, a pessoa usa a IA para iterar, ajustar e aprender.
Em 45%, o uso se parece mais com automação, ou seja, a pessoa tenta delegar a tarefa quase por completo. Isso mostra que, no geral, a IA é usada como apoio ao trabalho humano e não como substituta.
Uma pesquisa da própria Anthropic, publicada em março de 2026 com os dados desse levantamento, também observou um sinal importante no mercado de trabalho. Ela não encontrou uma prova clara de desemprego causado pela IA nas ocupações mais expostas.
Mas, a pesquisa encontrou uma queda de cerca de 14% na taxa de contratação de pessoas entre 22 e 25 anos para esses cargos, quando comparado ao que seria esperado sem esse efeito. Os próprios autores avisam que esse número está no limite da significância estatística, ou seja, é um sinal fraco, que ainda precisa se confirmar.
A leitura disso precisa ser cuidadosa. Não é correto resumir como “a IA está demitindo todo mundo”. O sinal é mais específico: pode estar ficando mais difícil entrar na profissão.
Muitas tarefas simples, que antes serviam para treinar pessoas iniciantes, são justamente as tarefas que a automação consegue assumir. Se esse primeiro degrau fica menor, a área precisa criar novas maneiras de formar profissionais.
Os riscos
A aviação não descobriu apenas os benefícios da automação. Ela também descobriu os riscos. Em 1983, a pesquisadora Lisanne Bainbridge escreveu um artigo sobre um problema que depois ficou muito conhecido: quando a automação faz quase tudo, a pessoa deixa de praticar algumas habilidades no dia a dia.
Só que, quando acontece uma falha, essa mesma pessoa precisa agir rápido e bem. Por isso, automação não elimina a necessidade de treinamento. Na verdade, é o contrário ela aumenta essa necessidade.
A automação tira as partes mais fáceis e repetitivas do trabalho, mas deixa para a pessoa justamente as situações difíceis, incomuns e críticas. Então o trabalho não fica necessariamente mais fácil.
O trabalho muda: em vez de lidar com o rotineiro, a pessoa passa a lidar mais com exceções e particularidades de negócio. E, justamente lidando com exceções e particularidades é que o domínio técnico se faz mais necessário.
Na aviação, existe até uma expressão para isso: “children of the magenta”. Ela se refere a pilotos que sabem seguir muito bem a rota mostrada pelo computador de voo, geralmente desenhada em uma linha magenta na tela, mas perdem prática no voo manual. Programar a rota é uma coisa. Saber voar bem quando a rota não está disponível é outra.
Em tecnologia, o paralelo é esse:
-
Aprovar um código que você não conseguiria explicar.
-
Aceitar uma sugestão da IA que você não saberia corrigir se desse problema.
-
Perder o hábito de ler mensagens de erro porque a IA sempre interpreta por você.
-
Deixar de entender como o sistema funciona porque a resposta chega pronta antes de você raciocinar sobre ela.
Isso não significa que você deve evitar IA. Significa que deve usar IA com intenção. Na aviação, pilotos treinam em simuladores situações em que a automação falha.
Eles fazem isso para não perder a prática de controlar a aeronave e diagnosticar problemas quando algo sai do esperado.
Em tecnologia, dá para fazer algo parecido:
-
Reserve problemas para resolver sem ajuda da IA.
-
Leia código sem pedir resumo.
-
Investigue um erro antes de colar a mensagem no chat.
Não é por orgulho nem por resistência à tecnologia. É para manter sua habilidade ativa. Você vai precisar dela justamente no dia em que a resposta da IA parecer convincente, mas estiver errada.
O que é dívida cognitiva
O que estou chamando de “dívida cognitiva” aqui? Simples, é quando a gente começa a depender demais de ferramentas, como a Inteligência Artificial, para pensar, analisar e decidir por nós. É o risco de perder a capacidade de pensar só, porque você se acostumou a deixar uma ferramenta pensar por você.
Quando a pessoa passa a deixar sempre o esforço mental para uma ferramenta ela perde o costume de pensar por conta própria. É como usar calculadora para qualquer conta: ela ajuda, faz ganhar tempo, mas, se você nunca mais resolver nenhuma conta sem esse suporte, com certeza sua habilidade vai enfraquecer pouco a pouco.
A dívida cognitiva na computação não é um problema novo. O que mudou foi a velocidade com que ela pode crescer e a quantidade de problemas que podemos criar ao usar ferramentas poderosas sem o conhecimento técnico que é necessário.
Vou explicar com mais detalhes.
Tudo começa na escola
A nossa dívida cognitiva começa antes do que parece: na escola, quando criamos nossos hábitos de estudo, ou a falta deles. Vou simplificar.
Desde cedo, muita gente aprende a estudar só para passar em uma prova com data marcada, conteúdo definido e um esquema feito para garantir a nota mínima e evitar a reprovação.
Aprendemos o processo:
- Aula.
- Revisão.
- Prova.
Sabendo como funciona, e com aviso prévio das datas, o que muita gente faz? Cola, pesca, chama como quiser. Tem gente que gasta mais energia preparando a cola do que gastaria se tivesse criado o hábito de estudar.
O hábito não ficou na escola
Aí você pensa que esse hábito ficou lá na escola. Não ficou. Ele foi internalizado. Na faculdade, aparecia como Ctrl + C e Ctrl + V do Google, como trabalho pago para outra pessoa fazer ou como qualquer jeito de entregar sem raciocinar sobre o assunto.
A pessoa terceiriza o pensamento e mira só na nota. A nota deixa de ser consequência do aprendizado e vira o objetivo principal. E aí o desenvolvimento do raciocínio, o aprendizado, que deveria ser o verdadeiro propósito, “vai para o espaço” para não dizer outra coisa.
E no trabalho, isso muda?
A resposta é: NÃO. Por isso que tanta gente “defende com unhas e dentes” o código que escreveu e decora o primeiro jeito que aprendeu para resolver uma tarefa.
O medo aparece só de pensar em mudar uma parte da lógica do código. Se um ponto e vírgula sai do lugar, a pessoa já não sabe mais explicar o que acontece, não sabe dizer o que mudou.
Antes da IA já era assim
Antes da Inteligência Artificial, quantas pessoas já copiavam e colavam linhas inteiras de código, ou até arquivos completos, do Stack Overflow, de repositórios do GitHub e de qualquer lugar da internet, sem entender direito o que aquilo fazia?
A pessoa pesquisava algo no Google parecido com:
“como criar endpoint com validação em Java para receber dados de cliente”.
Daí ela testava os resultados no projeto e, se funcionasse, deixaria lá para sempre.
Licença de código? Biblioteca maliciosa? Risco de comprometer a empresa ao colocar na base algo encontrado na internet? Tudo isso era tratado como se nem existisse.
Isso já era terceirização do raciocínio e já criava dívida cognitiva. A diferença é que essa dívida crescia mais devagar. O cérebro também se acostumava mais devagar a não pensar.
O que muda com a IA
A inteligência artificial amplia a dívida cognitiva em outro nível. Agora, a pessoa nem precisa mais copiar e colar: basta pedir para a IA gerar o arquivo inteiro e aceitar a resposta sem ler.
Antes, muita gente ainda pesquisava no Google, abria uma resposta no Stack Overflow, olhava algum trecho rápido de código e copiava para o projeto. Hoje, tem gente que pega o texto da demanda, joga direto na inteligência artificial e envia para o repositório tudo o que ela devolver.
Se os testes passam, o código compila e o Github Actions não reclama, a pessoa assume que funcionou, mesmo sem ter lido uma linha.
Antes, ainda havia quem pagasse para alguém fazer as listas de programação da faculdade e depois revisasse o material, pelo menos para se preparar caso o professor fizesse alguma pergunta. Hoje, a pessoa pede para a inteligência artificial resolver a lista. Se o professor pergunta algo, ela também joga a pergunta na IA.
Quando as consequências da dívida aparecem
Enquanto tudo funciona, a dívida cognitiva quase não aparece. O código compila, os testes passam, a tarefa vai para concluído e parece que está tudo certo.
Sabe quando você finalmente percebe que a situação saiu do controle? Normalmente é numa sexta-feira à noite, com uma “bela surpresa” em produção. Algo quebra, claro, no horário mais inconveniente possível, e alguém precisa entender o que aconteceu.
O problema é que, muitas vezes, essa pessoa é justamente quem colocou o código ali sem ter entendido de verdade. Ela sabe que a IA gerou, sabe que os testes passaram, mas não sabe o que cada trecho faz, por que aquela decisão foi tomada pela IA ou o que pode ser alterado sem quebrar o restante do sistema.
Dizer que os testes passavam não ajuda em nada nesse caso, se a IA escreveu o código e escreveu os testes, claro que eles vão ser feitos para passar, ainda mais que a pessoa desenvolvedora não estabeleceu regras, resultados esperados e muito menos barreiras de segurança.
Também podem acontecer problemas com licenças de código. Imagine só, um trecho copiado de um repositório, de um fórum ou gerado por uma IA pode ter vindo de um projeto com obrigações que a empresa nunca previu. Se a pessoa colou o código e não sabe a origem, ninguém consegue conferir direito então o que parecia só uma função rápida pode virar uma questão jurídica.
Os problemas também podem vir pelas dependências do projeto. Antes, as bibliotecas vinham de um tutorial qualquer, agora, a IA sugere e ainda entrega a linha pronta dentro do pom.xml ou em algo parecido.
A pessoa checou se a biblioteca está atualizada? Viu se há falhas de segurança, recursos escondidos para capturar dados ou custos de licença para uso comercial? Claro que não.
Quem adiciona dependências sem verificar quem as mantém, quando foram atualizadas, qual é a licença e o que fazem está abrindo um buraco de segurança na base de código da empresa. Não é apenas uma linha em um arquivo, é uma decisão técnica entrando no sistema.
E, quando falo em segurança, não me refiro só a invasões: também entram nessa conta riscos jurídicos e danos à imagem da marca.
Isso aparece de novo na manutenção, nas revisões manuais de código e no post-mortem de algum incidente. Também aparece na entrevista técnica, quando alguém precisa explicar uma decisão. A IA não vai estar na reunião para justificar o problema, quem fez o commit vai.
Usar IA não significa fugir da responsabilidade. A IA não tem CPF, não responde processo, não perde o emprego e não assume culpa quando alguém trata qualquer resposta dela como verdade absoluta.
Como usar IA sem contrair a dívida
Nada disso significa que a IA deva ser abandonada, ela é útil. Ignorá-la seria cair no outro extremo. O problema não está em usar a ferramenta, o problema começa quando a pessoa entrega a ela a parte que deveria continuar sendo sua: o raciocínio.
- Entenda o problema
Antes de pedir a IA para resolver, entenda o problema. Pense nas classes envolvidas, no fluxo da solução e nos erros que podem acontecer.
Faça um esboço do fluxo, o famoso teste de mesa, pode ser no papel, em pseudocódigo ou em uma lista mesmo.
-
As minhas entradas são: “A”, “B”, “C”.
-
Os meus resultados esperados são: “1”, “2”, “3”.
-
Para isso acontecer preciso de: “Condição 1”, “Condição 2” E “Condição 3”, OU “Condição 4”.
-
Se “condição X” falhar pode acontecer: isso, isso e aquilo.
-
Os erros que podem acontecer são: “erro 1”, “erro 2”… “erro N”.
E assim por diante. O importante é não entregar a demanda inteira para a IA esperando uma solução pronta, dividir o problema já é parte do ato de programar.
- Leia as respostas da IA
Depois, quando a resposta da IA vier, leia tudo. Linha por linha. Como se fosse o código de outra pessoa entrando no seu projeto.
Faça perguntas a si mesmo:
-
O que isso faz?
-
Por que foi escrito assim?
-
O que acontece se a entrada vier nula, vazia ou grande demais?
-
Será que dá para otimizar?
Se alguma parte não fizer sentido, pare. Pergunte, pesquise ou vá para a documentação.
commitsó o que você consegue explicar
Explique o código em voz alta, como explicaria para outras pessoas em uma revisão de código ou pareando para programar no Google Meet, Teams, Slack e por aí vai. Se você “travar” em algum trecho, ainda não está pronto.
O código pode até compilar, os testes podem passar. Mas, se você não entende o código pelo qual está se responsabilizando, no qual está “assinando embaixo”, a dívida cognitiva já começou.
- Desconfie do que a IA diz e sempre se questione
Confira sempre tudo o que a IA afirma:
-
O método existe mesmo?
-
A API funciona daquele jeito?
-
A dependência existe?
-
Quem mantém?
-
Quando foi atualizada?
-
Qual é a licença?
-
Tem vulnerabilidade conhecida?
A resposta da IA não deve ser tratada como verdade absoluta, deve ser tratada como hipótese. A IA “mente” e “se engana” com uma convicção absurda, como se fosse até “errado” duvidar dela.
Ela não se retrata, no máximo um:
“Você está certo, eu não deveria ter entendido isso, deveria ter entendido aquilo.”
O que não quer dizer que a próxima resposta dela estará 100% correta. Por isso, questionar, dominar o contexto e conduzir a execução é fundamental.
Digo isso porque a IA algumas vezes é igual pombo: faz cocô na sua cabeça e ainda sai de peito estufado.
- Mude a posição da IA
Use a IA para discutir, não apenas para entregar, peça alternativas, peça para apontar os pontos fracos do seu código, peça para ela questionar a sua solução. Coloque a ferramenta no papel de revisora, não apenas no papel de quem escreve por você.
- De vez em quando, faça no manual
É sempre bom reservar algumas tarefas durante a semana para fazer manualmente. Como:
-
Resolver uma função sem ajuda.
-
Investigar um bug sem perguntar primeiro.
-
Estudar um assunto novo antes de pedir um resumo.
-
Ler, ler por conta própria
Habilidades que não são usadas enfraquecem. O raciocínio também.
No exemplo da aviação: hoje, a rotina de quem pilota é quase toda dedicada ao gerenciamento de sistemas automáticos.
Por isso, os treinamentos em simulador se tornam ainda mais importantes. As habilidades precisam ser preservadas; quando não são praticadas no dia a dia, é necessário criar espaços intencionais para exercitá-las. Assim, elas não se perdem justamente quando são mais necessárias.
Na programação, acredito que aconteça algo parecido, se no dia a dia, passamos cada vez mais tempo gerenciando sistemas automáticos, precisamos criar, de forma intencional, espaços para treinar e manter nossas habilidades. Caso contrário, elas podem falhar justamente em uma sexta-feira à noite, com um bug em produção e a empresa perdendo muito dinheiro a cada minuto de sistema fora do ar.
Para criar esses momentos de “treinamento em modo manual”, primeiro precisamos lembrar o que esse “manual” significa. Antes da IA as pessoas já usavam trechos de código, Google e Frameworks como “receitas prontas” que funcionam para tudo, então a pergunta que eu faço é: mesmo antes da IA, quando supostamente as pessoas programavam no “manual”, elas realmente sabiam o que significava PROGRAMAR?
Para responder a essa pergunta, vale voltar no tempo e retirar dos computadores algo que hoje parece indispensável: a TELA. Vou falar de uma época em que programar era muito mais manual do que costumamos imaginar.
Cartões perfurados: quando não dava para programar sem pensar
Hoje, estamos acostumados a usar computadores através de telas. Digitamos no teclado e o resultado aparece na tela, ou tocamos diretamente em uma tela sensível, que recebe nossos comandos e mostra a resposta quase na mesma hora.
Mas houve uma época em que computadores eram usados sem telas. Isso pode parecer absurdo até para pessoas desenvolvedoras, mas, por mais “surpreendente” que seja, a tela NÃO é essencial para um computador. O que realmente importa é a LÓGICA.
As telas surgiram para facilitar a interação com os computadores e, com o tempo, ganharam o protagonismo. Ainda assim, para quem desenvolve software, a LÓGICA computacional deve vir primeiro, junto com a capacidade de resolver problemas e construir soluções.
Telas e recursos visuais podem ser essenciais para usuários finais, mas não devem ser o centro da formação de uma pessoa que se considera desenvolvedora de software. Muito antes das telas, da interface gráfica e de qualquer ícone colorido as pessoas já programavam e como elas conseguiam? Tem gente que atua na área que acha que isso nem é possível.
Programação sem telas
Por quase nove décadas, do censo americano de 1890 até a popularização dos terminais de vídeo no fim dos anos 1970, dados foram processados e programas foram criados sem o uso de telas. A entrada acontecia por furos em papel, e a saída vinha impressa.
Nesse contexto, o programa só funcionava quando a lógica estava correta, pois não tinha nenhuma interface visual para esconder erros.
Essa história mostra uma coisa importante: programar nunca foi sobre telas bonitas. Programar sempre foi sobre resolver problemas através de sequências lógicas de instruções.
Um erro no cartão perfurado podia obrigar a pessoa a refazer parte do trabalho e esperar outra execução por horas. No teletipo, a resposta vinha em papel, devagar, linha por linha.
Não tinha interface para facilitar, enfeitar ou esconder. Ou a lógica estava certa, ou o programa não funcionava.
Da IDE à IA: quando a ferramenta pensa por você
Antes da IA já existiam IDEs cheias de recursos, autocompletar, frameworks, bibliotecas prontas e ferramentas que organizam quase tudo. Com isso, já existiam várias e várias pessoas que só conseguiam “programar” porque a ferramenta sugeria, completava ou corrigia por elas.
Isso aí era programar? A pessoa estava raciocinando sobre o sistema ou estava apenas seguindo o ambiente mais o que conseguia “catar” na internet? Para esse tipo de “pessoa desenvolvedora”, se compilou sem erros e executou então está tudo certo.
Já na era da Inteligência Artificial (IA) essa pessoa nem abre mais o código, pois a IA consegue escrever, sugerir soluções e explicar. Só que, ela também pode errar, pode inventar coisa que não existe ou entregar uma resposta que parece correta, mas só parece mesmo.
Sem lógica, a pessoa aceita, com lógica, ela questiona, testa, ajusta e entende. Então a IA não elimina a necessidade de pensar e saber lógica de programação; ela joga essa necessidade na cara de quem queria fugir. Antes, era preciso minimamente fazer o programa compilar, agora você pode subir para o repositório do projeto código que compila, derruba produção e você quem responde por ele, mas não conhece uma linha dele.
Por isso a lição dos cartões perfurados ainda vale hoje, a tela mudou, as ferramentas melhoraram e agora a IA entrou no jogo, mas o centro da programação continua o mesmo: LÓGICA. Se você é uma pessoa desenvolvedora, seu papel é entender o problema, organizar o pensamento e construir uma solução lógica.
Quem domina a lógica usa a IA como ela deve ser usada, como uma ferramenta para reduzir tarefas repetitivas e manuais, liberando tempo para focar no que realmente importa: a lógica e as regras de negócio. Quem não domina a lógica acaba sendo conduzido pela IA, passa a enxergar qualquer solução como mágica e perde autonomia para agir sem ela.
Resumo
A automação tende a assumir tarefas repetitivas, fáceis de conferir e com pouca decisão. Ela muda o papel de quem trabalhava com tecnologia: menos execução mecânica, mais orientação, revisão e verificação.
Ela traz um risco importante: se você parar de praticar certas habilidades, pode perdê-las justamente quando mais precisar delas.
Quem entende isso sabe onde investir tempo: aprender a analisar melhor, decidir melhor, testar melhor e explicar melhor. Quem não entende pode acabar gastando energia apenas em decorar prompts, como se isso fosse suficiente.
Olhando para trás, o padrão se repete, na era dos frameworks, muita gente decorava etapas sem entender o que acontecia por trás. Com o Git, memorizava comandos sem compreender commit, branch ou merge. Com o Docker, copiava Dockerfiles da internet sem saber a função de cada linha.
Em toda onda de inovação, sempre há quem tente fugir do que realmente importa: A LÓGICA. A IA é a versão mais forte e sedutora desse comportamento.
As ferramentas não são o problema, o problema é esquecer como as ações são feitas. Use a IA, os frameworks, o Git, o Docker e qualquer ferramenta que surgir depois.
Só não desista de entender o raciocínio por trás porque as ferramentas mudam, a lógica não, ela continua com a gente.
Referências
Experimento da METR (2025)
Atualização do Experimento da METR (2026)
Relatório DORA (2025)
Dados de uso e mercado de trabalho (Anthropic)
-
Anthropic Economic Index, relatório de janeiro de 2026 (a origem dos 52% e 45%)(abre em nova janela)
Aviação e automação