PRO продукты и системы | Иннокентий Бодров
Open in Telegram
Пишу о продуктах, системах и анализе. Показываю, как с помощью AI строю и развиваю собственные проекты — с решениями, ошибками и выводами.
Show more2 621
Subscribers
No data24 hours
+17 days
-430 days
Loading data
Similar Channels
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
October '26Oct '26
October '26
+28
in 2 channels
September '26
+24
in 0 channels
Get PRO
August '26
+19
in 0 channels
Get PRO
July '26
+30
in 1 channels
Get PRO
June '26
+29
in 0 channels
Get PRO
May '26
+75
in 0 channels
Get PRO
April '26
+66
in 1 channels
Get PRO
March '26
+25
in 0 channels
Get PRO
February '26
+95
in 0 channels
Get PRO
January '26
+36
in 2 channels
Get PRO
December '25
+105
in 3 channels
Get PRO
November '25
+158
in 2 channels
Get PRO
October '25
+181
in 3 channels
Get PRO
September '25
+134
in 3 channels
Get PRO
August '25
+31
in 0 channels
Get PRO
July '25
+57
in 1 channels
Get PRO
June '25
+106
in 1 channels
Get PRO
May '25
+54
in 2 channels
Get PRO
April '25
+45
in 0 channels
Get PRO
March '25
+39
in 1 channels
Get PRO
February '25
+127
in 6 channels
Get PRO
January '25
+55
in 1 channels
Get PRO
December '24
+43
in 2 channels
Get PRO
November '24
+48
in 0 channels
Get PRO
October '24
+66
in 0 channels
Get PRO
September '24
+92
in 1 channels
Get PRO
August '24
+100
in 0 channels
Get PRO
July '24
+82
in 1 channels
Get PRO
June '24
+82
in 0 channels
Get PRO
May '24
+176
in 2 channels
Get PRO
April '24
+75
in 0 channels
Get PRO
March '24
+120
in 0 channels
Get PRO
February '24
+98
in 0 channels
Get PRO
January '24
+114
in 0 channels
Get PRO
December '23
+127
in 0 channels
Get PRO
November '23
+89
in 0 channels
Get PRO
October '23
+163
in 1 channels
Get PRO
September '23
+68
in 0 channels
Get PRO
August '23
+79
in 0 channels
Get PRO
July '23
+57
in 0 channels
Get PRO
June '23
+82
in 0 channels
Get PRO
May '23
+57
in 0 channels
Get PRO
April '23
+76
in 0 channels
Get PRO
March '23
+586
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 21 October | 0 | |||
| 20 October | +2 | |||
| 19 October | 0 | |||
| 18 October | 0 | |||
| 17 October | +2 | |||
| 16 October | +1 | |||
| 15 October | +2 | |||
| 14 October | +2 | |||
| 13 October | +6 | |||
| 12 October | +2 | |||
| 11 October | +1 | |||
| 10 October | +4 | |||
| 09 October | 0 | |||
| 08 October | +5 | |||
| 07 October | 0 | |||
| 06 October | 0 | |||
| 05 October | 0 | |||
| 04 October | 0 | |||
| 03 October | 0 | |||
| 02 October | 0 | |||
| 01 October | +1 |
Channel Posts
Уважаемые коллеги! Сегодня — подробнее о докладе Иннокентия Бодрова на АМ18
Иннокентия хорошо знают в профессиональном сообществе: основатель AnalystCraft и частый спикер «Аналитического марафона» — он выступал на AM4, AM5, AM7 и AM16. 24 октября на АМ18 Иннокентий расскажет:
«AI-разведка чужой системы: как собрать проверяемый контекст из документации и кода»
Знакомая ситуация: команде нужно изменить интеграцию существующего сервиса. У аналитика на руках — публичная документация API, внутренняя Wiki прошлой версии, несколько ADR, задачи из трекера, чужой репозиторий и переписка с владельцами системы.
Всё это можно отдать AI — и за один проход получить связное описание системы. Связное, но частично вымышленное: модель смешивает действующий API-контракт, устаревшую Wiki и фактическое поведение кода в одну правдоподобную картину.
Иннокентий покажет, как из тех же материалов собрать не «ответ о системе», а проверяемый пакет контекста: карту источников, подтверждённые правила, найденные противоречия и вопросы владельцам — и как понять, когда AI должен остановиться и передать решение человеку.
После доклада вы сможете:
🔹 организовать исследование незнакомой системы с AI;
🔹 отделять факты от интерпретаций модели;
🔹 находить конфликты между документацией, решениями и реализацией;
🔹 собирать проверяемый контекст перед изменением системы.
📝 Программа и билеты
🏢 Участие от компании по счёту
| 2 | А я напомню, что буду выступать уже в субботу на АМ и мне даже промик для вас дали)
Промик для подписчиков 20% на полный доступ "IB20_AM18" | 64 |
| 3 | No text... | 137 |
| 4 | Ребят, решил чуть больше рассказывать здесь о том, как работает ИИ: что означают разные термины, зачем нужны отдельные подходы и где они пригодятся на практике.
Сделал первую пробную статью — про RAG, CAG и KAG. Это разные способы работы ИИ с документами: найти нужную информацию, использовать заранее подготовленные материалы или разобраться в связях между ними. Объяснил на одном примере, где что полезно и какие есть ограничения.
Статья в Telegraph
Как вам такой формат? Продолжать подобный ликбез? | 203 |
| 5 |  🔥 Агент не смог подтвердить публикацию. Но статья существует. И вот тут начинается самое интересное.
Продолжаю строить свою Portfolio OS — систему управления проектами, задачами и публикациями с помощью AI-агентов. И недавно поймал довольно показательный случай, который заставил ещё раз задуматься о том, как мы вообще определяем, что агент успешно выполнил задачу.
Один из агентов отправлял статью в Дзен. Попытка завершилась без однозначного подтверждения, поэтому повторную отправку мы заморозили, чтобы случайно не создать дубликат.
Позже я передал системе публичную ссылку на статью:
https://dzen.ru/a/atOveCKVowlfZeLT
Казалось бы, всё хорошо. Статья существует, можно закрывать задачу.
Но опубликованная статья и корректно завершённый процесс публикации — две разные вещи.
В планировщике по-прежнему нет канонического факта публикации, а первоначальная попытка остаётся в неопределённом состоянии. Ручная ссылка помогает подтвердить существование публичного объекта, но не восстанавливает автоматически историю его появления.
При этом есть и другой кейс, где публичный объект и факт публикации были подтверждены штатно.
И вот здесь я понял, что нельзя сводить работу агентной системы к одному статусу Done или Failed.
Для себя теперь выделяю три уровня:
1. Agent State — что агент сделал и чем завершилась его работа.
2. Provider State — что известно о результате операции на стороне внешнего сервиса.
3. Publication Evidence — какие подтверждения существования публичного объекта есть и как они связаны с записью в нашей системе.
Эти состояния совершенно не обязаны совпадать.
Агент может сообщить об успехе, хотя публикация не состоялась. Может потерять подтверждение, хотя статья появилась. А может оказаться, что публичный объект существует, но система не смогла связать его с исходной попыткой.
Отсутствие подтверждения — не доказательство отсутствия результата.
И это уже не просто техническая тонкость. Если разрешить агентам автоматически повторять любую неподтверждённую операцию, рано или поздно получим дубли публикаций, платежей, заявок и других действий с внешними последствиями.
Поэтому для таких ситуаций я хочу явно сохранять состояние UNCERTAIN: не повторять операцию автоматически, сохранять историю попытки, проверять внешнюю реальность и только после этого решать, что делать дальше.
А если результат подтверждён вручную, это тоже нужно фиксировать отдельно, не переписывая историю так, будто всё прошло штатно.
Кажется, именно здесь проходит одна из границ между набором AI-автоматизаций и полноценной операционной системой.
Хорошая система должна не просто выполнять действия, а уметь объяснить, что действительно произошло, что подтверждено и где остаётся неопределённость.
А как вы поступаете, когда автоматизация не получила подтверждения? Повторяете операцию или сначала пытаетесь выяснить, что произошло на самом деле? | 193 |
| 6 |  Последний год мы все чаще слышим разговоры о размытии привычных ролей и неизбежном появлении product engineer'ов. Кто это такие, пока не знаем, но добавить продуктового мышления в работу точно не будет лишним.
Поэтому приглашаем завтра на иишечно-продуктовый митап, где будем думать об экономике, собирать second brain, автоматизировать проектирование UX и создание прототипов.
Будет полезно системным и бизнес-аналитикам для расширения кругозора, а продакты и дизайнеры сразу получат инструменты для работы.
Конструктор тарифов и скидок: финмодель от AI, которая не развалится от критики
🎙 Татьяна Сущенко — Product Manager в Яндексе, автор канала Семейка продактов
Собираем второй мозг продакта
🎙 Светлана Дергачева — Lead Product Manager в Constructor, участвует в создании AI-методологии Cyber Pilot
Как сделать продукт на рынке, где ты никто
🎙 Павел Челюскин — Product Designer, основатель Module Agency, автор канала Паша, ты на мьюте
📆 Суббота, 17 октября, 11:00-14:00 мск
🔗 Смотрите расписание и регайтесь тут | 186 |
| 7 | Андрей меня не позвал выступить на этом митапе и рассказать про мой второй мозг, а я все равно позову вас послушать, кто там что умного придумал! | 210 |
| 8 |  Под постом о Portfolio OS меня спросили, как устроена система и зачем там граф.
Покажу на недавнем примере.
Одна публикация в Дзен несколько дней не доходила до проверенного результата. Было исходное поручение, несколько попыток и технический ремонт. Журнал одной попытки зафиксировал ответ площадки с ID объекта. На момент контрольного чтения публичная статья не была подтверждена, а факт публикации в Planner отсутствовал. Значит, работа оставалась незавершённой.
В системе эта история выглядит как цепочка:
источник → сигнал → поручение штабу → задача → результат
Источник сохраняет контекст: откуда появилась работа. Сигнал описывает проблему. Портфельный штаб решает, нужно ли превращать её в задачу и кто за неё отвечает. Штаб продукта ведёт выполнение. В конце нужен результат, который можно проверить вне переписки с агентом.
Агенты внутри штабов выполняют ограниченные шаги: читают источники, готовят изменения, запускают проверку, приносят доказательства. Доставка поручения агенту ещё не означает, что штаб принял результат. И ответ агента «готово» не превращает попытку в выполненное действие.
Граф помогает пройти по этой цепочке назад. Я могу открыть задачу и увидеть, из какого поручения она появилась, к какому продукту относится и какие события меняли её состояние. У каждой связи есть тип и источник. Если связь не подтверждена, система показывает пробел, а не достраивает историю по похожим словам.
Сам граф у меня сейчас довольно приземлённый: локальная проекция SQLite только для чтения. Он собирает разрешённые связи из реестра продуктов и Portfolio Ops. Роли продуктов и маршруты живут в реестре, портфельные поручения — в Portfolio Ops, согласования и факты публикаций — в ContentOps Planner.
Граф знает, что задача относится к AnalystCraft и появилась из конкретного документа пилота. Но он не решает, опубликована ли статья. За этим ответом нужно идти в Planner и на сторону Дзен.
Отсюда две разные проверки.
Первая: почему появилось решение и какие объекты с ним связаны. Здесь помогает граф.
Вторая: кто сейчас отвечает за действие и насколько свежи данные. Это проверяется у владельца задачи и в системе, где произошло действие.
На момент контрольного чтения граф подтверждал источник, назначение и историю задачи. Внешний результат ещё не был подтверждён, поэтому статус оставался «ждём проверку», а не «готово».
Для меня в этом и есть смысл Portfolio OS: в любой момент можно увидеть, откуда пришла работа, кому она принадлежит и какого доказательства ещё не хватает. | 236 |
| 9 |  Агент написал код. Потом написал тесты. Что именно они доказали?
В худшем случае — что две версии понимания одной задачи не спорят друг с другом. Если и реализацию, и тесты пишет один агент из одного описания, зелёный прогон может подтверждать внутреннюю согласованность, а не пользовательский результат.
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 остаётся отдельной проверкой исходного замысла.
Если ваши тесты зелёные, какой наблюдаемый результат пользователя они доказывают — и кто проверил, что проверяется именно он? | 320 |
| 10 | Всем привет, мы в эфире | 274 |
| 11 | 🔥 Иногда лучший способ улучшить собственный фреймворк — показать его другим аналитикам и получить в панамку.
В субботу проводил воркшоп в Техклубе аналитиков. Показывал ребятам свой подход к разработке продуктов с 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
А вы замечали за собой, что самые очевидные для вас рабочие практики почему-то оказываются совершенно неочевидными для остальных? | 327 |
| 12 |  Почему я всё ещё работаю диспетчером
Я собираю систему, которая должна разгружать меня. На этой неделе она несколько раз сделала обратное.
Текст был готов. Редакционная проверка пройдена. Время публикации стояло в плане. Но между «всё подготовлено» и «пост действительно вышел» работа останавливалась.
Я замечал это по очень простому признаку: время прошло, а подтверждённой ссылки нет. И снова шёл разбираться, какой именно шаг не случился. Иногда нужно было заново проверить разрешение на публикацию. Иногда — состояние внешней площадки. Иногда — попросить продолжить уже начатую цепочку.
После этого мы добавили отдельные состояния: подготовлено, разрешено, отправлено и подтверждено. Для опубликованного поста теперь недостаточно уверенного ответа агента — нужна ссылка и записанный факт публикации.
Стало понятнее, где произошла остановка. Но главная проблема пока осталась: слишком часто система показывает её только после моего вопроса.
Получается странно. Я строю операционную систему для портфеля, а сам всё ещё работаю её диспетчером.
Где в вашей автоматизации работа тоже двигается только после напоминания? | 301 |
| 13 | Сегодня при проверке своей системы управления проектами увидел статус «карта связей устарела».
Исходные данные обновились, а граф, по которому агенты находят связанные задачи и решения, ещё не был пересобран.
Кажется, мелочь. Но именно здесь можно получить уверенный ответ на вопрос «что мы решили», который уже не соответствует текущим записям.
Граф пересобрали и проверили одну конкретную цепочку: от исходного сигнала до передачи в продуктовый штаб и записанного решения.
Причём граница проверки осталась видна: запись в локальном источнике подтверждена. Что прямо сейчас происходит в самом штабе, эта проверка не доказывает.
Мне хочется, чтобы система, которой я поручаю работу, умела показывать такие ограничения до следующего действия. Иначе приходится самому вспоминать, где что поменялось, и постоянно поправлять агентов.
Постепенно собираю такую операционную систему для своих проектов. Пока это внутренний пилот: часть механизмов работает, часть ещё проверяем. Буду показывать конкретные случаи, на которых приходится её докручивать. | 366 |
| 14 |  Анонс стрима "ИИ vs Системный аналитик"
13 октября в 19:00 - стрим «ИИ vs Системный аналитик» вместе с Андреем Царевым
Кейс - перевод сотрудника между командами, где доступы и права не успевают за переводом. Сначала разбираем сами: какие вопросы задать, что нельзя решать без владельца. Потом даем то же агенту и сравниваем постановки.
В конце будет открытый микрофон, можно будет позадавать вопросы.
Участие бесплатное, но нужно предварительно зарегистрироваться по ссылке: https://t.me/manage_the_event_bot?start=8600505f-92de-5186-a396-2170dc30f018
Всех ждем! | 441 |
| 15 |  Если LLM не ограничить контекстом и критериями, она легко уйдёт в сторону. В коротком фрагменте — почему с AI полезно работать как с подготовленным джуном: задавать рамки и проверять результат. Больше разборов: https://t.me/spherical_analyst | 396 |
| 16 | Я начал небольшой эксперимент с короткими видео.
У меня есть длинные закрытые и платные лекции. Внутри них много фрагментов, которые, возможно, полезны сами по себе — без часового контекста вокруг.
Первые два фрагмента я опубликовал нативно в 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
Это именно фрагменты, а не полные разборы тем. Я пока проверяю, выдерживает ли отдельный кусок самостоятельный просмотр: понятен ли он без лекции, есть ли в нём законченная мысль и хочется ли после него продолжения.
Посмотрите, пожалуйста, и скажите: такой формат имеет смысл продолжать? И какие темы из длинных лекций вы бы хотели увидеть следующими? | 403 |
| 17 | Публикация может существовать, даже когда автоматизация уверена, что её нет. Сегодня у нас случился именно такой сбой.
Мы выпускали статью в Дзене. Статья появилась, но контур доставки сохранил ошибку загрузки изображения и статус неопределённого результата.
Один из агентов попробовал проверить публикацию с сервера, получил редирект на авторизацию и сделал неверный вывод: статьи нет. Я открыл канал и прямую ссылку сам — статья на месте и видна читателю.
В итоге одновременно существовали три разных факта:
— попытка доставки завершилась с ошибкой;
— подтверждение результата со стороны провайдера осталось неопределённым;
— публикация была доступна по публичной ссылке.
Если хранить это одним полем «опубликовано / не опубликовано», система неизбежно начнёт врать. Ошибка отдельного шага превратится в вывод обо всём результате. А одна неудачная проверка — в доказательство отсутствия того, что на самом деле существует.
Поэтому теперь дорабатываем ContentOps так, чтобы отдельно сохранять попытку, подтверждение провайдера и проверку публичной видимости. Исправление ещё в работе. Этот случай как раз показал, зачем оно нужно.
Сообщение агента, ошибка адаптера и ответ одной проверки — наблюдения, а не финальный факт. Вопрос к команде должен звучать иначе: какое независимое свидетельство подтверждает, что результат действительно существует и доступен тому, для кого мы его делали?
А что у вас считается доказательством завершения: статус внутри контура или внешний проверяемый результат? | 424 |
| 18 | Кажется, в среду на SBC я обнаружил у себя новый скилл. И моему внутреннему ребёнку он категорически не нравится 😁
Я никогда не был человеком, которому легко подойти к совершенно незнакомому человеку и сказать: «Привет, давай поговорим». Особенно если у меня при этом есть какая-то цель — узнать про компанию, обсудить работу, познакомиться с нужными людьми.
А вот на SBC я внезапно поймал себя на том, что спокойно делаю это весь день.
Подхожу к людям, знакомлюсь, начинаю с обычного small talk, а потом перевожу разговор туда, куда мне нужно: чем занимается компания, какие у них продукты, кого ищут, какие есть карьерные возможности. Причём уже практически без разницы — на русском или на английском.
В какой-то момент со мной просто за компанию начали ходить знакомые. Потом нас стало трое, и мы уже небольшой группой пошли знакомиться с очередной компанией.
И тут я поймал довольно забавное ощущение.
Мой внутренний ребёнок всё это время орёт: «Ты что делаешь?! Мы не разговариваем с незнакомыми людьми!»
А взрослый я спокойно отвечает: «Привет! Расскажите, чем вы занимаетесь?» 😁
Наверное, это одна из вещей, которые я сильно недооценивал раньше. Networking — это не магическая способность экстравертов заходить в комнату и через час знать всех.
Это вполне тренируемый навык: начать разговор, услышать, что человеку интересно, найти точку пересечения и аккуратно перевести разговор на нужную тебе тему.
И я впервые заметил не то, насколько мне это сложно, а насколько проще мне стало это делать.
Возможно, лучший способ заметить собственный прогресс — однажды обнаружить, что спокойно делаешь то, от одной мысли о чём несколько лет назад хотелось спрятаться за ближайшей колонной.
Внутренний ребёнок, правда, всё ещё против.
Но его мнение по этому вопросу мы пока учитывать не будем 😁 | 347 |
| 19 |  Уважаемые коллеги, всем хорошей пятницы!
Мы тоже отлично поработали — и с радостью объявляем начало продаж на
Аналитический марафон #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 дней цены минимальные
🏢 Оплата от компании по счёту — отдельная корпоративная страница
Мы очень благодарны нашим спикерам за такую поддержку и мощнейший заряд энергии! 💙
Ждём вас на конференции! | 344 |
| 20 | Кажется, я нашёл один из лучших способов проверить свой английский. И это не экзамен и не рабочий созвон.
После целого дня на SBC Summit меня неожиданно пригласили на небольшую закрытую дегустацию в Lisbon Winery.
И получился прекрасный контраст.
Днём на международной конференции в Лиссабоне я постоянно слышал русскую речь. А вечером оказался единственным русскоязычным человеком в компании и следующие несколько часов общался только на английском — в том числе с нейтивами-британцами.
Вот это, как выяснилось, совсем другой уровень нагрузки на голову 😁
На рабочем созвоне есть контекст. Ты знаешь терминологию, примерно понимаешь, куда идёт разговор, можешь заранее сформулировать сложную мысль.
А здесь темы прыгают каждые пять минут: технологии, бизнес, страны, вино, путешествия, жизнь. Нужно не просто понимать английский, а шутить, перебивать, быстро формулировать мысли и следить сразу за несколькими собеседниками.
Через несколько часов мозг буквально кипит.
Но одновременно поймал приятное ощущение: я всё это время не переводил разговор в голове — я просто разговаривал.
Да, иногда медленнее, чем хотелось бы. Иногда ищешь слово. Иногда понимаешь британца со второй попытки 😁
Но, кажется, именно такие вечера дают для языка больше, чем ещё десять упражнений в приложении.
Так что мой вечерний networking закончился неожиданным языковым стресс-тестом.
Голова квадратная. Зато тест, кажется, пройден. | 348 |
