A tradicional prática de desenvolvimento de manter Pull Requests (PRs) pequenos e fáceis de revisar está caindo por terra com a ascensão dos agentes de IA. A Rootly, especialista em gestão de incidentes, abandonou oficialmente a regra ao notar que o fracionamento prejudica a inteligência de contexto e o fluxo de trabalho dos bots de codificação.
A Rootly abandonou os 'Small PRs' porque as IAs criam códigos completos e integrados, que perdem o sentido se fragmentados.
O verdadeiro desafio no desenvolvimento com IA não é a lógica, mas sim o contexto sistêmico e as dependências estruturais.
O foco da segurança operacional mudou do momento do merge para o pós-merge, priorizando Feature Flags e rollbacks imediatos.
Especialistas em DevOps sugerem que os fluxos de revisão baseados estritamente em PRs podem se tornar um gargalo ou antipadrão dentro das empresas.
O declínio dos pequenos pull requests na era da IA
Por dois anos, a Rootly manteve uma cultura rigorosa de commits atômicos e PRs pequenos, limitados a algumas centenas de linhas de código. Esse modelo, consolidado na indústria de software por anos, foi desenhado para facilitar a revisão humana de código escrito à mão, permitindo correções rápidas e reversões sem traumas. No entanto, o advento de agentes de inteligência artificial autônomos que codificam mudou drasticamente essa realidade.
Segundo Quentin Rousseau, cofundador e CTO da Rootly, os agentes de IA não trabalham em incrementos lógicos lineares como os humanos; eles pensam na funcionalidade completa. Ao receber uma tarefa, a IA gera simultaneamente o modelo de dados, as migrações, os serviços, os controladores, os testes unitários e até os componentes de interface em uma única entrega.
Forçar a IA a fracionar esse trabalho resultou em retrabalho e dificuldades gigantescas de revisão contextual para a equipe de engenharia.
Agentes de IA entregam features completas de uma vez.
A tentativa de quebrar o código da IA em blocos pequenos causou confusão contextual.
O tempo gasto gerenciando PRs fragmentados tornou-se um gargalo operacional.
Bugs de IA são problemas de contexto, não de sintaxe
A equipe de engenharia da Rootly destaca que os erros cometidos por agentes de IA raramente estão associados a falhas sintáticas ou lógicas básicas. Pelo contrário: as ferramentas produzem códigos tecnicamente corretos, mas que falham por falta de contexto sistêmico.
Um exemplo clássico ocorre quando uma IA cria uma migração que remove uma coluna de banco de dados que ainda está sendo utilizada por um processo secundário em segundo plano, ou quando altera um serviço cujo impacto atinge tabelas consumidas por times paralelos. A revisão clássica de poucas linhas de código é cega para esse tipo de problema integrativo.
Erros de IA envolvem dependências cruzadas entre microsserviços.
Revisores humanos precisam de uma visão holística para identificar conflitos.
A validação de pequenos diffs isolados perdeu sua utilidade prática.
Mitigando riscos com o modelo 'blast radius'
Para solucionar o impasse, a Rootly tomou a decisão estratégica de parar de revisar códigos gerados por IA da mesma forma que revisa produções humanas. A empresa desenvolveu uma ferramenta de revisão automatizada interna que analisa cada PR contra padrões de engenharia. Em vez de imitar um humano, a ferramenta responde à seguinte pergunta: 'Se esse código falhar, qual comportamento do sistema será quebrado?'.
Essa análise avalia o risco do Pull Request e o classifica de acordo com o impacto gerado. Mudanças estruturais recebem perfis de alta criticidade, enquanto alterações puramente estéticas ou de performance localizada ganham menor atenção. O ponto de segurança crítico, portanto, migrou do processo de merge de código para o ambiente de produção via Feature Flags. Toda nova funcionalidade entra desativada por padrão, sendo ativada progressivamente primeiro para o time, depois para clientes selecionados, até atingir 100% da base.
Feature flags movem o ponto de segurança da revisão para o rollout progressivo.
A análise se concentra na capacidade de rollback rápido caso algo dê errado.
O tamanho do arquivo alterado deixa de ser um indicador de segurança confiável.
A transição da indústria e o debate sobre novos workflows
A transformação vivida pela Rootly não é um caso isolado. Empresas como a Rewind integraram modelos semelhantes de análise de risco com ferramentas como o 'Diff Vader', que avalia o impacto de alterações de código de forma independente do volume de linhas modificadas.
O debate ganhou tração em eventos como o AI Native DevCon London, onde líderes do setor, incluindo Patrick Debois (reconhecido mundialmente como um dos criadores do movimento DevOps), apontaram que o fluxo tradicional baseado em PRs pode se tornar um antipadrão corporativo ao competir com a velocidade de desenvolvimento dos agentes de inteligência artificial.
Debois argumentou que, embora o modelo de PR faça sentido no ecossistema open-source devido à falta de alinhamento e confiança prévia, o mesmo rigor dentro de um time integrado gera apenas atrito desnecessário em alta velocidade.
| Indicador | Abordagem Tradicional (Humana) | Abordagem com IA Agente |
|---|---|---|
| Tamanho ideal do PR | Pequeno (focado em poucas linhas) | Completo (toda a feature em um único bloco) |
| Principal métrica de risco | Quantidade de linhas alteradas | Raio de impacto no sistema (Blast Radius) |
| Mecanismo de validação | Revisores humanos linha por linha | Revisores IA analíticos + Feature Flags em produção |
| Causa comum de bugs | Erros de lógica ou sintaxe do desenvolvedor | Falta de contexto e integrações entre equipes |
Arraste para o lado para ver toda a tabela.
Perguntas frequentes
Por que a rootly abandonou a regra de pequenos prs?
Porque agentes de IA geram funcionalidades completas (incluindo migrações, testes e front-end) de uma vez só. Forçar a IA a quebrar o código em pedaços pequenos gerava atritos e bugs de contexto na revisão.
O que são bugs de contexto cometidos por ias?
São problemas em que o código gerado funciona perfeitamente de forma isolada, mas falha ao interagir com outras partes do sistema, como remover uma coluna do banco que ainda é usada por serviços secundários.
Como o risco é gerenciado agora SEM os small prs?
Através do mapeamento do raio de impacto (blast radius) de cada modificação e do uso rigoroso de Feature Flags, garantindo que o código novo seja testado progressivamente direto em produção.
