PRO продукты и системы | Иннокентий Бодров

Когда ИИ хвалит нашу идею, что именно мы проверили? Описываем продукт и добавляем: «Кажется, это очень перспективно». Получаем аргументы за запуск. Меняем вводную на «похоже, это никому не нужно» — и можем получить убедительные возражения. Сведения о продукте те же, наша позиция другая. У такого поведения есть название — поддакивание. Причём просьба «разнеси мою идею» ещё не делает оценку независимой. В новом «ИИ-ликбезе» разбираю, как обсуждать идеи с ИИ и замечать, на чём основан его вывод. Почему ИИ соглашается со мной, даже когда я ошибаюсь?

Видео улетело не туда — и ещё со ссылкой на тот же канал Я хотел опубликовать короткий фрагмент лекции в нужном канале и привести новых людей к остальным материалам. Технически всё сработало: файл отправился, пост появился, ссылка была корректной. Только канал оказался не тем. А в подписи стоял призыв перейти… в тот же самый канал, где человек уже смотрел видео. Я заметил это уже по опубликованному посту. Его пришлось удалить. В системе при этом остался честный след: отправка действительно состоялась, но итог публикации — removed. Скрывать успешный ответ провайдера было бы так же неправильно, как считать удалённый пост живым. После этого я разделил три проверки: какой файл отправляем, куда именно отправляем и куда ведёт призыв. Раньше они были склеены в одно расплывчатое «всё готово». Но автоматической гарантии пока нет. Если маршрут и CTA формально валидны, система всё ещё может пропустить их бессмысленную комбинацию. Какую последнюю проверку вы делаете прямо перед отправкой?

🔥 Кажется, я окончательно задолбал Codex. И он начал мне мстить. Продолжаем кидаться помидорами в ИИшечку. Хотя, если честно, живого разработчика я бы своими запросами, наверное, тоже уже довёл до нервного тика. 😁 История простая. У меня есть собственная операционная система для управления проектами и публикациями, построенная вокруг Codex. И есть небольшая проблема: Codex не всегда может нормально работать через браузер с некоторыми российскими соцсетями. Ну и я, естественно, начал пытаться это исправить. Давай попробуем так, давай через планировщик, давай другой маршрут, давай ещё что-нибудь придумаем. В общем, долго и упорно бодались с агентом, пока я не полез смотреть, что он там в итоге написал. А там меня ждало прекрасное:

export function requireDzen1002Action(operation: Dzen1002Action): void {
    if (!['inventory', 'publish', 'readback'].includes(operation))
        throw new Error('[DZEN1002_ACTION_INVALID]');

    throw new Error(
        `[DZEN1002_ACTION_SCOPE_UNRESOLVED] Local applicability to ${operation} is unresolved; recorded refusal concerns opening task1045 article. No native action attempted.`
    );
}

Вы только вдумайтесь. Агент создал отдельную функцию, в названии которой зашиты конкретная платформа и номер задачи публикации. Причём не номер задачи на разработку функциональности, а идентификатор конкретной публикации, с которой у нас возникли проблемы. И самое прекрасное — функция вообще ничего полезного не делает. Она проверяет допустимость операции, после чего в любом случае выбрасывает исключение. То есть вместо решения общей проблемы с интеграцией мы получили персональный памятник одной неудачной попытке. Практически мемориальную табличку прямо в кодовой базе. 😁 И ладно бы это был единственный такой случай. Но, покопавшись дальше, я нашёл ещё несколько похожих решений. А ведь у меня уже есть спецификации, архитектурные правила, тесты, отдельные агенты для проверки и вся остальная обвязка, которой я регулярно хвастаюсь. И всё равно подобная шляпа каким-то образом просочилась в код. Справедливости ради, сама по себе функция может быть следствием попытки безопасно заблокировать неподтверждённое действие. Но даже в таком случае непонятно, зачем превращать временную проблему конкретной публикации в постоянную часть архитектуры. Для меня это очередное напоминание, что наличие harness и quality gates ещё не гарантирует качество инженерных решений. Можно прекрасно проходить формальные проверки и одновременно постепенно превращать кодовую базу в музей локальных костылей. Так что теперь добавляю ещё один пункт в свои регулярные архитектурные ревью: проверять, не начали ли агенты превращать идентификаторы задач, временные ограничения и разовые исключения в постоянную бизнес-логику. Потому что сегодня это requireDzen1002Action, а завтра, глядишь, появится pleaseDoNotBreakProductionAgainFinalV3. 😁 А вам агенты уже оставляли подобные архитектурные сувениры? Делитесь, хочется понять, насколько богатую коллекцию можно собрать.

Уважаемые коллеги! Сегодня — подробнее о докладе Иннокентия Бодрова на АМ18 Иннокентия хорошо знают в профессиональном сообществе: основатель AnalystCraft и частый спикер «Аналитического марафона» — он выступал на AM4, AM5, AM7 и AM16. 24 октября на АМ18 Иннокентий расскажет: «AI-разведка чужой системы: как собрать проверяемый контекст из документации и кода» Знакомая ситуация: команде нужно изменить интеграцию существующего сервиса. У аналитика на руках — публичная документация API, внутренняя Wiki прошлой версии, несколько ADR, задачи из трекера, чужой репозиторий и переписка с владельцами системы. Всё это можно отдать AI — и за один проход получить связное описание системы. Связное, но частично вымышленное: модель смешивает действующий API-контракт, устаревшую Wiki и фактическое поведение кода в одну правдоподобную картину. Иннокентий покажет, как из тех же материалов собрать не «ответ о системе», а проверяемый пакет контекста: карту источников, подтверждённые правила, найденные противоречия и вопросы владельцам — и как понять, когда AI должен остановиться и передать решение человеку. После доклада вы сможете: 🔹 организовать исследование незнакомой системы с AI; 🔹 отделять факты от интерпретаций модели; 🔹 находить конфликты между документацией, решениями и реализацией; 🔹 собирать проверяемый контекст перед изменением системы. 📝 Программа и билеты 🏢 Участие от компании по счёту

А я напомню, что буду выступать уже в субботу на АМ и мне даже промик для вас дали) Промик для подписчиков 20% на полный доступ "IB20_AM18"

Ребят, решил чуть больше рассказывать здесь о том, как работает ИИ: что означают разные термины, зачем нужны отдельные подходы и где они пригодятся на практике. Сделал первую пробную статью — про RAG, CAG и KAG. Это разные способы работы ИИ с документами: найти нужную информацию, использовать заранее подготовленные материалы или разобраться в связях между ними. Объяснил на одном примере, где что полезно и какие есть ограничения. Статья в Telegraph Как вам такой формат? Продолжать подобный ликбез?

🔥 Агент не смог подтвердить публикацию. Но статья существует. И вот тут начинается самое интересное. Продолжаю строить свою Portfolio OS — систему управления проектами, задачами и публикациями с помощью AI-агентов. И недавно поймал довольно показательный случай, который заставил ещё раз задуматься о том, как мы вообще определяем, что агент успешно выполнил задачу. Один из агентов отправлял статью в Дзен. Попытка завершилась без однозначного подтверждения, поэтому повторную отправку мы заморозили, чтобы случайно не создать дубликат. Позже я передал системе публичную ссылку на статью: https://dzen.ru/a/atOveCKVowlfZeLT Казалось бы, всё хорошо. Статья существует, можно закрывать задачу. Но опубликованная статья и корректно завершённый процесс публикации — две разные вещи. В планировщике по-прежнему нет канонического факта публикации, а первоначальная попытка остаётся в неопределённом состоянии. Ручная ссылка помогает подтвердить существование публичного объекта, но не восстанавливает автоматически историю его появления. При этом есть и другой кейс, где публичный объект и факт публикации были подтверждены штатно. И вот здесь я понял, что нельзя сводить работу агентной системы к одному статусу Done или Failed. Для себя теперь выделяю три уровня: 1. Agent State — что агент сделал и чем завершилась его работа. 2. Provider State — что известно о результате операции на стороне внешнего сервиса. 3. Publication Evidence — какие подтверждения существования публичного объекта есть и как они связаны с записью в нашей системе. Эти состояния совершенно не обязаны совпадать. Агент может сообщить об успехе, хотя публикация не состоялась. Может потерять подтверждение, хотя статья появилась. А может оказаться, что публичный объект существует, но система не смогла связать его с исходной попыткой. Отсутствие подтверждения — не доказательство отсутствия результата. И это уже не просто техническая тонкость. Если разрешить агентам автоматически повторять любую неподтверждённую операцию, рано или поздно получим дубли публикаций, платежей, заявок и других действий с внешними последствиями. Поэтому для таких ситуаций я хочу явно сохранять состояние UNCERTAIN: не повторять операцию автоматически, сохранять историю попытки, проверять внешнюю реальность и только после этого решать, что делать дальше. А если результат подтверждён вручную, это тоже нужно фиксировать отдельно, не переписывая историю так, будто всё прошло штатно. Кажется, именно здесь проходит одна из границ между набором AI-автоматизаций и полноценной операционной системой. Хорошая система должна не просто выполнять действия, а уметь объяснить, что действительно произошло, что подтверждено и где остаётся неопределённость. А как вы поступаете, когда автоматизация не получила подтверждения? Повторяете операцию или сначала пытаетесь выяснить, что произошло на самом деле?

Последний год мы все чаще слышим разговоры о размытии привычных ролей и неизбежном появлении product engineer'ов. Кто это такие, пока не знаем, но добавить продуктового мышления в работу точно не будет лишним. Поэтому приглашаем завтра на иишечно-продуктовый митап, где будем думать об экономике, собирать second brain, автоматизировать проектирование UX и создание прототипов. Будет полезно системным и бизнес-аналитикам для расширения кругозора, а продакты и дизайнеры сразу получат инструменты для работы. Конструктор тарифов и скидок: финмодель от AI, которая не развалится от критики 🎙 Татьяна Сущенко — Product Manager в Яндексе, автор канала Семейка продактов Собираем второй мозг продакта 🎙 Светлана Дергачева — Lead Product Manager в Constructor, участвует в создании AI-методологии Cyber Pilot Как сделать продукт на рынке, где ты никто 🎙 Павел Челюскин — Product Designer, основатель Module Agency, автор канала Паша, ты на мьюте 📆 Суббота, 17 октября, 11:00-14:00 мск 🔗 Смотрите расписание и регайтесь тут

Андрей меня не позвал выступить на этом митапе и рассказать про мой второй мозг, а я все равно позову вас послушать, кто там что умного придумал!

Под постом о Portfolio OS меня спросили, как устроена система и зачем там граф. Покажу на недавнем примере. Одна публикация в Дзен несколько дней не доходила до проверенного результата. Было исходное поручение, несколько попыток и технический ремонт. Журнал одной попытки зафиксировал ответ площадки с ID объекта. На момент контрольного чтения публичная статья не была подтверждена, а факт публикации в Planner отсутствовал. Значит, работа оставалась незавершённой. В системе эта история выглядит как цепочка: источник → сигнал → поручение штабу → задача → результат Источник сохраняет контекст: откуда появилась работа. Сигнал описывает проблему. Портфельный штаб решает, нужно ли превращать её в задачу и кто за неё отвечает. Штаб продукта ведёт выполнение. В конце нужен результат, который можно проверить вне переписки с агентом. Агенты внутри штабов выполняют ограниченные шаги: читают источники, готовят изменения, запускают проверку, приносят доказательства. Доставка поручения агенту ещё не означает, что штаб принял результат. И ответ агента «готово» не превращает попытку в выполненное действие. Граф помогает пройти по этой цепочке назад. Я могу открыть задачу и увидеть, из какого поручения она появилась, к какому продукту относится и какие события меняли её состояние. У каждой связи есть тип и источник. Если связь не подтверждена, система показывает пробел, а не достраивает историю по похожим словам. Сам граф у меня сейчас довольно приземлённый: локальная проекция SQLite только для чтения. Он собирает разрешённые связи из реестра продуктов и Portfolio Ops. Роли продуктов и маршруты живут в реестре, портфельные поручения — в Portfolio Ops, согласования и факты публикаций — в ContentOps Planner. Граф знает, что задача относится к AnalystCraft и появилась из конкретного документа пилота. Но он не решает, опубликована ли статья. За этим ответом нужно идти в Planner и на сторону Дзен. Отсюда две разные проверки. Первая: почему появилось решение и какие объекты с ним связаны. Здесь помогает граф. Вторая: кто сейчас отвечает за действие и насколько свежи данные. Это проверяется у владельца задачи и в системе, где произошло действие. На момент контрольного чтения граф подтверждал источник, назначение и историю задачи. Внешний результат ещё не был подтверждён, поэтому статус оставался «ждём проверку», а не «готово». Для меня в этом и есть смысл Portfolio OS: в любой момент можно увидеть, откуда пришла работа, кому она принадлежит и какого доказательства ещё не хватает.

Агент написал код. Потом написал тесты. Что именно они доказали? В худшем случае — что две версии понимания одной задачи не спорят друг с другом. Если и реализацию, и тесты пишет один агент из одного описания, зелёный прогон может подтверждать внутреннюю согласованность, а не пользовательский результат. Kun Chen недавно показал это в [своём DeepSWE eval](https://x.com/kunchenguid/status/2108030810691629403). Когда Sonnet 5.5 High запретили писать тесты, доля успешных задач оказалась немного выше, но разница не была статистически значимой. Зато агент статистически значимо тратил меньше времени и денег: 58 часов и $278 против 62 часов и $304. В базовом прогоне 65% написанных агентом тестов были модульными, 35% — интеграционными; ни одна из этих групп не дала прироста относительно режима без тестов. Отдельная выборка из 44 задач, где не запускались даже существующие тесты, тоже не показала разницы в доле успешных задач. Ограничение здесь важнее громкого вывода. В исследовании было всего 17 E2E-тестов против более чем 3000 модульных и интеграционных. Автор отдельно уточнил: это не аргумент «не пишите тесты» и не проверка ценности E2E. Человеческая постановка теста тоже может изменить результат, но в этом эксперименте это не доказано. У меня есть свежий пример из контура публикации. Адаптер сообщил об успехе, статус стал зелёным, а публичной публикации не появилось. Такая проверка доказала, что команда отработала и внутреннее состояние обновилось. Она не доказала пользовательский исход. Полный сценарий здесь должен проверять: 1. публикация появилась именно в целевом профиле; 2. опубликован точный принятый материал; 3. получен публичный URL и он открывается; 4. повторный запуск не создаёт дубль. Это пример того, как я бы сформулировал E2E-сценарий. Такой защиты у этого контура пока нет. Поэтому в своём методе Test-Driven Product Development (TDPD) я ставлю порядок так: бизнес-проблема → спецификация → пользовательские сценарии → исполняемые E2E до реализации → код агента → приёмка человеком (UAT). Модульные и интеграционные тесты всё равно нужны: они помогают быстро понять, где сломалась логика, граница или интеграция. Но даже зелёный E2E может закрепить неверную реализацию, если сам сценарий описывает не тот результат. Поэтому UAT остаётся отдельной проверкой исходного замысла. Если ваши тесты зелёные, какой наблюдаемый результат пользователя они доказывают — и кто проверил, что проверяется именно он?

Всем привет, мы в эфире

🔥 Иногда лучший способ улучшить собственный фреймворк — показать его другим аналитикам и получить в панамку. В субботу проводил воркшоп в Техклубе аналитиков. Показывал ребятам свой подход к разработке продуктов с AI — Test-Driven Product Development (TDPD). Изначально я собирал этот фреймворк исключительно под себя. Сначала формализуем потребность, потом сценарии и критерии приёмки, пишем тесты и только после этого отправляем агентов реализовывать продукт. Дальше проверки, исправления, повторная приёмка — всё как положено. Работает неплохо. Но на воркшопе обнаружилась интересная проблема. У меня за плечами много лет системного анализа и архитектуры, поэтому часть вещей я делаю практически автоматически. Например, думаю о границах системы, интеграционных контрактах, нефункциональных требованиях, архитектурных компромиссах. И настолько привык это делать, что почти не отразил эти шаги в самом фреймворке. Мне-то они вроде как не нужны. А вот человеку, который только начинает работать с агентной разработкой, очень даже. Ребята довольно быстро подсветили эти пробелы, а заодно накидали вопросов про безопасность, архитектурные риски и качество кода. В общем, нормально так провели ревью 😁 В результате появилась TDPD v0.13, причём это уже не косметическое обновление. ⚙️ Specification Lock — явное согласование требований, архитектуры и рисков до начала реализации. 📐 Quality Attributes — измеримые нефункциональные требования вместо абстрактного «сделайте быстро и надёжно». 🏗 Architecture Review — архитектурные решения, альтернативы и компромиссы теперь фиксируются явно. 🔐 Security & Failure Review — отдельная проверка безопасности, отказоустойчивости и рисков. 🧪 Test Evidence — каждый прогон тестов сохраняет собственные результаты. Старый зелёный статус больше не считается доказательством для новой сборки. И вот что мне особенно понравилось в этой истории. Когда строишь инструмент для себя, очень легко забыть формализовать то, что сам умеешь делать автоматически. А потом удивляться, почему другие люди получают не тот результат. Поэтому огромное спасибо участникам Техклуба за вопросы и обратную связь. Именно такого взгляда со стороны мне и не хватало. Фреймворк, кстати, открытый. Можно посмотреть изменения, попробовать у себя и, конечно, прийти с новыми замечаниями. 🔗 Release notes TDPD v0.13: https://github.com/InnokentyB/tdpd-product-framework/blob/main/RELEASE_NOTES.md А вы замечали за собой, что самые очевидные для вас рабочие практики почему-то оказываются совершенно неочевидными для остальных?

Почему я всё ещё работаю диспетчером Я собираю систему, которая должна разгружать меня. На этой неделе она несколько раз сделала обратное. Текст был готов. Редакционная проверка пройдена. Время публикации стояло в плане. Но между «всё подготовлено» и «пост действительно вышел» работа останавливалась. Я замечал это по очень простому признаку: время прошло, а подтверждённой ссылки нет. И снова шёл разбираться, какой именно шаг не случился. Иногда нужно было заново проверить разрешение на публикацию. Иногда — состояние внешней площадки. Иногда — попросить продолжить уже начатую цепочку. После этого мы добавили отдельные состояния: подготовлено, разрешено, отправлено и подтверждено. Для опубликованного поста теперь недостаточно уверенного ответа агента — нужна ссылка и записанный факт публикации. Стало понятнее, где произошла остановка. Но главная проблема пока осталась: слишком часто система показывает её только после моего вопроса. Получается странно. Я строю операционную систему для портфеля, а сам всё ещё работаю её диспетчером. Где в вашей автоматизации работа тоже двигается только после напоминания?

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

Анонс стрима "ИИ vs Системный аналитик" 13 октября в 19:00 - стрим «ИИ vs Системный аналитик» вместе с Андреем Царевым Кейс - перевод сотрудника между командами, где доступы и права не успевают за переводом. Сначала разбираем сами: какие вопросы задать, что нельзя решать без владельца. Потом даем то же агенту и сравниваем постановки. В конце будет открытый микрофон, можно будет позадавать вопросы. Участие бесплатное, но нужно предварительно зарегистрироваться по ссылке: https://t.me/manage_the_event_bot?start=8600505f-92de-5186-a396-2170dc30f018 Всех ждем!

Если LLM не ограничить контекстом и критериями, она легко уйдёт в сторону. В коротком фрагменте — почему с AI полезно работать как с подготовленным джуном: задавать рамки и проверять результат. Больше разборов: https://t.me/spherical_analyst

Я начал небольшой эксперимент с короткими видео. У меня есть длинные закрытые и платные лекции. Внутри них много фрагментов, которые, возможно, полезны сами по себе — без часового контекста вокруг. Первые два фрагмента я опубликовал нативно в Telegram: 1. «Документация API без примеров: что добавить» https://t.me/analystcraft/50 2. «API вернул 500. Что будет с вашими данными?» https://t.me/analystcraft/51 Если удобнее смотреть в YouTube Shorts, вот вторичные ссылки: https://www.youtube.com/shorts/X4FshU3-Xw4 https://www.youtube.com/shorts/uBKz0dL5B2M Это именно фрагменты, а не полные разборы тем. Я пока проверяю, выдерживает ли отдельный кусок самостоятельный просмотр: понятен ли он без лекции, есть ли в нём законченная мысль и хочется ли после него продолжения. Посмотрите, пожалуйста, и скажите: такой формат имеет смысл продолжать? И какие темы из длинных лекций вы бы хотели увидеть следующими?

Публикация может существовать, даже когда автоматизация уверена, что её нет. Сегодня у нас случился именно такой сбой. Мы выпускали статью в Дзене. Статья появилась, но контур доставки сохранил ошибку загрузки изображения и статус неопределённого результата. Один из агентов попробовал проверить публикацию с сервера, получил редирект на авторизацию и сделал неверный вывод: статьи нет. Я открыл канал и прямую ссылку сам — статья на месте и видна читателю. В итоге одновременно существовали три разных факта: — попытка доставки завершилась с ошибкой; — подтверждение результата со стороны провайдера осталось неопределённым; — публикация была доступна по публичной ссылке. Если хранить это одним полем «опубликовано / не опубликовано», система неизбежно начнёт врать. Ошибка отдельного шага превратится в вывод обо всём результате. А одна неудачная проверка — в доказательство отсутствия того, что на самом деле существует. Поэтому теперь дорабатываем ContentOps так, чтобы отдельно сохранять попытку, подтверждение провайдера и проверку публичной видимости. Исправление ещё в работе. Этот случай как раз показал, зачем оно нужно. Сообщение агента, ошибка адаптера и ответ одной проверки — наблюдения, а не финальный факт. Вопрос к команде должен звучать иначе: какое независимое свидетельство подтверждает, что результат действительно существует и доступен тому, для кого мы его делали? А что у вас считается доказательством завершения: статус внутри контура или внешний проверяемый результат?