Suite de testes substitui code review na era dos agentes

Allen Hutchison, cofundador da Vycari, argumenta que, com agentes de código escrevendo e revisando pull requests, o gargalo do desenvolvimento passou do code review para a suíte de testes - e que a resposta estrutural é quebrar o monorepo em repositórios pequenos e convencionais.

O novo gargalo

Hutchison descreve um fluxo em que um agente abre um pull request, outro (via Greptile) o revisa em poucos minutos, e o que resta esperando é a suíte de testes - treze minutos no caso do Pepper, produto da empresa. Antes dos agentes, o CI era escalonado por camadas: testes de unidade rápidos localmente, rodadas mais longas no CI e suítes de integração lentas de madrugada. Isso funcionava porque a revisão humana, lenta, dominava o tempo de espera. Com revisão por máquina em minutos, esses treze minutos viraram o ponto crítico, a ponto de um projeto de duas pessoas precisar de uma fila de merge - algo que antes pareceria piada.

A estratificação também não protege mais: o deploy é contínuo, com cada merge gerando uma imagem que chega à produção em ciclo de quinze minutos. Uma suíte noturna só avisaria sobre um bug já enviado pela manhã, com centenas de pull requests de agentes empilhados em cima.

O repositório difícil de reter

O segundo problema é de contexto: um humano constrói intuição sobre os limites de um codebase grande ao longo de semanas; um agente chega frio a cada tarefa e infere o resto do código vizinho. Arquivos de contexto hierárquicos e skills ajudam, mas têm custo de manutenção. Para Hutchison, o monorepo é um padrão ruim quando a maior parte do trabalho é feita por algo que reaprende as paredes a cada tarefa.

Extrair fatias em repositórios próprios

A solução adotada é estrutural: quando uma funcionalidade está madura, ela é extraída para repositório próprio, com testes, fila de merge e cadência de release. A primeira fatia foi o módulo groups, cujos pull requests fecham CI em cerca de dois minutos contra treze no monorepo. Hutchison compara a abordagem ao mandato da Amazon de expor dados apenas via interfaces de serviço, descrito por Steve Yegge em 2011 - só que os "membros de equipe" que não se enxergam são modelos. Ele cita a Anthropic, que enfrentou o mesmo problema pelo outro lado: engenheiros entregam oito vezes mais código por trimestre, com Claude escrevendo 80%, e os jobs de CI cresceram vinte e cinco vezes em seis meses; a resposta deles foi análise de impacto de testes. Como ele não tem equipe para manter esse sistema, a divisão de repositórios compra velocidade similar e resolve o problema de contexto. Um princípio guiado: cada codebase Python deve se parecer com um repositório open source comum, porque modelos viram milhões de repositórios naquele formato.

Fronteiras reais e custos

A divisão só funciona com interfaces definidas - Hutchison cita os protocol buffers do Google como referência. Bugs entre serviços são pegos pelo contrato, por uma suíte de navegador noturna e pelo uso próprio do produto - o que ele admite ser frágil num time de duas pessoas sem clientes.

Ele lista quatro custos: decidir antes em qual serviço o trabalho cabe; falhas independentes entre repositórios (custo ainda teórico para eles); coordenação permanente de versionamento e atualizações; e o risco de investir em infraestrutura em vez de produto antes do lançamento. O cofundador Chris argumentou que construir sobre fundação ruim corrói a velocidade, e que repositórios delimitados serão melhores de entregar a novos engenheiros.

Coordenação com um agente UTL

Para trabalho entre repositórios, Hutchison usa um agente inspirado no cargo de Uber Tech Lead do Google, rodando no modelo Fable 5.1, que vive num meta-repositório pai e quase nunca escreve código: ele delega para subagentes especializados - Opus para design e resposta a review, Sonnet, Luna ou Flash para implementação - rastreando cada pull request até a conclusão.

Conclusão e próximos passos

Com a revisão agêntica quase instantânea, o fator limitante migrou do julgamento humano para o tempo de computação - o único atraso tratável por engenharia, já que se pode encurtar a suíte reduzindo o que ela precisa conhecer. O próximo experimento é criar um segundo agente tech lead mais barato para uma migração, escalando só decisões humanas e mudanças em produção; se funcionar, o documento de design se tornaria a unidade real de trabalho. Chris ressalva que experiência do usuário não pode ser especificada antecipadamente.