É impressionante como não-desenvolvedores foram recentemente capacitados a criar seus próprios aplicativos que podem até gerar receita. Recentemente, vimos progresso no campo do desenvolvimento de IA, com a IA sendo bem-sucedida em 'greenfield code' (aplicativos construídos do zero) e avançando para 'brownfield code' (aplicativos existentes em larga escala). Os modelos mais recentes se tornaram muito melhores no uso de ferramentas e tiveram um sucesso tremendo na implementação de funcionalidades em aplicativos maiores, a ponto de os desenvolvedores mal pararem para revisar o código. Em vez disso, eles concentram seu tempo mais na solicitação de requisitos e em testes funcionais, o que os capacita a entregar mais.
Ao mesmo tempo, construir novos recursos tão rapidamente corre o risco de aumentar a dívida técnica a ponto de se tornar praticamente impossível progredir. Sem supervisão, as equipes podem acabar com pilhas de código espaguete, então os padrões de qualidade de código devem ser uma prioridade antes que o problema fuja do controle.
Manter altos padrões de qualidade de código é mais fácil falar do que fazer. A revisão humana não consegue acompanhar, e pedir a Claude ou Cursor para revisar seu código é como pedir a alguém para revisar uma dissertação sem qualquer contexto da disciplina ou dos padrões que devem ser seguidos.
O que as equipes fazem quando o código de IA se acumula
O custo de pular revisões, especialmente em mudanças arquitetônicas, aparece mais tarde, geralmente alguns meses depois. Mudanças geradas por IA se acumulam sobre outras mudanças geradas por IA, e cada camada assume que a anterior é sólida. Quando não é, o modelo tem uma base fraca para construir, e o mesmo acontece com os desenvolvedores que o solicitam. Bugs surgem em lugares estranhos e até pequenas mudanças começam a produzir efeitos colaterais que levam tempo para depurar.
Em algum momento, a velocidade que era alta no primeiro mês começa a reverter. A equipe entrega mais lentamente porque cada PR agora sente o peso de tudo o que veio antes.
Então, quando as equipes tentam fazer a limpeza, é uma grande tarefa. As organizações estão até tentando resolver o problema com especialistas em limpeza de vibe coding. Você pode encontrar pessoas com essa função no LinkedIn agora mesmo.
Parece contraditório se beneficiar da IA, mas depois exigir mais pessoas para corrigir os problemas que a IA tornou possíveis. Portanto, as equipes devem tomar medidas para revisar o código cedo e de forma eficiente.
Como manter a dívida de código baixa
As melhores opções que as pessoas encontraram até agora para reduzir a dívida de código geralmente se enquadram em uma das duas categorias:
- Uma ferramenta para verificar a qualidade do código em pull requests para identificar a dívida de código precocemente
- Uma ferramenta para verificar a qualidade do código em repositórios
As equipes as utilizam para:
- Do ponto de vista gerencial, verificar quais equipes poderiam se beneficiar de mais desenvolvedores sêniores, ou quais equipes precisam que o nível de qualidade do código seja elevado.
- Rastrear descobertas individuais. Por exemplo, mesmo quando você tem um repositório legado que não é alterado porque “simplesmente funciona”, analisar as descobertas de bugs lógicos ainda é interessante para entender se pode haver efeitos colaterais inesperados com impacto oculto.
Ambos os casos de uso funcionam apenas se as verificações subjacentes forem precisas, e a precisão depende de quão restrito é o escopo de cada verificação. Pedir a um LLM para revisar um repositório inteiro em uma única passada resulta no mesmo problema de um prompt genérico para o Cursor, com muita informação para focar em algo específico.
É por isso que o recurso Code Quality do Aikido inicia chamadas de LLM por regra. Isso ajuda muito o LLM a focar em uma pergunta específica por vez. Além disso, é possível refinar essas regras com contexto adicional para garantir que as descobertas correspondam ao estilo de código. Se não houver uma regra que atenda a um requisito específico, regras personalizadas também podem ser adicionadas. Essa camada de controle ajuda a otimizar todo o processo em toda a equipe.
Além disso, essa camada de controle se aplica tanto às verificações de PR quanto à varredura de repositórios simultaneamente, para garantir que os números estatísticos da varredura de repositórios se alinhem com o feedback dos pull requests.
Prompts benchmarkados para qualidade de código
Uma segunda vantagem em usar um sistema dedicado de qualidade de código é que os LLMs recebem prompts refinados que foram benchmarkados (algo que também fazemos com AutoTriage). O processo é simples. Coletamos amostras de código para uma determinada regra e rotulamos manualmente se elas devem ser sinalizadas ou não, com uma pontuação de confiança.
Algumas regras de qualidade de código vivem em uma zona cinzenta, tornando incerto se devem ser sinalizadas ou não. Por exemplo, notamos grandes diferenças na forma como as equipes tratavam a regra de “sem duplicação óbvia”. O próprio estilo de código do Aikido é não aplicar essa regra de forma muito estrita. A legibilidade é frequentemente preferida em detrimento da vantagem de manutenibilidade da deduplicação. Novos contratados às vezes desejariam que fosse mais ‘DRY’ e fariam um grande esforço para adicionar abstrações para que isso acontecesse. Não há certo ou errado aqui, é apenas um tom diferente de cinza. Nesses casos, um rótulo de confiança define quantas pessoas esperamos que sinalizem algo ou não.
No entanto, precisamos tomar uma decisão de preto ou branco ao sinalizar algo em um PR. Então, como navegamos na zona cinzenta ao aplicar rótulos de confiança? Primeiro, simplesmente visamos não sinalizar amostras da zona cinzenta – é mais provável que frustremos os desenvolvedores com muitas descobertas do que os surpreendamos com descobertas precisas. Também incorporamos isso em 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 erros continuam acontecendo, então precisamos escolher nossas batalhas. Ter amostras de zona cinzenta nos ajuda a escolher as batalhas certas. Quando tomamos a decisão errada em uma amostra de zona cinzenta, ela é penalizada menos em comparação com uma decisão errada em uma amostra óbvia. O resultado é que as descobertas estão bem próximas da verdade, significativamente mais próximas do que se obtém com prompting vanilla.
Foco na qualidade do código em vez de encontrar bugs
Uma fonte interessante de confusão entre um sistema de qualidade de código e outros sistemas de revisão de PR é que a maioria dos sistemas tende a focar na localização de bugs. Isso é, claro, um aspecto importante, mas serve a um propósito diferente. A maneira mais conveniente de progredir é iterar rapidamente sobre o estilo de código, e esses sistemas devem funcionar rapidamente. O sistema de qualidade de código do Aikido geralmente termina em menos de 1 minuto após o push do commit, mantendo o ciclo de feedback curto. Isso inclui verificações de qualidade de código e segurança.
Em um futuro próximo, também será possível solicitar uma verificação rigorosa em um commit. Essa verificação, então, buscaria bugs lógicos e problemas de autorização com mais profundidade. Ela se comporta de maneira agêntica e, portanto, é mais lenta e mais cara, mas é uma verificação final ideal em um PR antes da implantação.
Conclusão
Um prompt genérico para Claude ou Cursor verifica o código contra o que o modelo prioriza naquele dia, não a cultura de codificação específica em uma base de código. Um sistema dedicado de qualidade de código corrige isso porque executa as mesmas regras ajustadas em pull requests e repositórios completos, então uma equipe obtém uma resposta consistente em vez de duas diferentes, dependendo de onde a verificação é executada. O próximo passo aprofunda essa resposta: uma verificação agêntica construída para rastrear bugs lógicos e problemas de autorização, estável e segura o suficiente para ser executada logo antes da implantação, em vez de em cada commit.
