Этап 7 — Промпты для кода (ключевой)

Здесь prompt engineering переходит в инженерную практику разработки.

Темы этапа

• Генерация кода с требованиями
• Рефакторинг
• Поиск багов
• Генерация тестов
• Документация из кода

Генерация кода

Надёжный prompt для кода должен включать:

• язык/версию,
• архитектурные ограничения,
• стиль и соглашения,
• критерии приёмки,
• формат результата (файлы, diff, список изменений).

Рефакторинг

Запрашивай не «сделай лучше», а:

• конкретные smell-и,
• целевую структуру,
• запрет на изменение поведения,
• требования к тестам после изменений.

Поиск багов

Эффективный шаблон:

• контекст (симптом, лог, стек-трейс),
• гипотезы причин,
• минимальные шаги воспроизведения,
• фикс + объяснение, почему он корректен.

Генерация тестов

Важно задавать:

• тип теста (unit/integration),
• границы мокирования,
• набор edge-cases,
• ожидаемые инварианты.

Документация из кода

Полезные форматы:

• API контракты,
• ADR summary,
• runbook для поддержки,
• changelog для релиза.

Кодовые prompts как инженерная спецификация

Prompt для кода должен работать как компактная инженерная задача. Модели нужно знать репозиторий, версию языка, framework, границу ответственности и критерий готовности. Иначе она может создать код, который выглядит корректно отдельно, но не подходит существующему проекту.

Для поиска багов prompt должен отделять симптомы от причин. Логи и скриншоты — это симптомы. Исправление должно устранять причину и объяснять, почему симптом исчезнет. Для рефакторинга нужно явно сохранять поведение, потому что «почисти код» иначе может превратиться в случайную перепись. Для тестов нужно указать слой и границы мокирования, иначе сгенерированные тесты часто становятся хрупкими или слишком широкими.

Вывод этапа

Кодовые промпты должны быть максимально специфицированы.
Чем меньше двусмысленности, тем меньше технического долга после генерации.

Объяснение для новичка

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

Для генерации новой функции prompt должен включать acceptance criteria. Например: «добавь endpoint POST /orders, валидируй quantity >= 1, возвращай 400 при ошибке, добавь unit tests для service и integration test для controller». Такой запрос задаёт не только код, но и ожидаемое поведение.

Для bug fixing важно отделять симптом от причины. Stack trace, лог и скриншот показывают симптом. Хороший prompt просит найти root cause, предложить минимальный фикс и объяснить, почему он устраняет именно причину. Для refactoring нужно явно сказать «не менять публичное поведение» и попросить тесты или список рисков.

В проекте Spring Boot 3 исправь ошибку в OrderService.
Симптом: при quantity=0 заказ создаётся.
Ожидаемое поведение: вернуть validation error до сохранения.
Не меняй API response format.
Добавь тест на quantity=0 и quantity=1.
В ответе перечисли изменённые файлы и как проверял.

Мини-сценарии из практики

• Модель генерирует код, который компилируется, но не учитывает ограничения проекта: в запросе не зафиксированы версии и соглашения.
• Для поиска багов модель даёт поверхностный обзор: не задан формат findings с severity и ссылками на строки.
• Генерация тестов покрывает happy-path, но пропускает edge cases: нет явного требования на негативные сценарии.

Быстрые правила принятия решений

• Для кода всегда задавай контекст окружения: язык, версии, стиль, ограничения.
• Для ревью всегда требуй структурированный формат выводов и приоритизацию по риску.
• Для тестов всегда требуй покрытие happy-path, negative-path и boundary cases.

Вопросы для самопроверки

1. Почему «сгенерируй код» без ограничений почти всегда приводит к техническому долгу?
2. Какие поля должны быть обязательными в формате bug-finding отчёта?
3. Как формулировать запрос на тесты, чтобы покрыть не только счастливый путь?