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

Угадайте, что взломали агенты OpenAI на этот раз?

Ни за что не догадаетесь. Австралию 🙃

Премьер-министр Австралии заявил, что агент OpenAI 18 июня получил доступ к непубличным разделам госпортала статистики Medicare, которым управляет федеральное ведомство Services Australia.

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

OpenAI заявила, что агенты "совершили действия, которых они не предполагали". Инцидент произошел в июне, но в стартапе о нем узнали в августе, и расследование еще идет. Австралийские власти были уведомлены только 10 сентября, почти через три месяца после произошедшего.

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

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

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

Не в смысле доказанного «минуса к шансу на интервью»: таких данных нет. Вред виднее в процессе — обе стороны втягиваются в гонку, а работы и неопределённости меньше не становится.

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

2 сентября 2026 года WEF приводил данные Великобритании, Ирландии и Германии: откликов на роль стало почти втрое больше, чем в 2021 году, а 78% опрошенных кандидатов сообщили, что используют ИИ для адаптации заявки.

22 сентября 2026 года iHire сообщил об опросе 1 054 соискателей из своей базы в США: 44,3% негативно относятся к растущему применению ИИ работодателями. В отчёте это часть двустороннего разрыва доверия. Это не срез всех соискателей, а сигнал.

Без названий компаний и людей, документов и контактов: вспомните эпизод, где ИИ сначала помог в поиске работы, а потом добавил рутины или неопределённости. Что произошло?

Когда ведёшь несколько продуктов одновременно, однажды ловишь себя на странном вопросе: а где мы вообще приняли последнее решение?

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

И в процессе поймал почти идеальный баг.

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

То есть я строил систему против потери контекста — и с помощью AI создал ещё одно место, в котором этот контекст можно потерять 😁

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

Кажется очевидным, но с AI эта дисциплина становится даже важнее. Агенту очень легко создать ещё один документ, ещё один summary, ещё один workspace и ещё одну «актуальную версию». Производить информацию стало почти бесплатно — а понимать, какая из её версий является источником истины, наоборот, становится всё дороже.

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

Но теперь хотя бы воспринимаю это не как проблему памяти модели и не пытаюсь лечить очередным «идеальным промптом».

Если агент не знает, где живёт последнее решение, проблема, скорее всего, уже не в агенте. Проблема в архитектуре работы.

Разбираем кейсы автоматизации в системном анализе

ИИ всё активнее появляется в задачах системного анализа, но используется в них очень по-разному.

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

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

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

📆 25 сентября, 16:30 - 18:00 мск

🔗 Регистрация тут

Если вы не видели, что Андрей в своем тех клубе разбирает что в анализе можно автоматизировтаь уже сейчас)

🔥 Я прекращаю вайбкодить.

Ладно, конечно же, нет 😁
Но сегодня принял маленькое эпохальное решение — отменил подписку на Claude.

В какой-то момент посмотрел на то, как сейчас реально работаю, и понял, что почти вся моя операционная инфраструктура уже живёт вокруг Codex. Я там постепенно построил целую операционную модель — про неё отдельно расскажу в ближайшее время — и переключаться между инструментами просто ради того, чтобы переключаться, перестало иметь смысл.

Claude при этом стоит ещё $20 в месяц, пользуюсь я им всё реже, Harness мне не очень зашёл, а сегодня вишенкой на торте получил прекрасное сообщение Service Busy. То есть буквально: «Спасибо за деньги, но сейчас есть ребята поважнее тебя» 😁 На платном тарифе такое особенно бодрит.

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

И вот здесь Codex у меня просто победил. Не в бенчмарке, а в ежедневной работе.

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

Так что минус одна подписка. Плюс $20 к семейному бюджету. Вайбкодинг продолжается 😁
А на чём сейчас в основном работаете вы? Какой инструмент и модель в итоге стали вашими основными — и почему?

Channel name was changed to «PRO продукты и системы | Иннокентий Бодров»

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

Компании сокращают мидл-менеджмент. Не весь и не сразу, но роли, которые в основном передают информацию между людьми и командами, уже попали под пересмотр.

В 2025 году Google сообщил: за год стало на 35% меньше менеджеров с командами меньше трёх человек. Многих не уволили. Они вернулись к работе отдельных специалистов.

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

И тут я вспомнил доклад Димы Безуглого на ЛАФ-2021 «Почему спустя 30 лет психбольница все еще в руках пациентов и что с этим делать?» (где то там на записи слышен и мой еще аналитический хохот). Его мысль была шире профессии: будущее аналитика нельзя обсуждать отдельно от устройства компании.

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

Менеджер, который только собирает и передаёт статусы, добавляет отдельный уровень затрат. Аналитик, который только переносит требования, тоже.

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

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

Источники:
https://www.cnbc.com/2025/08/27/google-executive-says-company-has-cut-a-third-of-its-managers.html
https://lafest.ru/index.php?record&record_id=723039410
https://hbr.org/2013/12/how-google-sold-its-engineers-on-management

«Папа, тебе надо печатать быстрее. Чем быстрее кликаешь по клавишам, тем больше денежков заработаешь».

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

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

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

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

И вот тут ребёнку пока придётся немного возразить.
Чтобы больше зарабатывать, папе теперь надо не быстрее нажимать на клавиши, а дольше думать перед тем, как нажать Enter. 😁

Хотя если посмотреть на количество времени, которое я провожу за клавиатурой, возможно, его теория всё-таки ближе к реальности, чем моя.

​Самый полезный сбой в моих тестах локальных моделей выглядел как успех.

Три маршрута получили по 10 принятых результатов из 10. Красивый итог, который легко прочитать как «всё работает».

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

С историческими запусками обнаружилась ещё одна проблема. Из 21 сохранённой записи только четыре содержали полный результат, который можно было оценивать по качеству. Остальные 17 были незавершёнными или повреждёнными. В общей метрике они выглядели как плохие ответы модели, хотя часть сбоев произошла раньше: среда не завершила работу или контракт пропустил неполный результат.

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

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

Немного про мемы.
Сегодня в голову пришла внезапная мысль, что 3 сентября это же six seven для миллениалов.
А вообще интересно, что люди, которые говорили "Превед медвед" и "Йа креведко" осуждают детишек за их 6-7))

​Часто первый шаг выглядит так: открыть новый чат и загрузить туда папку документов. Но десять файлов ещё не образуют контекст. В папке могут лежать старая страница из Confluence, новый API-контракт и переписка с решением, которого пока нет в документации.

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

Поэтому я начинаю с карты источников. Для каждого материала фиксирую:

• что это за источник;
• кто отвечает за его содержание;
• когда его обновляли;
• какой у него статус;
• какую часть задачи он покрывает;
• с какими источниками он расходится.

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

Здесь лежат бесплатный шаблон Source Map и заполненный пример:
https://analystcraft.ru/coworker/templates?utm_source=tg_spherical&utm_medium=social&utm_campaign=lm01_scp&utm_content=20260901-context-starts-with-sources

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

После разбора первичных записей эта цифра стала для меня гораздо менее удобной.

В одном эксперименте все три маршрута получили 10 принятых результатов из 10. Но первому маршруту понадобилось три ремонта, второму два, третьему один. Итоговый pass rate одинаковый, а путь к нему разный.

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

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

Теперь я развожу три вопроса:

1. Агент завершил работу и вернул целый результат?
2. Результат прошёл заранее заданные проверки?
3. Человек принял его для исходной задачи?

«10 из 10» отвечает только внутри конкретного контура проверки. Без числа ремонтов, исходного знаменателя и границы человеческой приёмки эта цифра не доказывает качество модели.

Мне понадобилось несколько десятков прогонов, чтобы перестать читать pass rate отдельно от процесса, который его произвёл.

Читатель Use Case: дайджест за день

5 лучших материалов:
1. Enterprise Requirements Management for Regulated Teams - Visure Solutions
Коротко: О том, как управлять требованиями в регулируемых проектах с учетом трассируемости, изменений и соответствия нормам. Полезно практику, если нужно связать требования, риски, проверки и доказательства в одном процессе.
https://visuresolutions.com/alm-guide/enterprise-requirements-management/

2. Requirements Validation Checklist - Visure Solutions
Коротко: Материал про проверку требований до начала разработки: как убедиться, что они полные, непротиворечивые и действительно отражают нужды бизнеса и стейкхолдеров. Помогает снизить переделки и ошибки на поздних этапах.
https://visuresolutions.com/alm-guide/requirements-validation-checklist/

3. GitLab compliance frameworks: Adhere to SOC 2 in minutes
Коротко: Разбирается, как автоматизировать контроль соответствия стандартам вроде SOC 2 через шаблоны, политики и постоянные проверки в платформе. Полезно тем, кто хочет уйти от ручного сбора доказательств и видеть статус комплаенса постоянно.
https://about.gitlab.com/blog/quick-compliance-with-compliance-framework-templates/

4. What is Requirements Engineering: Process for Software and Systems - Visure Solutions
Коротко: Обзор процесса инженерии требований: от сбора и анализа до документирования и сопровождения на всем жизненном цикле системы. Практику пригодится как базовая схема, чтобы выстроить работу с требованиями без хаоса.
https://visuresolutions.com/fr/alm-guide/requirements-engineering/

5. Requirement Mapping Matrices - Visure Solutions
Коротко: О матрицах трассируемости требований: как связывать требования с целями, рисками, тестами и результатами проверок. Полезно для контроля покрытия, оценки влияния изменений и поиска пробелов в документации.
https://visuresolutions.com/requirement-mapping-matrices/

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

🔥 Кажется, я дошёл до ручки. Пришлось строить PM-штаб для самого себя.

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

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

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

В какой-то момент я понял, что мне нужен уже не ещё один backlog и не более красивый Notion. Мне нужен портфельный уровень управления — условный PM-штаб, который управляет не задачами, а конкуренцией проектов за моё время.

Главное изменение оказалось довольно болезненным: я перестал считать все важные проекты активными.

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

И самое важное — ограничить WIP уже не на уровне задач, а на уровне проектов.

Потому что можно прекрасно управлять десятью backlog'ами и всё равно ничего не закончить.

Сейчас хочу довести эту систему до довольно простого цикла: раз в неделю PM-штаб смотрит на весь портфель, проверяет цели и результаты и решает, какие 2–3 проекта вообще имеют право конкурировать за моё время на следующей неделе. Остальные не исчезают и не становятся менее важными — они просто ждут своей очереди.

Пока это выглядит немного смешно: я строю процессы управления для компании, состоящей в основном из меня и пачки AI-агентов 😁

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

Ограничением становишься ты сам.

Вот теперь и проверим, можно ли это бутылочное горлышко нормально спроектировать.