Como refatoramos 80k linhas do Verboo Chat com mimo-v2.5

O backend do Verboo Chat tinha dois anos, 80.000 linhas de TypeScript e um arquivo router.ts com 4.200 linhas que nenhum dev queria abrir.

Tentamos refatorar três vezes. Nas três, o processo morreu da mesma forma: o agente de programação analisava 15 a 20 arquivos por sessão, tomava decisões de arquitetura num PR e esquecia o contexto no seguinte. O codebase ficava mais confuso depois de cada tentativa.

Na quarta tentativa, usamos o Verboo Code com mimo-v2.5 e seu contexto de 1 milhão de tokens. Carregamos o backend inteiro numa só sessão. O mapeamento que levaria 3 semanas manual ficou pronto em 8 horas, com 0 conflitos de arquitetura nos 19 PRs que se seguiram.

Por que as tentativas anteriores falharam

Não era falta de modelo bom. Claude Sonnet e Cursor geravam código excelente nos arquivos que viam. O problema era estrutural: nenhum conseguia ver o backend inteiro de uma vez.

A anatomia do monolito:

218 rotas distribuídas em 6 arquivos de router
14 domínios de negócio misturados: billing, sessions, agents, webhooks, usuários, integrações, templates e outros
Cerca de 40 funções utilitárias compartilhadas sem namespace claro
Cobertura de testes: 41%

Quando carregávamos 20 arquivos e pedíamos "mapeie os domínios", a resposta era boa. Mas na sessão seguinte, o agente não sabia que BillingService tinha sido separado de SubscriptionManager na sessão anterior. No terceiro PR, ele propunha unir o que tínhamos acabado de separar.

Sem memória arquitetural entre sessões, não se refatora um monolito. Se embaralha.

O que 1 milhão de tokens muda na prática

A lógica padrão de refator com IA assume escassez de contexto: você divide o codebase em pedaços, passa cada chunk para o agente e tenta manter coerência manualmente entre sessões. Funciona para alterações cirúrgicas. Quebra para refatorações sistêmicas.

O mimo-v2.5 tem janela de 1 milhão de tokens. O nosso backend de 80.000 linhas, incluindo tipos, comentários e testes, ocupa aproximadamente 320.000 tokens. Cabe numa sessão com 680.000 tokens de sobra para o diálogo.

Abordagem com 200k de contexto	Abordagem com mimo-v2.5 (1M)
Divide o codebase em chunks	Carrega tudo de uma vez
Decisões de arquitetura por chunk	Visão global antes de qualquer mudança
Múltiplas sessões com perda de contexto	Mapa de domínios como referência permanente
Conflitos de arquitetura entre PRs	0 conflitos: o plano existe antes dos PRs

Como fizemos, passo a passo

1. Selecionando o modelo no CLI

O Verboo Code oferece 11 modelos hoje. Para contexto longo e análise arquitetural, o mimo-v2.5 é o mais indicado. Para selecioná-lo na sessão:

cd /path/to/verboo-chat-backend
verboo

Dentro da sessão interativa:

/model mimo-v2.5

2. Mapeamento completo do codebase

Com o modelo selecionado, pedimos o mapeamento antes de tocar em qualquer arquivo:

Leia todos os arquivos em src/.
Identifique os domínios de negócio, as responsabilidades de cada módulo
e onde há acoplamento indevido entre domínios.
Retorne: domínio → arquivos → dependências externas.

O resultado: 14 domínios mapeados com interdependências. O mimo-v2.5 identificou um ciclo que três tentativas anteriores não tinham percebido: session-manager importava de billing, que importava de agent-config, que importava de session-manager.

Dependência circular. Invisível quando você vê 20 arquivos por vez. Óbvia quando você vê os 80.000 linhas de uma vez.

3. Plano de extração antes de qualquer PR

Com o mapa em mãos, pedimos a sequência de extração:

Com base no mapeamento acima, proponha a sequência de extração de módulos
que minimiza risco. Ordene do módulo com menos dependências externas
para o mais acoplado. Inclua o que cada PR deve conter e o que NÃO pode ser alterado.

Resultado: sequência de 19 PRs, começando pelo módulo notification (sem dependências externas) e terminando com session-manager (dependido por 11 módulos). Esse plano virou o documento de referência que toda sessão subsequente recebia no início.

Essa abordagem é uma variação do padrão Strangler Fig descrito por Martin Fowler: você não reescreve o monolito de uma vez, extrai peça por peça enquanto o sistema continua funcionando. Com contexto completo, a análise inicial que identificaria os módulos e a ordem de extração sai em horas, não semanas.

4. Execução por módulo com mapa de referência

Para cada módulo, nova sessão com mimo-v2.5, colando o mapa no início:

[Cola o mapa de domínios gerado na etapa de mapeamento]

Extraia o módulo 'notification' conforme o plano acima.
Crie os arquivos em src/modules/notification/.
Mova as funções mapeadas, atualize os imports e escreva os testes unitários.
Não crie dependência de módulos que ainda não foram extraídos.

Essa última instrução foi decisiva. Com o contexto completo do codebase, o agente sabia exatamente o que ainda estava acoplado e o que já estava limpo. Nas tentativas anteriores, sem o mapa, ele criava novas dependências porque "parecia natural".

5. Revisão automática a cada PR

Depois de cada PR, rodamos uma sessão de revisão pedindo ao agente para verificar se a extração havia introduzido alguma nova dependência indevida. Com 1M de contexto, ele analisava o PR inteiro mais o restante do codebase em simultâneo.

Regressões de acoplamento detectadas antes do merge: 3 nos 19 PRs. Com contexto limitado, vendo apenas os arquivos do PR: 0 detecções nas tentativas anteriores.

Resultados medidos

Após os 19 PRs de extração:

Cobertura de testes: 41% para 73%
Arquivo maior do backend (router.ts): 4.200 linhas para 340 linhas
Tempo de mapeamento arquitetural: 8 horas (estimativa manual: 3 semanas)
Conflitos de arquitetura entre PRs: 0
Tokens estimados consumidos em todo o processo: ~14 milhões

Esse último número tem contexto importante. Com 14M de tokens no Claude Code Max (antes da atualização de preço recente), o custo seria em torno de US$42. Com o Verboo Code, R$ 0 de custo extra, porque tokens ilimitados são o modelo base, não uma exceção.

O ROI real não é só o dinheiro economizado em tokens. É que o medo do custo nunca entrou na equação. Refatoramos sem pausar para calcular se essa análise valia a pena pelo preço.

Quando essa abordagem faz sentido

1 milhão de contexto não resolve tudo. Funciona especialmente bem em:

Codebases entre 30k e 300k linhas: grande demais para análise manual, pequeno o suficiente para caber no contexto de uma sessão
Refatorações arquiteturais: extração de módulos, migração de framework, limpeza de acoplamento circular
Onboarding técnico: novo dev entende o sistema inteiro numa primeira sessão com o agente
Auditoria de segurança: o modelo detecta padrões inseguros em todo o codebase de uma vez

Para codebases acima de ~1M de tokens (monorepos grandes, projetos enterprise), ainda é necessário dividir por pacote ou serviço antes. O padrão Strangler Fig ainda se aplica, só que agora você executa cada extração com contexto completo dentro do pedaço.

Para comparação de janelas de contexto e qualidade de raciocínio dos modelos disponíveis hoje, o Artificial Analysis mantém um índice atualizado com benchmarks de contexto longo, incluindo dados sobre o mimo-v2.5 e os modelos concorrentes.

O que vem a seguir nesta série

Com o backend modularizado, o próximo passo foi code review automático dos 19 PRs via Verboo Code. Esse processo cobriu cerca de 40% do trabalho manual de revisão do time. Esse resultado vira o próximo post desta série de dogfooding.

Se quiser ver como times que não têm cap de tokens trabalham diferente no dia a dia, leia 57 bilhões de tokens no Verboo Code: 5 padrões de quem não tem cap.

Quer rodar isso sem cap de tokens? Conheça o Verboo Code, agente de programação com tokens ilimitados.