Regresso ao passado para domesticar os agentes de IA

Vivemos um período de deslumbramento com os agentes de IA, com limitados alertas para os erros que cometem: perante qualquer tarefa, resolvem sempre de forma optimista, inventam quando não conseguem responder e raramente admitem que ficaram aquém. Se isto é normalmente inofensivo quando dialogamos sobre temas gerais, pode ter impactos altamente negativos quando os usamos como ferramenta produtiva no desenvolvimento de aplicações.
Noutro artigo, falámos da especificação fina dos requisitos, o spec-driven development, que procura domesticar os agentes. partindo o problema em problemas cada vez mais pequenos, até se chegar a problemas triviais, e usando depois vários agentes para resolver cada um.
Nestas reflexões sobre o impacto da IA na profissão, conversei com o Pedro Sousa, uma das pessoas com um trabalho mais extenso em Arquitectura Empresarial no nosso país, Professor Associado no Instituto Superior Técnico (IST), meu aluno e co-criador do Departamento de Informática do IST.
A carreira do Pedro assenta há muito na modelação e na arquitectura como forma de tornar explícito e verificável aquilo que antes ficava apenas na cabeça de quem programa. Perguntei-lhe como essa tradição se relaciona com o desafio actual de domesticar os agentes. A resposta foi directa: é o momento da vitória. Depois de anos a ouvir que arquitecturas e planos detalhados não valiam o esforço de os manter, tornam-se agora, como elementos accionáveis, parte integrante do próprio sistema a produzir.
Na sua leitura, o spec-driven surge depois de duas décadas de Agile, período em que se tentou saltar por cima do desenho. É, na prática, um regresso à velha sequência (requisitos, desenho funcional, desenho técnico e só depois o código) mas com uma diferença essencial: cada etapa deixou de produzir um documento para um humano ler e passou a produzir artefactos accionáveis, dos quais se derivam, por pessoas e por programas, as etapas seguintes. Quem sempre levou a engenharia de requisitos a sério não está a aprender um processo novo; está a ver o seu processo tornar-se executável.
Refinar os requisitos com este grau de detalhe multiplica também as interacções com os agentes, o que pode criar um sobrecusto. O Pedro aponta três cuidados: ajustar o modelo à complexidade do problema; nunca pedir a um agente o que um programa já resolve, como processamento de informação ou expressões regulares; e manter a informação em formatos simples (ficheiros md) em vez de complexos, como PDF, Word, Excel ou PowerPoint.
Este método explica bem a construção de uma aplicação nova, mas quis perceber como se aplica à manutenção evolutiva e às inúmeras alterações que surgem ao longo de um projecto. Segundo o Pedro, isso já está resolvido pelas velhas engenharias de desenvolvimento, que sabem identificar e propagar os gaps em cada etapa. A diferença é que, tendo agora um processo automatizado sobre artefactos accionáveis, se torna muito rápido identificar as alterações e calcular o seu impacto a jusante. Quando se chega ao código, sabe-se exactamente o que tem de mudar — um problema já trivial para um agente resolver.
Em resumo duas ideias a reter, a primeira relativamente ao Agile que nasceu em 2001, com o Manifesto Ágil como resposta à rigidez dos modelos tradicionais, tipo waterfall. O manifesto privilegiava a colaboração, a entrega contínua e a adaptação à mudança em detrimento de planos fixos. Metodologias como Scrum, XP e Kanban, ao longo das duas décadas tornaram o Agile no paradigma dominante do desenvolvimento de software. Como é óbvio esta é uma metodologia pensada para as equipas estritamente humanas, para as equipas de agentes: requisitos, desenho funcional e desenho técnico volta a ser a sequência necessária. Claro que a gestão Agile de equipas entre os humanos continua a ter o seu sentido.
A segunda ideia relevante é a evolução do objecto “especificação”. Naa abordagem tradicional, as especificações eram documentos estáticos: escritos no início do projecto, consultados algumas vezes e rapidamente desactualizados à medida que o código evoluía. A especificação e a implementação viviam em mundos separados, e manter as duas sincronizadas dependia inteiramente da disciplina da equipa. Com agentes de IA capazes de interpretar linguagem natural e gerar ou modificar código autonomamente, a especificação deixa de ser um artefacto passivo e passa a ser accionável. Ou seja, um input que o agente pode ler, interpretar e transformar directamente em trabalho executado (código, testes, documentação, configuração).
Isto muda a natureza do documento: já não é apenas comunicação entre humanos, mas também uma interface entre a intenção humana e a execução automatizada. A especificação torna-se a fonte de verdade viva. Em vez de o código divergir do documento ao longo do tempo, o agente pode regenerar ou validar a implementação a partir da especificação sempre que esta é alterada, mantendo ambos alinhados.