31 августа прод моего приложения пролежал около часа.

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

Дальше он начал чинить. Ошибка, правка, следующая ошибка, еще правка. Каждая починка тянула за собой новую поломку. Я посмотрел на это и написал: «верни просто старую версию» То есть откатись к последнему состоянию, про которое точно известно, что оно работало.

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

Декабрь: наставник джуна

Я Product Lead, около 7 лет в цифровых продуктах, код руками не пишу. В декабре 2025 года начал делать приложение для личных финансов с ИИ-агентами. В июле оно вышло в App Store, про этот путь была первая статья.

В начале я общался с агентом как с джуном. Маленькие шаги, проверка каждого результата, объяснение очевидного. К апрелю картина перевернулась: агент исполнял задачи быстрее, чем я успевал их продумывать. Он свободен, а я еще думаю, что ему поручить. Узким местом стал я.

Июнь: что-то это напоминает

Файл с правилами для агентов постепенно разросся до размеров регламента. Каждое правило в нем появлялось после конкретной ошибки. Агентов стало несколько, и они начали мешать друг другу. В июле к проекту присоединился еще один IC, и появилась приемка: на каждую сборку агент готовит тест-план, человек проверяет результат.

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

Август: пазл собрался

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

Первая. Я спросил агента про одну механику в продукте, и он уверенно ответил, что ее нет. Она была. Больше того, она была подробно описана в документе по этому самому разделу продукта. Агент его просто не прочитал. Знакомо? Сотрудник, который не открыл регламент своего же отдела. Решение тоже оказалось знакомым: разделить знания по направлениям, у каждого своя зона ответственности, а над ними роли техлида и CTO, которые решают, какие направления задевает задача.

Вторая. Я разделил агентов по ролям. Один разбирает проблему и пишет постановку файлом: что сломано, почему, какие есть развилки, что считается готовым. Другой делает. Для себя сформулировал грубо: «ты мозг, Codex руки». Постановщик и исполнитель, классика.

Третья. Мы переезжали на новый сервер, и агент дважды подряд взял старый адрес из старого документа. Во второй раз прописал платежи не туда. Документ не врал, он просто описывал прошлое. Как вики пятилетней давности, по которой новичок настраивает не то окружение. После этого появился один документ «как все устроено сейчас», а остальное стало архивом.

А потом упал прод, и я провел тот самый разбор.

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

Сентябрь: департамент живет своей жизнью

Дальше проблемы пошли уже совсем управленческие.

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

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

Что дальше

Честно признаюсь: сейчас я все еще сижу в деталях. Сам разбираю инциденты, сам решаю, куда откатываться. Так ведет себя руководитель, который только что собрал отдел. Хороший руководитель так не делает. Он строит систему, в которой разборы происходят без него, а сам занимается приоритетами и приемкой. Агент сделает любую задачу, но не скажет, что она не нужна.

Мне кажется, через 2-3 года все это станет базой. Регламенты для агентов, роли, постановки и разборы инцидентов будут такой же привычной частью работы, как сейчас трекер задач. А главным навыком окажется не промпт-инжиниринг, а то, чему годами учатся руководители: передавать контекст, держать один источник правды и проверять результат, а не отчет о нем.

Интересно сверить с вашим опытом. Какие практики управления командой у вас сработали с агентами, а какие нет?

Приложение, на котором все это выросло: https://apps.apple.com/app/id6778792103