Основатель уволил разработчиков и доработал CRM с Claude Code: 22 набора тестов

Знакомая ситуация для любого основателя: продукт строили годами, команду пришлось распустить, а код остался. Автор этой истории несколько лет делал CRM для работы с лидами в Telegram. Когда разработчиков уволили, он оказался один на один с системой, которую не писал. Он описал на Habr, как выходил из этого с помощью Claude Code.

Что досталось в наследство

Система состоит из шести сервисов: админка на React, главный бэкенд на FastAPI с MongoDB и Redis, фоновый движок рассылок, модуль работы с живыми Telegram-аккаунтами через Telethon, обогащение лидов и приём заявок с сайта. Поверх этого Docker и GitLab CI.

Логика продукта тоже осталась от команды. Это шесть блоков: приветствие новых участников групп, кампании по шаблону, повторное сообщение тем, кто не ответил, интро-группы, холодные сообщения и анализатор активных участников для персонального касания.

Есть и неприятные находки. Во всех шести репозиториях не было ни одного автотеста, хотя pytest значился в зависимостях. В трёх вспомогательных скриптах лежали пароли от базы. Самая серьёзная проблема нашлась не в коде: у всех лидов была одна база MongoDB, и её копии не существовало. Код можно поднять из GitLab, а данные нельзя.

Как работал Claude Code

Первым шагом был аудит. Токен в GitLab был только на чтение, так что оригинал не пострадал. Claude склонировал 10 репозиториев, прочитал README, вытащил связи между сервисами из env-ключей и docker-compose и нарисовал карту системы.

Второй шаг оказался неожиданным. Автор собирался писать новую CRM с нуля, но после аудита ассистент сказал, что этого делать не надо: система написана нормально, её нужно укреплять. Сначала тесты и секреты, потом изменения маленькими блоками.

Третий шаг: вокруг старой системы появился второй слой на локальных SQLite-базах с лидами, личными перепиской и чатами. Сейчас в базе лидов около 99 тысяч записей, а в новом слое 22 набора тестов.

Четвёртый шаг: ассистент и автор вместе нашли пробелы в продукте. Все блоки работали только наружу, от автора к человеку. Не было сценария для тех, кто пришёл сам, не было поля «чем человек полезен» и даты, после которой карточка лида устаревает.

Как устроен процесс

Задачу автор ставит своими словами, часто голосом. Claude открывает отдельную сессию, читает код и реальные данные и объясняет, что изменится и что может сломаться. Затем пишет небольшой скрипт и тесты. Результат дополнительно смотрят другие модели: Codex, Grok и Gemini. Автору так кажется надёжнее.

Все отправки в Telegram идут через safe_send.py, а budget.py считает лимиты, обычно 5 сообщений в сутки на аккаунт. Ночью CRM обслуживает себя сама: скачивает переписки, пересчитывает, какие лиды тёплые, и напоминает об обещанных датах. Это обычные скрипты без LLM, поэтому токены почти не тратятся, а доработка идёт по подписке.

Ограничения и вывод

Статья написана от первого лица и без независимой проверки. Цифр экономии нет, есть только слова «намного дешевле». Сам автор честно говорит, что программисты построили продукт, а ИИ его прочитал и улучшил.

Практически полезны три вещи. Первая: прежде чем переписывать унаследованный код, пусть агент сделает аудит и карту сервисов в режиме только чтения. Вторая: сначала тесты и бэкап данных, потом новые функции. Третья: всё, что может работать без LLM, выносите в обычные скрипты. Так вы платите за ИИ только за разработку, а не за каждую ночную задачу. Для маленьких команд и одиночных основателей это рабочая схема, если есть дисциплина и страховка в виде тестов и лимитов.