É incrível como, nos últimos tempos, pessoas que não são programadoras têm tido a possibilidade de criar as suas próprias aplicações, que podem até gerar receitas. Temos assistido recentemente a progressos no campo do desenvolvimento de IA, desde o sucesso da IA no «código greenfield» (aplicações criadas do zero) até ao «código brownfield» (aplicações existentes em maior escala). Os modelos mais recentes tornaram-se muito mais eficientes na utilização de ferramentas e têm tido um enorme sucesso na implementação de funcionalidades em aplicações de maior dimensão, ao ponto de os programadores mal terem de parar para rever o código. Em vez disso, concentram o seu tempo na definição de requisitos e em testes funcionais, o que lhes permite lançar mais produtos.
Ao mesmo tempo, desenvolver novas funcionalidades a este ritmo corre o risco de aumentar a dívida técnica a tal ponto que se torne praticamente impossível continuar a avançar. Sem supervisão, as equipas podem acabar com montes de código esparguete, pelo que os padrões de qualidade do código devem ser uma prioridade antes que o problema fique fora de controlo.
Manter elevados padrões de qualidade do código é mais fácil na teoria do que na prática. A revisão humana não consegue acompanhar o ritmo, e pedir ao Claude ou ao Cursor para rever o seu código é como pedir a alguém para rever uma tese sem qualquer contexto sobre a disciplina ou os padrões que devem ser seguidos.
O que fazem as equipas quando o código de IA se acumula?
O custo de ignorar as revisões, especialmente no que diz respeito a alterações arquitetónicas, acaba por se fazer sentir mais tarde, normalmente alguns meses depois. As alterações geradas pela IA acumulam-se sobre outras alterações geradas pela IA, e cada camada parte do princípio de que a camada subjacente está correta. Quando isso não acontece, o modelo tem uma base frágil sobre a qual construir, tal como os programadores que o orientam. Os erros surgem em locais inesperados e até mesmo pequenas alterações começam a produzir efeitos secundários que demoram algum tempo a corrigir.
A certa altura, o ritmo acelerado do primeiro mês começa a abrandar. A equipa passa a lançar atualizações mais lentamente, porque cada PR sente agora o peso de tudo o que veio antes.
Então, quando as equipas tentam fazer a limpeza, trata-se de uma tarefa complexa. As organizações estão até a tentar resolver o problema recorrendo a especialistas em limpeza de código «vibe». Já é possível encontrar pessoas com esta função no LinkedIn.
Parece contraditório tirar partido da IA e, em seguida, precisar de mais pessoas para resolver os problemas que a própria IA tornou possíveis. Por isso, as equipas devem tomar medidas para rever o código numa fase inicial e de forma eficiente.
Como manter a dívida de código baixa
As melhores opções que as pessoas têm encontrado até agora para reduzir a dívida de código enquadram-se, em geral, numa das duas categorias:
- Uma ferramenta para verificar a qualidade do código nas solicitações de integração, com o objetivo de detetar precocemente a dívida de código
- Uma ferramenta para verificar a qualidade do código nos repositórios
As equipas utilizam-nas para:
- Do ponto de vista da gestão, verifique quais as equipas que poderiam beneficiar da presença de programadores mais experientes, ou identifique quais as equipas que necessitam de elevar o nível de qualidade do código.
- Acompanhe as descobertas individuais. Por exemplo, mesmo quando se tem algum repositório antigo que não se altera porque «simplesmente funciona», é sempre interessante percorrer as descobertas de erros de lógica, para perceber se poderá haver efeitos secundários inesperados com impacto oculto.
Ambos os casos de utilização só funcionam se as verificações subjacentes forem precisas, e essa precisão depende do grau de especificidade de cada verificação. Pedir a um LLM para analisar um repositório inteiro de uma só vez leva ao mesmo problema que um prompt vago dado ao Cursor: há demasiada informação à sua frente para que consiga identificar algo específico.
É por isso que a funcionalidade «Code Quality»Aikido lança chamadas ao LLM numa base por regra. Isto ajuda significativamente o LLM a concentrar-se numa questão específica de cada vez. Além disso, é possível ajustar essas regras com contexto adicional para garantir que os resultados correspondem ao estilo de código. Se não existir uma regra que aborde um requisito específico, também é possível adicionar regras personalizadas. Essa camada de controlo ajuda a otimizar todo o processo em toda a equipa.
Além disso, esta camada de controlo aplica-se simultaneamente às verificações de PR e à análise do repositório, para garantir que os dados estatísticos relativos à análise do repositório correspondam ao feedback sobre os pedidos de integração.
Critérios de referência para a qualidade do código
Uma segunda vantagem da utilização de um sistema dedicado à qualidade do código é que os LLMs recebem prompts otimizados que foram submetidos a testes comparativos (algo que também fazemos com o AutoTriage). O processo é simples. Recolhemos amostras de código para uma determinada regra e classificamos manualmente se devem ou não ser sinalizadas, atribuindo-lhes uma pontuação de confiança.
Algumas regras de qualidade do código encontram-se numa zona cinzenta, o que torna difícil determinar se devem ou não ser sinalizadas. Por exemplo, reparámos em grandes diferenças na forma como as equipas aplicavam a regra «sem duplicação óbvia». Aikidopróprio estilo de código Aikidoconsiste em não aplicar esta regra de forma muito rigorosa. A legibilidade é frequentemente preferida à vantagem de facilidade de manutenção proporcionada pela deduplicação. Os novos colaboradores, por vezes, preferiam um código mais«DRY»e esforçavam-se bastante para adicionar abstrações que permitissem alcançar esse objetivo. Não há certo ou errado aqui, é apenas um tom diferente de cinzento. Nesses casos, um indicador de confiança define quantas pessoas esperamos que sinalizem ou não algo.
No entanto, precisamos de tomar uma decisão clara e definitiva ao assinalar algo num PR. Então, como é que lidamos com a zona cinzenta ao aplicar rótulos de confiança? Em primeiro lugar, procuramos simplesmente não assinalar amostras da zona cinzenta — é mais provável que frustramos os programadores com demasiadas detecções do que que os surpreendamos com detecções certeiras. Também integramos esta abordagem no nosso sistema de engenharia de prompts. Após rotular as amostras, ajustamos os prompts de forma a maximizar a satisfação do cliente.
Infelizmente, os LLMs não são perfeitos e os erros continuam a ocorrer, pelo que temos de escolher bem as nossas batalhas. Dispor de exemplos da «zona cinzenta» ajuda-nos a escolher as batalhas certas. Quando tomamos uma decisão errada relativamente a um exemplo da «zona cinzenta», a penalização é menor do que no caso de uma decisão errada sobre um exemplo óbvio. O resultado é que as conclusões ficam bastante próximas da verdade, significativamente mais próximas do que as que se obtêm com prompts «vanilla».
Dê prioridade à qualidade do código em vez de à deteção de erros
Uma fonte interessante de confusão entre um sistema de qualidade de código e outros sistemas de revisão de PR é o facto de a maioria dos sistemas tender a concentrar-se na deteção de erros. Esse é, evidentemente, um aspeto importante, mas serve um objetivo diferente. A forma mais prática de avançar é iterar rapidamente sobre o estilo do código, e esses sistemas devem funcionar rapidamente. O sistema de qualidade de código Aikidonormalmente conclui o processo em menos de 1 minuto após o envio do commit, mantendo o ciclo de feedback curto. Isso inclui tanto verificações de qualidade de código como de segurança.
Num futuro próximo, também será possível solicitar uma verificação rigorosa de um commit. Essa verificação iria então detetar erros lógicos e problemas de autorização de forma mais aprofundada. Funciona de forma autônoma e, por isso, é mais lenta e mais dispendiosa, mas constitui uma verificação final ideal de um PR antes da implementação.
Conclusão
Uma solicitação genérica ao Claude ou ao Cursor verifica o código em função do que o modelo vier a priorizar nesse dia, e não da cultura de programação específica de uma base de código. Um sistema dedicado à qualidade do código resolve essa questão, pois aplica as mesmas regras otimizadas tanto a pedidos de integração como a repositórios completos, de modo que a equipa obtém uma resposta consistente, em vez de duas respostas diferentes, dependendo de onde a verificação é executada. O passo seguinte aprofunda essa resposta: uma verificação autónoma concebida para detetar erros lógicos e problemas de autorização, suficientemente estável e segura para ser executada imediatamente antes da implementação, em vez de em cada commit.
