---
title: "O custo real de abandonar o Git para perseguir a arquitetura do Mononoke"
author: "Pedro Dalben"
date: "2026-10-15T11:03:44Z"
category: "Arquitetura & CTO"
reading_time: "7 min"
canonical: "https://pedrodalben.com.br/blog/o-custo-real-de-abandonar-o-git-para-perseguir-a-arquitetura-do-mononoke"
---

# O custo real de abandonar o Git para perseguir a arquitetura do Mononoke

> A Anthropic recriou o servidor do Sapling em cinco meses, mas a conta de operar um controle de versão virtualizado quase nunca fecha.

**Autor:** Pedro Dalben (CTO no Integrar Plus)  
**Publicado em:** 15 de October de 2026  
**URL Canônica Oficial:** [https://pedrodalben.com.br/blog/o-custo-real-de-abandonar-o-git-para-perseguir-a-arquitetura-do-mononoke](https://pedrodalben.com.br/blog/o-custo-real-de-abandonar-o-git-para-perseguir-a-arquitetura-do-mononoke)  

---


A discussão em torno do Scion, o sistema interno de controle de versão que a Anthropic colocou de pé em cinco meses, começou como uma briga pública sobre apropriação de código aberto. Rain, engenheira que trabalhou no Sapling e no Mononoke dentro da Meta, apontou o óbvio: o Scion não apenas aproveitou lições aprendidas, ele copiou a modelagem de dados e a arquitetura do Mononoke quase ponto a ponto, com ex-engenheiros da Meta direcionando modelos de linguagem para cuspir a implementação em tempo recorde. Do outro lado, vozes influentes como Simon Willison defenderam que a menção ao Sapling já bastava e que tentar empurrar um milhão de linhas de código como contribuição para o projeto original seria inviável.

Essa discussão sobre boas maneiras no ecossistema de software livre é barulhenta, mas ela esconde a parte técnica que realmente interessa a quem lidera infraestrutura: o momento exato em que o Git quebra em monorepos colossais e o preço silencioso que se paga ao adotar uma camada virtualizada de código.

Eu acompanhei os dois lados dessa troca de farpas. A posição de que a Anthropic agiu com desonestidade intelectual ao disfarçar uma cópia como uma grande inovação própria tem respaldo na realidade. O design do Mononoke foi uma resposta extremamente contrária ao padrão da indústria anos atrás, desenhado para resolver uma dor específica que quase ninguém tinha fora das grandes empresas de tecnologia. Tratar essa arquitetura como mero detalhe de rodapé é deselegante. 

Por outro lado, quem senta na cadeira de liderança técnica entende o argumento pragmático de Simon. Tentar alterar o upstream do Mononoke, um projeto com governança engessada e dependências profundas do ambiente interno da Meta, teria consumido o dobro do tempo e entregue metade dos resultados que a equipe da Anthropic precisava internamente.

O problema é que os dois lados ignoram a pergunta que qualquer engenheiro responsável deveria fazer antes de se encantar com esse feito: por que diabos alguém decide reescrever o servidor de controle de versão em vez de atacar o problema na raiz?

## O ponto de ruptura do Git tradicional

O Git é uma ferramenta distribuída brilhante para projetos normais, mas seu modelo conceitual tem limites físicos claros. Ele assume que cada cliente local vai armazenar um grafo acíclico dirigido completo, ou pelo menos fatias pesadas dele, em arquivos de pacote compactados (os conhecidos packfiles). 

Quando um repositório atinge centenas de gigabytes de código e milhões de commits gerados tanto por humanos quanto por pipelines automatizados, o modelo desmorona. O comando `git status` precisa inspecionar o estado de centenas de milhares de nós no sistema de arquivos local. O índice do Git vira um gargalo de concorrência com travas constantes. Clonar o projeto passa a exigir dezenas de gigabytes de download e minutos de processamento de CPU para desempacotar objetos. 

Pior ainda: no lado do servidor, gerar diffs e calcular árvores de pacotes sob demanda consome memória e I/O de disco em níveis que inviabilizam a operação sem máquinas gigantescas dedicadas exclusivamente a responder requisições de transporte do Git.

Muitas empresas tentam contornar isso com remendos: clones rasos com `--depth 1`, checkout esparso e filtros de blob pelo Git LFS. Esses recursos ajudam a empurrar o problema com a barriga por alguns anos, mas não mudam a premissa de que o Git foi desenhado para agir sobre um sistema de arquivos POSIX local, onde a busca em disco é barata e a rede é usada apenas para sincronizar lotes eventuais.

## A promessa do Mononoke e a tentação do Scion

A arquitetura que a Meta criou com o Mononoke, e que a Anthropic reproduziu no Scion, joga fora o modelo tradicional de arquivos empacotados e divide o controle de versão em duas camadas bem distintas:

```
[ Cliente local: FUSE / Virtual FS ]
                  │
                  ▼ (requisições de nós sob demanda)
┌────────────────────────────────────────────────────────┐
│ Servidor Mononoke / Scion                              │
│                                                        │
│  ┌────────────────────────┐  ┌──────────────────────┐  │
│  │ Metadados (árvores)    │  │ Blobs (conteúdo)     │  │
│  │ Banco distribuído / KV │  │ Storage de objetos   │  │
│  └────────────────────────┘  └──────────────────────┘  │
└────────────────────────────────────────────────────────┘
```

Nesse desenho, o cliente não faz clone de verdade. Ele monta uma estrutura virtual no sistema de arquivos, frequentemente via FUSE ou extensões de kernel, que lista os diretórios como se tudo estivesse ali. Quando um editor abre um arquivo ou o compilador lê um módulo, o cliente busca apenas aquele nó específico no servidor.

No servidor, os metadados do grafo (commits, árvores de diretórios e ponteiros) moram em bancos distribuídos de baixa latência, enquanto o conteúdo bruto dos arquivos (os blobs) fica armazenado em storages de objetos baratos, como o S3 ou sistemas equivalentes em disco.

No papel, isso resolve a escala infinita. O desenvolvedor tem a ilusão de navegar em um monorepo de vários terabytes sem ocupar espaço em disco, e a ingestão de código automatizado por agentes de inteligência artificial pode cuspir commits sem sufocar o servidor com empacotamento de objetos.

## O imposto invisível da virtualização

O que os defensores desse modelo esquecem de mencionar é a dívida operacional que nasce no segundo em que você implementa essa arquitetura. 

Primeiro, você troca a latência previsível do SSD local por dependência direta da rede interna. Se a conexão oscila, se o storage de objetos tem pico de latência ou se o serviço de metadados sofre contenção de leitura, o desenvolvedor trava no meio de um salvamento de arquivo no editor. Comandos simples de terminal deixam de ser chamadas de sistema locais e passam a disparar dezenas de chamadas RPC remotas.

Segundo, a complexidade de manter consistência de cache entre milhares de nós de compilação remota e estações locais é brutal. O Git tradicional é resiliente justamente porque é burro: se o arquivo está no disco, ele está lá. Em um sistema virtualizado, uma falha de sincronização no driver de sistema de arquivos gera arquivos fantasmas, corrupção silenciosa de builds e horas perdidas depurando se o erro veio do código ou da camada de abstração do repositório.

A Anthropic colocou sete engenheiros para reescrever isso em cinco meses com o auxílio de Claude porque a escala de código gerado por testes sintéticos e automações internas deles provavelmente estrangulou o Git padrão. Eles têm capital e pessoal de sobra para manter uma infraestrutura sob medida rodando 24 horas por dia.

Para qualquer time operando no mundo real, assumir a sustentação de um sistema de controle de versão próprio baseado nessa premissa é uma das decisões mais perigosas que um time de engenharia pode tomar. 

Antes de sonhar com servidores inspirados no Mononoke para escapar da lentidão do Git, o caminho racional continua sendo a disciplina arquitetural: quebrar monólitos inchados em fronteiras de domínio claras, usar sparse-checkout de verdade, remover lixo binário do histórico e tratar dependências como pacotes versionados. Replicar a arquitetura da Meta ou da Anthropic em cinco meses pode impressionar nas redes sociais, mas a conta da manutenção chega toda semana, e ela nunca é paga com código gerado por inteligência artificial.

## Fontes

- [https://sunshowers.io/posts/anthropic-mononoke/](https://sunshowers.io/posts/anthropic-mononoke/)
