Автор инженерной заметки на Habr делится опытом передачи ИИ-агенту знаний, которые обычно накапливаются у разработчика. В его команде сценарии, когда правила закладываются в промпт, документацию или набор skills до начала работы, не сработали: код получался рабочим, но не проходил ревью. Значительная часть компетентности вспоминается только в процессе, поэтому инструкции нужно формировать в момент принятия решений.
Подход строится на шести правилах. Агент должен повторять путь разработчика: изучать проект, определять ограничения, формировать контракты и только потом усложнять реализацию. Задача декомпозируется так, чтобы для каждого шага существовало эталонное решение; это решение затем используется как few-shot для последующего кода. Проверенные тесты постепенно становятся отдельным этапом приёмки, а принятые решения превращаются в переиспользуемые skills. Автор подчёркивает, что речь про инженерную разработку, а не про вайбкодинг.
| Правило | Суть |
|---|---|
| Агент проходит путь разработчика | Изучает проект, ограничения, контракты и простейшую реализацию. |
| Декомпозиция до эталона | Задача разбивается на уровень, где можно создать эталонное решение. |
| Локальные знания проекта | Агент получает правила и документацию, актуальные для конкретного кода. |
| Проверенный эталон как few-shot | Используется как пример для последующего кода. |
| Тесты как этап приёмки | Проверенные тесты постепенно становятся самостоятельным этапом. |
| Принятые решения в skills | Опыт превращается в переиспользуемые инструкции. |
Человек остаётся финальным арбитром: он проверяет результат каждого шага. Полностью автономный режим в духе Ralph loop автор не использует — это дорого по вычислительным затратам и усложняет контроль качества. По мере накопления эталонов частота вмешательства снижается. Для описания контрактов команда применяет proto и OpenAPI, а затем кодогенерацию.
Приёмы вроде spec-driven development, context engineering и few-shot известны по отдельности; новизна в их сборке в единый процесс. Инженерные практики — DDD, TDD, правила именования — тоже можно оформлять как skills и отдельные проверки. Тогда агент получает не абстрактное требование «писать хороший код», а конкретные правила и примеры для конкретного проекта.
