От вайбкодинга к инженерии: как работать с AI-агентом по-взрослому

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

AI-агент действительно умеет писать код, объяснять ошибки, предлагать архитектуру и запускать инструменты. Но код — только один участок большой работы. До него есть продуктовая задача и требования, после него — проверка, безопасность, выпуск и поддержка.

Главный переход выглядит так: не «попросить модель сделать приложение», а построить процесс, внутри которого агент делает ограниченные шаги, а человек понимает цель, принимает решения и проверяет доказательства.

Вайбкодинг не проблема. Проблема — отсутствие рамок

Попросить AI «сделать авторизацию» — примерно как сказать подрядчику «покрась что-нибудь в красное». Он может выполнить просьбу, но не знает, что именно считать хорошим результатом.

Авторизация — это email и пароль или вход через внешний identity provider? Нужны ли восстановление доступа, MFA, подтверждение почты, ограничение попыток, выход со всех устройств, аудит сессий? Где хранятся секреты? Что происходит при ошибке? Какие данные видит пользователь?

Если ответы не зафиксированы, агент заполнит пробелы сам. Получится решение, которое выглядит убедительно, но не обязано соответствовать продукту. Так появляются четыре знакомых эффекта:

• «Дырявый носок»: интерфейс работает, но внутри есть уязвимость, секрет в коде или невалидированные данные.
• «Хомячье колесо»: новая правка исправляет один симптом и создаёт два следующих.
• Разрушительный рефакторинг: ради маленькой задачи переписывается большая часть проекта.
• Потеря контроля: через несколько итераций непонятно, что изменилось и почему.

Поэтому зрелость — не в том, чтобы запретить AI писать код. Она в том, чтобы не отдавать ему молча продуктовые и рискованные решения.

AI-агент — усилитель, но не ответственный за продукт

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

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

Полезно разделять три вещи:

1. Генерация — агент предлагает текст, код, схему или вариант решения.
2. Решение — человек выбирает вариант с учётом продукта, бюджета и рисков.
3. Доказательство — тест, проверка, лог или наблюдаемый результат подтверждает, что решение работает.

AI отлично помогает с первой частью и заметно ускоряет вторую. Третью желательно строить на воспроизводимых механизмах.

SDLC: код — середина, а не весь жизненный цикл

SDLC — Software Development Life Cycle, жизненный цикл разработки ПО. Это не одна обязательная схема с фиксированным числом стадий: команды делят цикл по-разному. Но почти в любой модели есть несколько повторяющихся видов работы:

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

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

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

Spec-driven: сначала чертёж, потом реализация

Спецификация — это короткий договор о задаче. В ней стоит зафиксировать:

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

Это не бюрократия. Спека снижает количество решений, которые агент вынужден угадывать. В небольшом проекте достаточно одного PRD.md и описания конкретного slice. В более сложном добавляются ARCHITECTURE.md, CONVENTIONS.md, SECURITY.md и TESTING.md.

Но документация — не магический источник истины. Она должна совпадать с кодом и проверками. Устаревшая спека опаснее короткой, но актуальной.

MVP не обязан быть идеальным, но обязан быть осознанным

MVP проверяет гипотезу. Production-продукт обслуживает реальных пользователей. У них разные критерии достаточности.

На MVP можно не делать сложную аналитику, десять интеграций и архитектуру «на сто лет». Нельзя при этом сознательно оставлять очевидную дыру в доступе к данным, хранить ключи в репозитории или принимать произвольный ввод там, где от него зависит бизнес-логика.

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

Vertical slice: маленький законченный маршрут через систему

Vertical slice — это не слой вроде «сначала вся база, потом весь backend». Это пользовательская возможность, проведённая через необходимые слои от начала до конца.

Например, для CRM рекрутингового агентства первый slice может быть таким: рекрутер создаёт карточку кандидата, форма проверяет поля, API принимает данные, сервис применяет бизнес-правила, запись появляется в базе, интерфейс показывает успех и корректно сообщает об ошибке.

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

FSM и lifecycle: не перескакивать через доказательства

FSM — Finite State Machine, конечный автомат. В прикладном смысле это набор состояний и разрешённых переходов. Для разработки он полезен как дисциплина процесса: пока текущий шаг не закрыт, следующий не начинается.

Практический lifecycle фичи может выглядеть так:

1. Context check — прочитать правила проекта, текущую архитектуру и ограничения.
2. Scope — определить, что входит в задачу, а что нет.
3. Plan — назвать шаги и ожидаемые изменения.
4. Components — перечислить затронутые части: UI, API, данные, тесты.
5. Implement — внести минимальные изменения.
6. Verify — сверить результат с запросом.
7. Test — запустить автоматические и ручные проверки.
8. Review — поиск лишнего, регрессий и нарушенных границ.
9. Document — обновить документы, если поведение изменилось.
10. Close — зафиксировать результат и открытые вопросы.

Это не водопад. После теста можно вернуться к требованиям, а после обратной связи — к scope. Важно другое: возврат должен быть явным, а не происходить незаметно внутри бесконечного чата.

Definition of Done: «готово» должно быть проверяемым

Фраза «сделай форму» описывает намерение, но не завершённую работу. Definition of Done превращает её в набор наблюдаемых условий.

Для формы заявки это может быть:

• форма работает на desktop и mobile;
• обязательные поля и формат email проверяются на сервере;
• невалидные данные не отправляются дальше бизнес-логики;
• успех и ошибка понятны пользователю;
• секреты не попадают во frontend;
• существующие страницы не сломаны;
• сборка и тесты проходят;
• документация обновлена, если изменился контракт.

Хорошая формулировка для агента после реализации: «Проверь каждый пункт отдельно. Для каждого укажи доказательство. Отдельно перечисли то, что нельзя подтвердить без ручного запуска или доступа к окружению».

AI для неоднозначности, инструменты для проверяемых вещей

LLM выдаёт вероятностный ответ. Это не делает её бесполезной: наоборот, гибкость ценна там, где нужно интерпретировать, сравнить варианты или найти неочевидное объяснение.

Но форматирование, типы, тесты, сборка, миграции и поиск секретов лучше проверять специализированными инструментами. Линтер не «думает», нравится ли ему код; он выполняет зафиксированные правила. TypeScript проверяет статические типы до запуска, но не проверяет автоматически данные, пришедшие от пользователя. Тестовый фреймворк не заменяет продуктовый сценарий, но воспроизводит конкретные проверки.

Принцип простой: всё, что можно сделать воспроизводимым скриптом, не стоит оставлять только на совести модели. При этом зелёная сборка не доказывает, что продукт удобен, а слова агента «готово» не заменяют smoke-check.

Архитектурные границы: кто за что отвечает

Архитектура нужна не ради красивых папок. Она снижает стоимость изменений. Если UI одновременно рисует экран, проверяет права, обращается к базе и содержит бизнес-правила, агенту трудно менять одну часть, не задев остальные.

На базовом уровне можно договориться:

• UI показывает состояние и принимает действие;
• схема описывает и проверяет форму данных;
• сервис содержит бизнес-правила;
• API координирует обмен;
• слой данных отвечает за хранение.

MVC — один из способов объяснить такое разделение через Model, View и Controller. Это полезная учебная модель, но не универсальный рецепт для любого современного приложения. В проекте могут быть другие границы: feature modules, ports and adapters, server actions или вообще статический сайт без backend. Важно не название паттерна, а ясные обязанности и запреты на нежелательные зависимости.

DTO и Zod: контракт и проверка — разные вещи

DTO, Data Transfer Object, описывает форму данных, которые переходят между частями системы. Это договор: какие поля есть, какие типы и какие ограничения ожидаются.

Zod — библиотека для runtime-валидации схем в JavaScript/TypeScript. Она полезна потому, что типы TypeScript проверяются до запуска и не защищают приложение от произвольного HTTP-запроса, ответа внешнего API или ошибки собственного frontend.

Поэтому DTO и схема Zod не одно и то же: первое — роль/контракт данных, второе — конкретный инструмент проверки во время выполнения. На границе системы данные нужно валидировать даже тогда, когда frontend уже проверил их.

Безопасность — сквозная практика, а не финальная галочка

Удобно разделять безопасность разработки и безопасность работающего продукта, но не стоит превращать это в две изолированные комнаты.

В разработке важны секреты, доступы к репозиторию, зависимости, CI/CD и права инструментов. В продукте — аутентификация, авторизация, обработка данных, сессии, журналы, ограничение запросов и реакция на инциденты. Базовый риск-ориентированный вопрос звучит так: что защищаем, от каких сценариев, какой ущерб возможен и какие меры соразмерны проекту.

Минимальные правила:

• не коммитить ключи, пароли и токены;
• не отправлять реальные секреты и персональные данные в AI без явной необходимости и понятной политики обработки;
• ограничивать доступы принципом наименьших привилегий;
• использовать проверенные библиотеки и стандартные протоколы вместо собственной криптографии;
• не путать .env с полноценным secrets manager: файл помогает не положить ключ в Git, но сам должен быть защищён и не обязан быть лучшим хранилищем для production;
• проверять границы авторизации и доступа к объектам отдельно, а не считать успешный вход доказательством права на всё.

OAuth — протокол делегированной авторизации, а не универсальный синоним логина. Конкретная схема зависит от identity provider и приложения. MFA — более широкое понятие, чем 2FA: двухфакторная аутентификация — частный случай многофакторной.

Человек, работающий с AI, должен понимать карту риска

Не обязательно вручную писать каждую строку. Но нужно уметь отличить клиент от сервера, API от базы, аутентификацию от авторизации, статический type-check от runtime-валидации, локальный запуск от production-деплоя.

Это не требование стать senior engineer. Это минимальная грамотность заказчика и оператора процесса. Иначе агент будет принимать решения вместо вас там, где вы не можете оценить последствия.

Рабочий шаблон запроса

Вместо «сделай CRM» задайте агенту контекст и границы:

Мы делаем CRM для небольшого рекрутингового агентства. Сейчас реализуем один vertical slice: создание карточки кандидата. Цель — чтобы рекрутер сохранил имя, email и текущий статус и получил понятный результат.

Используй PRD.md, ARCHITECTURE.md и CONVENTIONS.md. Не меняй авторизацию, платежи и существующий API вне этого сценария. Сначала выполни context check, перечисли scope и предложи план с файлами и проверками. Код пока не пиши.

После согласования реализуй только план. Затем проверь Definition of Done, запусти доступные тесты и отдельно укажи: что доказано, что проверено косвенно, а что требует ручной проверки.

Такой промт не делает модель безошибочной. Он уменьшает пространство угадывания и создаёт точки, в которых человек может остановить неверное решение.

Итог: зрелая работа с AI — это управление процессом

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

Хороший процесс выглядит так: понять продукт, записать требования, определить границы, выбрать небольшой slice, провести его через lifecycle, проверить результат детерминированными инструментами, оценить риск, обновить документацию и только потом назвать задачу закрытой.

AI в этом процессе становится не магической кнопкой и не «младшим разработчиком, которому всё можно», а мощным участником инженерной системы. Чем яснее контекст и критерии, тем больше пользы от его генерации — и тем меньше цена неизбежных ошибок.

Автор лекции: Igor Bergand