Como avaliar a qualidade de código de uma squad antes de contratar?

Avaliar a qualidade de código de uma squad antes de contratá-la significa medir sinais objetivos —cobertura de testes, code churn, densidade de código duplicado, tempo real de code review— em vez de confiar em um portfólio bem-apresentado ou em uma única entrevista técnica. Fazer isso bem importa mais do que antes: com cada vez mais código escrito ou assistido por IA, a linha entre “funciona” e “é sustentável” ficou mais difícil de enxergar à primeira vista.

Isso não é um detalhe técnico menor. Segundo a 2025 Developer Survey do Stack Overflow, 84% dos desenvolvedores já usam ou planejam usar ferramentas de IA para programar —mas a confiança na precisão desse código caiu de 40% para 29% no mesmo período, e 66% apontam código que fica “quase certo, mas não exatamente” como o problema mais comum. Uma squad pode estar gerando mais código do que nunca e, ao mesmo tempo, gerando mais trabalho de correção do que parece à primeira vista.

Por que a qualidade de código ficou mais difícil de avaliar do que há dois anos?

Porque o volume de código não diz mais nada por si só. A GitClear analisou mais de 211 milhões de linhas de código em seu AI Copilot Code Quality Research 2025 e descobriu que a frequência de blocos de código duplicado multiplicou por oito durante 2024, que o code churn —código reescrito poucos dias depois de ter sido escrito— passou de um patamar histórico de 3,3% para 7,1% em 2025, e que o código refatorado caiu de cerca de 25% das linhas alteradas em 2021 para menos de 10% em 2024. Pela primeira vez na série da GitClear, houve mais código copiado e colado do que código movido ou reorganizado com critério.

Uma squad que entrega mais rápido com IA entrega necessariamente melhor?

Não necessariamente, e aí está a armadilha de olhar só para a velocidade. O relatório Acceleration Whiplash da Faros AI, baseado em telemetria real de 22 mil desenvolvedores em mais de 4 mil times, descobriu que a adoção de IA aumentou em 34% as tarefas concluídas por desenvolvedor —mas também aumentou em 54% os bugs por desenvolvedor, mais que triplicou a proporção de incidentes por pull request, e multiplicou por cinco o tempo mediano de revisão de código. Uma squad pode parecer mais produtiva na superfície e estar gerando, ao mesmo tempo, mais dívida técnica do que está faturando.

Quais métricas de qualidade de código realmente ajudam a avaliar uma squad antes de contratar?

Nenhuma métrica sozinha é suficiente, mas combinadas dão um retrato bem mais confiável do que um portfólio:

• Cobertura de testes, e se esses testes realmente rodam em cada pull request —não só quando alguém se lembra de rodá-los.
• Code churn: qual porcentagem do código escrito é reescrita poucos dias depois. Existe um patamar normal; um salto sustentado é sinal de pressa, não de iteração saudável.
• Densidade de duplicação: quanto do código novo é uma variação de algo que já existia no repositório, em vez de uma solução pensada para aquele caso específico.
• Tempo real de code review: se um segundo par de olhos revisa antes do merge, e quanto tempo isso leva —não se a política existe no papel.
• Densidade de bugs encontrados depois do merge, não só durante o desenvolvimento, que é quando são mais baratos de corrigir.

Como auditar isso sem pedir para a squad se autoavaliar?

Olhando o histórico real no repositório, não uma demo montada para a entrevista. Um commit com data e autoria diz mais do que um case bem escrito, porque não depende de alguém escrevê-lo a favor da squad —ou o padrão está no histórico, ou não está.

Como a Zenit resolve isso

Em vez de pedir para a empresa auditar manualmente o código de cada squad, o ZenitRank cruza esses sinais —código real no GitHub, cumprimento de milestones, disputas resolvidas— em uma pontuação que se atualiza sozinha a cada entrega, não com o que a squad diz sobre si mesma em uma ligação de vendas.

E antes de chegar a esse ponto, o Kaizen já entendeu o projeto real —não um briefing genérico— então o match prioriza a squad com histórico verificável em projetos comparáveis, não a que monta a melhor demo.

A pergunta que importa não mudou com a IA, só ficou mais urgente: não é quanto código um time produz, é se esse código pode ser sustentado seis meses depois da entrega —e essa resposta nunca está no portfólio, está no histórico.