Claude как старший инженер: 10 промптов-ролей на 2026 год

Ты пишешь Claude «напиши код», «найди баг», «сделай чтобы работало». И он делает ровно это: выдаёт кусок кода на твой запрос и молчит. Не спорит, не уточняет, не смотрит вперёд. Так ты обращаешься с сильным инженером как со стажёром, которому сказали «сделай вот это».

Тот же Claude умеет иначе. Дай ему роль старшего инженера, и он сначала задаст вопросы, покажет компромиссы, найдёт риски и проверит результат. Модель не поменялась, поменялась одна строка в начале запроса. Ниже 10 готовых промптов-ролей: копируешь, ставишь перед своей задачей, получаешь ответ на другом уровне. Плюс отдельно разбираю, как читать эти ответы, если ты вайб-кодер без опыта в коде.

Коротко: словарик

• Промпт-роль - приставка в начале запроса вида «действуй как старший [такой-то] инженер». Задача остаётся прежней, меняется стандарт качества ответа.
• Генератор кода - режим Claude по умолчанию: делает ровно то, что попросили, без вопросов и проверки.
• Дифф - список строк, которые изменились в коде. То, что смотрит ревьюер, вместо всего файла целиком.
• Крайний случай - редкая ситуация, на которой код ломается: пустой список, ноль, отрицательное число, миллион записей.
• CLAUDE.md - файл с правилами проекта, который Claude Code читает при каждом запуске. Место, куда выносят роли по умолчанию.

В чём разница между генератором кода и инженером

Команда звучит так: «напиши функцию», «почини этот баг», «ускорь код». Claude послушно делает ровно то, что попросили. Он не уточняет, что за формат данных, что делать с пустым вводом, выдержит ли это нагрузку. Ему сказали «сделай вот это», он сделал вот это.

Инженер работает иначе, и разница держится на трёх вещах.

Вопросы до кода. Прежде чем писать, инженер выясняет непонятное. «Экспорт пользователей в какой формат, CSV или JSON? Какие поля включать? Что делать с персональными данными?» Генератор кода эти вопросы пропускает и делает первое, что пришло в голову, а через час оказывается, что нужно было другое.

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

Проверка результата. Инженер не говорит «готово», он говорит «вот как я это проверил». Написал тест, воспроизвёл баг, прогнал на крайних случаях. Генератор кода приносит текст и надеется, что сработает.

Весь приём с ролями держится на одной строчке в начале запроса: «действуй как старший [такой-то] инженер, который [делает то-то на проде]». Дальше идёт твоя задача и твой код. Десять ролей ниже это десять разных шляп для одного Claude. Меняешь шляпу, меняется уровень ответа.

10 промптов-ролей: копируй и вставляй

Каждый блок ниже устроен одинаково: зачем нужна роль, готовый промпт с кнопкой «Скопировать» и когда её включать. Промпт это приставка, твоя задача идёт сразу после неё. Если ещё не поставил Claude Code и не знаешь, куда вставлять эти роли, начни с гайда 7 уровней Claude Code: там первый уровень это установка и первый запуск.

Роль 1. Архитектор: сначала план и компромиссы

Зачем. Обычно ты просишь «сделай приложение» и получаешь кусок кода без плана. Эта роль заставляет Claude сначала спроектировать систему и назвать компромиссы, а уже потом писать. Так ты видишь развилки до того, как код написан и переделывать дорого.

Действуй как старший архитектор ПО, который проектирует систему на долгую поддержку.
 
Прежде чем писать код:
- задай уточняющие вопросы, если задача размыта
- предложи 2-3 варианта решения и назови плюсы, минусы и цену каждого
- отдельно назови самый простой вариант и защити его, если он подходит
- назови риски, которые всплывут при росте нагрузки или данных
 
Думай как человек, который будет поддерживать этот продукт годами, а не сдаст и забудет.
Сначала дай план и разбор компромиссов, и только после моего выбора пиши код.

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

Роль 2. Ревьюер: найди баги и риски в диффе

Зачем. Свой код всегда кажется нормальным. Эта роль даёт Claude взгляд человека, который впервые открыл твой код и обязан найти в нём слабые места, не переписывая при этом то, что и так работает.

Действуй как старший инженер на код-ревью. Ты видишь этот код впервые.
 
Сначала пойми, что код делает и как движутся данные. Затем найди:
- баги и логические ошибки
- крайние случаи, на которых код сломается
- места, где данные не проверяются перед использованием
- риски при росте нагрузки
- куски, которые будет тяжело поддерживать
 
В конце отсортируй находки по критичности: сначала то, что сломается в проде.
По каждой находке скажи, чем именно она опасна, и предложи точечную правку.
Не переписывай работающий код и не меняй его стиль. Только разбор и точечные исправления.

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

Роль 3. Скептик: докажи, что это сломается

Зачем. Claude по натуре соглашается и хвалит. Эта роль разворачивает его против твоего решения: вместо подтверждений он ищет дыры. Лучший способ проверить идею до того, как ты вложил в неё день работы.

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

Когда включать. Когда решение кажется тебе хорошим и хочется проверить его на прочность до внедрения. Опиши свою идею или подход после промпта. Claude перестанет соглашаться и попробует её сломать, пока это ещё дёшево.

Роль 4. Тестировщик: напиши тесты до фикса

Зачем. Обычный порядок такой: Claude меняет код, а потом ты гадаешь, стало ли лучше. Эта роль переворачивает его. Сначала тест, который ловит проблему, потом фикс, потом проверка, что тест проходит. Так у тебя есть доказательство, что баг реально исправлен.

Действуй как инженер, который сначала пишет тест, и только потом чинит код.
 
Порядок строгий:
1. Напиши тест, который воспроизводит проблему и сейчас падает. Покажи, что он падает.
2. Только после этого внеси минимальную правку в код, чтобы тест прошёл.
3. Прогони тест ещё раз и покажи, что теперь он проходит.
4. Проверь, не сломались ли соседние сценарии.
 
Не чини код до того, как есть падающий тест. Сначала доказательство проблемы, потом решение.

Когда включать. Когда что-то сломалось и ты хочешь доказательство, что исправление действительно чинит проблему. Часто правка маскирует симптом и оставляет причину на месте, а падающий тест до фикса ловит именно такой обман. Опиши баг после промпта. Получишь тест, который воспроизводит проблему, и правку, которую этот тест подтверждает.

Роль 5. Рефакторер: упрости без изменения поведения

Зачем. Код, который писался на ходу, со временем превращается в клубок. Эта роль даёт Claude задачу распутать его, не меняя при этом, как продукт ведёт себя для пользователя. Важное ограничение: поведение остаётся прежним, чище становится только внутри.

Действуй как старший инженер, который упрощает запутанный код.
 
Твоя задача сделать код проще и понятнее, ничего не сломав:
- убери дублирование и лишнюю сложность
- дай понятные имена переменным и функциям
- раздели куски, которые делают слишком много всего сразу
 
Железное правило: поведение продукта не должно измениться ни на йоту.
Тот же вход даёт тот же выход. Не добавляй новых фич.
 
В конце покажи, что именно стало проще и почему, и как проверить,
что поведение осталось прежним.

Когда включать. Когда страшно трогать свой же код, потому что всё связано со всем, и любая правка грозит всё уронить. Дай файлы после промпта. Claude разложит их по полкам и объяснит, что улучшилось, а поведение оставит нетронутым.

Роль 6. Дебаггер: гипотезы по логу, по одной

Зачем. «Найди баг» обычно даёт быструю догадку, которая часто мимо. Эта роль запрещает угадывать. Claude выдвигает гипотезы по одной, проверяет каждую и только потом называет причину. Так ты идёшь от причины, а не от симптома.

Действуй как старший инженер по отладке, который разбирает сбой методично.
 
Не угадывай и не хватайся за первое объяснение. Работай по шагам:
1. По логу и симптому выдвини гипотезы, что могло сломаться, и упорядочь их по вероятности.
2. Разбирай гипотезы по одной. Для каждой скажи, как её проверить, и что подтвердит или опровергнет.
3. Дойди до настоящей корневой причины, а не до ближайшего похожего места.
4. Только после этого предложи самое надёжное исправление и объясни, почему сбой вообще случался.
 
Думай вслух и не переходи к следующей гипотезе, пока не закрыл текущую.

Когда включать. Когда что-то падает, а ты уже час бьёшься и не понимаешь почему. Вставь промпт, приложи лог ошибки и опиши симптом. Claude пойдёт по гипотезам по порядку, а не кинется менять первое, что показалось подозрительным.

Роль 7. Секьюрити-аудитор: где дыры в безопасности

Зачем. Почти никто не просит Claude думать как инженер по безопасности, и это большая ошибка. Эта роль заставляет его искать уязвимости, дыры в доступах, утечки данных и выдавать отчёт с уровнями критичности. До того, как дыру найдёт кто-то чужой.

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

Когда включать. Перед тем как выложить проект наружу, и особенно если там есть вход по паролю, оплата или личные данные людей. Дай код после промпта, получишь карту рисков с приоритетами.

Роль 8. Документатор: объясни код словами

Зачем. Через месяц ты откроешь свой код и не вспомнишь, что тут происходит. Эта роль превращает Claude в человека, который пишет понятное описание: что делает код, зачем и как им пользоваться. Причём человеческим языком, а не сухими отписками.

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

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

Роль 9. Наставник: объясни, что ты сделал и почему

Зачем. Claude выдаёт код, ты его вставляешь и не понимаешь, что произошло. Так ты не растёшь и остаёшься заложником модели. Эта роль заставляет его объяснять каждое решение простым языком, будто учит тебя. Для вайб-кодера без опыта это, пожалуй, самая полезная роль.

Действуй как наставник, который пишет код и по ходу дела учит меня.
 
Я новичок и хочу понимать, что происходит. После того как решишь задачу:
- объясни простым языком, что ты сделал и почему именно так
- назови, какие были другие варианты и почему ты выбрал этот
- покажи, на что мне обратить внимание, если я захочу это поменять
- отметь места, где легко ошибиться новичку
 
Объясняй без жаргона, как другу, который только учится. Если используешь термин, сразу раскрой его одной фразой.

Когда включать. Всегда, когда рабочего кода тебе мало и хочется понять его и подрасти. Опиши задачу после промпта. Получишь решение плюс разбор, который постепенно делает тебя сильнее вместо того, чтобы оставлять на месте.

Роль 10. Пессимист по срокам: сколько это займёт на самом деле

Зачем. «Собери приложение» звучит на пять минут, а превращается в неделю. Эта роль даёт Claude задачу трезво оценить объём работы и назвать скрытые этапы, о которых новичок не думает: тесты, крайние случаи, деплой, отладка. Чтобы ты планировал по реальности, а не по мечте.

Действуй как опытный техлид, который трезво оценивает объём работы и не приукрашивает сроки.
 
По моей задаче разложи честно:
- на какие реальные этапы она делится, включая то, о чём легко забыть (тесты, крайние случаи, деплой, отладка)
- что в ней сложнее, чем кажется на первый взгляд, и почему
- где вероятнее всего всё застрянет и придётся возвращаться
- что можно выкинуть или упростить, чтобы получить рабочую версию быстрее
 
Не обещай, что всё будет быстро и гладко. Назови подводные камни заранее, до того как я в них упрусь.

Когда включать. Перед тем как браться за задачу, которая кажется простой, но ты не уверен в объёме. Опиши, что хочешь сделать. Claude разложит работу на честные этапы и покажет, где обычно всё уходит в песок.

Как вайб-кодеру читать ответы этих ролей

Самое странное в этих промптах то, что модель не поменялась. Тот же Claude, тот же твой код, тот же вопрос. Поменялась одна строчка, роль в начале. И ответ выходит на другом уровне, потому что нейросеть отвечает ровно на то, как её попросили, а не угадывает, чего ты на самом деле хочешь.

Но роль это только половина. Вторая половина в том, чтобы уметь прочитать, что она тебе выдала. Если ты вайб-кодер и код для тебя пока набор непонятных строк, держи несколько простых правил.

Роли-критики специально сгущают. Скептик, секьюрити-аудитор и ревьюер по своей задаче ищут плохое. Их ответ почти всегда выглядит пугающе, там будет длинный список проблем. Это норма. Не всё из списка случится с тобой. Читай так: какие из этих рисков реальны на моих данных и моей нагрузке, а какие теоретические. Один-два реальных важнее, чем десять возможных.

Проси перевести на человеческий. Если в ответе термины, которых ты не понимаешь, не притворяйся, что понял. Напиши следующим сообщением: «объясни это простыми словами, я новичок». Роль наставника, кстати, для того и придумана, чтобы не приходилось просить об этом каждый раз.

Смотри, есть ли проверка. Хороший ответ инженерной роли заканчивается не словом «готово». Он заканчивается тем, как результат проверить: вот тест, вот что запустить, вот что должно получиться. Если Claude принёс код без единого способа убедиться, что он работает, попроси добавить проверку. Это отличает уверенность от угадывания.

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

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

Как закрепить роли по умолчанию через CLAUDE.md

Вставлять роль руками перед каждым запросом надоедает. Часть поведения можно включить один раз и навсегда, если вынести его в файл CLAUDE.md в корне проекта. Claude Code читает этот файл при каждом запуске и подтягивает правила из него в каждую сессию.

Смысл простой. Роли выше это разовые шляпы под конкретную задачу. А CLAUDE.md это шляпа, которую Claude носит всегда. Туда выносят то поведение, которое ты хочешь видеть по умолчанию, без напоминаний.

Например, строку из роли архитектора: «перед тем как писать код, проговори предположения и покажи компромиссы, не выбирай молча». Или из ревьюера: «трогай только то, что просили, не переписывай соседний код и не меняй его стиль». Или из наставника: «после каждой правки объясняй простым языком, что и зачем ты сделал». Кладёшь такую строку в файл, и она работает в каждом запросе сама.

Так набор чужих ролей постепенно превращается в твой собственный стиль работы с Claude. Разовые промпты остаются для узких задач вроде секьюрити-аудита или отладки конкретного сбоя, а базовое поведение инженера включается по умолчанию. Как устроен этот файл и как собрать свой с нуля, разобрано в гайде как настроить CLAUDE.md. А живой разбор популярного примера с готовыми правилами поведения лежит в гайде 4 правила Karpathy в CLAUDE.md: половина ролей из этой статьи там уже сведена в короткие строки, которые можно скопировать себе.

Чек-лист: что у тебя теперь есть

Пройди по списку. Если разобрался с ролями правильно, все пункты закрыты.

• Понимаешь разницу между генератором кода (делает буквально запрос) и инженером (вопросы, компромиссы, проверка).
• Знаешь, что роль это приставка в начале, а твоя задача идёт сразу после неё.
• Забрал себе 10 промптов-ролей и понимаешь, когда включать каждую.
• Помнишь, что роли-критики (скептик, ревьюер, секьюрити-аудитор) специально сгущают, и читаешь их через фильтр «что реально на моих данных».
• Просишь Claude переводить термины на человеческий, когда не понял ответ.
• Требуешь от инженерных ролей способ проверки, а не только слово «готово».
• Знаешь, где отчёт Claude это повод позвать живого человека: деньги, чужие данные, необратимые действия.
• Вынес две-три строки нужного поведения в CLAUDE.md, чтобы часть ролей включалась по умолчанию.

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