Рабочий процесс ИИ-разработки: от вайбкодинга к инженерной дисциплине
🎬 Видео на YouTube: Рабочий процесс ИИ-разработки
Источник исследования: оригинальное видео на русском
Генеративный ИИ делает написание кода дешевым. Проблема начинается тогда, когда скорость генерации становится скоростью накопления технического долга. Несколько расплывчатых запросов превращают проект в монолит, где изменение одной переменной ломает соседние модули.
В исходном видео предлагается обратный подход: сначала добавить структуру, а затем просить модель что-либо реализовать.
Навык должен быть исполняемым инструментом
ИИ-навык полезнее, когда это исполняемая возможность проекта, а не абзац, который копируют в чат. Командная утилита может установить инструкции, скрипты и соглашения прямо в репозиторий. После этого агент видит правила как часть рабочей среды.
Есть два типа навыков. Вызываемые пользователем запускают явные процессы — анализ или подготовку спецификации. Вызываемые моделью выполняют рутинные проверки — например, чтение структуры каталога или проверку типов. Это сокращает повторяющиеся запросы и сохраняет поведение рядом с кодом.
Сначала задавайте вопросы
Первый важный навык действует как строгий интервьюер. Вместо догадок о недостающих требованиях агент задает точные вопросы о границах, ошибках, данных и интеграциях. Реализация начинается только после того, как слепые зоны стали видимыми.
Это не бюрократия, а защита от привычки модели соглашаться и заполнять пробелы правдоподобными предположениями.
Память проекта должна быть компактной
Длинные диалоги плохо заменяют постоянную память проекта. Файл context.md может хранить архитектуру, ограничения и общий словарь. ADR — записи архитектурных решений — фиксируют не только решение, но и причины отказа от альтернатив.
Общий словарь также убирает двусмысленность. Короткий термин вроде “каскад материализации” заменяет длинное описание, если команда и модель понимают его одинаково. В видео это показано как способ уменьшить повтор контекста и сохранять замысел между сессиями; точная экономия токенов зависит от проекта и модели.
Превращайте разговор в спецификацию
После интервью диалог нужно скомпилировать в строгую спецификацию, а затем разбить на небольшие отслеживаемые задачи. Каждая задача должна помещаться в эффективную зону внимания модели.
После выполнения задачи сессию лучше закрыть. Следующая начинается с чистым краткосрочным контекстом, но получает долговременную память — context.md, ADR и общую спецификацию. Так модель не устает от истории диалога и не теряет архитектурный замысел.
Независимая проверка лучше самопроверки
Агент, написавший код, не должен быть единственным судьей. Отдельный проверяющий получает исходную задачу и результат, но не внутреннюю историю первого агента. Он проверяет соответствие спецификации и архитектурные стандарты: дублирование, запахи кода и лишнюю связанность.
Тесты усиливают границу. При TDD падающие тесты задают контракт до реализации. Модель должна получить проверяемое поведение, а не просто убедительно описать результат.
Главный вывод прост: ИИ усиливает и дисциплину, и небрежность. Навыки, память проекта, небольшие задачи, чистые сессии, независимая проверка и тесты превращают скорость генерации в поддерживаемый процесс.