Введение: иллюзия бесконечной памяти
Когда вы впервые начинаете работать с AI-ассистентом в режиме vibe coding — когда код пишется не руками, а через естественные запросы — возникает магическое ощущение: нейросеть помнит всё. Вы обсуждаете архитектуру, меняете требования, пишете функции. Но наступает момент, когда вы спрашиваете: «Почему ты забыл, что мы договорились о паттерне Singleton?» — и получаете пустой взгляд.
Это не баг. Это фундаментальное ограничение: у vibe-кода нет памяти. Каждый новый запрос — это чистый лист. LLM (Large Language Model) не хранит историю диалога бесконечно: контекстное окно ограничено (у GPT-4o — 128K токенов, у Claude 3.5 Sonnet — 200K). После его переполнения — или при ручной очистке — все договорённости исчезают. Решение? DESIGN.md — файл, который становится внешней памятью для вашего AI-кода.
Почему LLM забывает? Техническая подоплёка
Ограничение контекстного окна
Каждый токен в диалоге занимает место. Средний коммерческий AI-ассистент (ChatGPT, Claude, Gemini) использует sliding window: когда диалог превышает лимит, старые сообщения отбрасываются. Исследование Anthropic (2024) показало, что даже при сохранении контекста, модели хуже удерживают информацию из первых 10% диалога по сравнению с последними 30%. Это явление называется «middle-of-context degradation».
| Модель | Макс. контекст (токенов) | Примерное время диалога до сброса |
|---|---|---|
| GPT-4o | 128,000 | ~300-500 сообщений |
| Claude 3.5 Sonnet | 200,000 | ~500-800 сообщений |
| Gemini 1.5 Pro | 1,000,000 | ~2000-3000 сообщений |
Но даже у Gemini с его миллионом токенов память — это не файловая система. Модель не может «запомнить» структуру вашего проекта, если вы не повторяете её явно в каждом запросе.
Проблема «затухания» решений
В vibe coding вы часто принимаете архитектурные решения: «используем React с функциональными компонентами», «все API-запросы через единый клиент», «логирование через централизованный сервис». Через 10-15 итераций AI может начать генерировать код, нарушающий эти договорённости — просто потому что они выпали из активного контекста.
DESIGN.md как внешняя память
DESIGN.md — это не просто документация. Это манифест решений, который вы передаёте AI-ассистенту в каждом новом запросе. В отличие от README (который описывает, как использовать проект), DESIGN.md фиксирует почему и как вы строите архитектуру.
Структура DESIGN.md для vibe-кода
# DESIGN.md — Архитектурные решения проекта X
## 1. Фундаментальные принципы
- Все компоненты — функциональные (запрещены классовые).
- Единый API-клиент через axios с перехватчиками ошибок.
- Состояние — только через Zustand (не Redux).
## 2. Именование и структура
- Файлы: kebab-case (user-profile.tsx).
- Компоненты: PascalCase.
- Хуки: use* (useAuth).
## 3. Критические паттерны
- Авторизация: JWT, хранится в httpOnly cookie.
- Ошибки: централизованный обработчик в `src/lib/errors.ts`.
- Логирование: Winston с ротацией.
## 4. Исключения (когда можно нарушить)
- Для тестов разрешены классовые компоненты.
- В утилитарных функциях — snake_case.
## 5. История изменений решений
- 2026-06-15: Перешли с Redux на Zustand для уменьшения бойлерплейта.
- 2026-06-20: Добавлен rate limiting на API-клиент.
Как использовать DESIGN.md в каждом запросе
Правило простое: каждый запрос к AI начинается с @DESIGN.md (или явной вставки содержимого). В Claude и ChatGPT есть функция «Project files» (Claude Projects, ChatGPT Custom Instructions), где DESIGN.md можно закрепить как постоянный контекст. Но если вы работаете через API — передавайте файл как system prompt.
Пример запроса:
«У нас есть проект с архитектурой, описанной в DESIGN.md. Следуя этим принципам, добавь компонент для отображения списка пользователей. Используй единый API-клиент и Zustand-стор.»
Без DESIGN.md AI мог бы сгенерировать классовый компонент на Redux — и вы бы потратили часы на рефакторинг.
Кейс: как DESIGN.md спас проект от хаоса
Рассмотрим реальный сценарий. Команда из 3 разработчиков использует Claude для генерации фронтенда на React. Без DESIGN.md:
- День 1: AI генерирует компоненты на функциональном React.
- День 3: В одном из запросов AI создаёт классовый компонент — контекст потерян.
- День 5: AI предлагает Redux для управления состоянием, хотя команда договорилась о Zustand.
- День 7: Проект содержит 4 разных стиля кода, 2 менеджера состояний и 3 подхода к API-запросам.
С DESIGN.md:
- День 1: Создан DESIGN.md с 10 правилами.
- День 1-30: Каждый запрос начинается с «Следуя DESIGN.md...».
- Результат: 95% сгенерированного кода соответствует архитектуре. Ручной рефакторинг — только для 5% случаев.
Практические советы по внедрению
1. Держите DESIGN.md коротким (не более 30 строк)
LLM лучше обрабатывают короткие, структурированные инструкции. Длинный документ будет проигнорирован или приведёт к перекосу внимания.
2. Обновляйте DESIGN.md после каждого значимого решения
Если вы решили сменить библиотеку для работы с формами — запишите это в DESIGN.md. Иначе через 10 запросов AI вернётся к старой библиотеке.
3. Используйте «архитектурные тесты»
После каждой генерации можно запускать скрипт (например, ESLint с кастомными правилами), который проверяет соответствие кода DESIGN.md. Это автоматизирует контроль.
4. Для команд: DESIGN.md как часть CI/CD
Включите проверку на соответствие DESIGN.md в pipeline. Например, скрипт, который проверяет, что в коде не используются запрещённые паттерны (классовые компоненты, Redux).
Заключение: память — это дисциплина
Vibe coding — мощный инструмент, но без внешней памяти он превращается в генератор технического долга. DESIGN.md — это не роскошь, а необходимость для любого проекта, где AI участвует в написании кода. Он превращает хаотичные диалоги с LLM в структурированный процесс, где каждое решение зафиксировано и воспроизводимо.
Начните с малого: создайте DESIGN.md для своего текущего проекта. Запишите 5-10 правил. И каждый раз, когда обращаетесь к AI, напоминайте ему о них. Через неделю вы заметите, что количество «грязного» кода уменьшилось, а время на рефакторинг — сократилось. Память vibe-кода — это ваша дисциплина, а не функция AI.
Комментарии