30 промптов для разработчика — Claude, GPT, Gemini для кода

В 2026 году разработчик без AI — это разработчик с одной рукой. Хороший AI-помощник пишет 30–60% кода, делает code review, объясняет legacy, создаёт тесты и документацию. Но разница между «джуниорским использованием» и «продвинутым» — это качество промптов.

В этой статье — 30 проверенных промптов для всех этапов разработки. От написания фичи до подготовки к релизу. Работают в любой современной модели: Claude Opus 4.7, GPT-5.5, DeepSeek V4-Pro, Gemini 3.1 Pro.

Какую модель выбрать для какой задачи

Задача	Лучшая модель	Альтернатива	Дешёвая
Генерация нового кода	Claude Opus 4.7	GPT-5.5	DeepSeek V4-Pro
Code review	Claude Opus 4.7 (87.6% SWE-bench)	GPT-5.5	DeepSeek V4-Pro
Объяснение legacy-кода	Claude Sonnet 4.6	GPT-5.5	DeepSeek V4-Flash
Юнит-тесты	Claude Opus 4.7	GPT-5.5	DeepSeek V4-Pro
Дебаг	Claude Opus 4.7	GPT-5.5	—
Архитектурные решения	Claude Opus 4.7	GPT-5.5	—
Алгоритмы и LeetCode	DeepSeek V4-Pro (Codeforces 3,206)	GPT-5.5	—
DevOps и автоматизация	GPT-5.5 (Terminal-Bench 82.7%)	Claude Opus	—
Анализ всей кодовой базы	Llama 4 Scout (10M контекст)	Gemini 3.1 Pro	—
Массовая обработка (миграция, рефакторинг 100+ файлов)	DeepSeek V4-Flash	Llama 4 Maverick	—

В Lumen AI все модели в одном чате — пробуйте через /compare.

Раздел 1. Генерация нового кода

1. Production-ready функция

Ты — Senior [LANG] Developer.

Напиши функцию [НАЗВАНИЕ], которая [ОПИСАНИЕ ЗАДАЧИ].

**Контекст:**
- Используется в production [ОПИСАНИЕ СИСТЕМЫ]
- Вызывается [ЧАСТОТА]
- Ожидаемая нагрузка: [МЕТРИКИ]

**Требования:**
- Type hints / type annotations
- Docstring с примерами
- Обработка ошибок (что возвращать при невалидных входах)
- Логирование на нужных уровнях
- Без зависимостей вне стандартной библиотеки (или укажи минимальный набор)

**Производительность:**
- Время выполнения < [N] мс для типичного входа
- Память O(1) если возможно

После функции — 5 unit-тестов: happy path + 4 edge cases.

2. API endpoint

Напиши endpoint [METHOD] [PATH] на [FRAMEWORK].

**Что делает:** [ОПИСАНИЕ]

**Запрос:**
```json
[ПРИМЕР ЗАПРОСА]

Ответ:

[ПРИМЕР УСПЕШНОГО ОТВЕТА]

Требования:

Валидация входных данных через [Pydantic / Zod / Joi]
Обработка типичных ошибок (400, 401, 403, 404, 422, 500)
Логирование запроса
Аутентификация через [JWT / session / API key]
Rate limiting [N] req/min
Документация в OpenAPI / Swagger формате

Дай: код endpoint + middleware + типы + 3 интеграционных теста.


### 3. Класс с методами

Создай класс [НАЗВАНИЕ] на [LANG].

Назначение: [ОПИСАНИЕ]

Состояние (поля):

field1: type — что хранит
field2: type — что хранит

Методы:

method1() — что делает
method2(arg) — что делает
method3() — что делает

Принципы:

Single Responsibility
Иммутабельность где возможно
Никаких side effects в методах кроме явно указанных

Дополнительно:

Конструктор с валидацией
repr / toString
Сравнение (eq) и хеширование если нужно
Сериализация в dict / JSON

После класса — 10 unit-тестов покрывающих все методы и edge cases.


### 4. CLI-инструмент

Напиши CLI-утилиту на [LANG].

Что делает: [ОПИСАНИЕ]

Интерфейс:

mytool [команда] [опции]
mytool --help

Команды:

command1 [args] — что делает
command2 [args] — что делает

Требования:

Использовать [argparse / click / commander.js / cobra]
Цветной вывод (зелёный = успех, красный = ошибка, жёлтый = warning)
Прогресс-бары для долгих операций
Дружелюбные сообщения об ошибках
--verbose для подробного логирования
--dry-run для предпросмотра действий

После кода — README с примерами использования.


### 5. SQL-запрос

Напиши SQL-запрос для [СУБД: PostgreSQL / MySQL / SQLite].

Задача: [ОПИСАНИЕ ЧТО НУЖНО ПОЛУЧИТЬ]

Схема таблиц:

[CREATE TABLE statements]

Требования:

Оптимизация: учитывай индексы
Читаемость: CTE (WITH) для сложных частей
Без N+1 проблемы
Учитывай NULL-значения

Дай: запрос + объяснение каждой части + примерный EXPLAIN PLAN.


---

## Раздел 2. Объяснение и понимание кода

### 6. Объяснение функции для джуна

Объясни код, как для джуна с 6 месяцами опыта в [LANG]:

[ВСТАВИТЬ КОД]

Структура объяснения:

Что делает в целом (1-2 предложения)
Что делает каждая часть (комментарии по строкам/блокам)
Какие концепции нужно знать чтобы понять (с краткими определениями)
Подводные камни — где новичок может запутаться или сделать ошибку
Как можно было бы переписать проще (если есть варианты)


### 7. Reverse-engineering legacy-кода

У меня есть legacy-код без документации:

[ВСТАВИТЬ]

Помоги разобраться:

Что делает в целом — основная цель этого модуля
Какая бизнес-логика реализована (не техническая, а доменная)
Какие данные обрабатывает (input → output)
Внешние зависимости — с чем взаимодействует
Потенциальные баги — что выглядит подозрительно
Что можно безопасно удалить (мёртвый код)
Как переписать чисто — план рефакторинга

Если что-то непонятно из контекста — задавай уточняющие вопросы.


### 8. Архитектурный обзор проекта

У меня проект на [STACK]. Структура:

[ДЕРЕВО ПАПОК ИЛИ ОПИСАНИЕ]

Главные файлы (вставлю по запросу).

Помоги мне понять:

Архитектурный паттерн — что использовано (MVC / Clean / DDD / etc)
Точка входа и flow запроса
Слои абстракции — где какая логика
Зависимости между модулями — что от чего зависит
Шаблон для новых фич — как добавить новую функциональность по образцу проекта
Архитектурные риски — где код плохо масштабируется

Используй для контекста большую модель с длинным контекстом (Llama 4 Scout 10M или Gemini 3.1 Pro 1M).


### 9. Расшифровка регулярки

Объясни эту регулярку:

[ВСТАВИТЬ REGEX]

Дай:

Что matches (с примерами)
Что НЕ matches (с примерами)
Каждую группу/часть отдельно
Возможные edge cases где работает неожиданно
Если есть подвохи (greedy vs non-greedy, backtracking) — объясни


### 10. Реверс-инжиниринг чужого API

У меня есть пример запроса/ответа от чужого API:

Запрос: [HTTP MEHTOD, URL, HEADERS, BODY]

Ответ: [STATUS, HEADERS, BODY]

Помоги:

Опиши что вероятно делает endpoint
Какие параметры обязательны / опциональны
Возможные коды ошибок и что они значат
Как это лучше всего обернуть в клиент на [LANG]
Дай готовый класс/функцию-клиент с типизацией


---

## Раздел 3. Рефакторинг

### 11. Базовый рефакторинг

Отрефактори этот код:

[ВСТАВИТЬ]

Цели:

Читаемость (понятные имена, разбиение на функции)
Тестируемость (выделение чистых функций, dependency injection)
Следование SOLID
Удаление дублирования (DRY)

Сохранить:

Публичный API (имена и сигнатуры функций)
Поведение (всё работает как раньше)
Тесты (если есть — должны проходить)

После кода — список всех изменений с обоснованием каждого.


### 12. Перевод на функциональный стиль

Переведи императивный код на функциональный стиль:

[ВСТАВИТЬ]

Принципы:

Чистые функции (без side effects)
Иммутабельность данных
Использование map / filter / reduce вместо циклов
Композиция функций
Pattern matching где уместно

Сохрани: имена функций, типы. Покажи рядом старую и новую версии для сравнения.


### 13. Разбиение монолитной функции

Эта функция стала слишком большой:

[ВСТАВИТЬ]

Разбей её на несколько маленьких:

Каждая новая функция делает одну вещь
Имя описывает что функция делает
Не больше 20 строк на функцию (идеально 5-10)
Чистые функции где возможно
Side effects изолированы

После рефакторинга — главная функция должна стать «оркестратором» из вызовов мелких функций.


### 14. Миграция между фреймворками

Перепиши этот код с [FRAMEWORK A] на [FRAMEWORK B]:

[ВСТАВИТЬ]

Контекст миграции:

Версия source: [X]
Версия target: [Y]
Известные различия: [ЕСЛИ ЗНАЕТЕ]

Сохрани:

Бизнес-логику
Public API
Поведение

Адаптируй под идиомы целевого фреймворка — не просто перевод 1-в-1, а переписать "как нативно для [B]".

После кода — список главных архитектурных изменений и почему так нужно.


### 15. Удаление мёртвого кода

Проверь код на мёртвый код и неиспользуемые элементы:

[ВСТАВИТЬ]

Найди:

Неиспользуемые импорты
Неиспользуемые переменные / функции / классы
Недостижимый код (после return, throw, etc)
Закомментированный код
TODO без конкретных дат
Дублирующуюся логику

Дай: список всего что можно удалить + очищенную версию кода.


---

## Раздел 4. Тесты

### 16. Юнит-тесты для функции

Напиши юнит-тесты для функции на [LANG] с использованием [pytest / jest / vitest / go test]:

[ВСТАВИТЬ ФУНКЦИЮ]

Покрой:

Happy path (типичный успешный сценарий)
Edge cases (пустые входы, очень большие, минимальные, граничные)
Invalid inputs (null, неправильный тип, out of range)
Boundary conditions (0, 1, max, max-1, max+1)
Error handling (что возвращает / как падает на ошибках)

Принципы:

Один test = одна проверка
Описательные названия (test_should_return_zero_when_input_is_empty)
Использовать parametrize / table-driven tests где уместно
Без shared state между тестами

Дай тесты + объяснение какой кейс какой тест покрывает.


### 17. Mocking внешних зависимостей

Напиши тесты для функции, которая использует внешние сервисы:

[ВСТАВИТЬ ФУНКЦИЮ]

Внешние зависимости:

HTTP API: [ОПИСАНИЕ]
БД: [ОПИСАНИЕ]
Файлы: [ОПИСАНИЕ]
Время: [ИСПОЛЬЗУЕТСЯ ЛИ now()]

Требования:

Замокать все внешние вызовы
Тестировать что моки вызваны с правильными аргументами
Тестировать поведение при разных ответах от моков (success, error, timeout)
Использовать [pytest-mock / unittest.mock / jest mocks / sinon]

Дай: тесты с моками + setup/teardown.


### 18. Integration tests

Напиши integration tests для [API endpoint / модуль / workflow]:

[ОПИСАНИЕ]

Контекст:

Stack: [STACK]
Test framework: [FRAMEWORK]
Тестовая БД: [SETUP]

Требования:

Реальные вызовы (не моки) внутри своей системы
Очистка состояния после каждого теста
Тестировать end-to-end сценарии (создание → чтение → обновление → удаление)
Тестировать edge cases (concurrent requests, large payloads, etc)

Дай: тесты + setup/teardown + fixtures.


### 19. Property-based testing

Напиши property-based tests для функции:

[ВСТАВИТЬ ФУНКЦИЮ]

Используй [Hypothesis / fast-check / QuickCheck for X].

Properties для тестирования:

Идемпотентность: f(f(x)) == f(x)
Симметричность: f(x, y) == f(y, x)
Инверсия: g(f(x)) == x
Сохранение длины / объёма
[Другие свойства специфичные для функции]

Для каждого property — отдельный test и объяснение почему оно должно выполняться.


### 20. Test coverage analysis

Анализирую покрытие тестами модуля:

[ВСТАВИТЬ КОД И СПИСОК ТЕКУЩИХ ТЕСТОВ]

Дай:

Какие линии / ветки не покрыты тестами
Какие edge cases упущены
Какие ошибочные пути не тестируются
Дополнительные тесты которые стоит написать (с приоритизацией)
Что можно безопасно НЕ тестировать (тривиальный код)


---

## Раздел 5. Дебаг

### 21. Разбор ошибки

У меня ошибка:

Сообщение: [ВСТАВИТЬ ERROR MESSAGE]

Stack trace: [ВСТАВИТЬ]

Релевантный код: [ВСТАВИТЬ]

Что делал: [ОПИСАНИЕ ДЕЙСТВИЙ]

Контекст: [ВЕРСИИ, ОС, ENVIRONMENT]

Помоги:

Объясни что эта ошибка означает (для джуна)
Топ-3 вероятных причины
Для каждой — как проверить
Как исправить (с готовым кодом)
Как избежать этой ошибки в будущем


### 22. Performance debugging

Этот код работает медленно:

[ВСТАВИТЬ]

Симптомы:

Время выполнения: [N] сек на типичном входе
Ожидаемое время: [N] мс
Профилирование показывает: [ИЛИ "ещё не делал"]

Проанализируй:

Самые подозрительные места (по сложности и частоте вызовов)
Возможные причины медленности
План оптимизации в порядке приоритета
Рефакторинг с оптимизацией
Метрики до/после что измерять


### 23. Memory leak

У меня memory leak в приложении:

Стек: [ОПИСАНИЕ] Симптомы: память растёт на [N] МБ за [ВРЕМЯ] Подозреваемый код: [ВСТАВИТЬ ИЛИ "пока не знаю"]

Помоги найти:

Типичные паттерны утечек в [STACK]
Что проверить в моём коде
Какие инструменты использовать для профилирования
План диагностики шаг за шагом
Когда что-то найдём — как исправить


### 24. Concurrency bug

У меня intermittent bug, который воспроизводится только под нагрузкой:

[ВСТАВИТЬ КОД]

Симптомы:

Происходит [N] раз из [M] запросов
Воспроизводится только при > [N] req/sec
Логи показывают: [ОПИСАНИЕ]

Подозрение на race condition.

Помоги:

Найти места где может быть race condition
Понять как именно происходит конфликт
Предложить fix (mutex / atomic / queue / lock-free / etc)
Объяснить trade-offs выбранного подхода
Как протестировать что fix работает


### 25. Production incident

У меня production incident:

Симптом: [ОПИСАНИЕ] Когда началось: [ВРЕМЯ] Что изменилось: [ДЕПЛОИ, КОНФИГ, ИНФРА]

Логи: [ВСТАВИТЬ] Метрики: [CPU, MEM, RPS, ERROR RATE]

Помоги:

Триаж — что критично, что подождёт
Гипотезы топ-5 причин
Quick mitigation — что сделать прямо сейчас чтобы остановить кровь
Diagnostic plan — что проверять в каком порядке
Long-term fix — после остановки инцидента

Я в стрессе, отвечай чётко и без воды.


---

## Раздел 6. Архитектура

### 26. Выбор архитектуры

Я разрабатываю [ОПИСАНИЕ ПРОДУКТА]. Решаю архитектурный вопрос:

Выбор: [ВАРИАНТ A] vs [ВАРИАНТ B]

Контекст:

Размер команды: [N]
Опыт в [STACK]: [ОПИСАНИЕ]
Ожидаемая нагрузка: [МЕТРИКИ]
Ожидаемый рост: [МАСШТАБ]
Бюджет: [МАЛЫЙ/СРЕДНИЙ/БОЛЬШОЙ]
Time-to-market: [СРОЧНО / ЕСТЬ ВРЕМЯ]
Existing infrastructure: [ОПИСАНИЕ]

Дай:

Объективное сравнение по критериям
Pros/cons каждого варианта в моём контексте
Hidden costs которые не сразу видны
Рекомендация с обоснованием
Risk mitigation для выбранного варианта


### 27. Системный дизайн

Помоги спроектировать систему:

Задача: [WHAT WE'RE BUILDING]

Требования:

Functional: [ЧТО ДОЛЖНА ДЕЛАТЬ]
Non-functional:
- Throughput: [N] req/sec
- Latency: [N] ms p95
- Availability: [99.X]%
- Data: [VOLUME, GROWTH RATE]
- Constraints: [BUDGET, TEAM, etc]

Дай:

High-level architecture (компоненты и их взаимосвязь)
Database schema (основные таблицы / collections)
API design (главные endpoints)
Scalability plan (где горизонтальное масштабирование, где вертикальное)
Bottlenecks (где будут проблемы первыми)
Trade-offs (что мы выбираем и от чего отказываемся)
Deployment strategy (где хостить, как деплоить)


### 28. Database schema design

Спроектируй схему БД для [ОПИСАНИЕ ДОМЕНА].

СУБД: [Postgres / MySQL / MongoDB / etc]

Сущности: [СПИСОК]

Главные операции (по частоте):

[READ HEAVY] выборка X по Y
[WRITE] создание Z
...

Объёмы:

Записей через год: [N]
Чтения: [N]/sec
Записи: [N]/sec

Дай:

Схему таблиц с типами полей
Индексы (какие, почему, на чём economy)
Constraints (foreign keys, unique, check)
Partitioning (если нужно)
Денормализация где оправдана
Миграционный план если есть legacy-схема


### 29. Microservices разбиение

У меня монолит на [STACK]. Думаю разбить на микросервисы.

Текущая структура: [ВЫСОКОУРОВНЕВОЕ ОПИСАНИЕ]

Команда: [N] человек

Боли монолита:

[ЧТО НЕ РАБОТАЕТ ХОРОШО]

Помоги:

Стоит ли разбивать вообще (часто = нет)
Если да — какие сервисы выделять (boundaries)
Контракты между сервисами (sync/async, REST/gRPC/events)
Какие новые проблемы появятся (distributed tracing, eventual consistency, etc)
План миграции (strangler pattern, по частям)
Что точно НЕ выделять в отдельные сервисы


### 30. Event-driven architecture

Хочу перейти на event-driven архитектуру.

Текущая система: [ОПИСАНИЕ] Что хочу решить: [МАСШТАБ / DECOUPLING / RESILIENCE]

Помоги:

Выбор брокера — Kafka / RabbitMQ / Redis Streams / NATS / SQS
Event schema design — schemas, versioning, evolution
Идемпотентность — как обеспечить
Order guarantees — какие нужны и как обеспечить
Failure handling — DLQ, retry policies, circuit breakers
Observability — distributed tracing, monitoring
Тестирование — как тестировать event-driven систему

Дай готовый план миграции с пошаговыми этапами.


---

## Бонус: техники, специфичные для кода

### Code in context (используйте Code Agent)

В [Lumen AI](https://lumen-ai.ru) есть [Code Agent](/agents-ai/code) — специализированный агент с:

- **6 режимами:** генерация / объяснение / рефакторинг / дебаг / тесты / review
- **15 языков** программирования
- **Подсветкой синтаксиса**
- **Запуском кода в песочнице** (Python, JavaScript, Go) для проверки
- **Историей сессий**

Удобнее чем работать в чате — не нужно повторять промпты для каждой задачи.

### Multi-step debugging

Сложные баги решайте через диалог, а не один промпт:

Запрос 1: "Вот код и ошибка. Какие 5 гипотез почему не работает?" [ответ]

Запрос 2: "Проверим первую гипотезу. Что для этого нужно?" [следуете инструкциям, проверяете]

Запрос 3: "Гипотеза не подтвердилась. Проверим вторую." ...


### Контекст всей кодовой базы

Для проектов >100K строк используйте модели с большим контекстом:

- **Llama 4 Scout** — 10M токенов (помещается весь репозиторий до 150K строк)
- **Gemini 3.1 Pro** — 1M токенов (~150K строк)
- **GPT-5.5 / Claude Opus 4.7** — 1M токенов

Запрос: «Вот вся моя кодовая база. Где у меня дублирование, которое можно вынести в общий модуль?»

---

## Связанные материалы

- [100 готовых промптов на все случаи](/blog/luchshie-promty-chatgpt)
- [Промпт-инженерия — основы](/blog/promt-inzheneriya-osnovy)
- [Code Agent — как работает](/agents-ai/code)
- [Сравнение моделей для разработки](/blog/gpt5-vs-claude-opus)

---

## Итог

**AI в разработке 2026 — это не "может ли заменить", а "как использовать максимально".** Команды с правильным процессом промптинга:

- Пишут код в 2-3 раза быстрее
- Делают code review в 5 раз быстрее
- Покрывают 80%+ тестами без выгорания
- Документируют код на ходу
- Меньше тратят на дебаг

Главные принципы:
1. Используйте правильную модель под задачу
2. Дайте AI контекст (не только код, но и почему)
3. Используйте Code Agent для рутины
4. Сохраняйте удачные промпты
5. Не доверяйте слепо — проверяйте критичные места

**Попробовать:** [Code Agent в Lumen AI](https://lumen-ai.ru/agents-ai/code) — 3 запроса в день бесплатно, 20 на Pro за 299 ₽/мес. Поддерживает 15 языков, песочницу, историю сессий.

Какую модель выбрать для какой задачи

Раздел 1. Генерация нового кода

1. Production-ready функция

2. API endpoint

Похожие статьи