Tem um tipo de medo sobre IA no trabalho de desenvolvimento que costuma ficar abstrato demais: a ideia de que produzir código ficou barato, mas entender o que foi produzido continua caro.
Nos últimos dias, esse medo ganhou uma cena concreta que explodiu no Hacker News. O artigo “AI is removing the middle class of software engineering”, de Florian Herrengt, passou de mil pontos e acumulou centenas de comentários porque transformou a tese em cotidiano de time: um dev abre a semana, encontra PRs enormes com descrição gerada por IA, pergunta por que uma decisão foi tomada e recebe de volta um link de conversa com modelo em vez de uma explicação humana.
A imagem pegou porque muita gente reconheceu o problema na hora. Não é a velha discussão rasa de “IA substitui ou não substitui programador”. É outra coisa: quando a velocidade de implementação sobe mais rápido do que a capacidade do time de revisar, explicar e desfazer decisões ruins, a qualidade deixa de cair aos poucos e começa a despencar de uma vez.
O que realmente bateu forte nessa discussão
O texto-base não trata IA como vilã total. Pelo contrário: o autor deixa claro que usa IA todo dia e não quer voltar ao fluxo de fazer tudo na mão. O ponto dele é mais desconfortável: o gargalo agora não é gerar código; é manter entendimento, julgamento e responsabilidade sobre o que entra no sistema.
No exemplo que abriu o debate, o símbolo não é nem a ferramenta. É o comportamento ao redor dela. O PR gigante deveria ter sido quebrado antes. O reviewer deveria poder recusar uma revisão daquele tamanho. Quem mexeu na feature deveria saber explicar de onde vem o dado, por que a arquitetura foi daquele jeito e qual risco foi aceito no caminho.
Quando isso some, a IA não corrige a cultura. Ela só acelera o estrago.
A parte mais incômoda: o que está ficando barato e o que continua caro
A frase mais forte do artigo talvez seja esta: hoje, implementação está barata; o que vale dinheiro de verdade é decisão boa.
Isso ajuda a explicar a ideia de “classe média” da engenharia de software no título original. Não é uma divisão formal de cargo. É uma provocação sobre o tipo de profissional que antes ainda conseguia se sustentar entregando bastante implementação sem carregar tanto contexto, tanto trade-off e tanta responsabilidade arquitetural.
Quando um agente consegue produzir muito código em pouco tempo, esse espaço aperta. O valor sobe para quem:
- percebe cedo que um PR ficou grande demais;
- sabe cortar escopo e reduzir blast radius;
- entende migração, incidente, rollback e dívida técnica de verdade;
- consegue explicar por que uma abstração entrou — ou por que ela não deveria entrar.
Em outras palavras: o mercado não está premiando só quem produz mais. Está premiando quem segura a linha quando produzir demais começa a piorar o sistema.
Por que tanta gente concordou — e por que parte da comunidade empurrou de volta
A discussão cresceu porque ela misturou identificação com nuance.
Muita gente no Hacker News reforçou a mesma sensação: testes, CI e code review foram desenhados para um mundo em que gerar uma montanha de mudança era caro e relativamente lento. Agora o time consegue abrir muito mais PR, muito mais rápido, com descrições convincentes e uma aparência de avanço que engana fácil quem está olhando só para throughput.
Também apareceu um ponto importante nos comentários: o dano maior nem sempre estoura no dia em que o código entra. Ele aparece depois, quando surge um bug estranho, uma migração mal pensada, uma integração difícil de reverter ou uma base que ninguém mais consegue explicar sem consultar a conversa que levou àquela decisão.
Ao mesmo tempo, não foi uma discussão unânime nem histérica. Houve quem lembrasse que débito técnico sempre existiu, que startup às vezes conscientemente compra velocidade e que bons engenheiros também estão ficando mais fortes com IA. Esse contraponto importa. O debate não é “usar IA = trabalhar mal”. O debate é outro: usar IA sem aumentar o nível de entendimento vira um jeito muito eficiente de empurrar custo para os outros.
O recado prático para carreira é menos dramático do que parece
Talvez a pior leitura desse caso seja pensar que a saída é rejeitar IA ou performar purismo.
O recado mais útil parece ser o oposto: usar IA ficou normal. O diferencial agora é mostrar que ela não terceirizou o seu raciocínio.
Na prática, isso muda o que vale como sinal de maturidade:
- explicar uma decisão sem depender do histórico do chat;
- abrir mudanças menores e mais defensáveis;
- saber mapear impacto antes de mexer em dado, integração ou fluxo crítico;
- registrar trade-off de um jeito que outro humano consiga auditar;
- aparecer bem quando o sistema quebra, não só quando a demo funciona.
Isso vale para sênior, pleno e até júnior. O próprio autor cita que prefere trabalhar com júnior que usa IA para entender melhor do que com sênior que parou de tentar entender o que está entregando.
No fim, o caso que viralizou não diz que “acabou para dev”. Ele diz algo mais útil — e mais duro: quem só acelera entrega sem aumentar compreensão está ficando mais arriscado de manter no time.
E talvez seja justamente por isso que tanta gente se viu nessa discussão tão rápido.
Fontes
- Florian Herrengt — AI is removing the middle class of software engineering: https://blog.florianherrengt.com/ai-removing-middle-class-software-engineering.html
- Hacker News discussion: https://news.ycombinator.com/item?id=49271994
