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


Kanal geosi va tili: Rossiya, Ruscha


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

Bog‘liq kanallar  |  O‘xshash kanallar

Kanal geosi va tili
Rossiya, Ruscha
Statistika
Postlar filtri


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

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

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

В итоге одновременно существовали три разных факта:

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

Если хранить это одним полем «опубликовано / не опубликовано», система неизбежно начнёт врать. Ошибка отдельного шага превратится в вывод обо всём результате. А одна неудачная проверка — в доказательство отсутствия того, что на самом деле существует.

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

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

А что у вас считается доказательством завершения: статус внутри контура или внешний проверяемый результат?


Кажется, в среду на SBC я обнаружил у себя новый скилл. И моему внутреннему ребёнку он категорически не нравится 😁

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

А вот на SBC я внезапно поймал себя на том, что спокойно делаю это весь день.

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

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

И тут я поймал довольно забавное ощущение.

Мой внутренний ребёнок всё это время орёт: «Ты что делаешь?! Мы не разговариваем с незнакомыми людьми!»

А взрослый я спокойно отвечает: «Привет! Расскажите, чем вы занимаетесь?» 😁

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

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

И я впервые заметил не то, насколько мне это сложно, а насколько проще мне стало это делать.

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

Внутренний ребёнок, правда, всё ещё против.

Но его мнение по этому вопросу мы пока учитывать не будем 😁


​​Уважаемые коллеги, всем хорошей пятницы!
Мы тоже отлично поработали — и с радостью объявляем начало продаж на
Аналитический марафон #18 · AI-Powered BA/SA🎉

Немного инсайдов с нашей внутренней кухни. План конференций на деловой сезон 25/26 и тема AM18 — AI-Powered BA/SA — очень сильно отозвались спикерам. У всех оказалось много наработок и идей, которыми хочется поделиться с коллегами-аналитиками. Уже подтвердили участие эксперты, которых хорошо знают в сообществе:

Иннокентий Бодров — автор AnalystCraft  и создатель «Подмастерья аналитика», AI-инструмента для исследования систем, проверки требований и подготовки аналитических артефактов. Более 17 лет в системном анализе, проектировании процессов и создании цифровых продуктов: свыше 60 спроектированных API-интеграций и четыре продукта, запущенных с нуля. Преподаватель курсов и опытнейший спикер АМ.
🎙 «AI-разведка чужой системы: как собрать проверяемый контекст из документации и кода»

Максим Смирнов — ИТ-архитектор, автор канала «Архитектура ИТ-решений» (t.me/it\_arch). В прошлом — руководитель департамента ИТ-архитектуры «Билайн», главный архитектор информационных систем Банка России, спикер, автор и преподаватель курсов по ИТ-архитектуре.
🎙 «Прочтёт ли AI-агент ваши требования? Как новый стандарт организации агентской памяти от Google меняет подход к разработке документации»

С таким началом уровень конференции, как вы понимаете, будет «по хаям» 🔥

📅 24 октября 2026, 10:00–17:00 МСК, онлайн
📝 Темы и тезисы — на странице конференции
💸 Ближайшие 5 дней цены минимальные
🏢 Оплата от компании по счёту — отдельная корпоративная страница

Мы очень благодарны нашим спикерам за такую поддержку и мощнейший заряд энергии! 💙

Ждём вас на конференции!


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

После целого дня на SBC Summit меня неожиданно пригласили на небольшую закрытую дегустацию в Lisbon Winery.

И получился прекрасный контраст.

Днём на международной конференции в Лиссабоне я постоянно слышал русскую речь. А вечером оказался единственным русскоязычным человеком в компании и следующие несколько часов общался только на английском — в том числе с нейтивами-британцами.

Вот это, как выяснилось, совсем другой уровень нагрузки на голову 😁

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

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

Через несколько часов мозг буквально кипит.

Но одновременно поймал приятное ощущение: я всё это время не переводил разговор в голове — я просто разговаривал.

Да, иногда медленнее, чем хотелось бы. Иногда ищешь слово. Иногда понимаешь британца со второй попытки 😁

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

Так что мой вечерний networking закончился неожиданным языковым стресс-тестом.

Голова квадратная. Зато тест, кажется, пройден.


Вчера сходил на SBC Summit в Лиссабоне и несколько раз ловил себя на мысли: а я точно в Португалии? 😁

SBC — огромная конференция вокруг gambling, affiliate marketing, payments и всей сопутствующей индустрии. Проходит она в павильонах Parque das Nações, где обычно живёт Web Summit, поэтому масштаб соответствующий.

Но больше всего меня удивил даже не масштаб.

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

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

И это, кстати, довольно интересное наблюдение про саму индустрию. Я примерно представлял, насколько сильны в gambling и affiliate marketing команды из Восточной Европы, но одно дело знать это теоретически, а другое — увидеть концентрацию людей в нескольких огромных павильонах.

При этом сама конференция оказалась гораздо технологичнее, чем я ожидал. За маркетингом, affiliates и красивыми стендами лежит вполне серьёзная инфраструктура: платежи, highload, antifraud, data, distributed systems.

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

Про одну из них — CockroachDB — напишу отдельно. Потому что вчера внезапно обнаружил её совсем не там и не в том масштабе, в котором ожидал.


Пять проверок: перед вами AI-инструмент или уже рабочий контур?
Последнее время вижу много «AI Operating System», которые при ближайшем рассмотрении оказываются набором чатов, агентов и автоматизаций.
Это может быть очень полезно. Но наличие пяти агентов ещё не означает, что появилась система управления работой.
После предыдущего разбора я свёл для себя проверку к пяти вопросам.
1. Какой объект работы меняется?
Не «агент ответил», а задача, решение, правило или артефакт перешли из одного состояния в другое.
2. Где находится актуальная версия?
Должно быть место, где можно однозначно отличить действующее решение от черновика, старой версии и очередного summary из чата.
3. Кто владеет переходом?
AI может предложить решение или выполнить ограниченный шаг. Но должно быть понятно, кто принимает результат и остаточный риск.
4. Что происходит при изменении?
Новое решение должно явно заменять старое, а связанные задачи и агенты — получать обновлённый контекст. Иначе очень быстро появляются две одновременно «актуальные» версии реальности.
5. Чем подтверждается завершение?
Вот это для меня самое важное.
Нужен внешний факт: ссылка, артефакт, измерение, прошедший тест или зафиксированное решение.
Сообщение агента «Done» доказательством не является.
Если хотя бы на два вопроса нет нормального ответа, перед вами вполне может быть хороший AI-инструмент. Но я бы пока не называл его управляемым рабочим контуром и точно не спешил расширять его автономию.
Потому что автономия становится полезной только тогда, когда вокруг неё появляются состояние, владелец и проверяемое завершение.
И самый диагностичный вопрос здесь очень простой:
Если агент завтра скажет «готово» — чем вы докажете, что работа действительно завершена?






Video oldindan ko‘rish uchun mavjud emas
Telegram'da ko‘rish
Угадайте, что взломали агенты OpenAI на этот раз?

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

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

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

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

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


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




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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


Tech Analyst Club - проектирование, архитектура, AI dan repost
Разбираем кейсы автоматизации в системном анализе

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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


Вчера совершил очередное "грехопадение" - арендовал 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 были незавершёнными или повреждёнными. В общей метрике они выглядели как плохие ответы модели, хотя часть сбоев произошла раньше: среда не завершила работу или контракт пропустил неполный результат.

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

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

20 ta oxirgi post ko‘rsatilgan.