AI-ассистенты для разработки (Copilot, Claude Code, Cursor, Windsurf) стали повседневным инструментом. Но продуктивность работы с ними сильно различается: одни команды экономят часы, другие застревают в цикле «сгенерировал → проверил → переделал → переделал ещё раз».
Rahul Garg (Principal Engineer, Thoughtworks) в статье на сайте Мартина Фаулера предлагает системный подход: пять паттернов, которые снижают трение и превращают AI из «генератора кода» в «напарника, понимающего контекст».
Сквозная мысль — и оригинала, и этого разбора — такая: AI-ассистент становится полезным не тогда, когда «умнее модель», а когда проект умеет отдавать ему контекст как часть инженерного процесса. Не «лучше промпт», а лучше выстроенный контекст: описанный стек, зафиксированные решения, кодифицированные стандарты.
В статье
- Ключевая идея: AI как напарник, а не инструмент
- Цикл разочарования
- Ловушка скорости
- Пять паттернов
- Что из этого работает на практике
- Критический взгляд
- Что сделать завтра в своём проекте
Ключевая идея: AI как напарник, а не инструмент
Автор проводит параллель с парным программированием: если бы к вам в команду пришёл новый разработчик, вы бы не просто дали ему задачу «напиши сервис». Вы бы объяснили архитектуру, показали конвенции, рассказали про принятые решения. AI-ассистенту нужно то же самое — но разработчики почему-то этот шаг пропускают.
Без контекста AI генерирует технически корректный, но чужеродный код: не те паттерны, не та структура, не те зависимости. Начинается цикл правок, который съедает больше времени, чем было бы потрачено на написание с нуля.
Цикл разочарования (Frustration Loop)
(промпт хуже)"] RP --> P R -->|"редко с первого раза"| OK["Принято"]
flowchart LR
P["Промпт"] --> G["Генерация"]
G --> R["Ревью"]
R -->|"не то"| X["Отклонение"]
X --> RP["Переформулировка
(промпт хуже)"]
RP --> P
R -->|"редко с первого раза"| OK["Принято"]
Автор описывает типичную деградацию: чем больше итераций правок, тем меньше доверия к инструменту, тем менее качественные промпты пишет разработчик, тем хуже результат. Порочный круг, который разрывается не «лучшей моделью», а изменением подхода к взаимодействию.
Ловушка скорости
Отдельная мысль оригинала (The Speed Trap), которую легко упустить: метрики «скорости» обманчивы. «AI генерирует код в 5 раз быстрее» и «написано N строк» — выглядят как прогресс, но ничего не говорят о результате. Быстро сгенерированный, но чужеродный код, который потом долго правят и отлаживают, в сумме медленнее, чем код, написанный сразу правильно.
Опасность в том, что скорость генерации видна и приятна, а скрытая стоимость (ревью, исправления, отладка «правдоподобно, но неверно») — размазана и незаметна. Поэтому мерить стоит не «сколько кода выдал AI», а «сколько приняли с первого раза» и «сколько времени до рабочего результата». Об этих метриках — в критическом разделе: идея правильная, но на практике их почти никто не считает.
Пять паттернов
Названия и порядок — как в оригинале; к каждому добавлю микропример (плохой запрос → хороший → какой артефакт завести).
1. Knowledge Priming — подготовка контекста
Перед генерацией дать AI кураторский контекст: стек, ключевые решения, примеры кода в текущем стиле. Не весь репозиторий, а отобранный релевантный срез.
- Плохо: «Напиши HTTP-сервис на Go.»
- Хорошо: «Вот наш
CLAUDE.md(стек, конвенции). Сделай handler в том же стиле: наш роутер, существующий тип ошибок, конфиг из env.» - Артефакт:
CLAUDE.md/.cursorrulesс описанием проекта.
2. Design-First Collaboration — сначала дизайн, потом код
Не просить сразу реализацию, а пройти по уровням (capabilities → components → interactions → contracts → implementation) — прогрессивная детализация в рамках одной сессии, не waterfall.
- Плохо: «Сделай очередь задач с воркерами.»
- Хорошо: «Сначала обсудим дизайн: компоненты, контракты, границы. Накидай 2–3 варианта, выберем — и только потом код.»
- Артефакт: короткая спека/план перед реализацией.
3. Context Anchoring — якорение контекста между сессиями
AI не помнит прошлые сессии. Решение — фиксировать принятые решения в живом документе, который подгружается в каждую новую сессию. ADR (Architecture Decision Records) — инструмент не только для команды, но и для AI.
- Плохо: в новой сессии заново объяснять «почему у нас так сделано» (и получать другое решение).
- Хорошо: «Учитывай ADR из
docs/: bucket-policy вместо sigv4-сайдкара — потому что…» - Артефакт: набор ADR, подгружаемый в каждую сессию.
4. Encoding Team Standards — кодификация командных стандартов
(в оригинале — Encoding Team Standards; по-русски — кодификация командных стандартов, по сути «sensible defaults».) Превратить «у нас принято» в явные правила: стиль кода, обработка ошибок, структура пакетов, выбор библиотек — то, что сеньор знает интуитивно, а AI нет.
- Плохо: каждый раз вручную править стиль ошибок и структуру после генерации.
- Хорошо: правила явно в контексте: «ошибки — через
thiserror+IntoResponse; конфиг — только env; без глобальных синглтонов». - Артефакт: раздел «conventions» в
CLAUDE.md, чеклист код-ревью.
5. Feedback Flywheel — систематический сбор обратной связи
Отслеживать, какие промпты работают, что AI воспроизводит неправильно, и улучшать контекст на основе этого — а не только переписывать промпт.
- Плохо: в десятый раз вручную исправлять одну и ту же ошибку генерации.
- Хорошо: после плохой итерации обновить правило в
CLAUDE.md— чтобы ошибка не повторялась. - Артефакт: растущий
CLAUDE.md+ сниппеты промптов для частых задач.
Что из этого работает на практике
Эта платформа (khorost.tech) построена в плотной работе с AI-ассистентом, и пять паттернов проявились не как теория, а на конкретных артефактах репозитория.
Knowledge Priming — CLAUDE.md в корне: стек (Hugo, Angie, Go, PostgreSQL; целевой деплой в дизайн-доках — Kubernetes через ArgoCD), конвенции (только env-конфиг без конфиг-файлов, префикс метрик khorost_tech, URL-стратегия, политики кеширования) и визуальный стиль. Один раз описано — и каждая новая сессия стартует с этого среза, а не с нуля.
Design-First Collaboration — крупные вещи (например, развязка публикации контента и переезд раздачи на S3) шли через спеку и план в docs/ до написания кода, и только потом реализация по TDD. Прогрессивная детализация «идея → компоненты → контракты → код» в рамках сессии работает именно так, как описывает автор.
Encoding Team Standards — правила в CLAUDE.md превращают «у нас так принято» в явные: env-vars вместо конфиг-файлов, неизменяемые медиа в S3, no-cache для HTML. AI не угадывает эти умолчания — он им следует.
Context Anchoring — файлы памяти и дизайн-доки выступают живыми ADR: почему bucket-policy вместо sigv4-сайдкара, почему один environment на процесс renderer — эти решения переживают сессии и подгружаются заново, вместо того чтобы пересогласовываться каждый раз.
Feedback Flywheel — самый показательный паттерн именно как цикл. Ассистент несколько раз подряд генерировал env-конфиг не по принятой в проекте конвенции; вместо того чтобы править результат в N-й раз, я дописал явное правило в CLAUDE.md — и повторные правки прекратились. Не «лучшая модель» разорвала цикл, а уточнение контекста по следам неудачных итераций.
Что окупилось — дешёвые и постоянные артефакты: CLAUDE.md и связка спека → план. Что осталось ближе к теории — формальные «метрики качества коллаборации»: на практике я их не считаю, обратная связь идёт неформально, по ощущению трения.
Критический взгляд
Статья полезная, но к ней есть вопросы.
Принципы без примеров (в оригинале). В статье Garg паттерны местами описаны на уровне идей; конкретики «как именно» мало. «Подготовьте кураторский контекст» — звучит разумно, но что класть в этот контекст и где граница между «достаточно» и «перегрузил» — остаётся за кадром (именно поэтому выше я добавил микропримеры с артефактами).
Метрики, которые никто не считает. «First-pass acceptance rate» и прочие «метрики качества коллаборации» красивы на бумаге, но на практике их почти никто не собирает — нет инструментов и привычки. Риск, что это останется благим пожеланием.
Где осторожнее с AI. Тема в оригинале обойдена, а она важна. В security-critical коде, новой криптографии, нетривиальных алгоритмах «правдоподобно, но неверно» дороже всего. Но практичнее не «не использовать вообще», а сменить роль AI: пусть будет ревьюером, объяснителем чужого кода или генератором тест-кейсов — но не автором финального решения, которое уходит в прод без разбора. Это менее категорично и реально применимо.
Предел аналогии с парным программированием. Напарник-человек проактивно задаёт уточняющие вопросы и спорит; AI (пока) в основном выполняет, а не сомневается. Поэтому ответственность за «правильный вопрос» целиком на разработчике — аналогия работает не до конца.
Цена контекста. Поддержание CLAUDE.md, правил и ADR — это тоже работа, и постоянная. Для маленького проекта накладные расходы могут превысить выигрыш; паттерны окупаются на масштабе и длительности.
Что сделать завтра в своём проекте
Минимум, который окупается почти сразу:
- Завести
CLAUDE.md/AGENTS.mdв корне репозитория. - Описать в нём: стек, явные запреты («не делай так»), стиль обработки ошибок, структуру директорий, выбор библиотек.
- Добавить команды проверки — тесты, линтер, сборка: AI должен знать, чем проверять свой результат, не меньше, чем стиль кода.
- Завести 2–3 ADR на ключевые решения и подгружать их в сессии.
- Ввести привычку: после каждой плохой AI-итерации обновлять правила в контексте, а не только переписывать промпт.
Это и есть та самая сквозная мысль на практике: пользу даёт не модель, а то, насколько проект умеет отдавать ей контекст.
Комментарии