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

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

У меня был другой путь. Я не «внедрял AI в компанию» и не измерял эффективность числом сгенерированных строк. Я начал использовать AI-агента как постоянного участника разработки. Он может исследовать, выполнять ограниченные задачи, проводить ревью, а иногда выступает неприятным собеседником, который заставляет ещё раз объяснить, чего именно я хочу.

И довольно быстро понял простую вещь:

AI не отменяет управление разработкой. С ним слабые места управления просто становятся заметнее.

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

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

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

Коротко

• AI одинаково ускоряет порядок и хаос.

• Задача для AI-агента должна описывать цель, подтверждённый контекст, границы и доказательство готовности.

• Перед production нужен не «зелёный билд», а точный revision, health-check и пользовательская проверка.

• Повторившаяся ошибка должна оставлять защиту: тест, инвариант, runbook или обновлённый контекст.

AI ускоряет и порядок, и беспорядок

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

В реальности AI ускоряет не только полезную работу.

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

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

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

Поэтому я не считаю, что AI делает разработку проще. Он ускоряет то, что уже есть:

• ясный процесс;

• работающий порядок;

• хаос;

• последствия плохо поставленной задачи.

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

От «сделай фичу» к «какое изменение мы хотим получить?»

Фраза «сделай авторизацию» кажется задачей. На самом деле это название целого леса, в котором ещё не проложена ни одна тропинка.

Для кого авторизация? Какие роли существуют? Какие действия должен видеть пользователь, а какие — сервис? Где заканчивается публичный маршрут и начинается внутренний? Можно ли менять существующий контракт? Что происходит со старыми сессиями? Как проверить, что чужой пользователь не получил доступ? И, наконец, можно ли сегодня вообще трогать production?

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

Плохая постановка выглядит так:

Добавь авторизацию и задеплой.

В ней нет цели, нет границ и нет критерия результата. Есть только глагол, который может означать двадцать разных решений.

Нормальная постановка устроена иначе:

Нужно закрыть один конкретный сценарий записи данных:
изменять запись может только её владелец.

Сначала установи текущий контракт по коду, тестам и runtime.
Не расширяй права «на всякий случай» и не меняй публичные маршруты.
Сначала добавь проверку, что другой пользователь получает отказ.
Production не трогай.

Готовность: целевой тест, сборка затронутого пакета,
проверка diff и список изменённых контрактов.

Это не «магический промпт» и не набор волшебных слов. Здесь зафиксировано управленческое решение:

• какой риск я закрываю;

• что считаю допустимой границей изменения;

• каким будет доказательство результата;

• какое действие сейчас запрещено.

Если я не могу это сформулировать, дело обычно не в агенте. Скорее всего, я сам ещё не разобрался с задачей.

Хорошая задача начинается с контекста

Человек в команде часто накапливает контекст годами. Он знает, где находится код, как устроен релиз, почему нельзя чистить эту таблицу и какой endpoint на самом деле проверяет пользователь.

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

У меня это стало почти ритуалом.

Перед заметной задачей агент сначала должен выяснить:

1. где он находится;

2. какой репозиторий и какая ветка являются рабочими;

3. есть ли незакоммиченные изменения;

4. где лежит подтверждённый контекст проекта;

5. что говорит актуальный план;

6. что реально происходит в коде, данных и runtime.

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

Поэтому я стараюсь держаться правила:

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

Это не значит, что документации нельзя доверять. Хорошая документация помогает быстро понять, что проверить и зачем.

Документация, которую действительно читают

Существует старый жанр инженерного юмора: документация — это место, куда информация уходит, чтобы никогда не вернуться.

С агентами у меня получилось чуть иначе. Документация стала рабочим инструментом, а не приложением к проекту.

У каждого заметного продукта есть несколько разных типов знания.

Важно не смешивать эти слои.

Исторический план — это не приказ продолжать работу с места, где остановились полгода назад. Он может объяснить, почему архитектура выглядит именно так. Но текущую задачу надо начинать с того, что реально подтверждено сегодня.

Документ со списком прошлых релизов — не замена проверке production. Он полезен, чтобы понимать, что спросить у системы. Но всё равно нужно посмотреть текущий revision, состояние процессов, health-check и нужный пользовательский маршрут.

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

Похоже, я наконец нашёл читателя для технической документации.

Пять слоёв постановки задачи

Со временем у меня сложилась простая конструкция. Почти любую работу с агентом можно проверить по пяти слоям.

1. Цель

Не «добавить кнопку», а ответить на вопросы:

• кто получает новое действие;

• какую проблему оно решает;

• что меняется в пользовательском сценарии;

• что сознательно не входит в задачу.

Например, цель может звучать так: «пользователь должен видеть понятную причину отказа и знать, что делать дальше». Это лучше, чем «сделай красивое уведомление».

В первой формулировке есть результат. Во второй — только эстетическое пожелание, которое можно трактовать бесконечно.

2. Реальность

До плана нужно установить факты.

Не «вроде бы сервис использует такую-то очередь», а проверить код и состояние системы. Не «кажется, endpoint защищён», а посмотреть маршрут, policy, тест и фактический HTTP-ответ. Не «релиз уже выкачен», а сверить revision и публичный маршрут.

Этот этап иногда выглядит как потеря времени. Особенно когда хочется немедленно дать агенту команду «исправляй». Но именно он спасает от классического сценария: три часа мы лечили проблему в одном окружении, а пользователь всё это время работал в другом.

3. Границы

В хорошей задаче нужно назвать и то, что сделать, и то, чего делать нельзя.

Например:

• не трогать production без отдельного решения;

• не менять инфраструктуру ради удобства одного патча;

• не удалять данные широким запросом;

• не раскрывать конфигурацию и секреты;

• не исправлять соседние подсистемы «заодно»;

• не стирать чужие незакоммиченные изменения.

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

4. Доказательство готовности

Фразы «код написан» недостаточно.

«Тест прошёл» — тоже не всегда готовность.

В зависимости от задачи доказательство может включать:

• regression test на конкретный контракт;

• сборку затронутого приложения;

• проверку API или очереди;

• подтверждённое состояние в базе;

• desktop- и mobile-проверку публичного сценария;

• независимый review;

• exact revision на сервере;

• возможность отката.

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

5. След знания

После заметной работы результат не должен оставаться только в чате.

Если выяснилось новое ограничение — оно попадает в документ или runbook. Если найден опасный сценарий — появляется тест. Если повторяется диагностический путь — он сохраняется как процедура. Если обновился контракт — это отражается в актуальном контексте.

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

Эти слои лучше работают не как чек-лист в конце, а как последовательность принятия решения:

flowchart TB
  goal[1 · Цель] --> facts[2 · Проверенные факты]
  facts --> scope[3 · Границы изменения]
  scope --> proof[4 · Доказательство готовности]
  proof --> memory[5 · След знания]

Агент не должен быть универсальным исполнителем

Самый опасный запрос к AI звучит просто: «разберись со всем».

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

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

Поэтому я разделяю роли.

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

Отчёт агента — это гипотеза до тех пор, пока она не подтверждена кодом, тестом, системой или независимой проверкой.

Особенно это относится к авторизации, данным, платежам, очередям, внешним интеграциям и production.

Почему скорость не равна отмене проверок

Есть две одинаково вредные крайности.

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

Вторая: «быстро сделать, потом разберёмся». Это обычно означает, что разбираться будут уже с последствиями — в логах, в базе, в рабочее время и в чужом настроении.

Я стараюсь использовать третий вариант: сила проверки должна соответствовать цене ошибки.

Это не означает, что я всегда угадываю идеальный набор проверок. Но сама постановка вопроса меняет работу.

Не «как заставить агента сделать всё быстро?», а «какая ошибка здесь будет самой дорогой и как её поймать раньше пользователя?»

Production — это не место для продолжения разработки

Отдельная дисциплина нужна для релизов.

Когда система работает для пользователей, нельзя считать успехом ни git push, ни зелёную сборку, ни сообщение process manager-а «online». Все эти вещи полезны, но каждая доказывает только свою маленькую часть истории.

Рабочая цепочка выглядит примерно так:

flowchart TB
  change[Локальное изменение] --> checks[Проверка]
  checks --> revision[Зафиксированный revision]
  revision --> candidate[Точный release candidate]
  candidate --> switch[Атомарное переключение]
  switch --> health[Health-check]
  health --> smoke[Пользовательский smoke]
  smoke --> rollback[Возможность rollback]

Я сознательно стараюсь не «доделывать на сервере». Сервер не должен становиться местом, где пишется код, исправляется lockfile, создаётся коммит или принимается архитектурное решение в полночь под давлением ошибки.

Production должен применять уже подготовленный релиз. И этот релиз должен иметь точный идентификатор: вот revision, вот сборка, вот проверка, вот предыдущая рабочая точка, к которой можно вернуться.

Такой подход кажется медленнее ровно до первого случая, когда нужно понять: пользователь видит новый код или старый? Система упала из-за релиза или проблема была раньше? Что именно откатывать? Есть ли у нас вообще куда откатываться?

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

Промпт — часть инженерной системы

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

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

Например, рабочее задание агенту может выглядеть так:

Контекст:
- это существующий работающий сервис;
- в рабочем дереве могут быть чужие изменения;
- документация описывает подтверждённое состояние,
  но перед действиями её нужно сверить с кодом и runtime.

Задача:
- устранить причину конкретного симптома;
- не расширять scope до соседних подсистем.

Порядок:
1. Собери evidence и назови root cause.
2. Добавь или уточни проверку, которая ловит регрессию.
3. Сделай минимальное изменение.
4. Выполни только релевантные проверки.
5. Верни изменённые файлы, доказательство результата,
   ограничения и оставшиеся риски.

Запрещено:
- production deploy;
- работа с секретами;
- массовые изменения данных;
- изменение инфраструктуры без отдельной команды.

В таком тексте нет просьбы «будь экспертом мирового уровня». Я не прошу агента «проявить инициативу» и не заставляю его писать эссе о том, как прекрасно он понял задачу.

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

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

После ошибки нужен не новый промпт, а новая защита

Когда агент делает неверный шаг, очень легко начать бесконечный цикл:

Не сработало → попробуй ещё → не сработало → попробуй по-другому.

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

Я стараюсь разбирать такие случаи иначе:

Симптом
→ факты
→ root cause
→ минимальное исправление
→ regression test или инвариант
→ обновлённый контекст

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

Если можно перепутать окружения, нужен предохранитель, который заставит сначала подтвердить цель действия. Если deploy-скрипт может взять не тот revision, ему нужен exact-SHA контракт. Если документ расходится с кодом, нужно не только исправить документ, но и понять, почему он перестал обновляться.

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

Чего AI не решает

Важно не превратить всё это в новую форму AI-оптимизма.

Агент не знает автоматически:

• какой продукт нужен людям;

• какой риск допустим для бизнеса;

• когда стоит отказаться от идеи;

• что можно считать достаточным доказательством;

• какая часть старой системы ценна, а какая давно просится на покой;

• почему пользователь недоволен, даже если формально все тесты зелёные.

Он также не заменяет обратную связь от живых людей. Можно идеально организовать pipeline, покрыть тестами контракты, написать прекрасную документацию — и всё равно построить вещь, которая никому не нужна.

AI не отменяет продуктовую ответственность. Он лишь делает дороже попытку от неё спрятаться.

Вопросы и ответы

Как ставить задачи AI-агенту в разработке?

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

Почему AI-агенту недостаточно короткого промпта?

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

Как безопасно использовать AI при production deploy?

Сначала подготовить и проверить конкретный revision вне production. Затем применять только этот revision, фиксировать health-check и отдельно проходить пользовательский smoke-сценарий. Если риск не согласован, агент должен остановиться до опасного действия.

Управление стало разговором — но не разговором ни о чём

Работа с агентом изменила моё представление об управлении разработкой.

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

• правильно назвать цель;

• отделить факт от предположения;

• обозначить границы;

• определить риск;

• договориться о доказательстве результата;

• сохранить знание после завершения.

Получается, что управление всё чаще сводится к качеству диалога. Но не к разговору ради разговора. К разговору, после которого появляется конкретный проверяемый результат.

Чем сильнее AI участвует в разработке, тем меньше можно управлять намёками.

Каждое неясное слово в задаче становится риском. Каждая непроверенная гипотеза — потенциальным багом. Каждая хорошо поставленная цель — возможностью двигаться быстрее без лишнего героизма.

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

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