Escalando o Git na OpenAI
O crescimento explosivo de código gerado por IA está levando a infraestrutura de Git da OpenAI aos seus limites, levando a um sistema personalizado (“Pando”) para lidar com monorepos em escala de petabytes e dezenas de milhares de commits por dia. Comentadores debatem se isso reflete ganhos reais de produtividade ou apenas “AI slop” — enormes quantidades de código redundante, de baixa qualidade ou constantemente reescrito que os humanos já não conseguem compreender ou revisar por completo. A discussão levanta questões mais amplas sobre manutenibilidade, segurança e o papel futuro dos desenvolvedores humanos à medida que grandes laboratórios redesenham o controle de versão para desenvolvimento de software orientado por agentes.
Explosão percebida de código e commits
- Muitos ficam surpresos com o enorme volume de commits/LOC e questionam como isso pode ser um ativo em vez de um passivo.
- Outros observam que, em relação ao tamanho da empresa, o volume pode ser “moderado”, e que as métricas tradicionais de LOC estão se tornando menos significativas do que o tamanho do repositório e os padrões de churn.
“Slop” gerado por IA vs produtividade
- Vários comentaristas descrevem a saída de agentes de IA como um “slop” volumoso: abstrações superdimensionadas, lógica duplicada, comentários prolixos e commits intermináveis de “fix”.
- Eles relatam tarefas pequenas se transformando em enormes contagens de tokens e commits, com agentes corrigindo repetidamente seus próprios erros.
- Os apoiadores argumentam que isso é aceitável se computação for barata: código e testes podem ser regenerados ou refatorados repetidamente até que os benchmarks sejam atendidos.
Supervisão humana, confiança e responsabilidade
- Um lado argumenta que LLMs podem escrever e revisar de forma confiável a maior parte do código, com humanos necessários apenas para casos fora de distribuição ou de alto risco.
- Os críticos enfatizam incentivos (pessoas são demitidas por código ruim, modelos não), responsabilidades regulatórias e com dados de clientes, e a necessidade de alguém realmente entender como os dados são processados.
- Há preocupação de que, eventualmente, os gerentes tenham de responder “não sei, o modelo fez isso”, e sobre a perda da capacidade humana de depuração.
O que é todo esse código?
- As especulações incluem: ambientes de RL, infraestrutura de treinamento/serving, apps internos, experimentação massiva e captura de cada edição do agente para treinamento.
- Outros suspeitam de duplicação, scripts efêmeros e “cache” de código gerado que poderia, em vez disso, ser regenerado sob demanda.
- Alguns se preocupam que o benefício para os usuários não esteja claro, dado o impacto relativamente modesto em produtos visíveis e, às vezes, apps cliente desajeitados.
Git, monorepos e modelos alternativos de VCS
- Vários observam que o Git já enfrentava dificuldades em escalas de monorepo grandes (Meta, Google); a OpenAI está atingindo limites semelhantes ou piores com fluxos de trabalho dirigidos por agentes.
- Há debate sobre se isso é fundamentalmente um problema de monorepo, um problema do Git, ou um novo caso de uso em “escala de agentes” (alta taxa de commits, uso tipo snapshot/log).
- Alguns argumentam que grandes players deveriam adotar topologias de VCS totalmente novas e centralizadas, em vez de esticar o Git; outros veem o Git evoluindo mais para uma camada de protocolo.
Implicações mais amplas
- Alguns veem isso como uma prova impressionante de que LLMs podem construir sistemas complexos rapidamente.
- Outros veem isso como um alerta: codebases em explosão, superfícies de ataque maiores e uma cultura de desenvolvimento que otimiza para throughput em vez de clareza e manutenibilidade.