40 правил инженерного подхода к созданию продукта при вайбкодинге
Выжимка лекции «От вайбкодинга к инженерии»: сорок правил, которые превращают AI-агента из кнопки «сделай приложение» в часть рабочего процесса.
Эта статья - выжимка лекции “От вайбкодинга к инженерии”
Вайбкодинг может быть сильным инструментом, если использовать AI-агента не как магическую кнопку «сделай приложение», а как помощника внутри нормального инженерного процесса.
Главная ошибка — сразу просить AI писать код. Код — это только один этап разработки. До него должны быть идея, требования, архитектура и план. После него — проверка, безопасность, доработка, релиз и поддержка.
Инженерный подход к вайбкодингу строится на простой логике: сначала понять, что мы делаем, потом описать это, затем разбить на маленькие управляемые части, провести каждую часть через понятный жизненный цикл и только после этого считать задачу готовой.
Ниже — список правил, которые помогают создавать продукт с AI более осознанно, безопасно и управляемо.
1. Начинай не с кода, а с задачи продукта
Перед тем как просить AI писать код, нужно понять, что именно мы строим, для кого и какую проблему решаем.
Плохой подход:
«Сделай мне CRM».
Хороший подход:
«Мы делаем CRM для HR-агентства, чтобы рекрутеры могли хранить кандидатов, видеть статусы, оставлять комментарии и отслеживать историю общения».
AI должен понимать продуктовую цель, а не просто техническое действие.
2. Сначала собери требования
Идея продукта — это ещё не техническая задача. Нужно описать пользователей, сценарии, ограничения и критерии успеха.
Пример:
Если мы делаем форму заявки, нужно заранее определить:
какие поля есть;
какие поля обязательные;
куда отправляются данные;
что пользователь видит после отправки;
что происходит при ошибке;
какие данные нельзя принимать.
Без требований AI будет додумывать сам.
3. Фиксируй требования в документе
Не держи требования только в голове или в переписке. AI может забыть контекст, неправильно его восстановить или начать противоречить предыдущим решениям.
Пример:
Создай файл PRD.md, где описаны:
цель продукта;
аудитория;
ключевые сценарии;
основные функции;
ограничения;
что входит в первую версию;
что не входит в первую версию.
Такой документ становится единым источником истины для тебя и AI-агента.
4. Используй spec-driven подход
Spec-driven подход означает: сначала спецификация, потом код.
Спецификация — это чертёж задачи. Она объясняет AI, что нужно сделать, как это должно работать, какие есть ограничения и как понять, что задача готова.
Плохой подход:
«Сделай авторизацию».
Хороший подход:
«Сделай авторизацию по email и паролю. Нужны регистрация, вход, выход и защита приватных страниц. 2FA, восстановление пароля и вход через Google пока не делаем».
Чем яснее спека, тем меньше AI будет угадывать.
5. Не проси AI сделать всё приложение сразу
Большая задача без границ почти всегда приводит к хаосу. AI начинает принимать слишком много решений самостоятельно, смешивает уровни системы и может сломать то, что уже работает.
Плохой подход:
«Сделай маркетплейс».
Хороший подход:
«Сначала сделай первый vertical slice: пользователь видит список товаров, открывает карточку товара и добавляет товар в корзину».
Один маленький законченный кусок лучше, чем огромный недоделанный фундамент.
6. Работай vertical slice’ами
Vertical slice — это маленькая фича, сделанная от начала до конца через все слои продукта.
Пример:
Для CRM первый vertical slice — создание кандидата.
В него входит:
форма на фронтенде;
валидация данных;
API-метод;
запись в базу;
сообщение об успехе;
обработка ошибки;
базовая проверка результата.
Такой кусок можно протестировать, показать пользователю и улучшать дальше.
7. Не строй огромный фундамент до проверки гипотезы
На этапе MVP не нужно сразу строить идеальную архитектуру на годы вперёд. Сначала нужно проверить, нужна ли пользователям сама фича.
Пример:
Для HR-CRM не нужно сразу делать сложную аналитику, роли, интеграции с почтой, календарём, Telegram и HH.ru.
Сначала достаточно проверить базовый сценарий: рекрутер может добавить кандидата, изменить статус и оставить комментарий.
8. Но даже MVP не должен быть хаотичной помойкой
MVP может быть простым, но не должен быть бессознательным.
Быстро — не значит без структуры.
Пример:
Можно не делать сложный модуль отчётов, но всё равно нужно:
понять структуру данных;
не хранить секреты в коде;
валидировать формы;
разделять UI и бизнес-логику;
фиксировать архитектурные решения.
Иначе MVP быстро станет продуктом, который невозможно развивать.
9. Перед кодом сделай архитектурный документ
Архитектура объясняет, из каких частей состоит система и кто за что отвечает.
Пример файла ARCHITECTURE.md:
фронтенд — Next.js;
бэкенд — API routes;
база данных — Supabase;
UI-компоненты лежат в /components;
схемы данных лежат в /schemas;
бизнес-логика лежит в /services;
работа с базой не должна находиться внутри UI-компонентов.
Такой документ помогает AI не раскладывать код случайно.
10. Разделяй ответственность компонентов
Каждая часть системы должна отвечать за своё.
Плохой подход:
React-компонент одновременно показывает форму, валидирует данные, проверяет права, ходит в базу и решает бизнес-правила.
Хороший подход:
UI-компонент показывает интерфейс;
schema проверяет данные;
service содержит бизнес-логику;
API отвечает за обмен между клиентом и сервером;
database layer отвечает за работу с базой.
Так проект проще понимать, тестировать и развивать.
11. Объясняй AI архитектурные границы
AI не должен сам решать, куда класть код и какие части проекта менять. Ему нужно явно задавать границы.
Пример запроса:
«Не добавляй бизнес-логику в UI-компоненты. Валидацию вынеси в /schemas/candidate.ts, работу с базой — в /services/candidates.ts. Авторизацию и структуру базы не меняй».
Чем точнее границы, тем меньше случайных поломок.
12. Используй lifecycle для каждой фичи
Фича не должна начинаться и заканчиваться генерацией кода. У неё должен быть жизненный цикл.
Хороший lifecycle:
context check — понять контекст;
scope — определить границы задачи;
plan — составить план;
components — определить затронутые части;
implement — реализовать;
verify — проверить;
test — протестировать;
review — сделать ревью;
document — обновить документацию;
close — закрыть задачу.
Пример:
Перед задачей «создать карточку кандидата» попроси AI:
«Сначала проверь контекст проекта, определи scope и предложи план. Код пока не пиши».
13. Не разрешай AI писать код до плана
Если AI сразу бросается в код, он может решить задачу неправильно. Сначала он должен показать, что понял задачу.
Пример промта:
«Сначала составь план реализации. Укажи, какие файлы будешь менять и почему. После этого остановись и жди подтверждения. Код пока не пиши».
Это помогает избежать ситуации, когда агент переписывает лишнее или уходит не туда.
14. Вводи Definition of Done
Definition of Done — это список условий, при которых задача считается готовой.
Без него AI может сказать «готово», хотя на самом деле фича работает только частично.
Пример Definition of Done для формы заявки:
форма отображается на desktop и mobile;
обязательные поля валидируются;
email проверяется на корректность;
данные отправляются на сервер;
при успешной отправке пользователь видит подтверждение;
при ошибке пользователь видит понятное сообщение;
секреты не попадают во фронтенд;
изменения не ломают существующие страницы.
Задача готова только тогда, когда выполнены все пункты.
15. Не доверяй фразе «готово»
AI может уверенно сказать, что всё готово, но это не значит, что задача действительно завершена.
Пример запроса после реализации:
«Проверь результат по Definition of Done. Отдельно укажи, какие пункты ты можешь подтвердить, а какие нельзя проверить без запуска проекта».
Так AI не будет маскировать неопределённость.
16. Используй FSM-логику: не перескакивай через этапы
FSM — конечный автомат. В простом смысле это процесс, где нельзя перейти к следующему шагу, пока текущий не закрыт.
Пример:
нельзя писать код, пока не согласован scope;
нельзя закрывать задачу, пока не пройдена проверка;
нельзя релизить, пока не проверены секреты;
нельзя менять архитектуру без отдельного решения.
Такой подход защищает от хаотичных прыжков между задачами.
17. Держи AI в одном режиме за раз
Не нужно просить AI одновременно быть продуктологом, архитектором, дизайнером, разработчиком, тестировщиком и специалистом по безопасности.
Лучше разделять роли.
Пример:
сначала: «Ты продуктовый аналитик, уточни требования»;
потом: «Ты архитектор, предложи структуру»;
потом: «Ты разработчик, реализуй первый slice»;
потом: «Ты ревьюер, проверь код на риски».
Так AI работает точнее.
18. Всё, что можно автоматизировать, не отдавай на усмотрение AI
AI — вероятностная система. Для жёстких проверок лучше использовать детерминированные инструменты.
Пример:
плохо: «Claude, проверь, нет ли ошибок типов»;
хорошо: запустить npm run typecheck;
плохо: «AI, посмотри, нормально ли отформатирован код»;
хорошо: запустить npm run lint.
AI полезен для анализа ошибок, но сами проверки лучше делать через тесты, линтеры, type-check и скрипты.
19. Проси AI объяснять изменения
После реализации AI должен объяснить, что он изменил, зачем и какие риски появились.
Пример запроса:
«Дай changelog: какие файлы изменены, зачем, какие потенциальные риски, что нужно проверить вручную».
Это помогает сохранять контроль над проектом.
20. Ограничивай зону изменений
AI не должен переписывать полпроекта ради маленькой задачи.
Пример:
«Реши задачу только в рамках /components/CandidateForm.tsx и /schemas/candidate.ts. Не меняй авторизацию, роутинг и структуру базы без отдельного согласования».
Чем меньше зона изменений, тем проще проверить результат.
21. Не давай AI “рефакторить всё” без причины
Рефакторинг должен решать конкретную проблему. Иначе он может превратиться в хаотичное переписывание рабочего кода.
Плохой подход:
«Улучши проект».
Хороший подход:
«Убери дублирование в обработке ошибок в этих трёх API-методах, не меняя публичный контракт API».
Рефакторинг должен иметь цель и границы.
22. Данные должны иметь контракт
DTO — Data Transfer Object — это описание формы данных, которые передаются между частями системы.
Пример DTO кандидата:
id;
name;
email;
phone;
status;
source;
createdAt.
Если контракт не описан, AI может в одном месте назвать поле name, в другом fullName, в третьем candidateName.
Контракт данных защищает проект от расползания.
23. Валидируй входящие данные
Нельзя доверять данным, которые приходят от пользователя, фронтенда или внешнего API.
Пример:
Если пользователь отправляет email, сервер должен проверить, что это действительно email.
Если статус кандидата может быть только new, screening, interview, offer, rejected, сервер не должен принимать произвольную строку.
Валидация — это базовая защита качества данных.
24. Используй zod или похожие схемы
Zod помогает описать схему данных и проверять её во время работы приложения.
Пример:
Перед сохранением кандидата в базу объект проходит через candidateSchema.
Если данные корректные — сохраняем.
Если данные кривые — возвращаем ошибку.
Zod работает как фейс-контроль на входе в систему.
25. Не доверяй даже своему фронтенду
Даже если форма на сайте проверяет поля, сервер всё равно должен проверять их повторно.
Почему?
Пользователь может подменить запрос;
фронтенд может сломаться;
бот может отправить данные напрямую;
внешний сервис может вернуть неожиданный формат.
Пример:
Форма на фронтенде не даёт отправить пустой email. Но сервер всё равно обязан проверить email ещё раз.
26. Секреты не должны попадать в код
API-ключи, токены, пароли и приватные данные нельзя хранить в коде и коммитить в репозиторий.
Плохо:
const API_KEY = "sk_live_..."
Хорошо:
process.env.PAYMENT_API_KEY
Секреты должны храниться в переменных окружения или специальных secret-хранилищах.
27. Не отправляй реальные секреты в AI-чат
AI может помогать с настройкой, но ему не нужны настоящие ключи, пароли и токены.
Плохо:
«Вот мой настоящий API-ключ, помоги настроить оплату».
Хорошо:
PAYMENT_API_KEY=[REDACTED_SECRET]
или
PAYMENT_API_KEY=your_key_here
Давай AI структуру, но не реальные секреты.
28. Не пиши свою криптографию и авторизацию без необходимости
Авторизация, пароли, токены и криптография — зона повышенного риска.
Плохой подход:
«AI, напиши мне свою систему хранения паролей».
Хороший подход:
Использовать проверенное решение: Supabase Auth, Firebase Auth, Clerk, Auth0, OAuth или другой зрелый сервис.
Безопасность — плохое место для самодеятельности.
29. Включай базовую безопасность с самого начала
Безопасность не должна появляться только перед релизом.
Минимум уже на старте:
не коммитить .env;
включить 2FA на GitHub;
валидировать формы;
не хранить пароли открытым текстом;
ограничивать доступы;
не давать AI лишние права;
не использовать неизвестные зависимости без проверки.
Пример:
Даже если это MVP, секреты всё равно не должны лежать в репозитории.
30. Оцени риск по трём осям
Риск можно оценивать через три вопроса:
какая поверхность атаки;
какой возможный ущерб;
какова вероятность атаки.
Пример:
Сервис заметок для себя и платёжный сервис требуют разного уровня защиты.
В первом случае ошибка неприятна.
Во втором — может привести к потере денег, утечке данных и юридическим последствиям.
31. Отделяй devsec от prodsec
Devsec — это безопасность разработки.
Prodsec — это безопасность работающего продукта.
Пример devsec:
не хранить токены в GitHub;
включить 2FA;
ограничить доступы;
проверять зависимости.
Пример prodsec:
пользователь не должен видеть чужие заявки;
данные должны валидироваться;
авторизация должна работать корректно;
персональные данные должны храниться безопасно.
Обе зоны важны.
32. Не выводи критичные продукты в продакшен без аудита
Если продукт связан с платежами, медициной, финансами, персональными данными или юридически важными процессами, AI-кода недостаточно.
Пример:
AI может помочь собрать MVP платежной формы. Но перед реальными платежами нужен инженерный аудит: безопасность, хранение данных, ошибки, доступы, соответствие требованиям.
Чем выше цена ошибки, тем меньше можно полагаться на «вроде работает».
33. Делай логи и мониторинг хотя бы на базовом уровне
После релиза нужно понимать, что происходит в продукте.
Пример:
Пользователь говорит: «Форма не отправляется».
Без логов ты не знаешь, что случилось.
С логами можно понять:
ошибка валидации;
API недоступен;
база не отвечает;
внешний сервис вернул ошибку;
не настроена переменная окружения.
Мониторинг превращает «что-то сломалось» в конкретную задачу.
34. Разделяй “работает у меня” и “готово для пользователей”
То, что проект запустился локально, ещё не значит, что он готов к реальным пользователям.
Пример:
Локально форма работает, но на продакшене:
нет переменной окружения;
сломана мобильная версия;
ошибки не логируются;
база не принимает часть данных;
пользователь видит техническую ошибку.
Готовность — это не только локальный запуск.
35. Документируй решения по ходу работы
Документация нужна не для красоты, а чтобы проект не терял память.
Пример:
Если вы решили, что статусы кандидата могут быть только:
new;
screening;
interview;
offer;
rejected;
это нужно записать в документации и схеме данных.
Через месяц AI не должен придумать новую систему статусов.
36. После каждой фичи обновляй контекст проекта
Если изменилась архитектура, API, структура данных или правила, это нужно зафиксировать.
Пример:
Добавили поле source у кандидата.
Нужно обновить:
схему данных;
API-документацию;
описание модели;
форму;
валидацию;
тесты, если они есть.
Иначе следующая задача будет строиться на старом контексте.
37. Проси AI явно отмечать сомнительные места
AI не должен уверенно маскировать неопределённость.
Пример промта:
«Если для решения не хватает информации, не придумывай. Отдельно перечисли вопросы, предположения и места, где нужна проверка человеком».
Это особенно важно в архитектуре, безопасности и интеграциях.
38. Не принимай архитектурные решения только потому, что AI предложил
AI может предложить звучащее убедительно, но неподходящее решение.
Пример:
AI предлагает микросервисы для маленького MVP.
Перед согласием нужно спросить:
какую проблему это решает;
какая цена поддержки;
можно ли проще;
не создаём ли мы лишнюю сложность;
кто будет это сопровождать.
Решение принимает человек, а не модель.
39. Используй AI как усилитель компетенции, а не замену ответственности
AI может объяснить, подсказать и помочь реализовать. Но ответственность за продукт остаётся на человеке.
Пример:
Ты можешь попросить AI объяснить, как устроена авторизация. Но если продукт хранит данные клиентов, ответственность за безопасную реализацию всё равно на тебе.
AI помогает думать, но не отвечает за последствия.
40. Думай не только о создании, но и о сопровождении
Продукт не заканчивается после первой генерации кода. Его нужно чинить, расширять, поддерживать и передавать другим людям.
Пример:
Если завтра придёт разработчик, он должен понять:
как устроен проект;
где документация;
какие есть схемы данных;
какие решения уже приняты;
как запускать проект;
где смотреть ошибки;
какие части нельзя менять без осторожности.
Если после 200 AI-итераций проект невозможно понять, значит, процесс был плохим.
Короткая формула инженерного вайбкодинга
Не проси AI «сделать продукт».
Сначала:
опиши продукт;
собери требования;
зафиксируй спецификацию;
задай архитектуру;
разбей продукт на маленькие vertical slices;
для каждой фичи используй lifecycle;
не пиши код до плана;
введи Definition of Done;
проверяй результат;
думай о безопасности;
документируй решения;
обновляй контекст проекта.
Только после этого задачу можно считать инженерно выполненной.
Главный вывод
Вайбкодинг становится опасным не потому, что AI плохой. Он становится опасным, когда человек отдаёт AI задачу без рамок, требований, архитектуры и проверки.
Зрелый подход выглядит иначе:
«Вот продуктовый контекст. Вот требования. Вот архитектура. Вот ограничения. Вот задача. Вот критерии готовности. Сначала проверь контекст, потом предложи план, потом реализуй согласованный slice, потом проверь результат и обнови документацию».
Так AI становится не хаотичным генератором кода, а помощником внутри инженерного процесса.
Отдельно про то, как ставить задачу модели, чтобы она не догадывалась: промт-инжиниринг по правилам OpenAI и Anthropic.
