---
title: "Engenharia de Software 2.0: Como os novos benchmarks do arXiv escancaram a morte do dev digitador"
author: "Ricardo Pupo Larguesa"
date: "2026-04-23 08:00:00-03"
category: "Opinião"
url: "http://aintuicao.scale.press/portal/aintuicao/post/2026/04/23/engenharia-de-software-20-como-os-novos-benchmarks-do-arxiv-escancaram-a-morte-do-dev-digitador/md"
---

Hoje um aluno me fez a pergunta que eu estava esperando o semestre todo. Ele levantou a mão no meio da explicação de Orientação a Objetos e soltou: "Professor, se o modelo já cospe a estrutura inteira da aplicação e configura o banco, por que eu ainda preciso decorar a sintaxe de herança em Java?".

Ele não está errado de questionar. Passei o final de semana dissecando uma leva de papers submetidos ao arXiv no final de abril, e a conclusão é incômoda para quem ainda ensina ou desenvolve software como se estivéssemos em 2018. O benchmark tradicional de código perdeu completamente o sentido na prática.

O estudo *[Beyond Rating](https://arxiv.org/abs/2604.19502)* (Li et al., arXiv:2604.19502), por exemplo, propõe uma nova estrutura de avaliação para revisões feitas por IA. A sacada deles é simples e demolidora: não dá mais para avaliar o modelo pela nota isolada ou pelo acerto de um trecho de texto. O paper foca em medir a coerência argumentativa, o alinhamento lógico e a construtividade. Trazendo isso para a nossa realidade de desenvolvimento de software, a mensagem é que nós paramos de medir se a IA sabe escrever um loop de repetição. Nós precisamos medir se ela entende a arquitetura do projeto.

Outro trabalho da mesma leva, o *[Malicious ML Model Detection by Learning Dynamic Behaviors](https://arxiv.org/abs/2604.19438)* (Nambiar et al., arXiv:2604.19438), vai direto na jugular desse problema. Eles propõem detectar modelos maliciosos não pela análise estática do código, mas pelo comportamento dinâmico em um sandbox, rastreando as chamadas de sistema. Ou seja, a avaliação da IA mudou do "o que ela escreve" para o "o que ela faz com o sistema inteiro". A IA deixou de ser um autocompletar glorificado. Ela virou um componente ativo e perigoso da arquitetura.

Na rotina de desenvolvimento, programadores humanos e agentes de IA dividem as tarefas. Na [T2S](https://t2s.com.br), já perdi a conta de quantas vezes a IA propôs abstrações estruturais que superavam a própria documentação oficial da linguagem ou do framework que estávamos usando. O modelo consegue correlacionar padrões arquiteturais que um desenvolvedor júnior demoraria três anos batendo cabeça para enxergar.

Mas isso nos leva a um problema grave de dependência. Se a IA resolve a arquitetura complexa, quem audita a IA? Já alertei antes sobre [o perigo de criar programadores frágeis](https://scale.press/portal/aintuicao/post/2026/02/25/o-perigo-da-divida-epistemica-por-que-o-copilot-esta-criando-programadores-frageis) que terceirizam a lógica para o Copilot. Se você não entende a sintaxe básica ou os princípios fundamentais, você simplesmente não tem ferramenta mental para julgar se a solução sistêmica proposta pelo LLM é genial ou apenas uma alucinação muito bem articulada e confiante.

É exatamente por isso que a disciplina de interagir com modelos mudou de patamar. Quando escrevi a primeira versão do livro [Engenharia de Prompt para Devs](https://www.casadocodigo.com.br/products/livro-engenharia-de-prompt), o maior desafio era fazer o modelo devolver a função exata sem inventar bibliotecas. Na segunda revisão, o alvo não é o código isolado, mas o sistema completo. Você não prompita mais pedindo um endpoint genérico. Você precisa estabelecer regras de negócio, limites de concorrência e dependências estruturais na mesma instrução.

Isso desmonta a ilusão corporativa de que basta jogar um monte de agentes no repositório do GitHub e esperar o SaaS nascer pronto. A [eficiência real da orquestração de agentes](https://scale.press/portal/aintuicao/post/2026/03/19/multi-agentes-na-engenharia-de-software-eficiencia-real-ou-apenas-mais-ruido) só aparece quando o arquiteto de software sabe exatamente quais limites impor a cada um deles. Sem supervisão humana forte, o código gerado por IA escala o caos técnico em uma velocidade assustadora.

O desenvolvimento de software não morreu. O que morreu foi a vaga do tradutor de requisitos mastigados para código-fonte. O papel do engenheiro virou outro. Ele é o auditor lógico de um sistema preditivo que programa mais rápido que ele.

Respondendo a perguntta inicial: não, você não precisa decorar a sintaxe de herança em Java para digitar o código no editor. Você precisa dominar o conceito para saber o que fazer quando o modelo usar herança, mas o problema pedia composição. Se você terceiriza o código sem entender a arquitetura por trás, você não está programando. Você está só rodando uma roleta russa no servidor de produção.

Quer continuar essa discussão e acompanhar os bastidores das ferramentas que testo no dia a dia? Conecte-se comigo nas redes: [https://linktr.ee/ricardo.pupo](https://linktr.ee/ricardo.pupo).