Written with AI assistance from the source video. The video is the authority.
5:31Maximilian Schwarzmüller
Log in to leave a comment
No posts yet
Desde a introdução de ferramentas de codificação de IA, a produção de código dos desenvolvedores júnior aumentou drasticamente. No entanto, é muito provável que sua rotina como líder técnico tenha se transformado em um inferno. Com uma grande quantidade de códigos não verificados sendo despejados de uma só vez, a revisão de código ficou estagnada, e conflitos de merge e interrupções inesperadas no ambiente de produção tornaram-se recorrentes. É hora de parar de seguir a moda das ferramentas. O que sua equipe precisa agora são critérios quantitativos e um sistema operacional claro para controlar o código cuspido pelas máquinas.
O método tradicional de envio de Pull Request (PR) por unidade de funcionalidade sobrecarrega severamente os revisores. Ao tentar verificar centenas de linhas de código de uma só vez, acaba-se checando apenas o funcionamento básico e clicando em 'LGTM (Looks Good To Me)'. É nesse momento que defeitos fluem livremente para a produção.
Você deve dividir as unidades de PR em unidades lógicas que resolvam apenas uma camada da arquitetura ou uma única responsabilidade. É recomendável impor limites quantitativos de 150 linhas ou menos de alteração e 5 arquivos ou menos alterados. De acordo com pesquisas da equipe de engenharia da Microsoft, quando o critério de enviar um aviso para PRs com mais de 400 linhas foi aplicado, a taxa de incidentes após o merge caiu 35%. Além disso, estatísticas da plataforma de análise de código Code Climate mostram que PRs pequenos, com menos de 150 linhas, têm uma velocidade de merge 40% maior e a taxa de detecção de defeitos potenciais aumenta para mais de 87% em comparação com PRs acima de 250 linhas.
Para reduzir o tempo de processamento da revisão de código, formalize as diretrizes internas da equipe e realize as seguintes práticas:
git add -p: Pratique com os membros da equipe como registrar blocos de código individuais (Hunks) na área de staging para dividir grandes alterações em pequenos commits.git rebase -i para editar e organizar os commits densos gerados, garantindo a legibilidade do histórico do projeto.Para uma imposição física, você deve inserir o Danger JS no seu pipeline de CI/CD. Crie um dangerfile.js na raiz do projeto e implante um script que falhe o build quando o número de linhas alteradas exceder 150 ou quando a descrição do PR tiver menos de 15 caracteres. Quando o sistema começar a bloquear, os próprios membros da equipe dividirão os PRs antes de enviá-los.
As ferramentas de desenvolvimento de IA são convenientes, mas trazem problemas como alucinações — onde inventam APIs falsas ignorando o contexto do domínio — ou vulnerabilidades de segurança. Para manter a produtividade da máquina e, ao mesmo tempo, garantir a qualidade, é essencial um rigoroso processo de 'humano no circuito' (Human-in-the-loop). O código gerado por IA deve ser verificado em um ambiente de branch independente antes de ser mergeado com o branch principal.
O fluxo de trabalho para verificação de código gerado por IA que reduz acidentes de implantação é o seguinte:
ai-refactor/ a partir do ponto de referência do branch main. Antes de modificar a fonte, configure um arquivo Markdown detalhado (spec.md) no caminho local contendo os objetivos e restrições para impedir que o modelo de IA adicione código desnecessário.Assisted-by: AI-Model-Name, que indica a posição de autoria auxiliar, no final da especificação do commit.Ao consolidar este fluxo de trabalho, você pode impedir que códigos de IA não verificados entrem diretamente no fluxo principal.
Dividir as unidades de PR em menos de 150 linhas maximiza a legibilidade do código, mas pode agravar os conflitos de controle de versão se vários desenvolvedores tentarem continuamente fazer merges no mesmo ponto de destino. Para resolver esse problema, é preciso adotar o paradigma de desenvolvimento baseado em trunk (Trunk-based development), integrar ferramentas de automação de envio contínuo como o Graphite e uma arquitetura de feature flags que controle os caminhos de execução do código em tempo de execução.
Para garantir que códigos de novos recursos inacabados não prejudiquem a operação normal do ambiente de produção mesmo sendo mergeados imediatamente no fluxo principal, instale a solução de feature flags Unleash na base de código e aplique o seguinte processo:
Extração de interface comum: Instale o Graphite CLI na equipe e use os comandos gt create e gt submit --stack para configurar os branches da pilha superior a usarem os branches inferiores como base. Dentro da base de código, defina antecipadamente uma interface comum que corresponda à área de alteração.
Escrita de implementações duais e integração de flag: Escreva o serviço da versão antiga e o novo serviço inacabado em processo de reformulação como classes independentes que implementam a mesma interface, e incorpore a biblioteca SDK do Unleash.
Controle de injeção baseado no padrão Factory: Na área do contêiner de dependência, faça o mapeamento de injeção adiado da instância de acordo com a condição de ativação em tempo de execução do sistema externo de feature flags (useFlag('feat_new_payment')). Configure a lógica de ramificação da fábrica para renderizar a versão antiga por padrão quando a flag estiver desativada.
Realize o merge no trunk principal com a taxa de entrada de destino da flag definida como 0% no painel do Unleash. Como o código inacabado não é exposto ao usuário final mesmo sendo mergeado constantemente, é possível evitar conflitos de merge com antecedência.
Para construir uma organização de desenvolvimento sustentável, é necessário controlar o processo de revisão de código com base em métricas para garantir que ele esteja circulando de forma saudável. De acordo com o guia de referência do Code Climate, é eficaz monitorar o 'Ciclo de Revisão (Review Cycles)', que é a frequência de feedback e commits de correção trocados desde a criação até o merge de um único PR. Organizações ágeis, situadas nos 25% melhores da indústria, convergem para uma média de menos de 1,1 ciclos de revisão. Por outro lado, se os indicadores de uma equipe específica excederem frequentemente 1,5 vezes, é um sinal de que existem barreiras internas, como a falta de documentos de critérios de convenção ou definições de planejamento pouco claras.
Para minimizar o atrito de convenção acumulado durante o processo de revisão, combine o mecanismo de aprendizado do CodeRabbit com o loop de feedback baseado no Rulens CLI:
npx rulens generate no pipeline para que o utilitário Rulens, residente no executor de CI/CD, intercepte essas mudanças na etapa de build e compile automaticamente um novo arquivo de regras docs/lint-rules.md.Uma vez estabelecida essa rotina operacional, a IA produzirá código já consciente das convenções internas da equipe desde a fase inicial de escrita. Isso reduz erros repetitivos de lint, correções manuais e loops de discussão exaustivos com revisores, permitindo um controle eficiente do número de ciclos de revisão de toda a equipe.