Когда я только начинал активно использовать AI в разработке, мне казалось, что главный навык — научиться писать хороший prompt. Не просто «сделай feature», а подробно. С ролью. С контекстом. С ограничениями. С последовательностью действий. С описанием архитектуры. С командами тестирования. С форматом ответа.
Иногда prompt начинал выглядеть почти как техническое задание внутри технического задания. Что-то вроде:
Ты senior PHP-разработчик.
Сначала изучи существующую реализацию.
Не меняй код до завершения исследования.
Найди связанные тесты.
Проверь архитектурные ограничения.
Предложи план.
После согласования реализуй.
Не делай unrelated refactoring.
Используй существующие abstractions.
После изменений запусти composer test и composer phpstan.
В конце проведи self-review.Всё правильно. Только через некоторое время я заметил довольно очевидную проблему. Я писал примерно один и тот же prompt снова. И снова. И снова. Менялась задача. Но большая часть инструкций оставалась прежней.
В какой-то момент стало трудно не задать вопрос: если я каждый раз объясняю AI один и тот же рабочий процесс, почему этот процесс вообще находится в prompt?
Сначала я пытался сделать идеальный prompt
Это довольно увлекательная ловушка. AI сделал что-то не так. Значит, в следующий раз нужно сформулировать точнее. Не написал тесты? Добавляем: обязательно добавь тесты. Начал сразу менять код? Добавляем: сначала только исследование. Устроил большой refactoring? Добавляем: не меняй код, не относящийся к задаче. Не запустил PHPStan? Ещё одна строка. Не проверил существующие решения? Ещё одна.
Через некоторое время небольшой запрос «добавь возможность повторной отправки» превращается в документ на несколько экранов. И самое смешное, что большая часть этого документа вообще не относится к повторной отправке. Она описывает то, как я хочу работать с любой feature.
Тогда я впервые разделил задачу и процесс
Это сейчас кажется совершенно естественным. Но для меня это был важный переход. Есть информация о конкретной задаче: что нужно изменить, зачем это нужно, какие есть acceptance criteria, какие ограничения относятся именно к этой feature. А есть мой общий процесс работы: сначала research, потом plan, потом implementation, потом tests, потом self-review, потом independent review.
Почему всё это должно находиться в одном prompt? Если процесс повторяется, его логичнее описать один раз. И дальше ссылаться на него. То есть вместо огромной инструкции хочется написать: реализуй задачу по нашему feature workflow. Вот это для меня и стало началом следующего этапа.
Prompt постепенно перестал быть местом, где живут все правила
До этого prompt был почти единственным способом управлять AI. Хочешь получить определённое поведение — напиши инструкцию. Но потом вокруг coding agents начало появляться всё больше отдельных механизмов:
rules
skills
agents
commands
workflows
hooks
tests
environmentИ внезапно стало понятно, что prompt — всего лишь один слой. Причём не обязательно главный.
Rules отвечают на вопрос «как у нас принято»
Например: не добавляй business logic в controllers. Не меняй public API без явного требования. Используй существующие Value Objects. Не добавляй новую dependency без необходимости. Не делай unrelated refactoring.
Это не инструкция к конкретной задаче. Это свойства среды. А значит, странно каждый раз писать их вручную. Они должны быть доступны агенту автоматически. Так же, как разработчик в команде постепенно узнаёт conventions проекта.
Skills отвечают на вопрос «как мы выполняем этот тип работы»
Например, у меня может появиться условный skill feature-development. Внутри которого уже записано:
1. Research existing behavior.
2. Find related tests.
3. Identify constraints.
4. Propose implementation plan.
5. Wait for approval when architecture changes.
6. Implement minimal change.
7. Add or update tests.
8. Run verification.
9. Review final diff.Теперь это уже не просто правило. Это повторяемая процедура. И здесь я начал чувствовать большую разницу между prompt и workflow. Prompt говорит: сделай вот так сейчас. Workflow говорит: такой тип работы у нас вообще выполняется вот так.
Commands убрали ещё немного повторений
Есть действия, которые я раньше буквально писал словами. Например: запусти тесты, PHPStan и formatter. Если это стандартная проверка проекта, почему агент должен каждый раз вспоминать конкретные команды?
Гораздо удобнее иметь что-то вроде verify, которое означает composer test, composer phpstan, composer cs-check. Или отдельные команды: test-unit, test-integration, quality, verify-feature.
Для человека это просто удобство. Для агента ещё и уменьшение неопределённости. Он не должен угадывать, чем именно здесь проверяется проект.
Environment оказался частью prompt, хотя я раньше так не думал
Это вообще один из самых интересных выводов. Допустим, я пишу великолепный prompt: исследуй задачу, реализуй, запусти тесты. Но локальная база не поднята. Fixtures устарели. Очередь не работает. Не установлена нужная версия PHP. Нет переменной окружения. И агент начинает чинить проблему, которой в коде вообще нет.
В этот момент качество prompt совершенно не важно. Плохая среда победит любую формулировку. Поэтому я начал воспринимать environment как ещё один способ давать инструкции AI.
Хорошо подготовленный проект сам говорит: вот как меня поднять, вот как меня проверить, вот какие сервисы нужны, вот где тестовые данные, вот какие команды считаются правильными. Чем меньше агент должен об этом спрашивать или догадываться, тем меньше текста нужно в запросе.
Hooks стали способом вообще ничего не просить
Есть действия, про которые странно каждый раз напоминать. Например: после изменения PHP-файла запусти formatter. Или: перед завершением задачи проверь статический анализ. Или: не позволяй завершить workflow, если тесты красные.
Если действие действительно обязательное и механическое, возможно, лучше не надеяться на prompt. Лучше встроить его в процесс: code changed → hook → verification. Вот здесь я впервые почувствовал, что AI-разработка начинает напоминать обычную инженерную автоматизацию.
Мы ведь давно не пишем разработчику в каждой задаче: пожалуйста, не забудь запустить CI. CI просто существует. С AI постепенно хочется того же.
Чем важнее правило, тем меньше мне хочется оставлять его в prompt
Потому что prompt — довольно хрупкое место. Сегодня я вспомнил написать «не трогай public API». Завтра забыл. В одной сессии правило есть. В другой нет. Один агент получил его. Другой — нет.
Если ограничение действительно важно, оно должно находиться ближе к проекту и процессу:
архитектурное ограничение
↓
project rule
способ проверки
↓
command / CI
повторяемая процедура
↓
workflow / skill
критическая автоматическая проверка
↓
hook / testА prompt остаётся для того, что действительно уникально для этой задачи.
Это немного похоже на переход от скрипта к системе
Представим, что каждый deploy я провожу вручную. Пишу себе инструкцию: собери assets, запусти tests, создай backup, выполни migration, перезапусти workers, проверь healthcheck. Можно каждый раз очень внимательно читать список. А можно один раз построить pipeline.
После этого команда становится короче: deploy. Не потому, что работа исчезла. Наоборот. Под короткой командой теперь находится намного больше работы. Просто она формализована. С AI у меня постепенно происходит похожее.
Короткий prompt может означать более сложный процесс
Это довольно важный парадокс. Если я пишу «реализуй feature», это может быть ужасный prompt. А может быть отличный. Всё зависит от того, что находится вокруг него.
В одном случае за фразой нет ничего. Агент должен сам догадаться, как исследовать, какие правила соблюдать, какие тесты запускать, где искать документацию, что нельзя менять. В другом случае существует workflow:
task
↓
research
↓
plan
↓
implementation
↓
tests
↓
self-review
↓
independent review
↓
verificationИ команда «реализуй задачу по feature workflow» запускает весь этот процесс. Текст короче. Работы под ним больше.
Я начал меньше верить в магию формулировки
Сначала казалось, что существует какой-то секретный способ написать prompt так, чтобы модель вдруг стала работать идеально. Добавить «think carefully». Или «act as a senior engineer». Или подробно перечислить двадцать требований.
В каких-то случаях формулировка действительно сильно влияет на результат. Я всё ещё считаю её важной. Но теперь мне гораздо интереснее другой вопрос: что произойдёт, если этот prompt выполнится сто раз? Будет ли процесс каждый раз одинаково надёжным?
Если нет, возможно, проблема не в prompt. Нужно улучшать систему вокруг него.
Хороший workflow уменьшает зависимость от моего настроения
Это тоже неожиданно важная вещь. Когда всё находится в prompt, качество процесса зависит от того, насколько хорошо я сегодня сформулировал задачу. Устал. Поторопился. Забыл упомянуть review. Не написал про тесты. Не уточнил, что сначала нужен research. И агент работает иначе.
Workflow снимает часть этой нагрузки. Я могу быть менее многословным, потому что базовая дисциплина уже встроена. Это примерно тот же смысл, что у coding standards или CI. Они существуют не потому, что разработчики не знают, как правильно. А потому, что важные вещи лучше не оставлять на память.
Некоторые части workflow у меня начали выполнять разные агенты
Здесь особенно интересно соединяется всё, к чему я пришёл раньше. Например:
TASK
↓
research
↓
Claude Code
↓
implementation
↓
self-check
↓
Codex
↓
independent review
↓
verificationИли наоборот. Конкретные инструменты могут меняться. Но теперь меня интересует не то, какой модели написать prompt, а какой этап процесса сейчас нужно выполнить и кто лучше подходит для этой роли. Это совсем другое мышление. Модель становится не центром процесса. Она становится исполнителем внутри workflow.
Мне всё меньше хочется создавать универсального суперагента
Сначала кажется очень привлекательной идея: сейчас я дам одному агенту все инструкции, все tools, все права, и он будет делать всё. Research. Архитектуру. Implementation. Tests. Review. Documentation. Deployment. Очень красиво.
Но постепенно мне стало нравиться разделение. Не обязательно потому, что один агент технически не способен всё это сделать. А потому, что разные этапы требуют разных режимов работы. При research полезна осторожность. При implementation — следование плану. При review — критичность. При verification — механическая строгость.
Если всё смешать в одной длинной сессии, роли начинают влиять друг на друга. Поэтому workflow для меня — ещё и способ переключать режимы явно. Это продолжает мысль из зачем мне несколько AI-разработчиков вместо одного.
Особенно полезным оказалось отделить обязательное от желательного
Например, обязательно: tests green, static analysis green, public API unchanged. Желательно: минимальный diff, переиспользовать существующую abstraction, избегать лишнего refactoring.
Это кажется мелочью. Но AI легко воспринимает длинный список рекомендаций одинаково серьёзно. И начинает оптимизировать всё сразу. Workflow позволяет разделить hard gates и мягкие предпочтения. Что блокирует завершение задачи. А что является просто ориентиром. Это делает процесс намного спокойнее.
Тесты стали частью workflow, а не финальной галочкой
Раньше схема была: написали код, ну и тесты добавь. Теперь тестирование может появляться в нескольких местах. До реализации — найти существующие тесты. Во время planning — определить нужные сценарии. После implementation — добавить новые тесты. После review — добавить пропущенные сценарии. В verification — запустить полный suite.
То есть тесты перестают быть одним действием. Это часть процесса проверки гипотезы. И опять же — нет смысла расписывать всё это в каждом prompt, если процедура повторяется. Про то, почему зелёный suite сам по себе меня уже меньше успокаивает, я писал отдельно.
Я стал больше думать о переходах между этапами
Это, пожалуй, самое workflow-мышление из всего. Раньше важно было: что должен сделать AI? Теперь: когда он имеет право перейти к следующему этапу?
research
↓
понимание подтверждено?
↓ yes
plan
↓
риски понятны?
↓ yes
implementation
↓
tests green?
↓ yes
reviewЕсли нет — возврат назад. Это уже не просто последовательность команд. Это процесс с checkpoints. И он гораздо лучше соответствует реальной разработке. Мы ведь тоже не должны идти в production просто потому, что дошли до конца checklist. Есть условия перехода.
В какой-то момент prompt превратился почти в входные данные
Если workflow уже знает, как исследовать, как планировать, как реализовывать, как проверять, то от меня остаётся передать саму задачу. Например:
Добавить возможность вручную повторно отправить failed notification.
Повторная отправка разрешена только пока связанный процесс актуален.
Existing automatic retry менять нельзя.
Реализуй по feature workflow.Вот такой запрос мне сегодня нравится гораздо больше огромного промпта на пять экранов. Потому что он описывает, что уникально сейчас. Всё повторяемое уже находится в системе.
Это также делает процесс переносимым между моделями
Если весь способ работы спрятан в одном сложном prompt под конкретную модель, смена инструмента может быть болезненной. Если же у проекта есть rules, skills, commands, tests, environment, workflows — новому агенту гораздо проще занять место. Claude сегодня. Codex завтра. Ещё что-то через год.
Модель получает не пустой repository и огромный prompt. Она получает рабочую среду. И это возвращает меня к мысли о контексте. Хороший workflow — это тоже форма контекста. Только не про устройство системы. А про устройство работы с ней.
У workflow есть одна неприятная сторона
Его тоже можно сделать слишком сложным. Это очень легко. Добавить research-agent, planning-agent, architecture-agent, implementation-agent, testing-agent, reviewer-agent, security-agent, documentation-agent. Потом orchestration между ними. И внезапно маленькая задача проходит через восемь стадий и генерирует сорок сообщений.
В этот момент процесс начинает существовать ради процесса. Поэтому я стараюсь держать простой принцип: сложность workflow должна соответствовать риску задачи.
Для маленького изменения: task → implement → verify. Для обычной feature: research → plan → implement → verify → review. Для рискованной: research → plan → human checkpoint → implementation → tests → independent review → additional verification → human checkpoint. Не каждой задаче нужна AI-корпорация.
Идеальный workflow не должен требовать идеального prompt
Мне кажется, это один из лучших критериев. Если система работает только тогда, когда я написал очень точную инструкцию на двадцать абзацев, система пока довольно хрупкая.
Если я могу написать «исправь проблему с повторной отправкой по стандартному bugfix workflow», а дальше агент сам знает, где искать инструкции, что сначала исследовать, как оформить план, какие команды запустить, когда нужен review — значит, часть процесса уже действительно вынесена из моей головы. Именно этого я сейчас и хочу.
В итоге я всё меньше занимаюсь prompt engineering
Не потому, что prompts больше не нужны. Они нужны. Хорошая постановка задачи по-прежнему критически важна. Но я перестал пытаться решить через prompt вообще всё.
Если правило повторяется — оно становится rule. Если действие повторяется — command. Если способ решения повторяется — skill. Если последовательность этапов повторяется — workflow. Если проверка обязательна — test, CI или hook. Если агенту постоянно нужен один и тот же setup — это проблема environment.
раньше:
prompt
├── task
├── context
├── rules
├── process
├── commands
├── testing
└── review
сейчас:
task
↓
workflow
а вокруг:
rules
skills
agents
commands
hooks
tests
environmentИ сам prompt становится заметно меньше.
Самое интересное, что работы при этом не становится меньше
Она просто переносится. Раньше я тратил время на то, чтобы каждый раз управлять конкретной сессией. Теперь больше времени уходит на создание системы, которой можно пользоваться повторно. Написать хороший rule. Сделать удобную verification command. Определить workflow. Разделить роли агентов. Настроить environment. Продумать checkpoint.
Это очень похоже на обычную разработку. Можно каждый раз вручную выполнять последовательность действий. А можно автоматизировать процесс. Сначала автоматизация стоит дороже. Потом начинает окупаться.
Возможно, именно здесь заканчивается эпоха «магических промптов»
По крайней мере для меня. Мне всё меньше хочется собирать библиотеку из «лучший prompt для code review», «идеальный prompt для feature development», «суперprompt для debugging».
Гораздо полезнее сохранить сам процесс. Не текст «скажи модели вот эти 37 предложений». А систему: вот так мы исследуем bug. Вот так реализуем feature. Вот так проводим review. Вот так проверяем результат. И тогда конкретная формулировка становится почти интерфейсом к этой системе.
Поэтому сегодня мне нравится очень короткий запрос
Например: реализуй задачу по нашему feature workflow. Несколько лет назад такая фраза была бы почти бессмысленной. Сегодня за ней потенциально может стоять:
project rules
↓
research
↓
context collection
↓
plan
↓
implementation
↓
tests
↓
self-review
↓
independent review
↓
verification
↓
human checkpointТо есть prompt стал короче не потому, что AI теперь понимает меня с полуслова. А потому, что всё больше нашего способа работы я пытаюсь вынести из разговора с AI в сам процесс разработки.
И, пожалуй, это одно из самых заметных изменений моего подхода за последнее время. Я всё ещё пишу prompts. Просто всё меньше хочу, чтобы именно в них находилась вся инженерия.
