Приходите послушать про джунов на эфир и задавайте свои вопросы.

NVLink Fusion: свой XPU, стойка NVIDIA и причем здесь Mediatek (Рубрика #AI)

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

Ответ NVIDIA на этот тренд выглядит довольно красиво: хорошо, делайте свой XPU — а стойку вокруг него мы поможем собрать на нашей архитектуре.

31 августа 2026 года NVIDIA и MediaTek объявили о расширении партнёрства. NVIDIA приобрела конвертируемые облигации MediaTek на $3,5 млрд — долговые бумаги, которые при предусмотренных условиях можно обменять на акции. Но технически интереснее другая часть анонса: MediaTek будет помогать заказчикам проектировать и интегрировать заказные AI-ускорители, а NVLink Fusion даст этим чипам путь в стоечную инфраструктуру NVIDIA.

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

Один из показанных NVIDIA вариантов подключения выглядит так: заказной XPU → UCIe → чиплет-мост NVIDIA → NVLink → NVSwitch → AI-стойка
UCIe — открытый интерфейс между чиплетами внутри многокристальной системы. Через него XPU подключается к мосту NVIDIA, а тот выводит ускоритель в NVLink. NVSwitch объединяет множество ускорителей в одну высокоскоростную сеть. Рядом NVIDIA предлагает блоки для связи с CPU/GPU, памяти и общего стоечного формата — NVLink-C2C, NVHBM и MGX. Такая архитектура позволяет совместно использовать сеть, питание, охлаждение и управление; NVIDIA и MediaTek также обещают помогать с тестированием и отладкой готовой системы перед её серийным выпуском.

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

Я бы читал NVLink Fusion именно так: NVIDIA не спорит с появлением заказных чипов у Google, AWS и других крупных игроков, а старается стать опорным слоем для гетерогенных AI-вычислений. Вычислительный кристалл может быть не NVIDIA, но обмен данными между ускорителями и, при выборе MGX, значительная часть стоечного контура могут остаться в её экосистеме.

При этом NVLink Fusion не стоит путать с полностью открытым стандартом. Открытой является локальная граница UCIe, а NVLink, чиплет-мост и NVSwitch остаются проприетарными технологиями NVIDIA. То есть зависимость возникает на уровне внутристоечной сети и может распространиться на архитектуру стойки.

И это не история одного MediaTek. При запуске NVLink Fusion 18 мая 2025 года NVIDIA назвала среди партнёров также Marvell, Alchip, Astera Labs, Synopsys и Cadence. Позднее AWS сообщила, что Trainium4 проектируется с поддержкой NVLink Fusion.

По утверждению NVIDIA, такая архитектура должна сокращать путь от проекта чипа до работающей стойки. Проверить это пока нельзя: у совместного проекта NVIDIA и MediaTek нет названного заказчика, даты выхода чипа и независимых данных о производительности или стоимости владения. Поэтому главный тест ещё впереди: появится ли серийная система, в которой XPU действительно свой, а NVLink Fusion действительно ускоряет путь до эксплуатации. Если да, защитный ров NVIDIA будет проходить уже не вокруг GPU. Он будет проходить вокруг стойки. И это, кажется, интереснее очередного сравнения FLOPS.

#AI #Engineering #Architecture #Infrastructure #Hardware #Bigtech

Материалы Code of Leadership S2E15: последние 90 дней в компании (Рубрика #Management)

Готовы материалы сольного выпуска Code of Leadership S2E15, который вышел 31 августа. В общей нумерации подкаста это выпуск №73.

Он получился личным: после почти десяти лет в одной компании я разбираю обратную сторону первых 90 дней — как осознанно завершить прежний этап. Заявление здесь не начало процесса, а трудно обратимая точка; до неё стоит понять, что именно перестало работать, проверить варианты и выбрать один из трёх исходов: пересобрать текущую роль, перейти внутри компании или уйти.

Это практическая модель, а не исследование: 90 дней — горизонт проектирования перехода, а не универсальный срок уведомления.

В выпуске разобрал:

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

Все материалы выпуска:

- Страница выпуска: конспект, таймлайн и ссылки
- Интерактивная дека и полный лонгрид
- Видео: YouTube, VK Видео
- Аудио: Podster, Яндекс Музыка, Apple Podcasts

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

#Management #Leadership #Career #Strategy #Engineering #Podcast

Code of Leadership S2E18: Продуктовый инженер — как изменится роль программистов в ближайшие 3 года

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

В новом выпуске Code of Leadership во вторник, 8 сентября, в 19:00 попробуем разобраться в этом вместе с Глебом Михеевым — CPO ГигаАгента в Сбере. Глеб в коммерческой разработке с 2003 года: работал в NVIDIA и Skillbox, основал и девять лет развивал студию заказной разработки, восемь лет отвечал за программу FrontendConf, а сейчас руководит программными комитетами AgenticDevConf и AI Native Conf.

Ещё Глеб ведёт отличный Telegram-канал «Уставший техдир», где пишет про агентную разработку, инженерную культуру, управление командами и продукт.

Поговорим о том:

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

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

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

#CodeOfLeadership #AI4SDLC #Engineering #Leadership #Product #Career

Stanford MS&E435: Али Годси говорит, что AGI уже здесь, а компания — ещё нет (Рубрика #AI)

Редкий случай, когда одна 39-минутная запись собирает в одну картину темы, о которых я писал по отдельности: корпоративную память, AI-native организацию, судьбу SaaS и перенос ценности вверх по стеку. Это встреча Stanford MS&E435: преподаватель Apoorv Agrawal разговаривает с Али Годси, сооснователем и CEO Databricks.

Годси начинает с провокации: «AGI уже здесь». Это его рабочая рамка, не консенсус. Полезнее следующий тезис: модели уже достаточно умны для многих корпоративных задач, но не знают контекста компании. Отсюда ссылка на "GenAI Divide": предварительный отчёт утверждал, что лишь около 5% специализированных enterprise GenAI-инициатив дошли до устойчивого измеримого эффекта. Авторы предупреждали, что оценки показывают скорее направление, а Годси оговаривается, что точная доля может быть другой.

Почти в каждой организации, говорит он, есть свой John или Jane: человек, который помнит, почему процесс устроен именно так, где лежат исключения и к кому идти за решением. Модель этого не знает и потому делает глупые ошибки. Это почти тот же «мозг компании», о котором я писал после доклада Гарри Тана: преимущество создаёт не только модель, но и способность дать ей правильную память.

Самый сильный фрагмент начинается на двадцатой минуте. По рассказу Годси, production-коннектор Databricks к Salesforce или Workday занимал девять месяцев. По оценке команды, использование AI сокращало цикл лишь до семи с половиной. Тогда процесс перепроектировали: квартал сбора требований превратили в неделю с быстрыми итерациями, тестовые окружения отдали внешним исполнителям и запускали параллельно, а семь инженеров стали вместе вести семь коннекторов вместо модели «один человек — один проект». Результат, по словам Годси, — семь коннекторов за квартал.

Ни GPT-7, ни следующая Claude не сняли бы эти блокировки: это был рефакторинг организации. Та же мысль соединяет мой текст про AI-native организацию и разбор "перестройки McKinsey": LLM поверх старого процесса даёт локальное ускорение, но не новый throughput. Аналогия с электрификацией похожа: фабрика стала продуктивнее не после установки одного электромотора, а после новой планировки вокруг независимых приводов.

Вторая линия — «software умер». Годси с этим спорит, но считает, что AI снижает барьер входа и switching costs. Если пользователь разговаривает с агентом, ему уже не так важно, какой GUI тот нажимает — Salesforce или продукт конкурента. Это очень близко к моему тезису, что "умирает монополия GUI, а не software".

При этом дешёвый код не отменяет данные, масштаб, бренд, доверие, сертификацию и process power. Годси прямо рекомендует Hamilton Helmer и его Seven Powers. А дальше прогнозирует, что модельный слой превратится в низкомаржинальные «фабрики токенов», а большая ценность уйдёт в приложения. Мы уже видели ту же логику в разговоре про коммодитизацию моделей. Правда, это прогноз заинтересованного инфраструктурного вендора, но направление выглядит правдоподобно.

И всё же «скачать мозг компании в silicon» — только половина задачи. Если контекст получит агент, а люди перестанут понимать систему, мы просто ускорим накопление когнитивного долга. Исполнение можно делегировать; ответственность за устройство процесса и способность его перепроектировать остаются у команды.

Если времени мало, то посмотрите отрывки "20:23–24:43" — кейс с коннекторами и "26:04–28:44" — история о том, как дефицит bandwidth сделал multicast модной научной задачей, а дешёвое оптоволокно обесценило её и открыло дорогу странным тогда приложениям вроде Amazon, Uber и Airbnb. Хорошее напоминание: главный продукт следующего цикла редко похож на модный инфраструктурный вопрос текущего.

#AI #Agents #Engineering #Software #Management #Strategy

Первые 90 дней CTO начинаются до первого рабочего дня - Менеджмент 360 (Рубрика #Management)

Сегодня я выступлю в 19:35 на «Менеджменте 360» от Стратоплана - буду рассказывать про первые 90 дней технического директора. Начну с небольшого переворота: первый рабочий день — уже середина перехода. В докладе разберу весь маршрут:

- Как выбирать задачу, а не красивый шилдик;
- Зачем до выхода договориться о полномочиях, ресурсах и критериях успеха;
- Почему первый месяц лучше потратить на сбор реальной карты компании, а не на формирование портфеля изменений;
- Как к 90-му дню выбрать одну-две системные ставки, показать первый результат и не пропустить красные флаги.

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

Регистрация бесплатная при подписке на Telegram-каналы спикеров. Есть и платный вариант без подписок — с именным сертификатом и курсами «Менеджмент 101» и «Директор 101». 👉 Регистрация

#Management #Leadership #CTO #Conference

Только что рассказал про первые 90 дней CTO на мероприятии Стратоплана
Вот слайд-дека - https://polomodov.tech/2026-09-03-first-90-days-cto/
Вот лонгрид - https://polomodov.tech/2026-07-31-first-90-days-cto/

Если мы набьем 50👌, то я сделаю режиссерскую версию этого доклада в виде прямого эфира.

Stanford MS&E435: Sachin Katti о том, когда человек становится bottleneck AI-системы (Рубрика #AI)

В этой лекции есть тезис, который для инфраструктуры звучит как победа, а для человеческой работы — почти как предупреждение. Sachin Katti говорит: OpenAI добьётся успеха в compute, когда bottleneck станет человек. Агент будет заканчивать шаги так быстро, что мы перестанем ждать и останемся в flow.

На встрече курса Stanford MS&E435 «Economics of the AI Supercycle» Apoorv Agrawal беседует с Sachin Katti. На момент записи Katti руководил Industrial Compute в OpenAI — compute для training и inference. Сейчас он VP, Compute Strategy & GPT-Infra в OpenAI; ранее был CTO Intel и преподавал в Stanford. Это не нейтральный обзор рынка, а взгляд оператора frontier-лаборатории.

Сильная часть лекции — агент как новый тип workload.
У чат-бота был короткий путь: пользователь → один inference call → ответ
Агент замыкает цикл: inference → поиск или база → tool call → VM или приложение → наблюдение и оценка результата → новый inference

Katti описывает execution как DAG; управляющая логика может оставаться циклической. Узлам нужны разные ресурсы:
» Ускорители для model inference
» CPU-backed runtimes и VM для инструментов и тестов
» Системы с большой памятью для длинного контекста
» Сеть и orchestration для сборки маршрута
Поэтому model + runtime + accelerators + network + data center + power приходится оптимизировать как одну систему.

Это продолжает два сюжета канала: hardware-software co-design у Dylan Patel и дерево агентных вызовов, превращающее бизнес-процессы в спрос на GPU. Новое — операторский взгляд OpenAI: куда поместить каждый узел и как latency всего графа влияет на human flow. Из этого я бы мерил не только tokens/s, а time to first useful action, время до проверенного артефакта и стоимость задачи. У Katti три рычага: более дешёвый токен, более умный токен и меньше токенов на результат.

Есть и большие числа. По прогнозу Katti, более 80% compute будет уходить на inference — включая synthetic data и часть post-training. Цель OpenAI в 30 ГВт он называет aspirational, а 1 ГВт грубо приравнивает к 500 тысячам GPU. Это оценки спикера. И утроение compute вместе с выручкой за три года показывает корреляцию, но не доказывает причинность.

Здесь появляется напряжение. Для Katti человек как bottleneck — признак успеха compute-инфраструктуры: сегодня агент выполняет задачу с инструментами минуты или часы, человек переключается, а затем заново загружает контекст. Быстрый AI должен вернуть интерактивность.

В канале мы уже смотрели на ту же картину с другой стороны. В Your Attention Is the Bottleneck человек превращается в диспетчера множества циклов: ставит задачи, снимает блокировки, проверяет и выгорает от переключений. А в посте про понимание как новое узкое место изменения производятся быстрее, чем команда успевает обновлять модель системы в голове. Возникает когнитивный долг: код работает, но отвечать за его развитие уже некому.

Ускорение агента не устраняет эту проблему и может повысить частоту решений, прилетающих человеку. Если разогнать конвейер, не усилив контроль качества, могут расти незавершённая работа, пропущенные дефекты и переделки. У человеческого bottleneck как минимум четыре ограничения: внимание, понимание, проверка и ответственность. Ни одно из них не масштабируется вместе с tokens per second.

Поэтому agentic UX стоит проектировать не только вокруг быстрого ответа. Агенту нужно собирать вопросы пакетно, возвращать компактный контекст, показывать evidence, тесты и неопределённость, а человека подключать там, где высока цена ошибки. И мерить время до понятого и проверенного результата вместе с числом steering points, переключений и переделок.

Я бы смотрел отрезок 18:05–24:40 про agentic graph и human flow, а затем 29:05–33:05 про latency. После него остаётся хороший вопрос: сколько параллельных агентных циклов человек способен не просто направить, а понять и ответственно закрыть?

#AI #Agents #Engineering #Architecture #Infrastructure #AI4SDLC

NVIDIA договорилась купить Hugging Face: проверка на нейтральность (Рубрика #AI)

После разбора стратегии NVIDIA эта сделка выглядит почти неизбежным следующим ходом. Только цена в $12,93 млрд немного отвлекает: NVIDIA договорилась купить не очередную модельную лабораторию и не новый тип ускорителя. В случае закрытия сделки она получит место, где разработчики находят, сравнивают, скачивают и запускают открытые модели — одну из главных точек выбора во всём AI-стеке.

Сначала аккуратно со статусом. 2 сентября 2026 года NVIDIA подписала definitive agreement, 3 сентября опубликовала анонс и форму 8-K. По документу для SEC, примерно $11,9 млрд предназначены акционерам Hugging Face, ещё до $1 млрд — retention-программа в акциях для сотрудников, которые перейдут в NVIDIA. Закрытие ожидается в первой половине 2027 года и зависит в том числе от регуляторных согласований. То есть сделка предложена, но пока не закрыта.

Почему Hugging Face стоит рассматривать не как «GitHub с весами»?
По данным самой NVIDIA, на платформе больше 18 млн разработчиков и исследователей, 3 млн моделей, 500 тысяч датасетов и 1 млн приложений. Но важнее сам механизм. Inference Providers даёт один API к Baseten, Cerebras, Groq, Nscale, Together и другим поставщикам, а без явного выбора автоматически направляет запрос к самому быстрому доступному provider. Dedicated endpoints можно разворачивать в AWS, Azure и Google Cloud. Получается уже не просто хранилище артефактов, а слой discovery, distribution и routing: что разработчик увидит, какую модель попробует и где её запустит.

Для NVIDIA логика понятна. Компания уже контролирует популярный compute/runtime-слой через GPU и CUDA и, по собственным данным, выложила на Hugging Face больше 500 моделей и 250 датасетов. Теперь к железу и software stack добавляется канал дистрибуции. Открытые модели удешевляют и ускоряют создание AI-продуктов, а каждый такой продукт всё равно создаёт спрос на inference. Плюс платформа даёт раннюю агрегированную картину того, какие модели, архитектуры и способы запуска набирают популярность. Последний пункт — интерпретация аналитиков, а не раскрытая цель сделки.

NVIDIA обещает сохранить Hugging Face открытой: её железо не будет обязательным, разработчики смогут выбирать модели, frameworks, clouds, inference providers и compute platforms. В 8-K обещание сформулировано чуть уже, но всё равно предметно: сохранить возможность загружать и скачивать выбранные модели и датасеты и продолжать поддержку других производителей чипов.

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

1️⃣ Кто и по каким правилам управляет ранжированием и рекомендациями моделей;
2️⃣ Как выбираются дефолты в маршрутизации инференса и какие провайдеры получают приоритет;
3️⃣ Будет ли одинаковой скорость интеграции и оптимизации для CUDA, ROCm, Trainium, TPU и CPU;
4️⃣ Где пройдёт граница использования телеметрии и данных о поведении разработчиков.

Сейчас нет доказательств, что NVIDIA собирается подкручивать эти механизмы в свою пользу. Но именно здесь и будет проходить настоящая проверка, а не в возможности скачать файл с весами. Поэтому обещание «Hugging Face останется открытой» — не сноска к пресс-релизу, а главный критерий приемки сделки. Если после закрытия конкурирующее железо и независимые провайдеры инференса будут появляться в роутинге, документации и оптимизациях на равных, а правила ранжирования и использования данных станут прозрачнее, ресурсы NVIDIA действительно могут усилить экосистему. Если нет, веса останутся открытыми, но площадка, на которой все их выбирают, перестанет быть нейтральной.

#AI #PlatformEngineering #OpenSource #Architecture #Infrastructure #Bigtech

Подтягивайтесь на очередной эфир 3 AImigo, где мы поговорим про изменения найма под влиянием AI.

An Illustrated Guide to AI Agents: полное издание (Рубрика #Agents)

В марте я уже рассказывал про "An Illustrated Guide to AI Agents". Тогда это был Early Release: готовы были шесть глав, а я обещал следить за продолжением. Теперь издательство O'Reilly выпустило полное издание — 450 страниц и 10 глав. Вернуться к книге стоит не только из-за новых страниц: она перестала выглядеть как сильная половина будущего учебника и наконец собралась в цельный маршрут — от устройства LLM до проверки и эксплуатации агентной системы.

Если сравнить финальное оглавление с тем, что было готово весной, доехали четыре большие главы.

1️⃣ Large Language Models делает книгу самодостаточной. Здесь есть tokens, system prompt, tool calls, pre-training и post-training, Transformer, context length, KV cache и Mixture of Experts — причем всё это привязано к поведению, задержке и стоимости агента. Становится понятнее, как сама модель, длина контекста и KV cache влияют на всю систему.
2️⃣ Evaluating Agents — пожалуй, самая важная новая глава. Авторы разбирают public benchmarks, outcome и trajectory evaluation, LLM-as-a-judge, rubrics, reliability, safety и собственные evals. Особенно полезна пара метрик: pass@k отвечает на вопрос «получилось ли у агента хотя бы раз за k попыток», а pass^k — «успешны ли все k попыток». Для эффектного демо часто хватает первого, для рабочего процесса гораздо важнее второе.
3️⃣ Multi-Modal Understanding объясняет, как агент начинает видеть изображения, слышать аудио и разбирать видео: encoder переводит вход в embeddings, connector приводит их к формату LLM, дальше модель использует их как контекст. Заодно хорошо показаны компромиссы: простой projection дешевле, query-подход лучше сжимает длинный вход, fusion обычно выразительнее, но сложнее и дороже.
4️⃣ Code Agents and Code LLMs доводит тему от генерации функции до работы внутри репозитория. Здесь есть инструменты для файлов и терминала, SQL, песочницы для исполнения кода, карты репозитория, кэширование и сжатие контекста, планирование, тесты и ручное подтверждение. Важная мысль: иногда фиксированный workflow надежнее полноценного агента, а доступ к shell — это не удобная галочка, а граница безопасности, от которой зависит масштаб возможного ущерба.

Кстати, финальная версия уже знакомой главы про Multi-Agent Systems включает orchestration patterns, communication protocols, deep research agents и сценарии вроде AI co-scientist. Но цельность книги создаёт сквозная конструкция. В первой части авторы последовательно собирают одного TinyAgent: LLM → reasoning → memory → tools → planning → evals. Во второй показывают, как та же архитектура специализируется в multi-agent, multi-modal и coding systems. Получился уже не каталог модных фреймворков, а понятный инженерный цикл.

Для инженера это закрывает несколько конкретных сценариев:
- спроектировать внутреннего исследовательского агента или агента поддержки и понять, где хранить контекст и какие инструменты ему дать;
- проверять изменения промпта, модели и памяти через регрессионные evals не только по ответу, но и по траектории;
- собрать code agent с поиском по репозиторию, тестами и песочницей;
- добавить изображения, звонки или видео туда, где текстовый агент просто не видит часть задачи.

Для техлида или руководителя сценарии другие:
- решить, где нужен агент, а где достаточно детерминированного workflow;
- выбрать single-agent или multi-agent архитектуру и посчитать цену координации;
- сравнить поставщиков на собственных задачах как связку «model + harness», учитывая надёжность, задержку и стоимость;
- задать границы автономности — права, необратимые действия, сценарии безопасности и места, где обязательно ручное подтверждение.

Если первые главы уже читали весной, начинать заново необязательно: главу 2 можно пробежать для связки с экономикой агента, главу 7 я бы точно не пропускал, а дальше — главы про мультимодальность и кодинговые агенты. Именно эта связка превращает ранний набор хороших объяснений в законченную инженерную книгу.

#Agents #Books #AI #Engineering #Architecture #Management #Software

Code of Leadership S2E17: Как действовать среднему бизнесу с AI, которому «по-науке» дорого? (Рубрика #AI)

У среднего бизнеса с AI есть неприятная развилка. Лаборатория, платформа и команда редких специалистов — тяжёлый входной билет. Но личные подписки, разрозненные демо и один «AI-волшебник», работающий по вечерам, ещё не складываются в практику.

Сегодня в 17:00 проведем прямой эфир и обсудим это вместе с Александром Воронцовым, партнером @revelio_tech и автором канала AI Subjects (@aisubjects, изучает когнитивные ошибки при работе с ИИ). В прошлом разговоре мы дошли до важной точки: внешний эксперт уйдёт, а внутри должен остаться человек, который понимает задачу, проверяет результат и продолжает изменение. Теперь разбираемся, как получить и удержать эту способность, если сильные люди заняты основной работой, а нанимать AI-департамент рано.

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

#CodeOfLeadership #AI #Consulting #Leadership #Management #DigitalTransformation

И я тоже в числе счастливчиков, кто сможет поэкспериментировать сегодня ночью с Astra от OpenAI:)

Новый подкаст «Где профит от данных, Лебовски?» о данных и их ценности для бизнеса (Рубрика #Data)

Мы запускаем новый подкаст с таким составом авторов
- Андрей Цыбин - взгляд со стороны продуктовой аналитики и онлайн-экспериментов
- Николай Голов - взгляд со стороны дата-архитектуры и продуктовой разработки платформы данных
- Александр Поломодов - взгляд со стороны software архитектуры, AI4SDLC и инженерного лидерства

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

Монетизация данных — это не только «продать массив». У компании есть как минимум три пути:
- продать или лицензировать данные;
- применить их внутри и улучшить решения;
- встроить данные в продукт, за результат которого платит клиент.

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

И для каждого кейса зададим один неприятный, но полезный вопрос:
- Кто платит, за какое изменение и где это видно в P&L?
- Без культа дашбордов и аналитики ради аналитики.

🗓 Премьера в прямом эфире 7 сентября в 12:00 МСК.

#Data #Database #Analytics #Money #Metrics #Business

Microsoft: почему быстрый AI-код не ускорил команду (Рубрика #AI4SDLC)

К моим рассказам про spec-driven development и AI-DLC у AWS появилось хорошее продолжение. Microsoft Digital, внутренняя IT-организация компании, 3 сентября 2026 года поделилась опытом внедрения SDD. И начала с довольно неудобного признания.

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

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

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

Меняются и роли. PM отвечает за спецификацию на протяжении разработки, инженеры больше времени тратят на требования, планы и проверку сгенерированного результата. Знакомая тема: AI заставляет раньше делать ту работу, которую раньше можно было отложить до первого «мы вообще-то другое имели в виду».

Впрочем, здесь нет замеров до и после или контрольной группы. Это рассказ Microsoft Digital о своём опыте; доказательства, что SDD ускоряет любую команду, из него не получается.

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

#AI4SDLC #AI #Engineering #Management #DevTools

AI4SDLC: Что бы я делал по-другому, если бы знал, что знаю сейчас (Рубрика #AI4SDLC)

Поучаствовал на Deep Tech Night Яндекса с двумя активностями
- Выступил с lighting talk "AI4SDLC: Что бы я делал по-другому, если бы знал, что знаю сейчас" - вот презентация
- Поучаствовал в дискуссии "Когда код стал дешёвым: где теперь ценность, ответственность и экспертиза?" - в рамках подготовки написал лонгрид свою позицию с отсылками на свои же публичные материалы

Lighting talk был на 15 минут, поэтому я рассказал презентацию очень кратко. По традиции, если есть желание послушать режиссерскую версию, то ставим 🔥 под постом и если мы наберем 100 реакций, то я устрою прямой эфир с режиссерской версией и ответами на вопросы.

P.S.
Пост про "Первые 90 дней CTO" набрал нужные количество 👌, поэтому на неделе я проведу прямой эфир с этим выступлением - https://t.me/book_cube/4919

#Agents #Books #AI #Engineering #Architecture #Management #Software

Stanford MS&E435: кто выбирает технологический стек — разработчик или кодинговый агент? (Рубрика #AI)

«Я вообще не знаю, что такое Vercel. Мой агент привёл меня сюда». Так, по словам Guillermo Rauch, написал ему в личку в X один из новых клиентов, столкнувшийся с ошибкой. В одной фразе — новая экономика дистрибуции софта: человек не сравнивал облака и, возможно, вообще не знал названия платформы. Платформу для развёртывания выбрал его любимый кодинговый агент:)

Это очередной разбор лекции из курса Stanford MS&E435, где мы начинали с карты экономики AI-суперцикла, а теперь дошли приложений и вопроса, а кто забирает ценность, когда софта становится больше. Guillermo Rauch, основатель и CEO Vercel, предлагает такой ответ: код дешевеет, но результат всё ещё нужно развернуть, запустить и обслуживать. Экономическая ставка Vercel — занять слой между намерением и работающим продуктом: дать агенту API для развёртывания, preview URL, изолированную среду, шлюз к моделям и долгоживущие процессы, а в перспективе — облако, которое само диагностирует эксплуатационные проблемы. Это одновременно содержательная лекция и аккуратно собранный питч от вендора.

Но интереснее то, что происходит до развертывания. По словам Rauch, агент приходит с уже сложившейся «картиной мира»: модели успели узнать Next.js, React и open-source инструменты Vercel из материалов в интернете. Такой агент не проводит нейтральный анализ. Я бы сформулировал экономическое следствие так: open source здесь становится дистрибуцией, а runtime — монетизацией.

В выступлении это подкрепляется цифрами из исследования Amplifying: Claude Code выбрал shadcn/ui в 64 из 71 ответов с извлечённым основным выбором (90,1%), а Vercel — во всех извлечённых deployment-ответах для Next.js и React SPA. Здесь важна сноска. Это 2 430 успешных ответов Claude Code с тремя моделями Claude на четырёх greenfield-репозиториях; Vercel получил 86 из 112 deployment picks в целом, то есть 76,8%. Это не доля рынка и не доказательство того, что выбранный продукт качественнее альтернатив.

Именно поэтому формула «агент выбрал» не равна формуле «рынок порешал». Выбор складывается из обучающих данных модели, системной инструкции, текущего стека, качества документации, видимости проекта в open source и того, может ли агент понять и применить компонент локально. В разборе Developer Experience для кодинговых агентов мы уже говорили про стандартный стек, CLI/API, быстрые тесты и понятные ошибки. Теперь видно экономическое продолжение: агентная эргономика становится не просто хорошим DevEx, а каналом продаж.

Есть и второй слой. Rauch считает, что интерфейс и локальный сценарий работы всё чаще будут генерироваться под задачу, а система учёта (system of record), данные, права доступа и API останутся. Я бы описал это как два периода полураспада софта: одноразовая оболочка и долговечное ядро. В самой лекции есть оговорка к тезису «software is basically free»: над сложным инфраструктурным кодом в Vercel, по словам Rauch, иногда собирают три агента и сильных инженеров, чтобы понять одну строку.

То есть дешевеет реализация, но не обязательно архитектура, проверка, безопасность и владение системой. В The New SDLC harness — это обвязка вокруг модели, делающая генерацию управляемой. Здесь появляется следующий экономический слой: агент и его harness становятся точкой выбора компонентов.

Для поставщика инструмента отсюда новый вопрос: сможет ли агент сам найти продукт, понять документацию, установить его, восстановиться после ошибки и объяснить свой выбор? Для покупателя — другой: почему агент принёс именно эту зависимость и какие варианты он даже не рассматривал? Раньше DevRel конкурировал за внимание разработчика. Теперь ему приходится бороться ещё и за место в картине мира модели — а этот gatekeeper часто вообще не виден пользователю.

#AI #Agents #PlatformEngineering #DevTools #Product #Economics