O próximo GitHub não precisa vencer o GitHub
O problema não é substituir o GitHub
O Git é distribuído desde 2005, mas a camada construída ao redor dele - revisão, integração contínua, issues, releases, pacotes e segurança - continua centralizada. O autor argumenta que o problema atual não é simplesmente o GitHub estar mal operado, mas usar uma infraestrutura destinada a trabalho durável para registrar experimentos efêmeros, especialmente os criados por agentes de programação. Em uma sessão comum, cinco worktrees e cinco agentes podem gerar quatro tentativas descartadas antes do almoço; ainda assim, cada uma produz branch remota, execuções de CI, webhooks, chamadas de API e registros em bancos de dados.
O texto aponta dois fatores. O primeiro é o acoplamento: Actions, Webhooks, Issues, Pull Requests, API e Copilot podem falhar juntos porque compartilham uma mesma base, consequência direta da integração que torna esses serviços úteis. Entre 1º e 18 de agosto, o histórico de status do GitHub registrou 17 incidentes, dois críticos. Em episódios citados, o Actions teve nove horas de degradação, a API GraphQL passou duas horas expirando e uma queda global afetou interface, API, downloads, Actions, Webhooks, Issues, Pull Requests e Copilot.
O segundo fator é a escala e a mudança no perfil do trabalho. O GitHub informa 630 milhões de repositórios, 230 novos por minuto, 43,2 milhões de pull requests mesclados por mês, crescimento anual de 23%, e quase 1 bilhão de commits enviados em 2025, alta de 25%. A empresa descreveu contribuições geradas por IA, numerosas e de baixa qualidade, como um “ataque de negação de serviço à atenção humana”. Para o autor, esse crescimento ocorre em uma arquitetura na qual as partes compartilham destino.
A solução proposta: uma área de preparação
Empresas como Cursor e Entire estão tentando tornar o armazenamento hospedado mais eficiente. A arquitetura Continuity, da Cursor, usa armazenamento de objetos como fonte de verdade, NVMe local como cache, registro antecipado de operações e réplicas sob demanda para lidar com centenas de réplicas e milhões de pequenos repositórios criados por agentes. A Entire, fundada pelo ex-CEO do GitHub Thomas Dohmke, espelha repositórios em uma rede distribuída e armazena prompts, transcrições e chamadas de ferramentas junto aos commits.
O autor considera essas respostas tecnicamente corretas, mas limitadas ao caso hospedado. Sua proposta é uma área de preparação local: experimentar de modo barato, rápido e privado, e só promover ao GitHub o que conquistar importância. O código continuaria usando os efeitos de rede da plataforma, enquanto experimentos descartáveis deixariam de consumir seus recursos. A diferença de incentivos, porém, dificulta essa mudança: Codespaces, Actions, Copilot e Advanced Security são produtos de nuvem medidos por uso. O texto especula, sem apresentar evidência, que o interesse estratégico no código como dado de treinamento também poderia influenciar a defesa desse modelo.
Primitivas locais e o próximo passo
O exemplo apresentado é o git-sprout, ferramenta criada pelo autor como substituta do git worktree add. No Linux kernel, com cerca de 95 mil arquivos rastreados, um worktree comum escreveu 1.816 MB, enquanto clones com cópia na gravação escreveram 36 MB e produziram uma árvore idêntica. A ideia é identificar primitivas existentes cujo pressuposto foi rompido pelo trabalho com agentes e corrigir apenas esse ponto.
O autor também cita um servidor local compatível com a API usada pelas ferramentas, CI local baseado em act e alternativas como Forgejo, Codeberg, Radicle, sourcehut e Jujutsu. Por fim, observa que modelos de pesos abertos podem reduzir outra dependência remota: modelos menores já cabem na memória de computadores locais, embora os modelos de fronteira ainda exijam data centers. A conclusão é que não vale disputar a próxima guerra de forjas; pode ser mais promissor manter repositórios, worktrees, forge, CI e, talvez, o modelo no mesmo computador para a maior parte do trabalho descartável.