Вайбкодинг: Как сделать бота в Телеграме за 2 часа?
В Абистеп разработчики подхватывают написанный нейронками код и работают с ним, редактируют, правят и дополняют.

Сам я не разработчик, а больше менеджер с уклоном в маркетинг. В 2025 году я часто слышал про вайбкодинг и видел, как люди «балуются» с программированием через нейронки. Мне стало интересное направление вайбкодерства, я начал пробовать и меня затянуло.
Для тех, кто не знает, что такое вайбкодинг — это способ делать программы и сервисы не зная классического программирования, а управляя процессом через смысл, логику и общение с ИИ. Ты пишешь ИИ задание в виде текста и он начинает генерировать код.
Итак, мне нужен был Telegram-бот, который автоматически выдаёт материалы (чек-листы, PDF, ссылки) по кодовому слову.
До этого у меня было два варианта:
1. отправлять материалы людям вручную;
2. использовать конструктор ботов.
У меня уже был Telegram-бот, собранный на конструкторе. И за него приходилось платить 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 Это уже структурированный технический документ, а не абстрактное описание идеи. Такой формат сразу подходит для передачи в разработку — как человеку, так и ИИ. Подготовленное ТЗ было загружено в среду разработки с ИИ-ассистентом (в данном случае — Google Antigravity). Когда у модели есть чёткая архитектура и пошаговые инструкции, она перестаёт «фантазировать» и генерирует вполне рабочую основу продукта. На этом этапе ИИ закрыл большую часть рутинной работы: структуру проекта, базовую логику, обработчики событий и взаимодействие с API. Про инструмент — почему Google Antigravity? Я выбирал между Cursor, Claude Code и Google Antigravity. В итоге начал с Google Antigravity, потому что: — это единая экосистема Google; — удобно работать с файлами и проектной структурой; — есть поддержка кодовых блоков и логических шагов; — можно использовать разные модели; — и важный плюс — более частое обновление лимитов токенов Gemini по сравнению с конкурентами, что сильно упрощает итерации. По факту, я просто начал с него — и он закрыл все мои задачи. Несмотря на высокую скорость генерации, ИИ не заменяет разработчика полностью. С первого запуска бот не заработал корректно. Однако благодаря заранее внедрённому логированию причина ошибки была найдена быстро. Логирование было заложено сразу, ещё на этапе ТЗ. Это было осознанное требование, а не инициатива ИИ Пример реальной строки из лога: Логи указали на проблему с уникальным ключом бота — использовался токен от старого, уже активного инстанса. Решение заняло не больше 10 минут: — проверка логов; — отключение старого инстанса; — генерация нового ключа; — обновление переменных окружения. После этого бот стабильно заработал — без костылей, ручных правок и дальнейших сбоев, полностью соответствуя изначальной логике и сценарию, заложенным на этапе архитектуры. Сейчас бот работает, он запущен в Docker на локальном сервере, а я продолжаю добавлять: — ключевые слова, — чек-листы, — и планирую сделать админку, чтобы использовать бота как мини-конструктор. После этого — деплой в продакшен. Этот кейс наглядно показывает, как работает гибридный подход к разработке: — человек задаёт архитектуру в начале; — ИИ быстро создаёт основу продукта; — разработчик подключается на этапе проверки и исправления критических ошибок. В результате получается рабочий продукт за вечер, а не за неделю. Экономия времени достигается не за счёт «магии ИИ», а благодаря правильному распределению ролей между человеком и ИИ. ИИ сильно ускоряет разработку, если использовать его не наобум, а по шагам. Когда есть понятное ТЗ, продуманная логика и финальная проверка, идеи быстро превращаются в работающие продукты — без хаоса и сюрпризов. И напоследок — три «совета другу», который хочет повторить мой опыт: 1. Сначала опиши логику словами: Кто что нажимает → что отвечает бот → какие есть ветки. Без этого ИИ будет гадать. 2. Попроси ИИ задавать вопросы, а не писать код: Лучший промпт: «Действуй как Senior Developer. Проанализируй требования, найди слабые места, задай уточняющие вопросы — и только потом составь план». 3. Делай функционал по шагам: Один сценарий = один чат / одна итерация. Не пытайся «сделать всё сразу» — получишь кашу.


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

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

Текущий статус проекта
Гибридная разработка как новая норма
Вывод