Вайб-гайд · 13 июля 2026
Базовые понятия: LLM, токены, API, ключи, webhooks, деплой
Базовые понятия: LLM, токены, API, деплой
Короткий словарь «чтобы понимать, что происходит», без лишней теории.
| Термин | Что это простыми словами |
|---|---|
| LLM | ИИ, который генерирует текст и код по запросу. Может писать уверенно, но иногда неправильно («галлюцинации»). |
| Промпт | Твоя инструкция модели. Качество зависит от ясности контекста, цели, ограничений и формата. |
| Токены | «Кусочки текста», которыми модель считает объём. От токенов зависят лимиты и стоимость. |
| API | Способ, которым программы «разговаривают» друг с другом — набор правил для интеграции. |
| REST API | Самый частый формат API в вебе: правила поверх HTTP. |
| API key | «Ключ от двери» к API. Нельзя светить в коде на фронте, в публичном репо и скриншотах. |
| Webhook | «Обратный звонок»: сервис сам дёргает твой URL при событии (оплата, заявка, PR). |
| Deploy | Выложить приложение так, чтобы оно работало по ссылке для пользователей. |
| Preview / Production | Два окружения: preview для проверки, production для реальных пользователей. |
| Environment variables | «Настройки проекта снаружи кода»: адреса, режимы, ключи. |
| Git | «Система сохранений» для кода: фиксирует версии, позволяет откатиться. |
| База данных | Организованное хранилище данных приложения: пользователи, заказы, контент. Без базы данных приложение «забывает» всё при перезагрузке. |
| No-code / Low-code | Визуальные платформы: no-code почти без кода, low-code — с минимумом кода. |
Подробнее о ключевых понятиях
LLM — что это и почему тебе важно
LLM (large language model) — это модель, которая «по сути» учится продолжать текст: на вход — текст, на выход — следующий текст. Из этого вырастают объяснения, код, планы.
Для вайб-кодинга важно понимать одно: LLM не хранит «истину» и не хранит «проект» в голове. Она каждый раз работает с тем, что попало в контекст окна (ввод, файлы, правила, логи). Поэтому качество сильно зависит от контекста и его чистоты.
Токены — «валюта» и лимит контекста
Токены — это «кирпичики текста», которыми модель оперирует. Считаются и в твоём вводе, и в ответе.
- Токены = деньги (в API) и скорость.
- Токены = лимит «рабочей памяти» модели.
Правило-на-пальцах (подсказка OpenAI): ~1 token ≈ 4 символа английского текста, ≈ ¾ слова.
API — что это и зачем оно почти везде
API — это «договор» между программами: как одна программа запрашивает данные/действие, и что получит в ответ.
В вайб-кодинге API важно по двум причинам:
- Большинство интеграций (платежи, почта, CRM, аналитика, базы) — через API.
- Агенты (Lovable, n8n, твой backend) «разговаривают» через HTTP-запросы и webhooks.
API-ключи и токены доступа
Ключ/токен — это «пароль» для программы. Если его украли — злоумышленник может тратить твой лимит/деньги, читать/писать данные, делать действия от имени твоего сервиса.
Практика хранения:
- Не хранить ключи во фронтенде (они видны пользователю).
- Хранить в секретах/secret store или как минимум в env vars на сервере/платформе деплоя.
Webhooks — как сервисы «звонят» друг другу
Webhook — это когда сервис сам отправляет HTTP-запрос на твой URL при событии. В GitHub это формулируется прямо: выбираешь URL и события, GitHub отправляет HTTP-request с данными события.
Важно: webhooks надо проверять (подпись/секрет), иначе любой сможет «подделать событие». GitHub рекомендует X-Hub-Signature-256 (HMAC-SHA256).
Деплой — что это по-простому
Деплой — это когда твой код превращается в «живой сайт/приложение по ссылке». В Vercel деплой — результат успешной сборки, и каждый деплой получает уникальный URL.
Идеальная «новичковая» схема окружений:
- Development: локально или в dev-среде
- Preview/Staging: проверить в живой среде, но не прод
- Production: то, что видят пользователи
База данных — зачем она нужна
База данных — это место, где приложение хранит данные: пользователей, заказы, посты, настройки. Без базы данных всё, что ты ввёл, исчезает при закрытии страницы.
Два основных типа для новичка:
- Реляционные (SQL) — данные в таблицах со строгой структурой. Примеры: PostgreSQL (Supabase), MySQL. Подходят для большинства MVP.
- Документные (NoSQL) — данные в «документах» (как JSON). Пример: Firebase Firestore. Гибче по структуре, но сложнее контролировать целостность.
Что важно понять:
- Таблица — набор записей одного типа (например, таблица «пользователи»).
- Строка (row) — одна запись (один пользователь).
- Столбец (column) — одно поле (имя, email, дата регистрации).
- Запрос (query) — команда к базе: «дай мне всех пользователей, зарегистрированных сегодня».
В вайб-кодинге базу обычно не разворачиваешь сам — используешь BaaS-сервис (Supabase, Firebase), который даёт базу + API + авторизацию «из коробки».
(Я сознательно не углубляюсь в «архитектуры», «микросервисы» и прочее — новичку это рано. Сначала нужен результат и правильные привычки.)