Промпты для coding agents в 2026

Короткая версия

Самый рабочий шаблон промпта для coding agents в 2026:

1. Цель: что должно получиться.
2. Контекст: стек, файлы, ограничения.
3. Границы: что можно и нельзя менять.
4. Критерии приёмки: как понять, что задача сделана.
5. Формат ответа: plan, diff summary, тесты, open questions.

Базовый шаблон

Задача:
[что нужно сделать]

Контекст:
- стек: [...]
- релевантные файлы: [...]
- текущая проблема: [...]

Ограничения:
- не меняй [...]
- не добавляй новые зависимости без необходимости
- сохрани текущий публичный интерфейс

Критерии приёмки:
- [условие 1]
- [условие 2]
- [условие 3]

Сначала:
1. кратко опиши plan
2. перечисли затронутые файлы
3. только потом переходи к изменениям

Задача: добавить rate limiting для публичного API.

Контекст:
- Node.js, TypeScript, Express, Redis
- релевантные файлы: src/middleware/, src/routes/, tests/
- сейчас endpoint /api/search можно вызывать без ограничений

Ограничения:
- не меняй контракт ответов API
- не добавляй новый storage, используй существующий Redis
- не трогай auth flow

Критерии приёмки:
- 100 req/min для анонимных
- 500 req/min для авторизованных
- 429 + Retry-After при превышении
- новые тесты проходят

Сначала дай краткий plan и список файлов.

1. Что изменилось в промптах для кодинга

Раньше хороший coding prompt был в основном про:

• язык;
• фреймворк;
• желаемый код;
• формат ответа.

Теперь этого недостаточно, потому что current tools могут:

• читать repo;
• менять несколько файлов;
• запускать tests;
• делать коммиты;
• пользоваться terminal и tools.

Поэтому современные промпты должны управлять не только generation, а behavior of the agent.

2. Лучший базовый паттерн: bounded task

Самая полезная единица в 2026 - не "большая feature", а bounded task.

Хороший bounded task:

• имеет понятный scope;
• имеет проверяемый результат;
• не требует бесконечных product-решений;
• укладывается в reviewable diff.

3. Пять обязательных блоков хорошего промпта

1. Objective

Сформулируйте, какой outcome нужен.

Не: "поработай над этим кодом".
Да: "исправь 500 ошибку на /api/search при пустом query".

2. Context

Дайте минимально достаточный context:

• стек;
• где искать код;
• какие файлы уже релевантны;
• какие паттерны проект использует.

3. Constraints

Это самый недооценённый блок.

Почти всегда полезно явно сказать:

• не менять публичный API;
• не добавлять новые зависимости без крайней необходимости;
• не трогать unrelated modules;
• следовать текущим проектным правилам.

4. Acceptance criteria

Без критериев агент часто останавливается слишком рано.

Полезные примеры:

• "все unit tests проходят";
• "новый endpoint возвращает 400 вместо 500";
• "не меняется response shape";
• "добавлены тесты на edge cases".

5. Expected output

Укажите, чего вы хотите от агента:

• сначала plan;
• потом изменения;
• в конце summary;
• список файлов;
• команды, которые были запущены;
• open questions.

4. Plan-first prompts работают лучше, чем "сразу пиши код"

Это один из самых стабильных паттернов across tools.

Фраза вроде:

"Сначала дай краткий план и перечисли затронутые файлы. Не пиши код до плана."

обычно заметно повышает качество, потому что:

• агент вынужден сузить scope;
• вы рано ловите неверное направление;
• уменьшается риск большого нерелевантного diff.

5. Лучшие промпты по типам задач

Дебаг

Для дебага самый важный вход - не описание эмоций, а evidence:

• stack trace;
• шаги воспроизведения;
• релевантный код;
• expected vs actual behavior.

Баг:
POST /api/register возвращает 500 при multipart/form-data

Ожидаемое поведение:
400 с ошибкой валидации, если email отсутствует

Фактическое поведение:
500 TypeError в normalizeEmail()

Релевантные файлы:
- src/routes/auth.ts
- src/utils/email.ts
- src/validation/register.ts

Сначала:
1. найди root cause
2. предложи минимальный fix
3. добавь тест

Рефакторинг

Для рефакторинга полезнее всего зафиксировать, что не должно измениться.

Отрефактори src/services/order.ts.

Цель:
- разбить processOrder на меньшие функции
- убрать any
- вынести типы в src/types/order.ts

Ограничения:
- не меняй публичный интерфейс processOrder
- не меняй текущую бизнес-логику
- не меняй названия внешних exports

Проверка:
- текущие тесты должны проходить
- если нужны новые тесты, добавь их

Тесты

Для тестов промпт должен задавать coverage surface, а не просто "напиши тесты".

Напиши unit tests для calculateTotal().

Покрой:
- обычный заказ
- процентную скидку
- бесплатную доставку
- пустую корзину
- отрицательные значения

Используй:
- Vitest
- текущий тестовый стиль из tests/services/user.test.ts

В конце:
- перечисли кейсы, которые остались вне покрытия

Code review

Review prompts должны задавать lens, а не "посмотри код".

Сделай review этого diff.

Фокус:
1. security
2. performance
3. error handling
4. API compatibility

Формат:
- severity
- file:line
- проблема
- как исправить

6. Что просить у агента в конце

Очень полезный current pattern - просить не просто "готово", а structured close-out:

• какие файлы изменены;
• какие команды запущены;
• что удалось проверить;
• что не удалось проверить;
• какие остались риски.

Это особенно полезно в Claude Code, Codex, Cursor Agents, Windsurf Cascade и других tool-using workflows.

7. Anti-patterns

Антипаттерн 1: giant prompt

Промпт, который одновременно просит:

• архитектуру;
• implementation;
• tests;
• docs;
• deploy;
• security review.

Обычно результат хуже, чем у двух-трёх фаз.

Антипаттерн 2: vague quality words

Фразы вроде:

• "сделай красиво";
• "сделай production-ready";
• "сделай best practice";
• "оптимизируй".

без конкретных критериев почти всегда слабо работают.

Антипаттерн 3: no boundaries

Если не написать "не трогай unrelated files", агент нередко расширяет задачу сам.

Антипаттерн 4: asking for hidden reasoning

Не нужно просить длинную chain-of-thought. Полезнее просить:

• краткий plan;
• assumptions;
• open questions;
• verification steps.

8. Как промпты сочетаются с repo instructions

Хороший prompt в 2026 не должен таскать весь project context внутри себя каждый раз.

Постоянные правила должны жить в:

• AGENTS.md
• CLAUDE.md
• .cursor/rules/*
• .github/copilot-instructions.md
• .windsurf/rules/*

А prompt должен добавлять только task-specific context.

Иначе вы каждый раз заново переписываете весь repo contract, что делает prompts длиннее и менее стабильными.

9. Практические шаблоны

Универсальный implementation prompt

Задача:
[что нужно сделать]

Контекст:
- стек: [...]
- релевантные файлы: [...]
- текущий паттерн: [...]

Ограничения:
- не меняй [...]
- не добавляй [...]
- придерживайся project rules

Критерии приёмки:
- [...]
- [...]
- [...]

Сначала:
1. дай краткий plan
2. перечисли затронутые файлы
3. затем реализуй

В конце:
- summarize changes
- перечисли запущенные команды
- укажи риски или open questions

Migration prompt

Мигрируй этот модуль на новый API.

Scope:
- только src/modules/billing/**
- не трогай UI

Нужно:
- обновить client calls
- сохранить текущий public contract
- обновить tests

Сначала дай migration plan.
Если найдёшь blocker, остановись и опиши его до изменений.

Проверьте себя