Взять старый код и попросить AI «сделать его лучше» — почти всегда плохая идея. Получите красиво отформатированное месиво, которое внешне выглядит чище, но тихо ломает какую-нибудь логику на третьем экране. Legacy-код не прощает небрежных промтов.
2026/04/09
Взять старый код и попросить AI «сделать его лучше» — почти всегда плохая идея. Получите красиво отформатированное месиво, которое внешне выглядит чище, но тихо ломает какую-нибудь логику на третьем экране. Legacy-код не прощает небрежных промтов.
Хорошая новость: правильно составленный промт превращает AI в очень педантичного коллегу-ревьюера, который видит весь проект, понимает зависимости и не трогает то, что вы не просили трогать.
Ниже — 5 промтов, которые реально работают. Для каждого расскажем, что он делает, когда использовать и какую модель взять в 2026 году.
Прежде чем к промтам — быстрый обзор актуальных моделей, потому что выбор модели влияет на результат не меньше, чем формулировка.
| Модель | Цена (input/output за 1M токенов) | SWE-bench | Лучше всего подходит |
|---|---|---|---|
| Claude Opus 4.6 | $5 / $25 | 80.8% | Сложная архитектурная логика, god objects, понимание неочевидных зависимостей |
| Claude Sonnet 4.6 | $3 / $15 | 79.6% | Рефакторинг конкретных функций и модулей, лучший баланс цена/качество |
| Gemini 3.1 Pro | $2 / $12 | 80.6% | Большие кодовые базы (1M токенов контекста), миграция зависимостей |
| GPT-5.4 | $2.5 / $15 | ~80% | Написание тестов, терминальные задачи, быстрые итерации |
| DeepSeek V3.2 | $0.28 / $0.42 | 72-74% | Простые рефакторинги, когда важна экономия |
Главный вывод по выбору модели: Claude Sonnet 4.6 — стартовая точка для большинства задач. Если код сложный и непонятный — берите Opus 4.6. Если проект огромный и нужно держать в памяти много файлов одновременно — Gemini 3.1 Pro с его 1M токенами контекста по умолчанию.
Инструменты для запуска этих промтов: Claude Code (терминальный агент), Cursor или Windsurf (IDE). Также отлично работает Aider — бесплатный open-source инструмент, где вы сами выбираете модель.
Модель: Claude Opus 4.6 или Sonnet 4.6
Когда использовать: Перед любым серьезным рефакторингом. Нельзя трогать код, не понимая, что он делает и что может сломаться.
Самая частая ошибка при работе с legacy — сразу просить AI «исправить». Сначала нужно получить карту проблем. Этот промт делает именно это: AI анализирует код, не меняет ни строчки и отдает структурированный отчет.
Ты — опытный технический ревьюер. Твоя задача — провести аудит кода
и выявить все проблемы БЕЗ внесения каких-либо изменений.
НЕ ИЗМЕНЯЙ КОД. Только анализируй и описывай.
Проанализируй следующий код и составь отчет по структуре:
## 1. Что этот код делает
Краткое описание логики (2-4 предложения).
## 2. Критические проблемы (нужно исправить срочно)
Для каждой проблемы укажи:Строка или функцияВ чем проблемаПочему это опасно## 3. Запахи кода (Code Smells)
Перечисли антипаттерны: дублирование, слишком длинные функции,
god objects, магические числа, неочевидные зависимости.
## 4. Что может сломаться при рефакторинге
Укажи неочевидные зависимости и побочные эффекты, которые надо
учесть, прежде чем трогать этот код.
## 5. Рекомендуемая последовательность рефакторинга
Что исправить первым, вторым, третьим — с обоснованием порядка.
Код для анализа:
[ВСТАВИТЬ КОД]Почему это работает: Модель не пытается «починить» — она думает и объясняет. Это важно: AI при немедленном рефакторинге часто убирает «лишний» код, который на самом деле закрывает какой-то edge-case. Аудит сначала — ошибок меньше.
Что делать с результатом: Прочитайте раздел 4 особенно внимательно. Именно там AI покажет зависимости, которые легко пропустить. Потом переходите к следующим промтам последовательно, как указано в разделе 5.
Модель: Claude Sonnet 4.6 или GPT-5.4
Когда использовать: Когда функция работает, но код в ней — ужас. Нужно сделать читаемее, не трогая логику.
Это самый используемый тип рефакторинга. Ключевое слово в промте — «поведение не должно измениться». Без него AI начинает «улучшать» логику и ломает что-нибудь неожиданное.
Ты — опытный разработчик, специализирующийся на чистом коде.
Задача: отрефакторить функцию ниже. Внешнее поведение должно
остаться АБСОЛЮТНО идентичным — те же входные и выходные данные,
те же побочные эффекты, те же крайние случаи.
Что разрешено:Переименовать переменные и параметры для ясностиРазбить на вспомогательные функции (если они не меняют логику)Убрать дублирование внутри функцииУпростить условные конструкции (if/else) без изменения условийДобавить JSDoc / комментарии к неочевидным местамЧто запрещено:
Менять логику, даже если она кажется неправильнойУбирать проверки, даже если они кажутся лишнимиДобавлять новую функциональностьМенять возвращаемые типы или структуру данныхПосле рефакторинга напиши:
1. Что именно ты изменил и почему
2. Какие места оставил как есть и почему
3. Что вызвало сомнение — если такое было
Функция:
[ВСТАВИТЬ ФУНКЦИЮ]Контекст проекта (язык, фреймворк, особенности):
[НАПРИМЕР: Python 3.11, Django 4.2, REST API, код работает в продакшне]
Почему это работает: Явный список «разрешено/запрещено» блокирует самодеятельность модели. Раздел «что вызвало сомнение» — особенно ценный: AI иногда находит баги, которые вы и не планировали искать.
Лайфхак: Добавьте в конец промта: «Перед ответом проверь: если запустить оба варианта функции с одинаковыми входными данными, результат будет идентичным?» Это заставляет модель самопроверяться.
Модель: Claude Opus 4.6
Когда использовать: Есть класс или модуль, который «знает всё и делает всё» — 500+ строк, 20+ методов, зависимости во все стороны. Один из самых сложных случаев рефакторинга.
God Object — классическая legacy-проблема. AI без правильного промта либо просто переименует методы, либо создаст такой же god object, только поделенный на файлы. Правильный промт заставляет думать об ответственностях.
Ты — архитектор программного обеспечения с экспертизой в SOLID и
Domain-Driven Design.
Перед тобой God Object — класс, который взял на себя слишком много
ответственностей. Твоя задача — спланировать его декомпозицию.
ШАГ 1: АНАЛИЗ ОТВЕТСТВЕННОСТЕЙ
Прочитай класс и выпиши все его ответственности списком.
Каждая ответственность — это отдельная «причина для изменения» по SRP.
Формат: "[Название ответственности]: [какие методы/поля к ней относятся]"
ШАГ 2: ПРЕДЛОЖЕНИЕ НОВОЙ СТРУКТУРЫ
На основе анализа предложи набор новых классов/модулей.
Для каждого нового класса укажи:Название и его смыслКакие методы из оригинального класса переходят сюдаЗависимости от других новых классовШАГ 3: ПЛАН МИГРАЦИИ
Опиши пошаговый план, как перейти от текущей структуры к новой
БЕЗ остановки работы продукта. Учти:Какие шаги можно делать независимоГде нужно сохранить временные обёртки для обратной совместимостиКак проверить каждый шаг (что тестировать)ШАГ 4: ПРИМЕР РЕАЛИЗАЦИИ
Реализуй один из новых классов полностью — тот, который несет
наибольший риск при переносе. Покажи, как он взаимодействует
с остальными.
Важно: не пиши весь рефакторинг сразу. Сначала только план.
Мы будем реализовывать поэтапно.
Класс для декомпозиции:
[ВСТАВИТЬ КОД КЛАССА]
Язык/фреймворк: [НАПРИМЕР: TypeScript, Next.js 14, PostgreSQL]
Есть ли тесты сейчас? [ДА/НЕТ]Почему это работает: Принуждение модели сначала думать («ШАГ 1: АНАЛИЗ»), потом проектировать, потом только реализовывать — это ключевое. Если просто попросить «раздели класс», AI начнет писать код немедленно и потеряет архитектурное мышление.
Важное уточнение: God Object декомпозиции — задача для Opus 4.6, не для Sonnet. Sonnet хорошо справляется с конкретными задачами, но для архитектурных решений, где нужно держать в голове много связей и «думать параграфами», Opus дает заметно лучший результат.
Модель: GPT-5.4 или Gemini 3.1 Pro
Когда использовать: Код работает, но тестов нет. Перед любым рефакторингом нужно сначала зафиксировать текущее поведение тестами — иначе вы не узнаете, что сломали.
Это контринтуитивный совет: не пишите тесты «правильно», пишите тесты, которые фиксируют существующее поведение. Даже если оно кажется странным.
Ты — разработчик, который пишет тесты для legacy-кода.
Твоя задача — написать тесты, которые ФИКСИРУЮТ текущее поведение
кода. Не то, как код должен работать в теории — а то, как он
работает СЕЙЧАС, включая странные и неочевидные случаи.
Принципы:
1. Каждый тест должен провалиться, если кто-то изменит логику функции
2. Тестируй граничные случаи: пустые значения, null, 0, очень большие числа
3. Если функция имеет побочные эффекты — тестируй их тоже
4. Не рефакторь код ради тестируемости — пиши тесты под то, что есть
Формат каждого теста:Название: что именно проверяет (на русском)Комментарий: почему этот случай важенКод тестаДополнительно:
Если код сложно тестировать напрямую — напиши об этом в комментариии предложи минимальный обёрточный класс, который не меняет логику,
но делает код тестируемымУкажи, какие части кода ты не смог покрыть и почемуФреймворк для тестов: [НАПРИМЕР: Jest, pytest, JUnit, Go testing]
Код для тестирования:
[ВСТАВИТЬ КОД]Почему это работает: Акцент на «фиксируй текущее поведение» — важен. AI по умолчанию хочет писать тесты под «правильную» логику и пропускает странные edge-cases. Это ровно то, что потом ломается при рефакторинге.
Почему GPT-5.4 или Gemini 3.1 Pro: Для написания тестов не нужен самый дорогой Opus — это механическая задача. GPT-5.4 отлично справляется с терминальными и тестовыми задачами, Gemini 3.1 Pro дешевле и при этом показывает сопоставимый результат на SWE-bench. Сэкономьте Opus для архитектурных решений.
Модель: Gemini 3.1 Pro (за счет 1M токенов контекста)
Когда использовать: Проект использует устаревшую библиотеку или старую версию фреймворка. Нужно обновиться без поломки продакшна.
Это один из самых рискованных видов рефакторинга, потому что изменения затрагивают много файлов, а контекст нужен огромный. Именно здесь контекстное окно Gemini 3.1 Pro в 1M токенов дает реальное преимущество.
Ты — старший разработчик, специализирующийся на миграциях.
Задача: спланировать безопасную миграцию с [СТАРАЯ ЗАВИСИМОСТЬ v.X]
на [НОВАЯ ЗАВИСИМОСТЬ v.Y].
ЧАСТЬ 1: АНАЛИЗ СОВМЕСТИМОСТИ
Изучи список изменений между версиями и составь:Список breaking changes (что перестанет работать сразу)Список deprecated features (что пока работает, но скоро нет)Список новых возможностей, которые можно использоватьЧАСТЬ 2: ИНВЕНТАРИЗАЦИЯ ИСПОЛЬЗОВАНИЯ
Вот код проекта, где используется старая зависимость:
[ВСТАВИТЬ КОД ИЛИ СПИСОК ФАЙЛОВ]
Найди все места, где используются:Функции/методы, которые изменились или удаленыПаттерны использования, которые больше не работаютКонфигурации, которые нужно обновитьФормат: [Файл, строка] — [что используется] — [нужное изменение]
ЧАСТЬ 3: ПЛАН МИГРАЦИИ
Раздели на этапы так, чтобы после каждого этапа приложение
продолжало работать:
Этап 0: Подготовка (без изменения кода)Что нужно сделать до начала миграцииКак убедиться, что тесты покрывают затронутые частиЭтап 1-N: Последовательные шаги
Для каждого шага:Что изменяемКак проверяем, что ничего не сломалосьКак откатиться, если что-то пошло не такЧАСТЬ 4: ПЕРВЫЙ ШАГ
Реализуй только первый этап полностью с кодом.
Текущая версия: [НАПРИМЕР: React 17, Node.js 16, Mongoose 5]
Целевая версия: [НАПРИМЕР: React 19, Node.js 22, Mongoose 8]
Среда: [production / staging / local]Почему это работает: Миграция зависимостей — это не «заменить импорты». Это анализ, инвентаризация и поэтапное движение с возможностью отката. Промт принуждает AI думать именно так.
Про контекст: При миграции часто нужно загрузить несколько десятков файлов одновременно. Gemini 3.1 Pro с дефолтным 1M токенов справится там, где Sonnet 4.6 (200k по умолчанию) начнет терять контекст.
На практике эти пять промтов работают как последовательность, а не как независимые инструменты.
Сценарий: есть модуль на 800 строк, который надо привести в порядок
Лиза: «Когда мы разгребали кодовую базу NeuroScribe после быстрого MVP-роста, именно такая последовательность спасла нас от багов. Без аудита сначала и тестов перед рефакторингом — мы бы сломали что-нибудь и потратили часы на поиск причины. AI не заменяет дисциплину, но с правильными промтами значительно ускоряет всё остальное.»
Несколько правил, которые спасут вас от типичных ошибок.
Никогда не давайте AI весь проект сразу без контекста. «Отрефакторь этот репозиторий» — плохой промт. Разбивайте на конкретные задачи: один модуль, одна функция, одна зависимость.
Всегда уточняйте язык, фреймворк и версию. Claude Sonnet 4.6 хорошо знает Python, но «чистый Python» и «Django 4.2 с кастомными мидлварами» — разные контексты. Чем точнее — тем лучше результат.
Проверяйте diff перед тем, как принять изменения. Особенно в Aider и Claude Code, где AI вносит изменения напрямую. Всегда смотрите, что именно изменилось. Иногда AI убирает строчку, которая кажется лишней, но закрывает race condition.
Используйте режим Plan перед сложными задачами. В Claude Code это /plan, в Aider — Architect Mode. Сначала AI составляет план, вы его проверяете, потом только выполнение. Это убирает половину неожиданных изменений.
Модель не знает вашу бизнес-логику. Если функция делает что-то неочевидное по причине особенностей вашего домена — объясните это в промте. «Эта проверка нужна, потому что…» предотвращает удаление важной логики.
Промты выше работают в любом AI-чате. Но для рефакторинга реального кода удобнее использовать инструменты, которые работают напрямую с файлами:
Весь каталог AI-инструментов для разработки — здесь.
Нужна помощь с выбором стека или разбором конкретного проекта?
Запишитесь на консультацию к Максиму.
Можно ли доверять AI весь рефакторинг без проверки? Нет. AI — это очень хороший черновик, а не финальный результат. Всегда проверяйте diff, запускайте тесты и читайте объяснения, которые модель дает к своим изменениям.
Какую модель взять, если я не знаю, насколько сложный у меня код? Начните с Claude Sonnet 4.6. Если результат кажется поверхностным или AI теряет контекст между разными частями проекта — переходите на Opus 4.6.
Эти промты работают только в Claude или в любой модели? В любой. Промты написаны независимо от модели. GPT-5.4 и Gemini 3.1 Pro дают хорошие результаты на тех же промтах. Разница будет в глубине анализа на сложных задачах.
Что делать, если AI начинает менять логику, хотя я попросил только почистить код? Это называется «overengineering» — частая проблема. Добавьте в промт жесткое ограничение: «Если ты не уверен, нужно ли это изменение — оставь как есть. Молчание лучше неправильного улучшения.»
Сколько кода можно отдавать в один запрос? Зависит от модели. Claude Sonnet 4.6 — 200k токенов (примерно 150k символов кода). Gemini 3.1 Pro — 1M токенов по умолчанию. Для больших файлов разбивайте на части или используйте Claude Code / Aider, которые сами управляют контекстом.
Как не потерять рабочий продакшн во время рефакторинга? Железное правило: рефакторинг делается только на отдельной ветке. Тесты пишутся до, а не после. Каждый шаг — отдельный коммит. И промт 5 (план миграции поэтапно) — следуйте ему буквально.
Legacy-код — код, который уже работает в продакшне, обычно написанный давно и с нарушениями современных практик. Не «плохой код» по определению — просто код, который сложно менять.
Рефакторинг — изменение структуры кода без изменения его внешнего поведения. Результат работы программы остается тем же — меняется только как он достигается.
God Object — антипаттерн: класс или модуль, который «знает всё» и делает всё. Нарушает принцип единственной ответственности (SRP) и создает хаотичные зависимости.
SRP (Single Responsibility Principle) — принцип единственной ответственности: каждый класс/функция должны иметь только одну причину для изменения.
SOLID — пять принципов объектно-ориентированного проектирования: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion.
Code Smell / Запах кода — признаки проблем в коде: дублирование, слишком длинные функции, магические числа, непонятные имена. Не баги, но сигналы, что что-то не так.
Breaking change — изменение в библиотеке или API, которое ломает существующий код при обновлении.
Edge case / Граничный случай — нестандартные входные данные: пустые строки, нулевые значения, очень большие числа, null. Часто именно здесь прячутся баги.
Diff — отображение изменений: что было в коде до, что стало после. Обязательно проверяйте перед тем, как принять AI-правки.
SWE-bench — бенчмарк для оценки AI-моделей на реальных задачах из GitHub: починить баг, добавить фичу, пройти тесты. Процент = доля успешно решённых задач.
Статья подготовлена командой VibeCoderz — крупнейшей базы знаний по AI IDE и вайбкодингу в СНГ. Последнее обновление: март 2026.