Книжный куб

Alexander Wang: если интеллект перестаёт быть дефицитом (Рубрика #AI)

Посмотрел разговор Гарри Тана с Александром Ваном на Startup School 2026 "Alexandr Wang: “This is a Once-in-a-Civilization Opportunity", опубликованный 29 июля 2026 года. Ван основал Scale AI, а сейчас занимает позицию Chief AI Officer в Meta, запрещенной в России. Но интереснее должностей его главный прогноз: интеллект и способность действовать станут изобильными, а дефицитом останутся видение, амбиция и умение собирать систему вокруг агентов.

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

Отсюда его версия персонального сверхинтеллекта (personal superintelligence): миллиарды людей получают персональных агентов, а миллионы компаний - агентов, которые договариваются между собой. Разработчик в этой картине поднимается по уровням абстракции: сначала писал код, затем оркестрировал отдельных агентов, дальше будет проектировать организации из миллионов или даже триллионов агентов. Но это пока футуристический прогноз, хотя основной механизм Ван описывает вполне приземлённо. Нужен замкнутый контур: цель, данные, действие, обратная связь и метрика, по которой система понимает, стало ли лучше. По его утверждению, внутри Meta удачный агентный контур (agentic loop) с подходящей проверкой качества (eval) уже позволял рою агентов делать больше команды из ста инженеров, но публичных данных для проверки этого сравнения в разговоре нет. Интересно, что концепцию Loop Engineering мы разбирали недавно с Максом Смирновым.

После просмотра видео с Alexander Wong я вспомнил, что Джефф Дин, о выступлении которого на Y Combinator School 2026 я рассказывал вчера, около десяти лет назад приходил говорить про будущее (это было на YC AI от 7 августа 2017 года). Дин тогда показывал TensorFlow, TPU, neural architecture search и формулировал «запросы будущего»: описать видео на испанском; найти работы по reinforcement learning для робототехники и суммировать их на немецком; научить робота безопасно работать рядом с людьми в неструктурированной среде. Первые два сценария сегодня уже не звучат как научная фантастика. Третий всё ещё остаётся фронтиром: модели научились лучше понимать сцену и инструкции, но надёжное физическое действие и безопасность требуют отдельного инженерного контура.

Разница оптик показательна. Дин смотрел на модель как на новый вычислительный инструмент и спрашивал, какие задачи она сможет решить. Ван начинает с предположения, что цифровой интеллект уже стал дешёвым и доступным, и спрашивает, кто поставит ему цель и соберёт из него работающую организацию. Единица изменения выросла от модели и запроса до компании и её контуров обратной связи. Но есть и важное сходство. Ни один не предсказывает исчезновение инженерии. У Дина человеческая экспертиза переезжала в архитектуру данных, вычислений и автоматизацию экспериментов. У Вана она переезжает в постановку целей, оркестрацию, evals и системное мышление. Абстракция меняется, а ответственность за устройство системы остаётся.

И здесь я бы не принимал весь оптимизм Вана за нейтральный прогноз. Разговор одновременно продвигает стратегию Meta, Muse Spark и будущую платформу для агентов. Оценки «в десять раз», «в сто раз» и сравнение со ста инженерами - позиции спикера, а не независимые бенчмарки.

#AI #Agents #Engineering #Architecture #Leadership #Management

ASUS ExpertCenter Pro ET900N G3: локальные модели за $100 тысяч (Рубрика #AI4SDLC)

Посмотрел опубликованный 30 июля 2026 года тест Алекса Зискинда «This was a data center a year ago… Now it's on my desk». Кажется, свои локальные модели никогда ещё не были так близко. Осталась мелочь: найти $100 тысяч на собственный настольный суперкомпьютер ASUS ExpertCenter Pro ET900N G3.

И это почти не преувеличение. Один из американских продавцов указал для системы цену $99,999.99. За эти деньги получаем башню на архитектуре NVIDIA DGX Station: 72-ядерный Grace CPU, Blackwell Ultra GPU, до 20 PFLOPS в FP4 по спецификациям NVIDIA и 748 ГБ когерентной памяти. Год назад такой объём AI-вычислений ассоциировался скорее со стойкой, а теперь коробку можно поставить рядом со столом. Правда, с максимальным энергопотреблением системы до 1,6 кВт это всё-таки больше сервер в офисе, чем новый домашний PC:)

Самое интересное здесь - память. В рекламной строке 748 ГБ выглядят как один огромный общий пул, но физически он состоит из двух очень разных частей:
- 252 ГБ HBM3e с пропускной способностью до 7,1 ТБ/с;
- 496 ГБ LPDDR5X с пропускной способностью до 396 ГБ/с;
- между Grace и Blackwell - когерентный NVLink-C2C, поэтому GPU может обращаться к обеим областям в общем адресном пространстве.

Это снимает жёсткую границу «модель не поместилась в VRAM - запуск невозможен», но не отменяет физику. В тесте квантованная до NVFP4 GLM-5.2 занимает около 465 ГБ и целиком в HBM не помещается. Она запускается локально, однако части весов приходится читать из более медленной памяти, поэтому скорость заметно уступает моделям, которые полностью остаются в HBM. Когерентная память - это не магические 748 ГБ одинаково быстрой VRAM.

Вторая важная часть видео - это не скорость одного чата, а конкурентный режим работы моделей. На NVIDIA Nemotron 3 Super 120B Алекс запускает до 128 параллельных агентов. В зависимости от модели и числа запросов суммарная производительность доходит до нескольких тысяч токенов в секунду. Это работает за счёт continuous batching: GPU собирает много запросов и эффективнее обрабатывает их вместе. При этом отдельный агент ждёт дольше - общий throughput растёт не бесплатно.

И вот здесь система становится интересной не богатому любителю, а команде. Один локальный узел может обслуживать coding agents, исследовательские задачи и внутренние AI-сервисы, не отправляя код и данные во внешний API. Можно держать десятки долгоживущих агентов, экспериментировать с большими open models и получать предсказуемую инфраструктуру под высокой постоянной нагрузкой.

Но я бы поспорил с формулировкой «нулевая цена токена». Цена просто переезжает из API-счёта в капитальные затраты, электричество, охлаждение, хранение, обновления и эксплуатацию. А ещё локальная модель должна пройти тот же quality gate, что и облачная: 128 агентов бесполезны, если каждый из них быстро производит посредственный результат.

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

Свои локальные модели ещё никогда не были так близко. Особенно если у вас завалялись $100 тысяч, отдельная линия питания и очень убедительный бизнес-кейс:)

P.S.
А моя жаба раскошелилась только на комп "Beelink GTR9 Pro AMD Ryzen™ AI Max+ 395" (или вот он же, но уже в России), которого тоже хватает для экспериментов:)

#AI #AI4SDLC #Agents #Engineering #Architecture #Hardware

Материалы по прямому эфиру с Анатолием Красновским про моделирование надёжности по графу зависимостей (Рубрика #SRE)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Анатолием Красновским (@mb3rlab):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка
- Репозитории: Sheaft, Bering и Procrustes

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

ИТ-Пикник 8 августа и мой доклад «Разработка после AI» и наше исследование (Рубрика #AI4SDLC)

8 августа в Москве пройдет ИТ-Пикник - летний фестиваль, который Т-Банк делает для ИТ-специалистов и их близких: лектории, интерактивные зоны и музыка на траве в музее-заповеднике «Коломенское». Я выступаю там с докладом «Разработка после AI»: расскажу, как сейчас дела с AI в разработке - в индустрии в целом и в Т-Банке в частности - и представлю наше исследование AI4SDLC Research 2026.

Сначала про доклад. AI меняет не только то, как мы пишем код, но и саму модель разработки: узкие места смещаются из написания кода в постановку задач, проверку результатов и организацию разработки. Опираясь на опыт трансформации разработки в Т-Банке и мировые тренды, разберем, что уже меняется в индустрии: почему появляется agent-based SDLC, зачем возвращаются спецификации и какой станет инженерная платформа в ближайшие годы.

Теперь про исследование. Это наш взгляд на переход от точечных AI-ассистентов к агентной разработке, где инженеры формулируют задачи, а агенты выполняют их под контролем человека. Мы идем двумя треками: метаисследование публикаций 2026 года и собственный опрос в логике DORA, расширенный вопросами про автономность агентов, разделение труда и стоимость проверки.

И про сам фестиваль. Кроме инженерных лекториев - от генеративного AI до кибербезопасности - будет научпоп (среди спикеров Михаил Гельфанд и Максим Кронгауз), десятки интерактивов и музыкальный лайнап с хедлайнером LAB Антона Беляева. По билету можно прийти с близкими: одним взрослым и двумя детьми до 16 лет. Половина стоимости билета идет в благотворительный фонд «Галчонок».

Когда и где: 8 августа, Москва, музей-заповедник «Коломенское», мой доклад - в 14:00 в лектории «Инженерная продуктивность». Участие платное, заявки модерируются - так что лучше зарегистрироваться заранее.

В общем, приходите послушать, куда движется разработка с AI, и поговорить лично - буду рад увидеться.

#AI #AI4SDLC #Engineering #Conference #Research

Джефф Дин: правило 1% для AI-продуктов (Рубрика #AI)

Видео с Джеффом Дином смотреть всегда интересно и познавательно. Он умеет начать с истории про MapReduce или расчёта на салфетке, а через несколько минут вывести разговор к архитектуре следующего поколения систем. Раньше я уже рассказывал про его TED-выступление, большую лекцию в Rice University, интервью с Ноамом Шазиром и ретроспективу развития AI в Stanford AI Club. А теперь посмотрел новый разговор Джеффа с Дианой Ху на YC Startup School 2026 - «The 1% Rule for Building in AI». Если в предыдущих лекциях он объяснял, как мы пришли к современным моделям, то здесь вопрос практичнее: что ещё имеет смысл строить небольшой команде, когда универсальные модели быстро забирают всё больше задач.

Самая полезная мысль выпуска - то самое правило 1%. По мнению Дина
⚠️ Опасно выбирать область, где frontier-модель уже справляется примерно в 20% случаев: это признак, что способность появилась и через полгода или год базовая модель может съесть значительную часть продукта.
✅ Лучше смотреть туда, где сегодня она успешна лишь в 0–1% случаев, а у команды есть способ превратить этот один процент в работающую систему.

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

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

Хороший пример - работа самого Дина с Санджаем Гемаватом. Они описали для агента привычный цикл оптимизации низкоуровневого кода: запустить микробенчмарки, изменить реализацию, снова измерить производительность, проверить более широкий набор сценариев и размер кэша, затем повторить. По сути, многолетний инженерный опыт превратился в skill. Их публичный документ «Performance Hints» можно использовать как исходный материал для похожей обвязки.

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

И, конечно, разговор с Джеффом не мог обойтись без железа. Он снова рассказывает историю TPU: в 2013 году расчёт показал, что всего три минуты распознавания речи в день на каждого пользователя потребовали бы удвоить серверный парк Google. Ответом стал специализированный чип для низкоточной линейной алгебры; опубликованный Google разбор первого TPU показывал в 30–80 раз лучшую производительность на ватт относительно тогдашних CPU и GPU.

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

Наконец, Дин ожидает, что в 2027 году заметно вырастет автоматизация самого ML: система будет раскладывать задачу, запускать множество экспериментов, оценивать результаты и собирать улучшенную версию. AlphaEvolve уже показывает форму такого цикла, хотя результаты Google здесь стоит воспринимать именно как данные компании, а не как независимое подтверждение универсальности подхода.

В общем, интересно было послушать мысли Джеффа о том, что ждет индустрию в будущем.

#AI #Agents #Engineering #Architecture #Infrastructure #Product

Code of Leadership S2E8: Цифровой тимлид или можно ли измерить эффективность разработчика по коду? (Рубрика #DevEx)

Работают ли ваши разработчики на 100%? И можно ли вообще ответить на этот вопрос по коду - без табелей, дополнительных отчётов и субъективной оценки руководителя? А если в работе случился спад - отличить недозагрузку от сложного легаси, техдолга, незнакомой технологии или месяца тяжёлой отладки?

6 авугста в 17:00 по Москве со мной в прямом эфире будет Иван Гель, основатель компании Dex, в рамках подкаста Code of Leadership. Мы поговорим об UpCore - системе, которую команда называет «цифровым тимлидом».

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

По заявлению команды UpCore, система может определить, сколько времени заняла бы работа у разработчика определённого уровня, увидеть долю сохранившегося кода, переделок и отладки, учесть сложность архитектуры, легаси, баги и технологии проекта. В презентации заявлена точность на уровне 85% относительно экспертной оценки, а также рост эффективности в среднем на 12% за три месяца после внедрения.

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

Обсудим:
- Что именно UpCore считает эффективностью и как нормализует разные проекты, стеки и типы задач;
- Можно ли автоматически определить грейд и трудоёмкость только по коду;
- Как в текущих условиях, когда код пишется с помощью ИИ, можно измерить эффективность программиста.
- Как отличить слабую работу от легаси, техдолга, сложного ядра системы и длительной отладки;
- На каких данных проверялись заявленные 85% точности и рост на 12%;
- Повышает ли полная прозрачность осознанность разработчика или разрушает доверие в команде;
- Как защитить такую систему от накрутки и саму команду - от ошибочных управленческих выводов;
- Где проходит граница между полезной инженерной телеметрией и цифровой слежкой.

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

#AI4SDLC #Engineering #Management #Leadership #Metrics #DevTools

Sonar и звёздный час верификаторов (Рубрика #AI4SDLC)

Sonar как продукт существует уже почти двадцать лет и всё это время пользовался популярностью в своей нише: статический анализ, quality gates, поиск багов, уязвимостей и code smells. Но теперь у компании началась настоящая пруха. Агенты генерируют код как не в себя - для всех и сразу. Контролировать его качество вручную становится всё сложнее. И тут на сцену выходит Sonar со своими детерминированными правилами. И не только с ними. И вот я посмотрел выступление Тарика Шауката, CEO Sonar, на "AI Engineer World’s Fair", в котором Тарик как раз про это и рассказывал.

Модели способны решать всё более длинные задачи, но надёжность отстаёт. В приведённых Шаукатом данных METR 16–20 часов человеческой работы - это горизонт при 50% вероятности успеха агента. При 80% он сокращается до 3-4 часов. Один из CTO клиентов Sonar заметил: сотрудник с точностью 80% уже оказался бы на performance review. Ещё неприятнее, что функционально правильный код может остаться сложным, уязвимым и дорогим в сопровождении. Краткосрочный рост скорости начинает съедаться ревью и техдолгом.

Ответ Sonar - Agent Centric Development Cycle, или AC/DC (про эту аббревиатуру от Sonar я уже рассказывал, когда говорил о другом их докладе примерно на эту же тему):
- Guide - дать агенту контекст, архитектурные ограничения и quality profile.
- Generate - агент пишет код.
- Verify - детерминированный анализ проверяет потоки данных, секреты и известные паттерны, а агентная проверка — намерение и бизнес-логику.
- Solve - найденные проблемы возвращаются агенту, он исправляет код и запускает цикл заново.

Проверка при этом должна жить не только в CI перед merge. Шаукат говорит о трёх связанных контурах: внутреннем цикле агента, CI verification и постоянном обслуживании кодовой базы. И здесь есть важный поворот: чистый код теперь нужен не только людям. Агенту проще в нём ориентироваться, он тратит меньше токенов и реже ошибается. Правда, цифры Sonar про снижение дефектов и расхода токенов пока остаются данными самого вендора.

Для меня главный вывод в том, что старый добрый статический анализ внезапно становится не наследием прошлого, а инфраструктурой будущего.

#AI #AI4SDLC #Agents #Engineering #DevSecOps #Software

Материалы по прямому эфиру с Сергеем Барановым про AI в архитектуре (Рубрика #Architecture)

Готовы материалы с прямого эфира подкаста Research Insights Made Simple с Сергеем Барановым (@blog_sb), партнером компании Скрамтрек и организатором конференции ArchDays (@blog_sb):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

P.S.
Как раз видео на выходные + если кто-то хочет почитать оригинальное исследование, то вот оно + мой краткий разбор

#AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

Приходите на подкаст, мы его сейчас только стартовали

Как AI-native разработка меняет роль продакта

Поймал себя на интересной мысли

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

В AI-native разработке продакт перестаёт быть интерфейсом между «бизнесом» и инженерами. Ему нужно самому зайти в данные, собрать с агентом прототип, сформулировать evals и критерии приёмки, понимать стоимость и риски.

В качестве доказательства можно посмотреть уже разобранный мной выпуск Lenny's Podcast с Зеви Арновиц, продактом из запрещенной в России компании Meta. У Зеви нет технического образования, и он признаётся, что почти не умеет читать код. При этом он построил вокруг моделей маленькую инженерную организацию с Claude, Gemini, Codex, Cursor и отгружает код на прод. Сам он отвечает за то, что должен почувствовать пользователь от фичи, а агентам делегирует реализацию.

Забавно, что теперь инженер с продуктовым мышлением и AI уже может забрать часть discovery, дизайнер — проверить сценарий, аналитик - собрать прототип. А продакт, чья сила держится на встречах, презентациях и бэклоге, внезапно обнаружит, что команда умеет обходиться и без этого.

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

#AI #ProductManagement #AI4SDLC #Engineering #Management #VibeCoding

По предложению канала Roots написал пост про то, как AI меняет профессию продакта
Спасибо ребятам, что предложили подумать над этим.

Frank Coyle про онтологии: логика снаружи вероятностного агента (Рубрика #AI)

Посмотрел двадцатиминутный доклад Фрэнка Койла «Why Agentic Systems Need Ontologies» с AI Engineer World's Fair 2026. У меня со словом «онтология» долго были сложные отношения: в разговорах об архитектуре оно было почти стоп-словом. Слишком часто этой терминологией пользовались люди, очень далёкие от практики: вместо работающего контракта получалась попытка сначала классифицировать весь мир.

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

Фрэнк Койл - это преподаватель School of Information в UC Berkeley; среди прочего он ведёт курс по представлению знаний для интеллектуальных приложений. Главный тезис его выступления простой: вероятностное рассуждение нужно оставить внутри LLM, а формальную логику - вынести наружу. Модель хорошо интерпретирует неструктурированный запрос, собирает контекст и предлагает следующее действие. Но она не обязана каждый раз заново угадывать, что такое заказ, кто имеет право получить выплату и какие состояния допустимы у доставки. Это уже знание конкретного домена.

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

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

Койл показывает очень приземлённые ошибки: повторный возврат денег по одному заказу, выплату сотруднику поддержки вместо покупателя и статус доставки probably shipped там, где система ожидает только paid, shipped или refunded. Описывать такие инварианты абзацами в системном промпте можно, но промпт остаётся просьбой к модели. Формальное правило становится общим машинно-проверяемым контрактом для разных агентов и инструментов.

Для меня именно здесь слово «онтология» перестаёт быть стоп-словом. Речь не о том, чтобы построить окончательную модель всей компании. Достаточно локальной онтологии операции: какие сущности участвуют, какие переходы разрешены и что должно быть истинно до необратимого действия. В этом смысле она оказывается рядом со схемой API, движком политик (policy engine), машиной состояний и ограничениями базы данных, а не рядом с красивой архитектурной картинкой.

Есть, правда, важная оговорка. В докладе OWL (Web Ontology Language) местами выглядит как готовый валидатор бизнес-правил, но семантика OWL работает в открытом мире: отсутствие факта не означает его ложность, а FunctionalProperty при двух значениях может привести к выводу, что значения обозначают один объект, а не к привычной ошибке валидации. Для закрытых проверок вида «не больше одного возврата» или «только одно из трёх состояний» обычно нужен отдельный слой: SHACL, код, ограничения базы данных, движок политик или их комбинация. И, конечно, идемпотентность и транзакционные гарантии онтология тоже не заменяет.

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

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

#AI #Agents #Architecture #Engineering #KnowledgeGraphs #Data

AMA Сессия #2 про AI-assisted Engineering с Алексеем Литвиновым (Рубрика #AI4SDLC)

В среду в 17:00 по Москве вместе с Алексеем Литвиновым в прямом эфире продолжим говорить про AI-Assisted Engineering и про то, как вообще строить AI-Native организацию. За первую серию AMA сессии мы не справились со всеми вопросами, поэтому мы продолжим обсуждать это с Лёшей, у которого есть свой tg-канал - @tip_podcast, подписывайтесь на него.

Мы договорились обсудить
- зрелость работы с AI // от «пишу код сам» до экосистемы на принципах
- verification debt и цена проверки
- почему навык уезжает из кодинга в менеджмент
- AI-native организация: операционка, роли, governance
- люди и найм, когда рядом агенты

И мы с радостью учтем еще и ваши вопросы, что вы можете оставить через Google Forms (https://forms.gle/3ScqHGyxUsZAf7Wz7), где вы сможете рассказать
- Кто вы по роли
- Что хотите, чтобы мы разобрали
- С каким тезисом про AI вы не согласны (опционально)

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

#Books #AI4SDLC #AI #Agents #Engineering #Architecture #Leadership

Прямой эфир стартанул, подключайтесь

Материалы по прямому эфиру с Александром Воронцовым про будущее консалтинга (Рубрика #Consulting)

Готовы материалы с прямого эфира подкаста Code of Leadership с Александром Воронцовым, партнером компании "Ревелио" (@revelio_tech.):
- Страничка выпуска
- Видео: YouTube, VK Video
- Аудио: Podster, Яндекс Музыка
- Текст: Краткая расшифровка

#AI #Management #Processes #Engineering #Software

Research Insights Made Simple #25: Моделируем надёжность по графу зависимостей (Рубрика #SRE)

Можно ли понять, где распределённая система сломается, ещё до дорогого эксперимента со сбоями? В этом выпуске сегодня в 17:00 мы вместе с Анатолием Красновским разберём его работу "Model Discovery and Graph Simulation: A Lightweight Gateway to Chaos Engineering", отмеченную Distinguished Paper Award на ICSE-NIER 2026 (кстати, я разбирал ее раньше).

Анатолий - инженер, который пошёл в науку, чтобы спасти IT от шаманства. За 10+ лет в разработке он устал от того, что сложные системы строятся на интуиции и слепом копировании «лучших практик». Сейчас он пишет кандидатскую по матмоделированию в Иннополисе, чтобы научиться доказывать их устойчивость математически, а не надеяться на эмпирический авось, а также ведет свой канал о том, как на самом деле работают сложные системы: @mb3rlab

Идея подхода Анатолия из этой статьи проста: автоматически извлечь из распределённых трасс граф обязательных вызовов, добавить число реплик и с помощью Monte Carlo оценить доступность системы при отказах. Получается не замена chaos engineering, а дешёвый фильтр перед ним: модель помогает найти подозрительные цепочки, единичные точки отказа и сценарии, которые стоит проверить на живой системе в первую очередь.

С автором обсудим:

- Почему для первого приближения может хватить топологии и числа реплик;
- Как автоматически обнаруживать модель из Jaeger и поддерживать её актуальной вместе с системой;
- Что означает высокая корреляция с живым fault injection и почему один benchmark ещё не доказывает универсальность метода;
- Где заканчиваются возможности модели: gray failures, коррелированные сбои, очереди, retries и асинхронные потоки;
- Как встроить такой анализ в CI/CD, связать его с SLO и превратить в приоритизацию chaos-экспериментов;
- Где проходит граница между полезным упрощением и опасной ложной уверенностью.

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

#Software #Engineering #Architecture #DevOps #Reliability #Research

Почему AI-copilot архитектора всё ещё не получился (Рубрика #Architecture)

Стартуем прямой эфир про AI в архитектуре с Сергеем Барановым через 5 минут. Сергей - практикующий архитектор, партнер Скрамтрека и основатель конференции ArchDays, в программный комитет которой я вхожу с первой конференции и до текущего момента. В общем, с Сергеем мы давно знакомы и обычно наши дискуссии выходят занимательными:)
Приходите и задавайте вопросы по ходу прямого эфира - мы с радостью на них ответим

#Architecture #AI #AI4SDLC #Engineering #Research #Software

Летняя распродажа в издательстве Питер (#Books)

По традиции рассказываю про распродажи в этом издательстве. В этот раз можно заказывать не только на сайте самого издательства, но и 🛍 Вб и 🛍 Озон. Оказывается, что эти две площадки добавились в честь 35-летия издательства.

P.S.
В ближайшее время подпишу с Питером договор и где-то к Новому Году моя книга тоже появится на полках, но про книгу я подробнее расскажу завтра.

Research Insights Made Simple #26: как строить работающие evals для AI-агентов (Рубрика #Agents)

Как понять, что AI-агент действительно готов к production? Красивый ответ и даже высокий "pass rate" показывают только финал одного запуска. Агент мог подсмотреть решение, выбрать опасный путь, нарушить права или рассыпаться при повторном прогоне.

В пятницу, 31 июля, в 16:00 МСК пройдет прямой эфир "Research Insights Made Simple" вместе с Евгением Сергеевым - Engineering Director в Flow Health с двадцатилетним опытом разработки и управления инженерными командами. Будем разбирать, как превратить evals из разовой проверки ответа в воспроизводимую инженерную систему.

Минимальная единица такой системы - воспроизводимый эпизод (replayable episode): замороженное исходное состояние, входные данные, контракт агента, скрытая проверка, трасса действий и критерий выпуска. Для кода это может быть commit до PR и hidden tests; для архитектуры - требования, ограничения и проверка исполнимости решения; для data platform - snapshot данных, lineage и инварианты.

Обсудим:

- Почему оценивать нужно всю агентную систему, а не только модель;
- Как заморозить исходное состояние и не дать агенту подсмотреть будущее решение;
- Что фиксировать в контракте: инструменты, права, сеть, время и бюджет;
- Зачем проверять не только результат, но и траекторию действий;
- Почему одного успешного запуска недостаточно и нужны повторные прогоны;
- Как собрать production scorecard из результата, траектории, стоимости, безопасности и принятия человеком;
- Как связать offline-evals с реальными production outcomes и превратить их в release gates.

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

#AI4SDLC #AI #Agents #Evals #Engineering #Metrics #Research