"Следуй существующим паттернам" — почему этого недостаточно для ИИ-агента, пишущего код

Инженерные команды массово используют ИИ-агентов для написания кода, но продолжают давать им расплывчатые инструкции. Проблема не в модели — проблема в том, как организации хранят и передают свои знания.

ИИ-агент не унаследует вашу инженерную культуру автоматически. Если знания живут только в головах опытных разработчиков, генеративный код будет слепым — как стажёр, которого бросили в проект без онбординга.

Проблема: слишком общие инструкции

Многие команды дают ИИ-агентам инструкции, которые звучат логично:

• Следуй существующим паттернам
• Не вводи новые абстракции
• Используй устоявшуюся архитектуру
• Придерживайся стандартов проекта

Человек-разработчик обычно понимает, что стоит за этими фразами. Слова — лишь часть коммуникации. Остальное он додумывает сам: профессиональный опыт, знание конкретной кодовой базы, разговоры с коллегами, замечания на код-ревью, понимание того, как в компании принимаются инженерные решения.

ИИ-агент такого контекста не имеет. Он может уловить паттерн в одном слое кода, но проигнорировать другое место, где тот же принцип должен примениться. Он воспроизведёт видимую структуру соседней реализации, не понимая, почему она вообще существует.

Это не про бессмысленность общих принципов

Важный момент: общие инженерные принципы не бесполезны. Они просто неполны, когда существуют изолированно.

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

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

Почему критика ИИ-кода часто бьёт мимо

Статья поднимает интересный системный момент. Критики ИИ-генерируемого кода справедливо указывают на небезопасный код, хрупкие системы, ненужные абстракции, несогласованные реализации и приложения, которые невозможно поддерживать.

Но многие из этих провалов — не доказательство бесполезности ИИ в разработке. Это симптом того, что организации используют агентов, не адаптировав при этом то, как передаётся инженерное знание.

Опытные инженеры несут в голове огромный массив неявных знаний об организации:

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

ИИ-системы не наследуют это культурное понимание. Их этому нужно научить — явно и системно.

Что нужно делать: оцифровать «племенные знания»

Автор оригинальной статьи формулирует чёткий рецепт: организации должны превратить «племенные знания» (tribal knowledge) — то, что хранится в головах отдельных людей — в явную организационную интеллектуальную собственность.

Это значит фиксировать не только что делает кодовая база, но почему она устроена именно так, и какие решения нельзя откатнуть «просто так».

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

Обратная проблема: устаревшая документация

В комментариях к оригинальной статье поднят важный нюанс, который автор не раскрыл. Направить агента на канонический гайд — это простая половина задачи. Сложнее другое: что делать, когда этот гайд устарел, а агент с полной уверенностью следует неверному правилу?

Это хуже, чем отсутствие документации вообще. Как поддерживать документацию в актуальном состоянии? Как привязать её к ревью, которые меняют паттерны? Как автоматизировать проверку свежести?

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

Вывод

Следующий раз, когда вы будете настраивать ИИ-агента для работы над кодовой базой, спросите себя: если бы вы наняли нового разработчика и дали ему только фразу «следуй нашим стандартам» — хватило бы ему этого для работы?

Скорее всего, нет. Ему нужен доступ к документации, примерам, архитектурным_decision records_, истории инцидентов. ИИ-агенту нужно ровно то же самое — только ещё более явно и структурированно.