Pull requests na era da IA

A IA está a mudar a velocidade a que conseguimos produzir código. Os nossos processos de revisão não acompanharam essa mudança.

Recentemente tive uma conversa no trabalho sobre este desfasamento. Há programadores a adoptar IA em várias fases do desenvolvimento. Outros continuam mais cautelosos, sobretudo quando um pull request contém código que a pessoa que o submeteu não consegue explicar. A questão é simples: o que devemos esperar de alguém que submete código produzido com a ajuda de IA?

Para mim, a resposta começa pela responsabilidade. A pessoa que submete o PR é responsável pelo resultado, independentemente de quem escreveu o código. O código gerado por IA pode conter bugs, problemas de segurança e decisões de design fracas. O código escrito por uma pessoa também. O critério de revisão deve ser o mesmo quando uma ferramenta ajudou a produzir o código.

O que significa explicar um PR?

Não significa memorizar cada linha. Um programador não precisa de justificar o nome de todas as variáveis ou de identificar de memória cada import não utilizado.

Precisa de compreender o objectivo da implementação e as decisões que a moldam. Deve conseguir explicar porque é que um repositório usa uma List em vez de um Set, porque é que um pedido é reactivo, qual é a complexidade esperada e que trade-offs foram aceites. Também deve saber que edge cases são cobertos pelos testes e onde a solução pode falhar.

A sequência de prompts e os inputs podem ajudar a explicar como o código foi produzido. Não substituem a compreensão do código. Se a pessoa consegue descrever o prompt, mas não consegue explicar o que a implementação faz, continua a existir uma falha na revisão.

O tipo de alteração importa

Nem todas as alterações precisam do mesmo nível de escrutínio.

Uma prova de conceito com vida curta pode ser avaliada sobretudo pela sua intenção, pelo resultado e pelos testes ou medições que mostram se funciona. Podemos aceitar mais imperfeições quando o código vai ser descartado.

Uma aplicação de produção que a equipa vai manter durante anos tem necessidades diferentes. O código precisa de cumprir os padrões mínimos de qualidade da equipa. Alguém vai ter de o corrigir, estender e analisar quando surgir um edge case. Complexidade, segurança, performance, decisões de design e custos de manutenção são importantes.

É aqui que a revisão de código se torna mais útil do que uma verificação de estilo. A questão é perceber se a implementação é adequada para a vida que vai ter.

Precisamos de uma revisão baseada no risco

A IA permite produzir mais código do que uma equipa consegue ler com o mesmo nível de atenção. As equipas não conseguem aplicar o mesmo processo a todos os PRs.

As equipas podem classificar as alterações por risco. Alterações de baixo risco, com boa cobertura automática, podem seguir um processo de aprovação mais leve. Alterações que afectem dados, segurança, pagamentos ou a arquitectura principal precisam de uma revisão humana mais profunda.

Este modelo só funciona quando existe evidência suficiente. Os testes unitários, de integração e end-to-end fornecem uma parte dessa evidência. Os testes de performance, carga e stress são importantes nos sistemas onde esses riscos são relevantes. As verificações automáticas podem ajudar a classificar uma alteração, mas não eliminam a necessidade de definir os critérios.

É preciso dar contexto às ferramentas

A IA funciona melhor quando a aplicação lhe dá limites claros. Cada equipa deve documentar as regras importantes para o seu código: convenções, requisitos de segurança, estratégia de testes, formato dos commits, linting e restrições arquitecturais.

Estas regras fornecem o contexto de que o modelo precisa. Também tornam as expectativas mais claras para os programadores que ainda estão a aprender a usar IA de forma eficaz.

Um grupo de trabalho transversal pode ajudar nesta transição. Pode mapear os usos mais comuns da IA, comparar práticas, criar uma base comum e apoiar as equipas que se sentem menos confortáveis com a tecnologia. Adopção sem orientação deixa cada pessoa a inventar os seus próprios critérios, o que torna a colaboração mais difícil.

A engenharia de software continua a depender de julgamento

A IA reduziu o custo de experimentar implementações diferentes. Isso cria mais espaço para comparar opções, questionar pressupostos e testar alternativas. Também aumenta o valor do julgamento.

O trabalho está a afastar-se de escrever cada linha e a aproximar-se de descrever intenções, verificar evidências, compreender trade-offs e assumir responsabilidade pelo sistema que chega a produção.

A decisão útil é mais concreta: que evidência exige cada alteração, o que precisa de compreender a pessoa que a submete e quanto risco está a equipa disposta a aceitar?

As ferramentas mudaram rapidamente. Os processos à sua volta precisam de acompanhar essa mudança.