O código é fácil, mais crítica ainda é a engenharia de software

Na reflexão sobre os impactos da IA na indústria e profissão informática, achei que deveria trazer vozes que vivem a mudança no terreno, no dia a dia das equipas. O meu primeiro convidado é o Pedro Samorrinha, meu aluno no Instituto Superior Técnico que tem hoje uma carreira de cerca de vinte anos em Engenharia Informática, com responsabilidades na liderança técnica de equipas, arquitetura de sistemas e condução do ciclo de desenvolvimento de software.
Comecei por lhe propor um cenário que anda a circular na comunicação sobre IA: o responsável técnico chega de manhã, consulta o trabalho produzido durante a noite por uma equipa de agentes, detecta alguns erros, corrige algumas especificações e planeia as novas tarefas, atribui os trabalhos aos agentes e fica com a tarde livre.
O Pedro não acha que este cenário seja a sua realidade, mas poderá vir a ser… Prefere ciclos mais curtos em que consiga validar o que está a ser feito. Insiste sobretudo numa condição prévia: esta forma de produzir software só se torna um verdadeiro factor de produtividade se assentar numa metodologia de desenvolvimento rigorosa.
Perguntei-lhe se isso significa que o trabalho tradicional de programação pode mesmo vir a ser todo executado por agentes. Depende, respondeu, de ter uma engenharia de requisitos muito precisa e documentada, um bom planeamento e capacidade de teste. Só assim os agentes conseguem autovalidar o que está a ser implementado.
Esta é uma das questões inevitáveis: a fiabilidade desta nova forma de trabalhar. A experiência no terreno mostra que os agentes ainda falham e que as equipas se depararam com todo o tipo de resultados inesperados. Na opinião do Pedro, aparecem ainda muitas situações, mas nos últimos meses a qualidade do que produzem melhorou de forma muito significativa. Resultante, naturalmente, da evolução dos modelos.
Este ponto leva-me a uma reflexão sobre a própria gestão das equipas. A popularização do vibe-coding pode criar a ideia de que o desenvolvimento se tornou uma atividade quase espontânea: descreve-se o resultado e deixa-se a IA construir. A experiência aponta no sentido contrário. Precisamente por causa das alucinações, dos riscos de segurança e da possibilidade de o resultado se afastar das expectativas, a equipa do Pedro evitou deliberadamente essa abordagem. Optou por manter um processo clássico de desenvolvimento, agora agentificado, com etapas verificáveis, validação humana e correcção a cada ciclo. É esse processo, e não apenas a capacidade dos modelos, que lhes permite confiar no que está a ser produzido.
A conversa com o Pedro reforça uma conclusão: a metodologia é o ponto crítico para tirar partido destas novas tecnologias. As equipas têm de se basear numa prática que lhes permita controlar finamente o que mandam os agentes executar, através de uma abordagem com especificações bem definidas (spec-driven development) e verificações da implementação em cada etapa (human in the loop). Ao limitar o contexto e orientar de forma mais rigorosa cada tarefa, reduz-se também o espaço que os agentes têm para interpretar, ou inventar, aquilo que lhes foi pedido.
Os efeitos na produtividade são, ainda assim, claros. A equipa do Pedro consegue desenvolver mais depressa, sem abdicar da qualidade, porque definiu uma arquitectura de agentes e skills replicável, construída a partir das suas próprias boas práticas. Convém, contudo, alguma prudência com as quantificações que começam a aparecer. Estamos perante um processo demasiado recente para que exista já um referencial de medição consensual e nem sempre é evidente o que comparar. Ainda assim, os dados que a equipa do Pedro recolheu apontam já para melhorias globais de produtividade de 30% ou mais. Não tomo este número como uma um valor calculado com rigor, mas como um sinal suficientemente relevante.
Há, finalmente, uma consequência que considero particularmente importante: a formação dos engenheiros mais jovens. Durante muito tempo, os juniores entravam nas equipas e aprendiam através da dureza da programação, acumulando experiência à medida que escreviam código, erravam e assimilavam as práticas dos colegas mais experientes.
Hoje, o centro de gravidade está a deslocar-se para a especificação funcional e técnica, onde a experiência dos seniores tem maior valor. Mas esta mudança não tem necessariamente de empobrecer a aprendizagem. Um júnior que acompanhe desde cedo processos rigorosos de especificação e validação pode aprender mais depressa do que aprendia antes. A dificuldade deixou de estar em escrever código; passou a estar em pensar e definir com precisão o que deve ser construído. E essa é uma competência que se pode começar a formar no primeiro dia de trabalho, não apenas ao fim de anos de prática.
Se o código, de facto, se tornou fácil, a engenharia de software, a disciplina de decidir bem o que construir e de verificar se foi bem construído, é hoje ainda mais crítica do que era. Criar uma arquitectura de agentes e skills que espelhe a melhor prática metodológica e, claro, com os humanos indispensáveis para o controlo. E se são essencialmente os seniores, uma nova geração de juniores vai ter de assimilar, certamente a enorme velocidade, um processo de desenvolvimento que é o novo normal.