A IA e o fim do boilerplate, e o que ocupa o espaço

Sou autodidata, e boa parte do meu aprendizado inicial foi digitar boilerplate. Controllers, DTOs, migrations, a mesma validação de formulário pela quadragésima vez. Esse trabalho me ensinou padrões por repetição, e também consumiu anos. Hoje um modelo escreve esse código em segundos, geralmente certo. Não sinto falta. Mas presto atenção no que ocupa o espaço que ele deixou, porque o espaço não está vazio, e quem assume que está é quem se surpreende.

O que de fato ficou barato

O custo que desabou foi o de produzir código plausível a partir de uma descrição clara. Scaffolding, cola, adapters, testes de comportamento óbvio, a tradução de um padrão conhecido para uma linguagem específica. Se você consegue descrever com precisão, o modelo consegue escrever. Esse "se" carrega muito peso. A precisão da descrição agora é o gargalo, e precisão é exatamente o que engenheiros juniores aprendiam escrevendo o boilerplate com as próprias mãos. Removemos o campo de treino sem remover a necessidade da habilidade.

O que ocupa o espaço

Três coisas, na minha experiência. Especificação: decidir o que o sistema deve fazer, incluindo os casos de borda, antes que alguém ou algo escreva código. Verificação: ler código gerado assumindo que está errado em algum lugar, e construir os testes e evals que provam o contrário. E critério sobre estrutura: saber qual das cinco soluções funcionais que o modelo ofereceu é a que continuará sustentável quando os requisitos mudarem. Nenhuma dessas habilidades é nova. Sempre foram as habilidades de sênior. O que mudou é que agora elas são o trabalho inteiro, e não os últimos vinte por cento dele.

Verificação é a nova digitação

Quando reviso código gerado, leio mais devagar do que leio código humano, não mais rápido. Código humano tem um autor consistente com pontos cegos consistentes. Código gerado é plausível em todo lugar e errado em lugares que não parecem errados: um off-by-one em um loop de paginação, um retry sem backoff, um erro engolido em um catch que loga e segue. Nos sistemas que audito, essas são as falhas que ninguém mais encontra, porque todo mundo assumiu que o código que compila e passa no caminho feliz está pronto. O engenheiro que consegue encontrá-las vale mais do que antes, não menos.

O problema do júnior

Me preocupo com como a próxima geração aprende. Se o modelo escreve o primeiro rascunho, onde o júnior consegue os dez mil pequenos erros que constroem intuição? Minha resposta, para quem eu oriento, é deliberada: escreva você primeiro, depois peça ao modelo, depois compare. Leia a versão do modelo como revisor, não como consumidor. Mantenha uma lista das classes de bug que ele produz. A repetição continua disponível, só não é mais imposta a você, e você precisa escolhê-la.

Onde investir

• System design, porque decidir fronteiras e fluxo de dados continua sendo trabalho humano e o modelo amplifica qualquer design que receba.
• Testes e evals, porque código gerado precisa de mais verificação, não menos.
• Profundidade de domínio, porque o modelo conhece o padrão geral e você sabe o que é de fato verdade no seu negócio.
• Escrita, porque uma especificação precisa agora é executável, e quem escreve bem entrega mais rápido do que quem só codifica bem.

O boilerplate acabou e fico feliz. O que o substituiu é mais difícil e mais interessante, e recompensa exatamente os hábitos que faziam bons engenheiros serem bons antes de tudo isso existir.