Un fundador despidió a sus desarrolladores y mejoró su CRM con Claude Code: 22 conjuntos de pruebas

Una situación conocida para cualquier fundador: el producto se construyó durante años, hubo que disolver el equipo y el código quedó ahí. El autor de esta historia dedicó varios años a crear un CRM para trabajar con leads en Telegram. Cuando despidieron a los desarrolladores, se encontró solo frente a un sistema que no había escrito. Contó en Habr cómo salió de esa situación con ayuda de Claude Code.

Qué heredó

El sistema consta de seis servicios: un panel de administración en React, un backend principal en FastAPI con MongoDB y Redis, un motor de envíos en segundo plano, un módulo para trabajar con cuentas reales de Telegram mediante Telethon, el enriquecimiento de leads y la recepción de solicitudes desde el sitio web. Encima de todo esto, Docker y GitLab CI.

La lógica del producto también quedó del equipo. Son seis bloques: saludo a los nuevos miembros de los grupos, campañas por plantilla, un mensaje de seguimiento para quienes no respondieron, grupos de introducción, mensajes en frío y un analizador de miembros activos para un contacto personal.

También hubo hallazgos desagradables. En los seis repositorios no había ni una sola prueba automática, aunque pytest figuraba en las dependencias. En tres scripts auxiliares había contraseñas de la base de datos. El problema más grave no estaba en el código: todos los leads estaban en una sola base MongoDB y no existía ninguna copia. El código se puede recuperar desde GitLab, pero los datos no.

Cómo trabajó Claude Code

El primer paso fue una auditoría. El token de GitLab era de solo lectura, así que el original no corrió peligro. Claude clonó 10 repositorios, leyó los README, extrajo las relaciones entre servicios a partir de las claves env y docker-compose, y dibujó un mapa del sistema.

El segundo paso fue inesperado. El autor pensaba escribir un CRM nuevo desde cero, pero tras la auditoría el asistente le dijo que no hacía falta: el sistema estaba bien escrito y lo que había que hacer era reforzarlo. Primero pruebas y secretos, después cambios en bloques pequeños.

Tercer paso: alrededor del sistema antiguo apareció una segunda capa sobre bases SQLite locales con leads, correspondencia personal y chats. Ahora la base de leads tiene unos 99 mil registros y la nueva capa cuenta con 22 conjuntos de pruebas.

Cuarto paso: el asistente y el autor encontraron juntos huecos en el producto. Todos los bloques funcionaban solo hacia fuera, del autor hacia la persona. No había un escenario para quienes llegaban por su cuenta, ni un campo «en qué es útil esta persona», ni una fecha a partir de la cual la ficha del lead caduca.

Cómo funciona el proceso

El autor plantea la tarea con sus propias palabras, a menudo por voz. Claude abre una sesión aparte, lee el código y los datos reales, y explica qué cambiará y qué puede romperse. Después escribe un script pequeño y pruebas. El resultado lo revisan además otros modelos: Codex, Grok y Gemini. Al autor le parece más fiable así.

Todos los envíos a Telegram pasan por safe_send.py, y budget.py calcula los límites, normalmente 5 mensajes al día por cuenta. De noche el CRM se atiende solo: descarga conversaciones, recalcula qué leads están calientes y recuerda las fechas prometidas. Son scripts normales sin LLM, así que casi no se gastan tokens y el desarrollo se hace con suscripción.

Limitaciones y conclusión

El artículo está escrito en primera persona y sin verificación independiente. No hay cifras de ahorro, solo las palabras «mucho más barato». El propio autor admite con honestidad que los programadores construyeron el producto y la IA lo leyó y lo mejoró.

Tres cosas resultan útiles en la práctica. Primera: antes de reescribir código heredado, que el agente haga una auditoría y un mapa de servicios en modo de solo lectura. Segunda: primero pruebas y copia de seguridad de los datos, luego nuevas funciones. Tercera: todo lo que pueda funcionar sin LLM, llévelo a scripts normales. Así se paga por la IA solo en el desarrollo, no por cada tarea nocturna. Para equipos pequeños y fundadores en solitario es un esquema viable, si hay disciplina y una red de seguridad de pruebas y límites.