Блог

Вайбкодинг: Как сделать бота в Телеграме за 2 часа?

Я — основатель и руководитель компании Abistep, где мы создаём онлайн-продукты: сайты, Telegram-ботов и мини-приложения. В последнее время мы активно используем гибридный формат разработки (ИИ + кастом). ИИ уже заменил нам дизайнеров, UX-специалистов и всё чаще берёт на себя написание кода. Разработчики в этом процессе подключаются на следующем этапе: берут код, сгенерированный нейросетями, проверяют его, дорабатывают, правят и расширяют.

Сам я не разработчик — скорее менеджер с уклоном в маркетинг. В 2025 году я всё чаще слышал про вайбкодинг и видел, как люди «играются» с программированием через нейросети. Мне стало интересно это направление, я начал пробовать — и довольно быстро втянулся.

Для тех, кто не знаком с термином: вайбкодинг — это способ создавать программы и сервисы без знания классического программирования, управляя процессом через логику, смысл и диалог с ИИ. Ты описываешь задачу текстом, а ИИ берёт на себя техническую реализацию.
Итак, мне понадобился Telegram-бот, который автоматически выдаёт материалы (чек-листы, PDF, ссылки) по кодовому слову.

До этого у меня было два варианта:

— отправлять материалы людям вручную;

— использовать конструктор ботов.

У меня уже был бот, собранный на конструкторе, за который приходилось платить 1000 рублей в месяц. При этом функционал был довольно простым. В какой-то момент я поймал себя на мысли:

«Почему я каждый месяц плачу за то, что потенциально могу сделать сам?»

Так я и решил собрать этого бота самостоятельно — с помощью ИИ и вайбкодинга.

Два часа на запуск: как распределилось время

Весь процесс уложился примерно в два часа и был разбит на два ключевых этапа:

— Первый час — архитектура и техническое задание
— Второй час — генерация кода и отладка

Именно такой порядок оказался критически важным. Одна из самых частых ошибок новичков — сразу просить ИИ «написать бота». С таким подходом получить адекватный результат гораздо сложнее.

Причина довольно простая и известная — контекстный лимит нейросетей:
— чем длиннее и хаотичнее диалог, тем хуже итог;
— без чёткого ТЗ ИИ начинает додумывать архитектуру за вас;
— в итоге получается не проект, а набор предположений.

На практике гораздо эффективнее сначала использовать ИИ как архитектора, а уже потом — как исполнителя.

Шаг 1. Подготовка технического задания с помощью ИИ

Техническое задание не писалось вручную и не держалось «в голове». Вместо этого в нейросеть были переданы сырые требования в свободной форме:

— логика поведения бота на каждом этапе (старт, выдача материалов, подписка);
— сценарии нестандартных действий пользователя;
— конкретный технологический стек, чтобы избежать размытых решений.

Ключевой промпт выглядел так:
Важно — попросить ИИ найти слабые места и задать уточняющие вопросы, и только после этого переходить к составлению пошагового плана реализации.

Далее процесс шёл в несколько итераций «вопрос–ответ». ИИ уточнял логику, пограничные сценарии и технические детали, а мои ответы постепенно дополняли и проясняли требования.

В итоге структура ТЗ выглядела так:
1.Стек:

  • Python 3.11+
  • aiogram 3.x
  • MongoDB — основное хранилище
  • Redis — кэш подписки
  • Docker + Docker Compose

2.Логика бота:

  • /start → приветствие и меню
  • ввод кодового слова → описание материала
  • задержка 2 секунды
  • запрос email (FSM)
  • проверка подписки на канал
  • выдача файла или запрос подписки

3.Состояния (FSM):

  • waiting_for_email
  • waiting_for_subscription

4.Хранение данных:

  • коллекция leads в MongoDB
  • user_id, email, статус подписки, количество скачиваний

5.Логирование:

  • INFO / ERROR / DEBUG
  • отдельная папка с логами внутри Docker
Это уже был полноценный технический документ, а не абстрактное описание идеи. В таком виде его можно сразу отдавать в разработку — как человеку, так и ИИ.

Шаг 2. Генерация кода по готовому ТЗ

Подготовленное ТЗ я загрузил в среду разработки с ИИ-ассистентом — в моём случае это был Google Antigravity. Когда у модели есть чёткая архитектура и пошаговые инструкции, она перестаёт фантазировать и начинает генерировать вполне рабочую основу продукта.

На этом этапе ИИ закрыл большую часть рутины:

  • структуру проекта,
  • базовую бизнес-логику,
  • обработчики событий,
  • взаимодействие с API.
Почему именно Google Antigravity?

Я выбирал между Cursor, Claude Code и Google Antigravity. В итоге начал с последнего по нескольким причинам:

  • это единая экосистема Google;
  • удобно работать с файлами и проектной структурой;
  • есть поддержка кодовых блоков и логических шагов;
  • можно использовать разные модели;
  • и важный плюс — более частое обновление лимитов токенов Gemini по сравнению с конкурентами, что сильно упрощает итерации.

По факту, я просто начал с него — и он полностью закрыл мои задачи.

Шаг 3. Финальная проверка и отладка

Несмотря на высокую скорость генерации, ИИ не заменяет разработчика полностью. С первого запуска бот не заработал корректно. Однако благодаря заранее внедрённому логированию причина ошибки была найдена довольно быстро.

Логирование было заложено ещё на этапе ТЗ — это было осознанное требование, а не инициатива ИИ.

Пример строки из лога:
2024-11-18 21:43:12 INFO User 123456789 selected keyword: "Система"

Логи указали на проблему с уникальным ключом бота — использовался токен от старого, уже активного инстанса.

Решение заняло не больше 10 минут:

  • просмотр логов;
  • отключение старого инстанса;
  • генерация нового ключа;
  • обновление переменных окружения.

После этого бот стабильно заработал — без костылей, ручных правок и дальнейших сбоев, полностью соответствуя логике, заложенной на этапе архитектуры.

Текущий статус проекта

Сейчас бот работает, он запущен в Docker на локальном сервере, а я продолжаю добавлять:

  • ключевые слова,
  • чек-листы,
  • и планирую сделать админку, чтобы использовать бота как мини-конструктор.

После этого — деплой в продакшен.

Гибридная разработка как новая норма

Этот кейс наглядно показывает, как работает гибридный подход к разработке:

  • человек задаёт архитектуру в начале;
  • ИИ быстро создаёт основу продукта;
  • разработчик подключается на этапе проверки и исправления критических ошибок.

В результате получается рабочий продукт за вечер, а не за неделю. Экономия времени достигается не за счёт «магии ИИ», а благодаря правильному распределению ролей между человеком и ИИ.

Вывод

ИИ сильно ускоряет разработку, если использовать его не наобум, а по шагам. Когда есть понятное ТЗ, продуманная логика и финальная проверка, идеи быстро превращаются в работающие продукты — без хаоса и сюрпризов.

И напоследок — три “совета другу”, который хочет повторить мой опыт:

1.Сначала опиши логику словами:
Кто что нажимает → что отвечает бот → какие есть ветки. Без этого ИИ будет гадать.

2.Попроси ИИ задавать вопросы, а не писать код:
Лучший промпт: «Действуй как Senior Developer. Проанализируй требования, найди слабые места, задай уточняющие вопросы — и только потом составь план».

3.Делай функционал по шагам:
Один сценарий = один чат / одна итерация. Не пытайся «сделать всё сразу» — получишь кашу.