Fundador demitiu desenvolvedores e aprimorou o CRM com Claude Code: 22 conjuntos de testes

Uma situação conhecida de qualquer fundador: o produto foi construído ao longo de anos, a equipe precisou ser dispensada e o código ficou. O autor desta história passou vários anos criando um CRM para trabalhar com leads no Telegram. Quando os desenvolvedores foram demitidos, ele ficou sozinho diante de um sistema que não escreveu. Ele contou no Habr como saiu dessa situação com a ajuda do Claude Code.

O que ele herdou

O sistema é composto por seis serviços: um painel administrativo em React, um backend principal em FastAPI com MongoDB e Redis, um motor de disparos em segundo plano, um módulo para trabalhar com contas reais do Telegram via Telethon, o enriquecimento de leads e a captação de solicitações do site. Por cima disso, Docker e GitLab CI.

A lógica do produto também veio da equipe. São seis blocos: saudação a novos membros de grupos, campanhas por modelo, mensagem de acompanhamento para quem não respondeu, grupos de introdução, mensagens frias e um analisador de membros ativos para um contato pessoal.

Houve também descobertas desagradáveis. Nos seis repositórios não havia nenhum teste automatizado, embora o pytest constasse nas dependências. Em três scripts auxiliares havia senhas do banco de dados. O problema mais sério não estava no código: todos os leads ficavam em um único banco MongoDB, e não existia cópia dele. O código pode ser recuperado do GitLab, mas os dados não.

Como o Claude Code trabalhou

O primeiro passo foi uma auditoria. O token do GitLab era somente leitura, então o original não corria risco. O Claude clonou 10 repositórios, leu os READMEs, extraiu as relações entre os serviços a partir das chaves env e do docker-compose e desenhou um mapa do sistema.

O segundo passo foi inesperado. O autor pretendia escrever um CRM novo do zero, mas, após a auditoria, o assistente disse que não era preciso: o sistema estava bem escrito e precisava ser reforçado. Primeiro testes e segredos, depois mudanças em blocos pequenos.

Terceiro passo: em torno do sistema antigo surgiu uma segunda camada, em bancos SQLite locais com leads, correspondências pessoais e chats. Hoje a base de leads tem cerca de 99 mil registros, e a nova camada conta com 22 conjuntos de testes.

Quarto passo: o assistente e o autor encontraram juntos lacunas no produto. Todos os blocos funcionavam apenas para fora, do autor para a pessoa. Não havia cenário para quem chegava por conta própria, nem um campo «em que a pessoa é útil», nem uma data a partir da qual a ficha do lead fica desatualizada.

Como funciona o processo

O autor define a tarefa com suas próprias palavras, muitas vezes por voz. O Claude abre uma sessão separada, lê o código e os dados reais e explica o que vai mudar e o que pode quebrar. Depois escreve um script pequeno e testes. O resultado ainda é revisado por outros modelos: Codex, Grok e Gemini. Ao autor, isso parece mais confiável.

Todos os envios ao Telegram passam por safe_send.py, e o budget.py calcula os limites, normalmente 5 mensagens por dia por conta. À noite o CRM se mantém sozinho: baixa as conversas, recalcula quais leads estão quentes e lembra das datas prometidas. São scripts comuns sem LLM, por isso quase não se gastam tokens e o desenvolvimento roda na assinatura.

Limitações e conclusão

O artigo é escrito em primeira pessoa e sem verificação independente. Não há números de economia, apenas as palavras «muito mais barato». O próprio autor admite com honestidade que os programadores construíram o produto, e a IA o leu e o melhorou.

Três coisas são úteis na prática. Primeira: antes de reescrever código herdado, peça ao agente uma auditoria e um mapa de serviços em modo somente leitura. Segunda: primeiro testes e backup dos dados, depois novas funcionalidades. Terceira: tudo o que puder funcionar sem LLM, leve para scripts comuns. Assim, você paga pela IA apenas no desenvolvimento, não a cada tarefa noturna. Para equipes pequenas e fundadores solo, é um esquema viável, se houver disciplina e uma rede de segurança de testes e limites.