Вайб-кодинг умер. Привет инженерия контекста

Вайб-кодинг умер. Привет инженерия контекста Как перестать гадать на промптах: практический гайд

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

🆕 На смену промптингу приходит более системная дисциплина — инженерия контекста. Андрей Карпатый говорит о ней как об искусстве правильно заполнять окно контекста, а LangChain в своём блоге описывает эволюцию от простого промптинга к управлению контекстом.

Если промпт-инжиниринг — это про задать вопрос, то инженерия контекста — это о создании информационной экосистемы, в которой ИИ сможет на него ответить.

Инженерный подход: от идеи до реализации ⚙️

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

Процесс разбивается на три инженерных этапа:

1️⃣ Определение цели и критериев приемки Вы начинаете с чёткого описания задачи, как в хорошем таск-трекере. Не «сделай страницу логина», а «создай React-компонент для страницы входа с полями email/пароль, валидацией на клиенте, кнопкой входа и интеграцией Google OAuth через вызов функции auth.signInWithGoogle()». Вы определяете, что значит «готово», и указываете на ограничения: «не использовать библиотеку X».

2️⃣ Архитектура контекста Это главный этап. Прежде чем ИИ напишет хоть строчку кода, вы готовите для него исчерпывающий бриф.

Предоставление знаний. Вы даёте прямые ссылки на документацию к API (или используете context7), но что важнее — конкретные сигнатуры функций и модели данных, которые агент должен использовать. Лучшая практика — не просто дать ссылку на 100-страничный PDF, а извлечь ключевые абзацы и примеры кода, отформатировав их в Markdown.

Обучение на примерах. Вы показываете модели файлы в вашем проекте, демонстрирующие, как вы работаете с API или логируете ошибки. Это на порядок эффективнее словесных инструкций, так как модель улавливает не только синтаксис, но и неявные архитектурные решения — как вы организуете импорты, именуете переменные и структурируете логику.

Определение инструментария. Вы явно прописываете, какие инструменты агент может использовать. Например, ReadFile, WriteFile, ListDirectory, RunTests и запрещаете всё остальное. То же относится и к MCP серверам. Это создает безопасную «песочницу», предотвращая случайные действия.

3️⃣ Итеративное исполнение с «рабочим журналом» Только после подготовки контекста вы запускаете ИИ-агента, который работает в предсказуемом цикле. В процессе агент ведет «рабочий журнал» (scratchpad): он записывает свои мысли, действия, выводы инструментов и наблюдения. Этот журнал становится частью его динамического контекста, позволяя ему не сбиваться и анализировать свои же шаги.

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

🛑 Частые ошибки, которых стоит избегать:

Перегрузка контекста. Попытка «скормить» модели всю кодовую базу целиком. Это приводит к рассеиванию внимания и снижению качества. Нужна точность — давайте только релевантные файлы и фрагменты.

Неявные инструкции. Надеяться, что ИИ «сам догадается». Если в проекте используется Tabs вместо Spaces, это нужно указать явно. Любая неявная конвенция должна быть задокументирована.

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

/ Не запрещена в РФ