Модель не сохраняет состояние между сессиями. Структуру должны хранить вы — и это важнее, чем в работе без LLM
Популярное заблуждение: раз LLM умная — можно работать небрежно, она «разберётся». На практике всё наоборот. Чем мощнее инструмент, тем дороже обходится отсутствие структуры.
Каждая новая сессия — чистый лист. Всё что агент знает о вашем проекте — это то что вы передали прямо сейчас. Без структуры: каждый раз объясняете контекст заново, получаете непоследовательные результаты, нет точки возврата если что-то пошло не так.
Что меняется с ростом структурированности
хаос
структура
Уровень 0: нет структуры
Без этого
Каждый запрос — угадайка. Результат зависит от того как сформулировали сегодня.
С этим
—
Структура в работе с LLM — четыре вещи: спецификация (что нужно), git (история изменений), документация (контекст проекта), тесты (критерий готовности). Разберём каждую.
Раздел 2
Спецификация — язык с моделью
Spec — не бюрократия. Это единственный надёжный способ передать намерение агенту
Разработчик читая задачу задаёт уточняющие вопросы, держит контекст в голове, интерпретирует неоднозначности из опыта. Агент делает буквально то что написано — и генерирует наиболее вероятное продолжение. Spec делает намерение явным.
Что происходит без spec — и как это исправить
❌ Расплывчато
«Сделай страницу логина»
Агент не знает: какой фреймворк? Какие поля? Что происходит после успешного логина? Нужна ли валидация? Какой дизайн?
✓ С контекстом
«Реализуй форму логина на React.
Поля: email (type=email), password.
При успехе — редирект на /dashboard.
При ошибке — показать сообщение под формой.
Не делать: регистрацию, восстановление пароля.»
❌ Расплывчато
«Создай тикеты по упавшим тестам»
Из какого источника? Какой приоритет? Что писать в описание? Куда создавать?
✓ С контекстом
«Прочитай ./test-results/last-run.json.
Для каждого теста со статусом failed:
создай задачу в Linear, команда ALPHA,
тип Bug, приоритет P2.
Заголовок: название теста.
Описание: текст ошибки (первые 10 строк).
Перед созданием покажи список.»
❌ Расплывчато
«Напиши саммари митинга»
Какого митинга? Какой формат? Для кого? Что важно выделить?
✓ С контекстом
«Прочитай транскрипт из файла meeting.txt.
Составь саммари для команды:
— принятые решения (маркированный список)
— открытые вопросы без решения
— ответственные и дедлайны если упоминались.
Максимум 15 строк. Без вводных фраз.»
Что обычно входит в spec
1
Источник данных / контекст
Откуда брать данные, какой файл читать, в какую систему идти
2
Задача — что сделать
Конкретный глагол: создай, найди, обнови, сгруппируй, отправь. Один глагол — одна задача
3
Ожидаемый результат / формат
Таблица? Список? Новый файл? Обновлённая страница? Сообщение в Slack? Укажите явно
4
Критерий «готово»
Как понять что задача выполнена верно. Для кода — тесты зелёные. Для данных — показать мне перед записью
5
Что не делать
Явные ограничения убирают неоднозначность. «Не трогать X», «только для команды Y», «без архивных задач»
Форматы и инструменты для spec
📝 Свободный текст
Обычный Markdown или просто текст в промпте. Для большинства задач — достаточно. Никаких инструментов не нужно.
📄 Файл в репозитории
SPEC.md или docs/spec/ — spec как часть проекта. Агент читает сам, версионируется вместе с кодом.
🗂 Notion / Linear
Задача в Linear с полным описанием — уже spec. Агент читает через MCP. Acceptance criteria в задаче = критерий готовности.
Главное: spec не обязана быть документом. Это может быть несколько строк в промпте. Важно что намерение явное — вход, действие, результат, ограничения.
Раздел 3
Git: история как страховка
Агент может переписать половину файла и сломать то что работало. Git — всегда точка возврата
Без git: агент сломал что-то — ищете что было, восстанавливаете вручную. С git: git reset --hard и вы там где были. Правило простое: коммит перед каждой значительной задачей агенту.
Нажмите на коммит — узнайте зачем он нужен
a3f92c1 · сейчас
feat: валидация email в authHEAD
Агент добавил валидацию email. Всё работает. Этот коммит — «всё хорошо» перед следующей задачей агенту.
b19e4a0 · 20 мин назад
checkpoint: before refactoring authcheckpoint
Коммит перед тем как дать агенту «отрефактори auth». Если результат не понравится — git reset --hard b19e4a0 и мы здесь.
c44f1b3 · 1 час назад
wip: agent session partialwip
Агент не закончил, прервали на середине. WIP-коммит — не теряем прогресс. В следующей сессии дадим агенту этот коммит как контекст.
d7a03e9 · 2 часа назад
revert: undo agent changes to db schemarevert
Агент изменил схему БД и сломал миграции. Откатили через revert. Именно для этого нужен checkpoint перед задачами с записью в БД.
e91b2c4 · вчера
init: project scaffold
Начало. Первый коммит — точка отсчёта. Всё что после — история решений агента и человека.
Три правила:
1. Коммит перед крупной задачей агенту — создаёт точку отката
2. WIP-коммит при прерывании сессии — не теряет прогресс
3. Читать diff перед коммитом — агент мог изменить больше чем просили
Раздел 4
Документация как контекст
Агент работает только с тем что вы дали. Документация — способ не объяснять одно и то же каждую сессию
Без документации: тратите 5–10 минут каждой сессии на «ввод в курс дела», рискуете забыть упомянуть важное. Решение — файлы контекста которые агент читает автоматически. В Claude Code это CLAUDE.md в корне проекта.
Нажмите на шаг — увидите детали
вы
Запуск сессии
Claude Code стартует в папке проекта. Автоматически ищет CLAUDE.md — никаких дополнительных команд.
→
агент
Читает CLAUDE.md
Узнаёт стек, соглашения по коду, что нельзя трогать, как запускать тесты. Всё из одного файла.
→
агент
Работает в контексте
Использует правильные утилиты, избегает запрещённых паттернов, называет переменные как принято в команде.
→
вы
Меньше правок
Не нужно говорить «это не наш стиль» или «мы не используем эту библиотеку». Агент уже знает.
📄 CLAUDE.md — корень проекта
# MyApp · Alpha project
## Стек
Node.js 22 · TypeScript · PostgreSQL · pytest для тестов
## Соглашения
- camelCase для переменных, PascalCase для классов
- Не изменять src/generated/ — автогенерируется
- Новые endpoints — через src/routes/
## Тесты
npm run test · npm run test:watch
## Не делать без явного запроса
- Не менять схему БД · Не ставить новые пакеты · Не трогать .env
CLAUDE.md — system prompt для вашего проекта. Пишется один раз, работает в каждой сессии. Обновляйте когда меняются соглашения.
Раздел 5
Тесты как критерий готовности
Без тестов — не знаете работает ли то что написал агент. С тестами — знаете объективно
Агент генерирует код который выглядит правильным. Тест — единственный объективный критерий. Важный сдвиг: при работе с агентом тесты пишутся до или вместе с реализацией — не после. Агент получает чёткий критерий «готово» и итерирует сам до зелёного.
Нажмите на карточку — увидите правильный подход
Антипаттерн
«Агент написал — значит работает»
Принять результат без запуска тестов. Код выглядит логично — наверное ок.
нажмите →
Как надо
Запускать тесты после каждой задачи агента
«Напиши реализацию и запусти npm test. Исправляй пока все тесты не зелёные» — агент итерирует сам до нужного результата.
Антипаттерн
Spec без критерия готовности
«Реализуй логин» — агент что-то сделал. Как проверить что правильно?
нажмите →
Как надо
Spec + acceptance criteria
«Готово = тесты в auth.test.ts зелёные: корректные данные → 200, неверный пароль → 401, нет пользователя → 404.»
Антипаттерн
Позволить агенту удалить тест
Агент «упростил» — убрал тест который мешал. Покрытие упало незаметно.
нажмите →
Как надо
Явный запрет в CLAUDE.md
«Не удалять тесты. Если тест мешает — сообщи мне.» Тест который мешает — это сигнал о проблеме, не мусор.
Антипаттерн
Тесты только для кода
Тестируем только функции. А правильно ли агент создал тикет в Linear? Верно ли обновил Notion?
нажмите →
Как надо
Верификация для любых задач
«После создания тикетов покажи их мне — проверим что все поля верны, потом считаем задачу выполненной.»