O que continua importando quando o código deixa de ser o diferencial

Em um momento em que boa parte da conversa sobre tecnologia gira em torno de qual Inteligência Artificial escreve código mais rápido, uma entrevista recente chamou atenção por ir para o lado contrário. Gergely Orosz, autor da newsletter The Pragmatic Engineer, conversou com Kent Beck, nome por trás de conceitos que moldaram a engenharia de software como ela é hoje, sobre o que realmente vai definir quem se destaca na profissão daqui para a frente. E a resposta dele não tem nada a ver com qual ferramenta de IA você domina.

Quem é Kent Beck, e por que vale ouvir o que ele pensa

Kent Beck criou a Extreme Programming (XP), foi um dos pioneiros do Test-Driven Development (a prática de escrever o teste antes do código, garantindo que você já sabe exatamente o que precisa validar antes mesmo de começar a programar), cocriou o JUnit (um dos frameworks de teste mais usados no mundo) e é um dos autores do Manifesto Ágil, documento que, até hoje, orienta como times de tecnologia organizam seu trabalho.

Ou seja: quando o assunto é "como construir software de forma sustentável", ele é uma das poucas pessoas que ajudou a escrever as regras que a indústria inteira ainda segue.

Escrever código é só uma parte pequena do trabalho

Um dos pontos centrais que Kent defende é direto: escrever código sempre foi uma parte muito pequena do que significa ser um engenheiro de software. O resto do trabalho, construir confiança com quem depende do seu sistema, se conectar com outras pessoas do time e desenvolver entendimento real sobre o problema que está sendo resolvido, não desaparece só porque uma IA consegue gerar código rapidamente.

Pelo contrário: à medida que gerar código fica mais barato e mais rápido, essas outras habilidades tendem a pesar ainda mais na diferença entre um profissional mediano e um de destaque.

Test-Driven Development não nasceu pra "testar melhor", nasceu pra acalmar a ansiedade

Uma curiosidade que aparece na entrevista ajuda a explicar por que Kent pensa dessa forma. Ele descreve a si mesmo como alguém cronicamente ansioso em relação à programação: quanto mais complexo o código, maior a certeza de que algo vai entrar em conflito.

O TDD (ou melhor, Desenvolvimento Guiado por Testes)  nasceu, na prática, como uma forma de lidar com essa ansiedade. Escrever o teste antes do código dá uma sensação de controle sobre algo que, de outra forma, seria só incerteza.

O maior aprendizado da carreira, segundo o próprio Kent

Um dos trechos mais marcantes da entrevista é quando Kent reflete sobre como sua geração foi ensinada: aprenda a entender o computador por completo, e o sucesso profissional era inegável. Só que, na prática, ele descobriu que a parte que realmente definia o sucesso era outra: a capacidade de se comunicar, de construir relação e de entender outras pessoas.

Habilidades que, segundo ele mesmo admite, não imaginava que precisaria desenvolver. Esse ponto ganha um peso particular agora. Se, durante décadas, "dominar a tecnologia" foi visto como suficiente para ter uma carreira garantida, a facilidade cada vez maior de gerar código com IA está deixando claro que essa nunca foi a habilidade mais rara, só era a mais visível.

Um contraponto direto ao discurso de que "programar vai acabar"

A entrevista ganha ainda mais contexto quando colocada ao lado de outra declaração recente, do CEO da Anthropic, Dario Amodei, que afirmou que a programação vai deixar de existir primeiro, seguida por toda a engenharia de software.

Kent rebate diretamente esse tipo de previsão: para ele, quem acredita nisso geralmente não vivencia o trabalho real de construir e manter sistemas complexos no dia a dia, só vê a geração de código, que é, de fato, a parte mais fácil de automatizar.

Esse é um sem consenso hoje: uma parte da indústria acredita que a IA vai substituir grande parte (ou toda) a engenharia de software; outra, representada por vozes como a de Kent, defende que o valor do profissional sempre esteve em outro lugar, e que esse lugar continua, por enquanto, fora do alcance da automação.

A habilidade que separa quem só gera código de quem gera resultado

Se escrever código nunca foi a parte difícil, o que muda com a IA é onde essa dificuldade se desloca. Especialistas do setor já apontam a engenharia de contexto como uma das tendências centrais de 2026: a capacidade de fornecer à IA exatamente a informação, o objetivo e o cenário certos pra que ela entregue uma solução realmente útil, em vez de uma resposta genérica.

Na prática, isso é uma continuação direta do que Kent descreve. Um bom engenheiro de software sempre precisou entender o problema a fundo antes de propor uma solução, e comunicar esse entendimento com clareza pra quem depende do sistema. Hoje, essa mesma habilidade se aplica também à forma como esse profissional conversa com a IA: quanto mais claro o contexto fornecido, papel, tarefa, objetivo e detalhe técnico, mais próximo o resultado fica do que um especialista sênior entregaria.

O que fica como aprendizado prático

Independente de qual lado desse debate se mostrar mais correto com o tempo, a reflexão de Kent serve como um bom lembrete pra qualquer área que lida com tecnologia, não só para quem programa: ferramentas mudam rápido. Confiança, entendimento de contexto e capacidade de trabalhar bem com outras pessoas, e agora, também com a IA, são construídos devagar, e são exatamente esses fatores que decidem se uma solução técnica realmente resolve um problema de negócio, ou só parece resolver no papel.

Fontes consultadas:

• Gergely Orosz: How Kent Beck shapes the tech industry, The Pragmatic Engineer (newsletter.pragmaticengineer.com)
• ChatGPT Brasil: Framework completo de prompt engineering para todos os modelos de IA em 2026 (chatgptbrasil.com.br)
• Aprender21: Prompt Engineering como carreira no Brasil 2026 (br.aprender21.com)

‍