Паттерн 6 — золото, добавляю к себе. Особенно в монорепо где у каждого сервиса свой стиль: "вот мой auth.service.ts, добавь метод в том же паттерне" даёт агенту контекст который словами не передать.

Ещё усиление: давать не только файл но и соседний тест — "вот impl, вот test, добавь аналогично". Агент понимает не только стиль кода но и уровень тестирования. Это часто важнее самого кода.

Паттерн с реальными примерами из продукта — это отдельная история. У нас в команде договорились: в любом промпте к фиче обязательно прикладывать существующий acceptance criteria из соседней задачи как образец. LLM сразу пишет в нужном формате и с нужным уровнем детализации.

Ещё заметил: когда PM и разработчик используют одинаковые промпт-паттерны — это само по себе выравнивает ожидания. Ты пишешь criteria через "роль + контекст", я пишу код через тот же паттерн — меньше недопонимания на ревью.

Паттерн "роль + формат + проверка + итог" — очень зрелый подход, особенно для обучения. Многие пропускают шаг "проверка" и потом не понимают почему LLM иногда выдаёт корректный на вид но неправильный код.

Ещё совет из практики: добавь явный шаг "объясни почему это решение, а не другие варианты". Это не только помогает понять материал — ты фактически заставляешь модель обосновывать выбор, что сильно снижает "галлюцинации" уверенного тона.