Engenharia ainda importa
Engenheiros de software não são operadores de prompt
Esse post foi traduzido automaticamente do inglês. Se você encontrar algum erro, por favor entre em contato.
O que se ouve por aí é que a engenharia virou uma ocupação sem graça, quase mecânica. Você pede ao agente de IA o que fazer, espera, dá algum feedback, espera, faz o commit, abre o PR. Depois vai ler os PRs criados por IA que seus colegas abriram, a maioria grande e complexa o suficiente para ser difícil de entender. Abre o laptop, lê texto e aperta enter em loop, fecha o laptop. Nada empolgante.
Escrevi um post sobre essa situação, e um dos meus argumentos era que engenheiros de software não podem reduzir o próprio trabalho a entregar código. Ser um engenheiro eficaz significa entregar valor por meio de software, usando ferramentas de IA ou não. O post gerou uma ótima discussão, mas não agradou um amigo meu, que disse, em outras palavras: isso é papo de gestor e não ajuda um engenheiro a saber o que fazer. O público não está fácil.
Mas meu amigo tinha razão. Dizer que nada mudou e que tudo se resume a valor pode ser verdade e, ao mesmo tempo, não ser útil. O trabalho claramente está mudando de várias formas, e engenheiros precisam entender como tirar o máximo proveito dessa mudança. No contexto de um engenheiro de software, o que significa entregar valor?
Como um engenheiro de software entrega valor?
Quando converso sobre esse assunto com os engenheiros com quem trabalho, costumo contar a história de um projeto do qual participei como consultor, muitos anos atrás. Nesse projeto, eu trabalhava com um colega bem mais sênior, o tech lead, planejando um sistema financeiro para um banco.
Passamos pelo processo de planejamento e apresentamos nossa solução ao cliente. O plano incluía cuidados com performance, escalabilidade e recuperação de falhas, entre outros aspectos técnicos que consideramos necessários por se tratar de um sistema financeiro crítico. Enquanto apresentávamos, o cliente perguntou “por que precisamos de tudo isso?”, e meu colega respondeu na hora: “porque eu não vou construir um sistema que me acorde todas as noites”. E a discussão acabou ali.
Aquele momento ficou marcado na minha memória. Era nosso trabalho, como engenheiros, definir onde ficava a barra de qualidade daquele sistema. Isso era verdade para aquele sistema, e é verdade para qualquer sistema.
Manter a barra não significa apenas concluir a próxima tarefa ou fazer as coisas como sempre foram feitas. Significa tanto entregar software o mais rápido possível agora quanto garantir que o custo de manter e evoluir esse software seja o menor possível. Como disse Alistair Cockburn, o objetivo principal do jogo é entregar software útil e funcionando, e o objetivo secundário é se preparar para o próximo jogo. Construir sistemas que sejam eficientes agora e no futuro.
“Todo projeto de software deixa um legado para o próximo projeto, e por isso as estratégias usadas no desenvolvimento de software devem levar em conta tanto este jogo quanto o próximo” - Alistair Cockburn
No mundo atual da IA, jogar o jogo do momento ficou mais fácil. O trabalho do engenheiro realmente mudou de forma significativa agora que construir algo leva alguns prompts. Já se preparar para o próximo jogo, não.
Estamos em um momento em que a indústria inteira está aprendendo. Na prática, isso significa empresas e times jogando agentes em todos os problemas, na esperança de redefinir a velocidade com que um time de software consegue se mover. Para o engenheiro, isso muitas vezes aparece como pressão. “A IA não consegue fazer isso?” é a versão atual da pergunta que fizeram ao meu colega muitos anos atrás. E, embora possa ser difícil resistir à pressão de simplesmente empurrar código o mais rápido possível neste momento, está claro que vamos ver as consequências disso em breve.
Software vai exigir tokens para ser projetado, construído, executado e mantido. Uma base de código mal projetada vai exigir mais raciocínio dos agentes para entregar código de alta qualidade, como Giles Edwards-Alexander mostrou em um experimento recente publicado no site de Martin Fowler. Entregar software de forma eficaz vai significar construir sistemas baratos de construir, baratos de rodar e baratos de evoluir, já que isso pode ser o que faz um produto dar certo ou não.
Nesse experimento, o número de tokens necessários para fazer uma mudança diminui conforme o sistema é refatorado (Gráfico: Giles Edwards-Alexander, The Economic Benefit of Refactoring)
Para os engenheiros, essa crise também é uma oportunidade, já que a qualidade técnica vai continuar fazendo parte da equação do software. Não é uma questão de quanto artesanato existe na engenharia, é uma questão de tempo e dinheiro. Sabemos que um agente consegue construir uma PoC muito rapidamente. Engenharia de alta qualidade significa garantir que o agente consiga construir a milésima feature em uma base de código grande com a mesma eficiência.
“Você é o guardião da barra de qualidade. Ninguém vai chegar aqui e dizer que o seu código não está bom o suficiente.” Esse é o conselho que costumo dar aos engenheiros e tech leads com quem trabalho. Na maioria das empresas de tecnologia (razoáveis), sua perspectiva técnica vai ser respeitada. Mas você precisa levantá-la, porque ninguém tem mais contexto do que você sobre o projeto que está liderando e o código que está entregando.
Esse conselho é mais importante do que nunca agora, com a pressão por velocidade crescendo e as proteções usuais de qualidade, como o code review, deixando de funcionar. Os engenheiros na linha de frente são, hoje, quem está definindo como o software será construído, tanto criando as novas proteções quanto projetando arquiteturas eficientes. As verificações que o código precisa passar antes de um PR existir, as regras de arquitetura escritas para humanos e agentes seguirem, as métricas que garantem que os agentes continuem eficientes conforme a base de código cresce. Ninguém mais vai fazer isso. Esse é o seu trabalho.
Comentários