AI как рычаг продукт-инженера

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

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

Что ИИ снимает, а что — нет

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

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

Что отдать агенту, что оставить себе

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

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

Серая зона: выбор библиотеки, схема, структура, формат API

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

Развилка простая и работает на любом из этих вопросов: насколько дорого это поменять потом и кто заметит, если решение окажется неверным.

Три вопроса, по которым решение относят к своей стороне, если таблицы под рукой нет:

• Это увидят снаружи? Всё, что попадает в контракт — имена, коды, форма ответа, событие, — решает человек. Наружу видное меняется согласованно с теми, кто им пользуется, а согласование делегировать нельзя.
• Сколько стоит передумать? Обратимое за час — агенту. То, что через полгода потребует миграции данных или согласованного выката нескольких частей, — себе.
• Есть ли записанное правило? Если да — это исполнение, и агент применит правило точнее человека. Если правила нет, а решение повторяющееся, самое полезное действие — не решить один раз, а записать правило и дальше отдавать агенту.

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

Отдельно про случай, который встречается чаще всех: агент предлагает решение из серой зоны сам. Это нормально и полезно — он видит варианты, которых вы не вспомнили. Плохо другое: принять предложение молча. Рабочая формулировка — попросить два-три варианта с ценой каждого и решить явно, а потом записать выбор с причиной. Именно так решение и попадает в память проекта.

Один день: задачи агента и задачи человека

Пришёл баг-репорт: у части пользователей страница отчётов открывается 8–12 секунд.

Что сделал сам. Прочитал несколько жалоб — замедление только у тех, кто работает с большими выборками за год и более. Написал двум пострадавшим, уточнил: это мешает им в конкретном рабочем процессе или просто раздражает? Оказалось, мешает: у одного отчёт открывается в начале совещания при коллегах, и 10 секунд ожидания создают дискомфорт. Решил, что порог «приемлемо» — 2 секунды для типичного объёма. После выката написал им снова.

Что отдал агенту. Включить логирование медленных запросов и снять по ним статистику (в PostgreSQL для этого есть pg_stat_statements), найти по ней узкое место в схеме, предложить три варианта оптимизации с ценой каждого, написать тест на регрессию по времени ответа. Агент нашёл: проблема в отсутствии составного индекса и в N+1 при сборке вложенных записей. Предложил три подхода. Из трёх вариантов выбрал третий сам — потому что только я знал, что через квартал эти пользователи переходят на вдвое больший объём данных и самый простой вариант снова стал бы узким местом.

Это структура почти каждой задачи. Агенту: «найди X», «проверь по правилам Y», «напиши тест на Z». Себе: понять, кому и насколько больно; что допустимо; убедиться, что результат действительно помог. Граница не в сложности задачи — а в том, кто несёт ответственность за последствия выбора.

Почему без методологии рычаг ломается

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

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

Как это выглядит на одной задаче. «Добавить отмену заказа» в трёх сессиях без общего контекста:

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

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

В каком виде живёт этот общий контекст

«Каркас, переживающий сессию» — это не метафора, у него есть конкретные носители, и завести их можно завтра утром. Четыре слоя, от самого дешёвого к самому дорогому:

1. Файл правил проекта. Короткий текст в репозитории, который агент читает каждую сессию: как собрать и проверить, стек, запреты, куда идти за доменом. Заводится за полчаса и сразу убирает половину разнобоя. Главное его свойство и главное ограничение — он читается всегда, поэтому должен быть коротким.

2. Записанная модель и контракт среза. Понятия, состояния, правила и то, что гарантирует операция. Именно отсюда берутся одинаковые имена в третьей сессии: cancel вместо revokeOrder не потому, что агент запомнил, а потому что имя записано в словаре домена. Как это устроено — в статьях про язык домена и контракт среза.

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

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

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

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

Что это значит на практике

Типичные ошибки при работе с ИИ как рычагом:

• Делегировать постановку. «ИИ, что строить?» — самая быстрая дорога получить уверенно сделанное не то. Модель не знает, что болит у твоих пользователей и что ты уже пробовал. Постановка — твоя, всегда.
• Принимать результат без проверки. Код выглядит правильно — не значит работает правильно. Агент оптимизирован на правдоподобие, не на корректность. Каждый значимый выход требует проверки по смыслу, а не только по форме.
• Работать без постоянного контракта. Если у агента нет каркаса — описания задачи, правил, ограничений — он каждую сессию изобретает их заново. Через месяц кодовая база выглядит как написанная пятью разными людьми, хотя её делал один.
• Ждать, что агент сам разберётся. Работа с агентами — профессиональный навык: как сформулировать задачу, как разбить её на части, как проверить промежуточный результат. Чем точнее вход — тем лучше выход. Это не метафора, это механика модели.

Семь эссе как один путь

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

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

Глубже: когда рычаг окупается: считать бюджет на срезрасширенное

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

Где окупается очевидно. Объёмная рутинная работа по понятному образцу: каркас модуля по спецификации, тесты на существующее поведение, миграции и маппинги, документация по коду, перенос между похожими форматами. Здесь час агента заменяет день человека, и цена в токенах меньше цены часа.

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

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

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

Глубже: чей это код: лицензии, совпадения и политика компаниирасширенное

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

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

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

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

Коротко

• ИИ снимает объём исполнения, не постановку и не ответственность; постановка и проверка остаются у человека.
• Агенту отдают рутинное по образцу и объёмное, себе оставляют выбор, границы и приёмку по смыслу.
• Без методологии рычаг ломается: постоянный контракт, правила и исполняемый стандарт держат согласованность между сессиями.
• Окупаемость считают на срез: очевидна на каркасе, тестах и переносах, сомнительна на мелких правках с большим контекстом; бюджет записан до старта, короткие циклы дешевле автономии.
• Юридическая сторона: договор с провайдером о правах на вывод и необучении, сканер лицензий против дословных совпадений, политика компании о разрешённых инструментах и данных.
• Серая зона решается тремя вопросами: увидят ли это снаружи, сколько стоит передумать, есть ли записанное правило; контракт и границы модулей — человеку, реализация и обратимое — агенту.
• Решение, принятое дважды одинаково, превращают в правило или запись памяти — так серая зона сжимается до действительно новых вопросов.
• Разнобой трёх сессий виден в мелочах и дорог в контракте: три способа сообщить об отказе означают три ветки обработки у клиента, а четвёртая сессия продолжит разнобой по образцу.
• Общий контекст живёт в четырёх носителях: короткий файл правил, записанная модель и контракты срезов, скиллы под ситуацию и проверки в сборке; текстовое правило выполняется часто, проверка — всегда.

Что почитать дальше

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