BotHub on Habr presented six prompt patterns for refactoring, tests, and databases

BotHub выпустил на Хабре большой практический материал о том, как писать промпты для задач разработчика, а не просто просить ИИ «починить код». В центре статьи — шесть готовых паттернов, которые помогают разбирать легаси, рефакторить сервисы, писать тесты и искать узкие места в SQL.

Шесть рабочих ролей

Статья построена вокруг шести сценариев, где нейросеть получает не общую просьбу, а конкретную профессиональную роль. Для Python-кода это «хирург-архитектор», который раскладывает жирный FastAPI-роутер по слоям router, service и repository. Для TypeScript — «терпеливый ментор», который не просто переписывает запутанную функцию, а сначала объясняет её логику, крайние случаи и слабые места.

Для React — «QA-параноик», который пишет тесты не только на happy path, но и на ошибки API, двойные клики и состояние загрузки. Во второй половине материала BotHub показывает ещё три роли. «Полиглот-транслятор» нужен для миграции с PHP на современный Python без переноса старых привычек и хаков из одного языка в другой.

«Жестокий ревьюер» используется для аудита Go-кода, где модель ищет гонки данных, утечки и path traversal. А «говорящий с базами данных» работает уже на уровне DBA: он получает не только SQL-запрос, но и EXPLAIN ANALYZE, после чего предлагает переписанный запрос и подходящие индексы. Главная идея в том, что один и тот же LLM меняет качество ответа в зависимости от постановки задачи.

Если запрос звучит как «сделай красиво», результат будет расплывчатым. Если же в промпте зафиксированы роль, стек, ограничения, формат ответа и критерии качества, модель начинает работать как узкий специалист, а не как универсальный болтун.

Как устроен промпт BotHub делает акцент не на магических фразах, а на структуре.

В удачных примерах всегда есть несколько одинаковых опор: кто именно отвечает, какую задачу решает, на каком стеке работает, что нельзя ломать и в каком виде нужно вернуть результат. За счёт этого модель меньше фантазирует и чаще попадает в реальные требования проекта. Особенно это заметно в примере с React-тестами, где заранее указаны Vitest, React Testing Library, мокирование fetch и формат AAA.

• Чёткая роль: Staff Engineer, Senior Frontend Developer, QA Automation Engineer или DBA.
• Ясные ограничения: сохранить бизнес-логику, не хвалить код, использовать конкретные паттерны и фреймворки.
• Пошаговая структура ответа: саммари, разбор, edge cases, исправленный код или список индексов.
• Глубокий контекст: кусок легаси, уязвимый сниппет, лог EXPLAIN ANALYZE, стек проекта.

«Будь предельно критичен, не хвали код».

Эта фраза из секции про security review хорошо показывает общий подход статьи. Автор буквально убирает у модели пространство для вежливой болтовни и заставляет её концентрироваться на проблемах. Тот же принцип работает и в других частях материала: когда в задаче на миграцию прямо запрещают переносить PHP-хаки в Python, а в задаче на SQL просят искать точное узкое место по плану выполнения, качество ответа заметно растёт.

Не вместо разработчика При этом статья не обещает волшебной кнопки.

В примере с медленным PostgreSQL-запросом BotHub отдельно показывает, что без EXPLAIN ANALYZE нейросеть не увидит физическое поведение базы и начнёт гадать вслепую. В примере с Go-сервисом польза тоже появляется не из «магии ИИ», а из того, что промпт направляет модель на конкретные классы проблем: race conditions, path traversal, ошибки обработки и утечки. То есть нейросеть здесь выступает не автономным архитектором, а ускорителем для уже понятной инженерной задачи.

Практическая ценность материала в другом: он снижает когнитивную перегрузку, с которой разработчики сталкиваются в легаси и рутинных ревью. Вместо хаотичного диалога с ботом статья предлагает набор повторяемых шаблонов, которые можно быстро адаптировать под свой стек. По сути, это инструкция по переходу от случайных запросов к рабочему интерфейсу с LLM, где разработчик задаёт рамки, а модель заполняет их полезным содержанием.

Что это значит

Материал BotHub показывает сдвиг в зрелости AI-инструментов для кодинга: выигрывает уже не тот, кто просто открыл чат, а тот, кто умеет формулировать инженерную задачу с нужным контекстом. Для команд это означает более быстрый рефакторинг, осмысленные тесты и меньше времени на разбор чужого кода.