Erick Wendell: virar revisor de código de IA expõe crise na formação de devs
Em entrevista a Gabs Ferreira, o instrutor conta como um experimento de 60 horas com IA sozinha revelou o que muda (e o que não muda) na engenharia de software.
Em uma entrevista a Gabs Ferreira, o instrutor e criador de conteúdo Erick Wendell descreveu algo que boa parte de quem programa hoje reconhece na própria rotina: a sensação de ter virado, na prática, um revisor de prompts e de diffs gerados por modelo, em vez de alguém que escreve código do zero. Wendell chama isso de "crise" e situa o momento em novembro, quando começou a se perguntar o que exatamente sobrou do trabalho de engenharia diante da pergunta que resume a inquietação da conversa: se o Claude faz o trabalho que o júnior faria, o que sobra para quem programa?
A entrevista completa está disponível na fonte enviada para esta pauta, mas o miolo da conversa vale mais que o clipe viral: não é sobre "a IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → vai tomar seu emprego", é sobre o que muda na prática de quem já trabalha com isso e no caminho de quem está entrando agora.
A camada de abstração não é nova, só ficou mais alta
O argumento central de Wendell é que a IA generativa não inventou um problema novo, ela empilhou mais uma camada de abstração em cima de discussões que a engenharia já tinha havia décadas. Ele cita como exemplo a pergunta clássica sobre se um júnior deveria aprender a usar framework ou fazer tudo do zero primeiro. "As perguntas são as mesmas desde sempre", diz ele na entrevista, incluindo uma referência a um post recente atribuído a Robert C. Martin (o Uncle Bob) dizendo que ele já nem lê mais código, só a mecânica que passa por ali.
Isso importa porque muda o discurso de pânico moral para um discurso de responsabilidade técnica: se o problema sempre foi "até onde eu preciso entender o que está por baixo antes de confiar na abstração", então o trabalho de quem constrói sistema não desapareceu, ele só migrou de nível. Um dev que usa Rails sem entender SQL↳SQL64 conteúdosSQL Server – Como evitar SQL Injection?Data · mai 2019Azure SQL DB Managed InstanceData · abr 2019SQL Server – Como evitar SQL Injection? Pare de utilizar Query Dinâmica como EXEC(@Query)Data · abr 2019Ver tudo em Data → por baixo já vivia esse dilema antes de qualquer LLM existir. A diferença é a velocidade com que a abstração de hoje entrega código funcional, e é aí que mora o risco real: a abstração via IA erra de um jeito muito mais convincente do que um framework errava.
A faculdade que Wendell descreve já mudou de ordem
Um dos pontos mais concretos da conversa é a comparação que Wendell faz entre a própria formação e a dos irmãos, que cursam Análise e Desenvolvimento de Sistemas agora. Na turma dele, começaram trezentos alunos e sobraram trinta até o fim do curso, porque o primeiro semestre era filtro puro: estrutura de dados e SQL sem contexto nenhum de para que servia aquilo, e quem não aguentava a abstração sem propósito saía. Os irmãos aprendem na ordem inversa: primeiro montam uma aplicação com low-code, modelam banco de dados no clique, veem o app funcionando de ponta a ponta, e só depois voltam para refinar a peça que não funciona bem.
Gabs Ferreira reforça o mesmo ponto pela própria experiência: levou dois anos para entender o que era um sistema de verdade, porque ficava preso fazendo aplicação de linha de comando no terminal sem nunca ver o conjunto. É um argumento pedagógico que vale a pena levar a sério além do clipe: ensinar de trás para frente, começando pelo sistema funcionando e voltando para o porquê da estrutura de dados, é mais parecido com como quem já trabalha resolve problema no dia a dia (primeiro entende o sintoma, depois cava a causa) do que o modelo tradicional de currículo linear.
Se a IA faz o trabalho do júnior, por que contratar um júnior?
Essa é a pergunta que Ferreira coloca direto e que resume a ansiedade de mercado em torno do tema. A resposta de Wendell não é "não vai fazer diferença", é que a definição de júnior muda de forma. Em vez de alguém contratado por saber a sintaxe de uma linguagem, o júnior do futuro descrito por Wendell é quem recebe uma tarefa concreta ("tem um bug, quando clica duas vezes o botão trava a tela, resolve"), escreve o prompt, resolve o problema, e principalmente faz perguntas sobre por que aquele bug existia e como a solução funciona. Isso empurra a curva de aprendizado para cima mais rápido: em vez de gastar meses só entendendo sintaxe, o júnior é jogado direto para perguntas de design de sistema, com uma camada de abstração a mais entre ele e o código bruto.
É um argumento honesto, mas incompleto se parar por aí: o risco que a entrevista não resolve é o que acontece com quem nunca desenvolveu o hábito de fazer essas perguntas, porque a IA já entregou algo que "parece" funcionar. A pressão sobre formação de júnior não é só "aprender mais rápido", é garantir que o júnior continue treinando o músculo de duvidar do próprio código, mesmo quando ele não escreveu uma linha.
Código deixou de ser o mais importante, mas não da forma que parece
Wendell usa um exemplo de sistema financeiro para ilustrar onde o julgamento humano continua insubstituível: se um app demora cinco segundos para carregar, isso pode ser irrelevante para a maioria dos usuários; se um pagamento via Pix demora vinte segundos, é um problema sério. A diferença entre os dois casos não está em nenhuma linha de código específica, está em entender o domínio, as expectativas do usuário e o custo de errar, algo que nenhum modelo hoje infere sozinho sem alguém decidir o que importa.
A comparação que ele faz com aviação ("você confiaria 100% numa pessoa que não entende de mecânica pra comandar aquilo?") é útil, e vale estender o raciocínio: sistemas de automação, de forma geral, reduzem a carga cognitiva do trabalho rotineiro, mas criam um risco específico quando o humano precisa retomar o controle sem ter mantido o modelo mental atualizado do que a automação estava fazendo. É a mesma armadilha que espera quem revisa código de IA sem nunca ter escrito a lógica equivalente: no momento em que algo quebra em produção, falta o modelo mental que só se constrói escrevendo.
O experimento: 30 horas de IA sozinha à noite
A parte mais concreta da entrevista é o experimento que Wendell descreve: um projeto open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) → em que ele impôs a si mesmo a regra de não tocar no código nem revisar nada, só observar como a IA se saía sem intervenção. No total, o projeto acumulou mais de 60 horas de trabalho da IA, das quais 30 horas aconteceram à noite, enquanto ele estava fora (segundo a própria descrição, "eu ia pro bar e ela ficava trabalhando sozinha"). A conclusão inicial que ele tira é que, para começar um projeto do zero, a IA hoje se sai muito bem sozinha.
O ponto em que a entrevista fica mais interessante é justamente onde a transcrição disponível se corta: Wendell começa a explicar que manter o projeto ao longo do tempo é onde "a coisa se torna" um problema diferente, e o relato para aí. Mas o recorte é suficiente para expor a assimetria que qualquer time que já usa agentes de codificação em produção reconhece: começar um projeto é o cenário mais fácil para uma IA generativa, porque não há histórico de decisões acumuladas, não há dívida técnica, não há três sprints de contexto que o modelo precisa reconstruir a cada prompt. Manter é outro jogo: exige lembrar por que uma decisão de arquitetura foi tomada seis meses atrás, entender o efeito colateral de uma mudança em um módulo que ninguém mexe há tempo, e notar quando uma sugestão do modelo é sintaticamente correta mas semanticamente errada para aquele sistema específico.
Por que revisar é mais difícil do que escrever
Aqui a entrevista para antes de fechar o argumento, mas o recorte da pauta pede justamente essa pergunta. Escrever código do zero obriga quem programa a tomar cada decisão de forma sequencial, e isso naturalmente constrói o modelo mental de por que o sistema funciona daquele jeito. Revisar um diff gerado por IA inverte essa ordem: a decisão já foi tomada, e quem revisa precisa reconstruir o raciocínio por trás dela só de olhar o resultado, sem o benefício de ter vivido o processo de tentativa e erro que levou até ali. É mais fácil confiar que algo está certo porque compila e passa nos testes do que verificar de fato se a lógica reflete a intenção original, principalmente sob a pressão de revisar dezenas de sugestões por dia.
Esse é o gargalo real que fica em aberto na conversa entre Wendell e Ferreira: a formação de júnior que prioriza prompt e pergunta sobre o "porquê" resolve parte do problema, mas só funciona se a cultura do time reservar tempo de fato para essa pergunta, em vez de tratar revisão como etapa burocrática entre gerar código e fazer merge. Sem esse espaço, o time não vira só revisor de IA no bom sentido (crítico e exigente), vira revisor no sentido ruim: alguém que carimba aprovação porque o código parece certo.
Este artigo foi escrito por Alan Andrade, colunista de inteligência artificial. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de IA aplicada. Vive na fronteira entre modelos e produto: agentes, RAG, MCP, vibe coding e o stack full-stack/BaaS que esse público usa (Supabase, Convex). Entusiasta cético — testa antes de recomendar e mostra o que quebrou.
