От промпта к команде AI-разработчиков:
где я оказался к августу 2026

В январе я решил открыть этот дневник и посмотреть, как AI изменит мой способ разработки. Прошло почти восемь месяцев. За это время поменялись модели. Появились новые инструменты. Coding agents стали заметно самостоятельнее.

Но сильнее всего изменилось не это. Изменился мой собственный процесс.

Если попытаться нарисовать его в январе, получилось бы примерно так:

developer
    ↓
prompt
    ↓
AI
    ↓
code

Я знал, что нужно сделать. Сам придумывал решение. А потом просил AI помочь написать его быстрее. Сегодня схема выглядит уже совсем иначе.

developer
    ↓
task definition
    ↓
research
    ↓
plan
    ↓
Claude / Codex
    ↓
cross-review
    ↓
tests
    ↓
browser verification
    ↓
developer approval

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

В январе мне нужен был хороший prompt

Тогда мне казалось, что это главный навык. Нужно научиться правильно разговаривать с AI. Не писать «сделай feature». А подробно объяснять. Что создать. Какие классы использовать. Какой pattern выбрать. Какие методы добавить. Какие тесты написать. Чем точнее prompt, тем лучше результат.

И в этом была логика. Потому что AI в моём процессе занимал довольно конкретное место:

я решил задачу
    ↓
AI помогает превратить решение в код

Поэтому качество запроса напрямую определяло качество реализации. Но постепенно я начал замечать неприятную вещь. Я слишком много решал до того, как вообще подключал AI.

Я использовал сильный инструмент на самом последнем этапе

Приходила задача. Я сам находил нужные файлы. Сам восстанавливал архитектуру. Сам выбирал подход. Сам определял границы изменения. И только после этого писал: теперь создай service.

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

Я перестал приносить AI готовое решение

Вместо «добавь метод сюда» появилось: сначала разберись, как это работает. Потом: расскажи, что нашёл. Потом: предложи варианты. И только потом: реализуй. Очень простое изменение. Но оно полностью поменяло роль AI.

было:

я исследую
    ↓
я решаю
    ↓
AI пишет


стало:

AI исследует
    ↓
мы обсуждаем
    ↓
AI предлагает
    ↓
я корректирую
    ↓
AI пишет

Впервые AI начал участвовать не только в implementation. Он начал участвовать в поиске решения. Это тот момент, когда я перестал сразу просить его писать код.

И тут выяснилось, насколько много проекта находится у меня в голове

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

Для AI всё это нужно сначала найти. И тогда появилась одна из главных мыслей этих восьми месяцев: размер задачи измеряется не количеством строк кода, а количеством неявного контекста. С этого момента я стал намного внимательнее смотреть не только на модель, но и на среду, в которую её запускаю.

Контекст неожиданно оказался важнее бесконечной гонки моделей

Конечно, я пробовал разные инструменты. Claude. Codex. Cursor. Новые версии моделей. И довольно долго первый вопрос после неудачи звучал примерно так: может, другая модель справится лучше? Иногда справлялась.

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

README
AGENTS.md
architecture docs
project rules
test commands
ограничения
понятное environment

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

Документация получила нового читателя

Раньше внутренняя документация была прежде всего для людей. Новый разработчик приходит в проект. Открывает README. Читает architecture docs. Спрашивает коллег. Теперь появился ещё один читатель:

developer
+
AI agent

И это неожиданно изменило само отношение к документации. Если я три раза объясняю агенту «не клади business logic в controller», возможно, проблема уже не в prompt. Возможно, это правило нужно записать. Если каждый раз напоминаю «после изменений запускай composer test и composer phpstan», это тоже должно жить в проекте. Постепенно повторяющиеся prompts начали превращаться в инфраструктуру работы. Я даже начал писать инструкции не для людей, а для AI.

А потом я заметил, что вообще пишу всё меньше prompts

Сначала в один запрос хотелось положить всё:

task
context
rules
architecture
workflow
testing
review

Но если значительная часть этого повторяется, зачем каждый раз писать заново? Так появились отдельные слои:

rules
skills
agents
commands
workflows
hooks
tests
environment

И хороший запрос стал короче. Иногда почти до «реализуй эту задачу по нашему feature workflow». Это интересный парадокс. Чем сложнее становился процесс вокруг AI, тем короче становился конкретный prompt. Не потому, что модель научилась читать мысли. А потому, что всё больше повторяющейся инженерии переехало из разговора в систему. Про это я писал в отдельной заметке.

В какой-то момент одного агента мне стало мало

Не потому, что один плохо пишет код. Совсем наоборот. Современный coding agent вполне способен исследовать, предложить решение, реализовать, написать тесты, запустить проверки, проверить собственный diff. И именно здесь появилась новая проблема. Он:

придумал решение
    ↓
написал его
    ↓
проверил
    ↓
подтвердил собственный выбор

У людей такая схема никогда не считалась полноценным code review. Почему с AI должно быть иначе? Не хочу, чтобы он проверял только самого себя.

Так появилась маленькая AI-команда

Сейчас моя схема часто выглядит примерно так:

Cursor
    ↓
task / environment / verification

Claude Code
    ↓
implementation

Codex
    ↓
review / alternative

Иногда роли меняются. Иногда Codex пишет, Claude проверяет. Иногда маленькую задачу делает только один агент. Названия здесь вообще вторичны. Главным оказалось разделение ответственности.

Один агент не обязан быть одновременно researcher + architect + implementer + tester + reviewer. Мне гораздо интереснее, когда один говорит «вот моё решение», а другой отвечает: а почему ты вообще решил делать именно так? Зачем мне несколько AI-разработчиков вместо одного.

Cross-review оказался полезен не количеством найденных bugs

Это тоже было неожиданно. Я думал, что второй агент нужен прежде всего для поиска ошибок. Null здесь. Edge case там. Забытый тест. Иногда так и есть. Но самые интересные результаты выглядели иначе.

Почему invariant находится на этом уровне? Почему создан новый service, если похожий механизм уже существует? Этот тест подтверждает implementation. А где тест исходного требования? Ты уверен, что вообще правильно понял business rule?

То есть второй agent не просто проверяет код. Он проверяет рамку, внутри которой первый агент написал код. Именно это оказалось особенно полезным. Я это увидел, когда Claude Code писал, а Codex шёл проверять.

Но потом появилась ещё более неприятная проблема

Оказывается, даже два агента могут быть очень уверены и очень согласны друг с другом. Особенно если исходное предположение неправильное. AI может неправильно понять задачу, написать неправильную implementation, написать тест под неё, пройти этот тест, провести self-review и получить положительный review второго агента. И всё выглядит великолепно.

wrong assumption
    ↓
wrong implementation
    ↓
matching tests
    ↓
review
    ↓
✓ green

Вот здесь зелёные тесты перестали успокаивать меня так же сильно, как раньше.

Техническая правильность оказалась не всей правильностью

За последние месяцы я всё чаще разделяю:

Code correctness

и

Task correctness

Можно великолепно написать неправильную feature. Можно идеально реализовать плохо сформулированное требование. Можно сделать архитектурно красивое решение проблемы, которую вообще не нужно было решать таким способом. И чем лучше AI становится в implementation, тем важнее становится эта разница. Потому что хороший код очень убедителен. Особенно с хорошими тестами. AI хорошо пишет код и всё равно может сделать не ту вещь.

Поэтому моя собственная работа начала смещаться в начало процесса

Раньше основная точка моего участия находилась здесь: requirement → я пишу код. Теперь всё чаще здесь:

problem
    ↓
что на самом деле нужно?
    ↓
какие ограничения?
    ↓
как выглядит правильный результат?
    ↓
что нельзя сломать?

После этого большую часть implementation уже можно делегировать. То есть чем сильнее AI становится в ответе на вопрос «как сделать?», тем больше ценности остаётся в вопросе «что именно нужно сделать?». Это немного неожиданное направление.

Cursor тоже перестал быть для меня просто редактором

Раньше его роль была понятна. Место, где я пишу code. А AI workflow начал выглядеть иначе. Теперь там сходятся:

task
research
context
agents
terminal
environment
diff
tests
browser
verification

Иногда Claude Code выполняет большую часть реализации. Codex проверяет. Но я всё равно нахожусь в Cursor и управляю всей задачей. Поэтому мне всё больше нравится выражение:

Cursor
    ↓
control plane development workflow

Не место написания каждой строки. А диспетчерская, из которой задача проходит разные этапы. Cursor стал для меня не редактором, а диспетчерской.

И я сам всё меньше управляю кодом напрямую

Вместо «измени этот файл» я могу управлять состоянием задачи.

research
    ↓
ready for plan
    ↓
planned
    ↓
implementation
    ↓
review
    ↓
verification
    ↓
done

На разных этапах работают разные agents. Я вмешиваюсь в разных точках. Иногда нужно принять архитектурное решение. Иногда уточнить domain. Иногда просто посмотреть итог. То есть процесс начинает немного напоминать управление небольшой командой. Только команда эта может полностью поменяться после очередного обновления моделей.

При этом я пока не готов отдать всё

Это тоже важно зафиксировать. На июль–август 2026 года у меня остаются довольно понятные human checkpoints. Я пока не хочу полностью делегировать:

финальное архитектурное решение
security-critical изменения
production migrations
destructive actions
важные бизнес-компромиссы
решение «что вообще нужно строить»

AI может исследовать. Предложить. Аргументировать. Подготовить. Но в дорогих по последствиям точках я пока хочу остановку. И человеческое решение. Что я пока не готов делегировать.

Более того, я всё ещё читаю весь AI-generated diff

Пока. Это слово становится всё важнее. Потому что возникает естественный вопрос. Если агент изменил 3000 строк. Есть tests. Static analysis. Self-review. Независимый agent review. Browser verification. Acceptance criteria выполнены. Должен ли я всё равно прочитать буквально каждую строку?

Сейчас мой ответ: да. Но я уже не уверен, что через год он останется таким же. Возможно, human review постепенно станет более risk-oriented. Меньше чтения механического кода. Больше проверки:

business rules
security boundaries
data changes
public contracts
assumptions
architecture

Пока я только учусь доверять этому процессу. Я читаю весь код, который написал AI. Пока.

И ещё я учусь вовремя говорить «Stop»

Это, пожалуй, отдельный новый навык. Потому что автономный agent может работать очень долго. И выглядеть занятым. Но активность не всегда означает прогресс. У меня появились свои красные флаги:

агент ходит по кругу
diff постоянно растёт
появляются странные abstractions
он чинит симптомы вместо root cause
не понимает domain
расширяет scope
начинает менять соседние системы

В таком случае моя работа иногда состоит всего из одной команды: stop. Дальше я сначала сам разберусь. Причём «сам разберусь» уже не обязательно означает «сам напишу код». Иногда я только нахожу root cause. Или объясняю business invariant. После этого агент снова продолжает implementation. Когда стоит остановить агента.

Получается странная новая форма программирования

За день я могу почти не написать production-код руками. Но при этом сформулировать несколько задач, провести research, скорректировать планы, остановить неправильную реализацию, принять архитектурное решение, отправить один diff на independent review, проверить browser scenario, разобраться в одном сложном domain rule, подтвердить итоговые изменения.

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

Если сравнить январь и август, главное изменение выглядит не так, как я ожидал

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

Как правильно формулировать задачу? Как давать агенту контекст? Как разделять research и implementation? Когда нужен второй agent? Что должно быть независимым источником истины? Когда можно довериться тестам? Когда нужен human checkpoint? Когда остановить автономную работу? Сколько кода человеку вообще нужно читать?

Это уже совсем другой набор вопросов.

Январская схема была про инструмент

developer
    ↓
prompt
    ↓
AI
    ↓
code

В центре всё ещё находился разработчик, который просто получил очень мощного помощника. Августовская схема скорее про процесс.

developer
    ↓
task definition
    ↓
research
    ↓
plan
    ↓
AI implementation
    ↓
independent AI review
    ↓
tests
    ↓
static analysis
    ↓
browser verification
    ↓
developer approval

AI больше не находится в одной точке. Он распределён по workflow. И разработчик тоже уже не находится в одной точке. Я могу появляться в начале. Потом на архитектурном checkpoint. Потом на review. Потом перед production. Получается не «я + AI». А система взаимодействия.

Поэтому мне всё меньше нравится выражение «AI пишет код за меня»

Оно слишком узкое. Да, пишет. Много. Иногда большую часть feature. Но если смотреть только на это, пропускается самое интересное.

AI исследует кодовую базу, строит карту зависимостей, ищет существующие решения, помогает составить план, реализует, пишет тесты, проверяет другой AI, работает с environment, помогает пройти verification. То есть вопрос давно вышел за пределы генерации кода.

Но я пока не называю это автономной разработкой

Потому что человек всё ещё находится в важных точках. И я пока не вижу в этом проблемы. Мне не очень интересна автономность ради самой автономности. Гораздо интереснее система, где AI самостоятельно делает всё, для чего у него достаточно информации и проверок. И останавливается там, где требуется другой уровень решения.

can verify
    ↓
continue

cannot verify
    ↓
stop

business ambiguity
    ↓
ask

destructive action
    ↓
approval

architecture tradeoff
    ↓
human checkpoint

Если получится хорошо построить именно такой процесс, для меня это будет намного ценнее красивой демонстрации «смотрите, агент сам работал три часа».

Наверное, главное изменение за восемь месяцев произошло всё-таки во мне

Модели действительно стали лучше. Инструменты — сильнее. Но если бы я сегодня работал с ними так же, как в январе — я придумываю решение, AI пишет функцию — то использовал бы лишь небольшую часть возможностей.

Главное, чему я учился эти месяцы, — не новым prompts. Я учился отпускать отдельные части процесса. Сначала набор кода. Потом исследование. Потом планирование. Потом implementation. Потом часть review. Потом verification. И одновременно учился понимать, какие части пока отпускать нельзя.

Я всё ещё не знаю, где этот процесс остановится

Возможно, через год agent будет самостоятельно:

получать задачу
    ↓
уточнять требования
    ↓
исследовать
    ↓
строить plan
    ↓
реализовывать
    ↓
отдавать второму agent
    ↓
исправлять review
    ↓
проверять UI
    ↓
готовить PR

А я буду смотреть только итоговое решение и ключевые риски. Возможно, наоборот, окажется, что некоторые сегодняшние эксперименты дают слишком мало пользы по сравнению со сложностью процесса. Не знаю. И именно поэтому это дневник. Мне хочется фиксировать не только удачные рецепты, но и то, как меняется собственная граница доверия.

Август 2026

Если совсем коротко описать точку, в которой я сейчас нахожусь, получится примерно так. Я больше не думаю об AI как об autocomplete. Не считаю хороший prompt главным инструментом. Не хочу, чтобы один agent одновременно был единственным автором и единственным reviewer. Не считаю зелёные тесты финальным доказательством правильности. Стараюсь хранить контекст в проекте, а не в своей голове. Строю workflows вместо повторения одинаковых инструкций. Использую разные agents для разных ролей. Пытаюсь автоматизировать verification. Оставляю human checkpoints там, где высока стоимость неправильного решения. И всё ещё читаю весь diff. Пока.

И всё же самое странное — я не чувствую, что программирую меньше

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

AI забирает всё больше механической части. И постепенно забирается выше. Но вместе с этим всё заметнее становится то, что раньше было спрятано за самим процессом написания кода.

В январе я учился писать prompts

В августе я учусь строить процесс, в котором prompt — только начало.

task
    ↓
context
    ↓
research
    ↓
decision
    ↓
implementation
    ↓
independent verification
    ↓
human judgment

Модели в этой схеме будут меняться. Инструменты будут меняться. Наверняка поменяется даже моя текущая комбинация Claude, Codex и Cursor. Поэтому мне хочется сохранить именно эту точку не как руководство «делайте так». А как запись: вот как я работаю сейчас. Чтобы через год вернуться и посмотреть, какие части сегодня казались смелыми, а потом стали обычными. И какие, наоборот, оказались тупиковыми.

Потому что я всё ещё программирую

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

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

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