O futuro da engenharia de software segundo a Anthropic

Os ganhos iniciais de produtividade com assistentes de código baseados em IA começam a ter um custo. A velocidade é inegável. Você consegue gerar centenas de linhas de código padrão ou até um algoritmo complexo em segundos. O problema aparece depois, no pull request. Revisar código gerado por IA parece diferente de revisar o trabalho de um colega. Você não pode perguntar o raciocínio nem discutir trade-offs. Você fica olhando para um bloco de código que está sintaticamente correto e muitas vezes parece lógico, mas cujas suposições são um mistério. A diferença entre a velocidade com que conseguimos gerar código e o tempo que leva para verificá-lo é o principal desafio de adicionar IA ao nosso trabalho, e isso mostra como nossos papéis precisam mudar. A pesquisa da Anthropic sugere um caminho à frente, um futuro de engenharia de software em que o papel principal do engenheiro é direcionar sistemas, não escrever código.

Essa é uma mudança fundamental em onde aplicamos nossa expertise.

A crescente diferença entre geração e verificação

Estamos batendo em um limite com a geração atual de ferramentas de IA. Elas são excelentes em acelerar tarefas que já sabemos fazer. O gargalo não é mais escrever o código; é garantir que o código gerado esteja correto, seja manutenível e seguro para dar merge.

O problema velocidade vs. controle

Um engenheiro júnior envia um pull request com 500 linhas. Você consegue revisar inferindo a intenção, corrigindo a lógica e ensinando padrões melhores. Um pull request de 500 linhas vindo de uma IA é um tudo-ou-nada. Você pode aceitar, rejeitar ou gastar mais tempo editando do que levaria para escrever do zero. A ferramenta te dá velocidade, mas você abre mão de controle e entendimento. Isso leva a um processo em que engenheiros geram código e depois passam uma quantidade equivalente de tempo fazendo engenharia reversa da lógica para escrever testes e confirmar que o comportamento corresponde ao que eles queriam desde o início.

De detalhes de implementação para falhas de especificação

Nosso atual processo de code review foca na implementação. A gente verifica estilo, performance e erros lógicos. Mas quando um bug aparece em um código gerado por IA, a causa raiz geralmente é uma falha no prompt original ou um mal entendimento do modelo, não um erro simples de programação. A conversa precisa acontecer em um nível mais alto. A pergunta deixa de ser “esse `for` está correto?” e passa a ser “meu prompt descreveu todos os edge cases com precisão?”. O foco do desenvolvedor sai de escrever código e passa para escrever uma especificação sem ambiguidades que uma máquina consiga executar.

Gerenciando sistemas complexos gerados

O problema piora quando você sai de funções isoladas e começa a gerar serviços inteiros. Você acaba com uma grande quantidade de código que ninguém no time conhece bem. Quem é o dono disso?

Quando algo quebra em produção às 3 da manhã, quem tem contexto suficiente para debugar rápido? A base de código começa a ficar difícil de entender, e o conhecimento sobre o sistema vai se perdendo com o tempo.

A perspectiva da Anthropic: o engenheiro como arquiteto de sistemas de IA

A visão da Anthropic é que esse desconforto é um sinal de uma fase temporária. Eles propõem um futuro em que engenheiros são arquitetos e validadores de sistemas de desenvolvimento dirigidos por IA, em vez de programadores focados em implementação. O valor deixa de estar na quantidade de código escrito e passa para a forma como definimos problemas e avaliamos soluções.

Uma mudança de valor: de implementação para especificação e validação

A ideia central é que a principal entrega de um engenheiro não será mais código. Será uma combinação de duas coisas:

1. Uma especificação precisa, legível por máquina, do problema. Isso não é um ticket de Jira. É uma definição formal de entradas, saídas, comportamentos e restrições.
2. Um conjunto completo de validação e verificação. Isso inclui testes, checagens baseadas em propriedades e benchmarks de performance que consigam certificar, sem revisão humana, que a solução gerada atende à especificação.

Nesse modelo, o trabalho do agente de IA é encontrar qualquer implementação que satisfaça a especificação e passe nos testes. O trabalho do engenheiro é tornar a especificação e os testes tão sólidos que qualquer implementação aprovada seja, por definição, correta.

Agentes de IA como colaboradores

Isso transforma a IA de uma ferramenta simples (como um compilador) em um colaborador ativo. É um sistema que recebe direção estruturada de alto nível e executa o trabalho repetitivo de implementação. A parte criativa da engenharia, quebrar problemas complexos em partes lógicas e verificáveis, continua sendo profundamente humana. A parte mecânica de traduzir isso em sintaxe fica com a máquina.

O que isso significa para o nosso dia a dia

Se essa ideia estiver certa, várias das nossas práticas vão precisar mudar. A estrutura dos times, a rotina diária e a forma como definimos “pronto” vão ser impactadas.

Code reviews viram revisões de especificação

O processo de pull request tende a mudar. Em vez de revisar 500 linhas de código gerado, o foco passa para a especificação e para os testes que sustentam aquela solução.

A revisão deixa de girar só em torno de legibilidade ou pequenos detalhes de implementação. O ponto principal passa a ser a clareza da especificação, se ela não abre margem para interpretações erradas e se os testes cobrem bem os cenários definidos, incluindo casos mais extremos.

O código gerado pode nem ser o foco principal. Ele vira mais uma evidência de que existe uma solução válida para aquela especificação.

Arquitetura como orquestração de agentes de IA

O design arquitetural também sobe de nível. Em vez de desenhar hierarquias de classes, você desenha sistemas de agentes de IA interagindo. Um diagrama pode mostrar um “agente de autenticação” com uma spec para lidar com JWT e políticas de segurança, um “agente de processamento de dados” com uma spec para um pipeline, e as APIs que definem como eles se conectam. O papel do arquiteto é definir limites e critérios de sucesso de cada parte, e deixar a IA construir e conectar.

Debug começa pela especificação

Quando aparece um bug em produção, o primeiro passo não é anexar um debugger no código gerado. É reproduzir a falha no ambiente de verificação. Se você consegue escrever um teste que demonstra o bug, existem duas possibilidades:

1. A implementação está errada. O agente de IA falhou em gerar código que satisfaz a especificação. A solução é reportar a falha e fazer o agente gerar uma nova versão que passe na suíte de testes mais rigorosa.
2. A especificação está errada. O código implementa corretamente uma spec ambígua ou incompleta. A solução é corrigir a spec, reforçar os testes e regenerar o componente.

Nesse cenário, dívida técnica se desloca para especificações mal definidas e cobertura de testes insuficiente.

Onde essa visão é incompleta ou otimista

Essa ideia é boa, mas na prática as coisas são mais complicadas. O modelo parte de projetos novos, onde dá para escrever boas especificações desde o início.

Como aplicar isso em uma codebase legada, sem documentação e com poucos testes? Criar uma especificação clara para um sistema que ninguém entende direito costuma ser mais difícil do que simplesmente corrigir um bug.

Muitos problemas de software, especialmente em produto, não são matematicamente precisos. Os requisitos são descobertos ao longo do caminho. Você constrói, mostra para usuários e ajusta. Um sistema que exige especificações perfeitas desde o início não se encaixa bem nesse tipo de trabalho exploratório.

E modelos não são compiladores. Eles são não determinísticos. O mesmo prompt pode gerar resultados diferentes. Isso cria uma nova classe de bugs em que algo funciona em um dia e quebra no outro após uma regeneração aparentemente irrelevante. Lidar com isso exige um nível de tooling e disciplina que ainda estamos começando a construir. Essa visão funciona melhor para problemas bem definidos, como algoritmos de ordenação ou parsers de protocolo. É menos convincente para produtos complexos voltados a usuários, onde a “spec” está sempre mudando.

O que fazer se a Anthropic estiver ao menos parcialmente certa

Não precisamos esperar esse futuro chegar para começar a nos adaptar. Se o trabalho mais importante está migrando de implementação para especificação e validação, dá para começar agora.

1. Trate especificações como código. Comece a escrever descrições mais detalhadas e formais do comportamento dos componentes antes de codar. Use formatos mais estruturados do que um README, como TLA+ para pensar sistemas ou até specs bem definidas de OpenAPI para APIs. Revise a spec com a mesma exigência que você revisa código.
2. Invista em verificação automatizada. Vá além de testes unitários simples. Use property-based testing para validar regras em uma grande variedade de inputs. Use mutation testing para encontrar fraquezas na suíte de testes. O objetivo é ter um setup que te dê alta confiança na correção do código, seja ele escrito por humano ou por IA.
3. Pratique instruir a máquina. Saber dizer para um agente de IA o que fazer é uma habilidade diferente de programar. Exige clareza de pensamento, entendimento das limitações do modelo e capacidade de quebrar problemas em prompts que gerem resultados verificáveis. Comece a praticar isso com as ferramentas atuais. Quando usar um assistente, foque menos no código gerado e mais em refinar suas instruções até o resultado ficar consistentemente correto.

O engenheiro do futuro pode escrever menos código, mas vai precisar pensar com mais estrutura do que nunca. O trabalho não está desaparecendo. Ele só está subindo um nível na stack.