Локальная модель не глупая — ей просто не объяснили, как работать

Я устал повторять один и тот же бриф каждому новому агенту: тонкий контроллер, DTO через spatie/laravel-data, валидация в FormRequest, бизнес-логика в Action, единый PHPDoc, файлы не длиннее 150 строк. Без этого даже сильная модель пишет «рабочий» код, который через неделю неудобно поддерживать.

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

Запрос к Preference Memory и сформированные правила PHP
Один запрос — и агент получает не общие пожелания, а конкретные правила проекта.

Память вместо промпта на пол-экрана

Сервис хранит не бесформенную заметку, а правила: что мне нравится и что нельзя делать, насколько это строго, к какому языку или проекту относится. Перед началом задачи агент вызывает get_context_for_task через MCP и получает ровно тот контекст, который нужен сейчас.

Например, для PHP он видит не «пиши красиво», а проверяемые требования:

  • контроллер только связывает FormRequest → DTO → Action → Resource;
  • DTO лежит в Application/DTOs, использует camelCase и spatie/laravel-data;
  • у класса и методов единый PHPDoc;
  • в теле метода нет болтовни-комментариев и «умных» цепочек ради цепочек;
  • каждый файл укладывается в лимит строк.

Это важная разница. Модель перестаёт угадывать вкус разработчика — она получает архитектурный контракт до первой строчки кода.

Пример DTO, сформированный с учётом предпочтений
DTO получается в заданной структуре, а не в случайном стиле модели.

Что меняется в реальном коде

На скриншотах не «идеальный ответ для демо», а обычная цепочка задачи: сформировать DTO, Request, Action и короткий контроллер. Контекст заставляет модель разделять ответственность до того, как она успела свалить всё в один файл.

FormRequest и Action в структурированном примере PHP
Валидация, бизнес-правила и HTTP-слой не смешиваются.

В результате локальная модель может быть заметно проще облачной, но её ответ становится предсказуемым: он попадает в конвенции проекта, проходит по понятному чек-листу и требует меньше переписывания. Не потому что «локалка стала Claude», а потому что ей дали систему координат.

Это не отменяет проверку — и в этом смысл

Preference Memory не превращает генерацию кода в автопилот. Она не проверяет миграции, не запускает тесты и не знает новую бизнес-логику без входных данных. Зато убирает самый дорогой вид рутины: повторять агенту правила, которые уже известны команде.

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

Результат и критерии готового кода
Критерии готовности делают результат проверяемым, а не «на глаз нормальным».

Попробовать Preference Memory

Проект открыт: Preference Memory — память предпочтений для AI-агентов. Его можно развернуть у себя, подключить к Claude Code, ChatGPT и другим MCP-совместимым агентам, а затем пополнять память по мере работы над проектами.

Начните с десяти правил, которые вы чаще всего повторяете в ревью. Уже этого достаточно, чтобы следующий запрос к локальной модели был не «напиши код», а «сделай задачу по нашему способу работы».

Теги: AI-агентыClaude Codeлокальные моделиMCPPreference MemoryPHP