Главное Авторские колонки Вакансии Вопросы
97 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

Я основатель и руководитель компании Абистеп, где мы делаем онлайн-продукты: сайты, Telegram ботов и мини-приложения.В последнее время мы активно применяем гибридный формат разработки (ИИ+ кастом), где ИИ нам заменил дизайнеров, UX и все больше и больше написание кода.
Мнение автора может не совпадать с мнением редакции

В Абистеп разработчики подхватывают написанный нейронками код и работают с ним, редактируют, правят и дополняют.


Сам я не разработчик, а больше менеджер с уклоном в маркетинг. В 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

Это уже структурированный технический документ, а не абстрактное описание идеи. Такой формат сразу подходит для передачи в разработку — как человеку, так и ИИ.


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

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

На этом этапе ИИ закрыл большую часть рутинной работы: структуру проекта, базовую логику, обработчики событий и взаимодействие с API.

Про инструмент — почему Google Antigravity?

Я выбирал между Cursor, Claude Code и Google Antigravity.

В итоге начал с Google Antigravity, потому что:

— это единая экосистема Google;

— удобно работать с файлами и проектной структурой;

— есть поддержка кодовых блоков и логических шагов;

— можно использовать разные модели;

— и важный плюс — более частое обновление лимитов токенов Gemini по сравнению с конкурентами, что сильно упрощает итерации.

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


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

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

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

Пример реальной строки из лога:

2024-11-18 21:43:12 INFO User 123456789 selected keyword: «Система»

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

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

— проверка логов;

— отключение старого инстанса;

— генерация нового ключа;

— обновление переменных окружения.

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


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

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

— ключевые слова,

— чек-листы,

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

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

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

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

— человек задаёт архитектуру в начале;

— ИИ быстро создаёт основу продукта;

— разработчик подключается на этапе проверки и исправления критических ошибок.

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

Вывод

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

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

1. Сначала опиши логику словами:

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

2. Попроси ИИ задавать вопросы, а не писать код:

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

3. Делай функционал по шагам:

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.