Claude Code + Python + Telegram: мой рабочий стек автоматизации

Каждый мой боевой проект — от личного ассистента до ботов для клиентов — стоит на одной и той же связке. Не потому что я не смотрел на альтернативы, а потому что именно эта комбинация даёт контроль над тем, что происходит внутри.

Почему не no-code

Конструкторы вроде n8n или Zapier хороши для простых цепочек: «пришло сообщение → отправить в таблицу». Но как только логика усложняется — нужно ветвление по контексту, память диалога, состояние пользователя, — визуальные схемы превращаются в нечитаемый клубок узлов. Код в этот момент остаётся кодом: его можно версионировать, тестировать и объяснить самому себе через полгода.

Из чего состоит стек

Claude Code — не только пишет код, но и выступает оркестратором на этапе разработки: собирает архитектуру, чинит баги, ведёт рефакторинг. Я формулирую задачу — он реализует, я проверяю на реальном сценарии.

Python + aiogram — слой самого бота: обработка сообщений, FSM-диалоги (рассылки, квизы, многошаговые воронки), клавиатуры. Aiogram даёт достаточно структуры, не навязывая лишнего.

SQLite — состояние: пользователи, лиды, история диалога, события воронки. Для нагрузки одного бизнеса — более чем достаточно, и не нужен отдельный сервер БД.

APScheduler — всё, что происходит по расписанию: автоворонка (напоминание на день +1, дожим на день +3), утренний дайджест, ежедневный отчёт владельцу.

systemd на VPS — деплой. Один процесс на сервис, автоперезапуск при падении, логи через journalctl. Не самое модное решение, зато предсказуемое: я точно знаю, что происходит с процессом в любой момент.

Где стек даёт трещину

Free-tier у managed-сервисов вроде Supabase — реальная боль: проект без активности ставится на паузу примерно через неделю, и восстановить доступ на анонимном ключе не получится — нужен service_role key. Это не аргумент против Supabase, но повод не полагаться на бесплатный план там, где важна непрерывность.

Второе ограничение — ручной деплой. Никакого CI/CD, обновление кода на VPS — это git pull и перезапуск сервиса руками. Для одного разработчика, ведущего 5-6 проектов, это осознанный компромисс: настройка полноценного пайплайна дороже, чем время, которое она экономит на этом масштабе.

Когда стоит взять другой стек

Если automation — это правда линейная цепочка без сложной логики (например, «новая строка в таблице → сообщение в Slack»), no-code решит задачу быстрее, чем разработка с нуля. Я использую этот стек там, где нужна память, ветвление и контроль над тем, что именно бот отвечает клиенту — то есть почти везде в моих проектах.