Большинство разработчиков используют AI-кодеров как продвинутый автокомплит: написал промпт → получил код → поправил → снова написал промпт. Работает… пока проект маленький. Но как только появляется архитектура, интеграции и исторический багаж кода — всё начинает сыпаться.
Разработчик Борис Тейн предлагает другой путь. В своём блоге он описывает жёсткий workflow работы с Claude Code: никакого кода до утверждённого письменного плана. Сначала исследование, потом план, потом аннотации — и только после этого реализация.
И знаете что? Это один из самых здравых подходов к AI-разработке, которые я видел.
🔍 Фаза первая: Исследование, а не «пробежаться глазами»
Тейн начинает каждую задачу с глубокой команды: «прочитай папку полностью, разберись во всех деталях, опиши всё в research.md».
Обратите внимание — он требует письменный артефакт, а не ответ в чате.
Почему это важно?
ИИ по умолчанию «сканирует». Он читает сигнатуру функции, делает вывод, идёт дальше. Если не указать явно «deeply» (глубоко), «in great detail» (в мельчайших подробностях), «intricacies» (со всеми тонкостями и нюансами), модель будет экономить усилия и ограничится поверхностным чтением, не вникая в архитектурные детали и скрытые зависимости системы.
Технически это связано с тем, как LLM оптимизируют внимание в длинном контексте. Без явного сигнала о глубине анализа модель стремится к поверхностной свёртке информации — иначе она просто не уложится в токены.
Создание research.md решает сразу несколько проблем:
🧩 Даёт поверхность для ревью — вы видите, что модель на самом деле поняла
🛑 Позволяет поймать неверные предположения до того, как они попадут в код
🏗 Предотвращает классическую катастрофу AI-разработки — «работает изолированно, ломает систему»
Это ключевой момент. Самая дорогая ошибка ИИ — не синтаксис, а неправильный контекст.
📝 Фаза вторая: План как контракт
После исследования создаётся plan.md. Не встроенный plan-mode, а реальный markdown-файл в репозитории.
И это гениально по простой причине: файл — это состояние.
В чате вы теряете структуру. В файле у вас есть спецификация, к которой можно возвращаться.
План включает:
⚙️ Конкретные файлы, которые будут изменены
🧠 Обоснование архитектурных решений
📦 Фрагменты кода
⚖️ Компромиссы (Trade-offs)
Тейн часто добавляет референсы из open-source. Это важный приём: LLM работают гораздо лучше, когда им дают пример реализации.
Почему? Потому что модель не «изобретает» решение, а сопоставляет с существующим паттерном. Это снижает креативную энтропию.
✏️ Самое интересное: цикл аннотаций
Вот где начинается магия.
ИИ пишет план → разработчик открывает файл → добавляет inline-комментарии → отправляет обратно → ИИ обновляет план.
Повторяется до шести раз.
Причём с жёсткой фразой: «don’t implement yet» (пока не приступай к реализации).
Это критично.
LLM склонны преждевременно переходить к генерации кода, если чувствуют, что задача «почти понятна». Но «почти» в архитектуре — это путь к рефакторингу через боль.
Типичные правки:
🛠 «используй drizzle:generate, а не raw SQL»
🔁 «retry здесь не нужен, очередь уже делает ретраи»
🚫 «это должен быть PATCH, не PUT»
🧱 «не меняем сигнатуры функций»
Фактически это injection человеческого суждения в модель.
И вот здесь происходит переход от «руления кодом» к «рулению архитектурой».
📋 Todo как система управления
Перед реализацией создаётся granular todo list.
Это кажется мелочью, но на практике:
📊 Вы видите прогресс
🧭 Модель знает границы задачи
⏳ Сессия может длиться часами без потери фокуса
ИИ отмечает выполненные пункты прямо в плане. План становится источником истины.
🚀 Реализация: скучная и механическая
Когда план готов, звучит команда: «implement it all» (реализуй всё целиком).
Обратите внимание на формулировку:
⚡ «не останавливайся»
🔒 «не используй any»
🧪 «постоянно запускай typecheck»
🧹 «не добавляй лишних комментариев»
Реализация должна быть скучной.
И это лучшая характеристика хорошего процесса. Креативность — в архитектуре. Исполнение — механика.
🎛 Почему это реально работает
С инженерной точки зрения этот workflow решает три фундаментальные проблемы LLM-разработки:
🧠 Проблему поверхностного контекста
📉 Проблему каскадных ошибок
💸 Проблему перерасхода токенов
Разделение thinking (этапа продумывания и проектирования) и typing (этапа непосредственного написания кода) — это почти применение принципов SDLC (жизненного цикла разработки ПО) к работе с AI.
ИИ — не архитектор. Он ускоритель исполнения.
🧭 Мой взгляд
Я давно наблюдаю, как разработчики строят вокруг LLM сложные orchestration-системы (системы координации и управления процессами): loops (циклы повторных вызовов), agents (агенты-исполнители), MCP (Model Context Protocol — протокол работы с контекстом модели), автоперезапуски. Но часто это попытка автоматизировать хаос.
Подход Тейна — противоположный. Он вводит дисциплину.
И самое интересное — он проводит исследование, планирование и реализацию в одной длинной сессии. Многие жалуются на деградацию контекста после 50% окна. Но если в сессии уже есть research.md и plan.md, модель имеет устойчивую опору.
Это напоминает старую инженерную истину: хорошая спецификация экономит больше времени, чем любой инструмент.
🔮 Что это меняет для индустрии
Мы переходим в эпоху, где разработчик становится:
🏗 Архитектором решений
🎯 Куратором приоритетов
🧪 Контролёром качества
🤖 Диспетчером AI-исполнителя
Это качественный сдвиг.
ИИ-кодеры не убирают инженеров. Они меняют их роль.
И если честно, метод Тейна — это первый по-настоящему зрелый workflow работы с AI-кодом, который я видел.
Он не про магические промпты.
Он про дисциплину.
Заключение
Метод Бориса Тейна можно свести к одной фразе:
Сначала думай. Потом планируй. Потом разрешай писать код.
Если вы работаете с крупными проектами, попробуйте этот подход хотя бы на одной фиче. Высока вероятность, что вы перестанете «чинить за ИИ» и начнёте управлять им.
И это — главный шаг от экспериментов к инженерной зрелости в эпоху AI.
Источники
🔗 Оригинальная статья Бориса Тейна:
https://boristane.com/blog/how-i-use-claude-code/
🔗 Русский разбор:
https://telegra.ph/Zabudte-o-haose-kak-upravlyat-II-koderom-s-pomoshchyu-plana-a-ne-molitvy-02-22