Книжный куб

AI Dev Podcast #8: автономия агента начинается с ограничений (Рубрика #AI4SDLC) Вышел новый выпуск AI Dev Podcast. Вместе с Владимиром Ятульчиком и Андреем Дмитриевым разбирались, как перейти от вайб-кодинга к управляемой агентной разработке. Главная мысль крутилось вокруг того, что автономный агент полезен не тогда, когда ему разрешили написать побольше кода, а когда он встроен в воспроизводимый процесс. Чем больше мы делегируем, тем яснее должны быть замысел, критерии приёмки, ограничения и границы прав. Владимир рассказал, как его команда адаптировала AIDLC под свою инфраструктуру. Важны четыре вещи: - Истории, ADR и документация живут в Git рядом с кодом; - Трассируемость связывает замысел, решения, реализацию и метрики; - Агенты требований и архитектуры отделены от агентов кода; - Проверки ADR и безопасности удерживают изменения в границах замысла. На небольших проектах у команды уже есть рабочие примеры, но перенос на крупную унаследованную систему ещё предстоит проверить. Там нужны управляемый контекст и процесс, который не рассыпается при масштабировании. Практический вывод: агентная разработка начинается не с выбора модели. Возьмите ограниченный репозиторий, опишите ожидаемый результат, дайте агенту минимальные права и поставьте проверки между этапами. Измеряйте не объём сгенерированного кода, а принятую работу, стоимость проверки и связь изменений с результатом в эксплуатации. Парадокс автономии в том, что она требует не меньше инженерной дисциплины, а больше. Агент может получить свободу лишь там, где система умеет удерживать его в границах замысла. Короткий конспект здесь. #AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering

Code of Leadership S2E10: PRD == evals: как AI стирает границу между продактом и ML Engineer (Рубрика #AI) В эту среду в 17:00 в прямом эфире обсудим с Альбиной Мунировой из Т-Банка последние изменения в профессии продакт менеджеров, когда граница между ним и ML-инженером становится заметно тоньше. Прототип теперь можно собрать за несколько дней, но главный вопрос начинается после демо: кто превратит продуктовое намерение в воспроизводимые проверки и возьмёт ответственность за поведение вероятностной системы? Альбина Мунирова - лидом продуктов в AI-центре Т-Банка, бывший ML-инженер и тимлид, лидером и создателем профессии ML-продакт-менеджера в банке. Центральная формула разговора - PRD == evals. Разберём, что она означает в реальной работе и почему это не просто замена одного документа таблицей тестовых вопросов. У Альбины есть свой Youtube канал. Поговорим о том: - Кто такой AI Product Builder и действительно ли это новая профессия; - Что продакт теперь должен уметь делать руками, а где специализация MLE остаётся критичной; - Как перевести требования к ассистенту в eval-набор, порог выпуска и продуктовые метрики; - Почему быстрый MVP ещё ничего не говорит о стоимости проверки и промышленной эксплуатации; - Как, по словам Альбины, её команда в 2023 году строила инвест-ассистента на RAG, когда готовая обвязка только формировалась; - Почему ассистент «по всему банку» - это не один большой промпт, а маршрутизация, данные, права, инструменты, память, безопасность и разные владельцы качества; - Что опыт ассистента Олега может дать современным LLM-продуктам. Для меня главный вопрос эфира такой: AI Product Builder - это новая клетка в оргсхеме или новый минимальный уровень владения результатом от проблемы до доказательства качества? Приходите с вопросами. Особенно интересны примеры, где продакт уже сам собирает прототипы и evals, а MLE всё чаще участвует в выборе пользовательского сценария и продуктовых компромиссов. #AI #Product #MachineLearning #Evals #Engineering #Agents

Starcloud: как принять решение строить дата-центры в космосе (Рубрика #Engineering) Посмотрел опубликованный 5 августа 2026 года выпуск Y Combinator с Филипом Джонстоном, сооснователем и CEO Starcloud. Формально разговор про дата-центры в космосе, но для меня самая интересная часть - не орбита и даже не H100 на спутнике, а то, как команда приняла решение заняться идеей, которая в 2023 году звучала почти как научная фантастика. Starcloud исходит из простой гипотезы: главным ограничением для новых AI-вычислений становится не выпуск чипов, а доступная энергия. На Земле энергопроекты упираются в сети, разрешения и сроки строительства; на подходящей орбите солнечная генерация может работать почти непрерывно. Но пока это именно ставка на будущую экономику запусков, а не доказанная замена наземным дата-центрам. Как Филип принял решение запустить космическую компанию В начале 2023 года он на выходные поехал в техасский Starbase ещё до первого запуска Starship. Масштаб производства подсказал ему мысленный эксперимент: что станет экономически осмысленным, если стоимость вывода груза снизится в десять раз, а доступная пусковая мощность вырастет на порядки? Дальше особенно интересна последовательность действий. Филип не пришёл к инженерам с готовым продуктом. Он сначала написал знакомым специалистам по спутникам с вопросом: какие бизнесы появятся при настолько дешёвом запуске? Из примерно десяти разговоров выросла команда сооснователей. Уже вместе они перебрали производство на орбите, добычу астероидов, космические отели и солнечные электростанции. Первые два месяца будущая Starcloud, тогда ещё Lumen Orbit, собиралась передавать солнечную энергию на Землю. По расчётам команды, при такой передаче терялось около 95% энергии, а запуск должен был подешеветь примерно до $50 за килограмм. Тогда они перевернули задачу: не передавать энергию к потребителю, а поднять потребителя к источнику. Для дата-центра расчётный порог оказался ближе к $500 за килограмм. После этого компания сменила направление. А затем команда создала себе физический аналог жёсткого релизного дедлайна. По рассказу Филипа, компанию основали 1 января 2024 года, а 2 января забронировали ближайший rideshare-запуск SpaceX примерно за $300 тысяч - ещё не зная, что именно полетит. Место на ракете стало forcing function: через 18 месяцев на ней в любом случае должен был оказаться работающий аппарат. Для меня это хороший пример решения под высокой неопределённостью. Не «поверили в мечту и прыгнули», а зафиксировали внешний технологический сдвиг, нашли людей с нужной экспертизой, сравнили несколько экономических моделей и купили необратимый дедлайн. Что ещё зацепило в выпуске 🚀 Starcloud-1 был не полноценным дата-центром, а демонстрацией с пятью GPU, включая NVIDIA H100 Перед отправкой инженеры в пять утра охлаждали систему в ванне со льдом, затем грели промышленными фенами: так в спешке проверяли материал, который должен был отводить тепло при фазовом переходе. 🔸 После запуска спутник перезагружался каждые два часа Возможных программных триггеров было около двадцати, а новый сеанс связи приходилось ждать примерно полтора часа. Команда по одному отключала условия отказа и за три дня нашла причину. Очень наглядное напоминание, как выглядит debugging, когда к устройству нельзя подойти с ноутбуком. ☢️ Две главные инженерные задачи - тепло и радиация В вакууме нет конвекции, поэтому тепло приходится переносить жидкостным контуром к большим радиаторам и излучать. Обычные H100, H200 и B200 команда испытывала на протонах и тяжёлых ионах в ускорителях, а затем подбирала защиту, программную устойчивость и даже серийные автомобильные компоненты вместо дорогой space-grade электроники. 🌟 Масштабирование разбито на ступени Starcloud-1 проверяет, что мощный GPU вообще работает на орбите. Десятикиловаттный Starcloud-2 должен продавать обработку данных другим спутникам: принять большой объём снимков или SAR-данных, обработать рядом с источником и вернуть на Землю уже координаты или другой компактный результат. А 200-киловаттный Starcloud-3 - пока план для конкуренции с наземной инфраструктурой при достаточно дешёвых запусках. 🚫 По словам Филипа, около ста венчурных фондов отказали компании на первом раунде, а после YC последовало ещё примерно двадцать отказов Позже Starcloud привлекла $170 млн при оценке $1,1 млрд, но Филип всё равно называет главным активом не капитал, а команду: после крупного раунда компания, по его словам, оставалась примерно с двадцатью инженерами и нанимала намеренно медленно. Самая здравая оговорка выпуска: вся большая экономика Starcloud зависит от - Cнижения стоимости запусков - Cпособности построить лёгкие радиаторы и устойчивую электронику - Способности спроектировать и реализовать надёжную распределённую систему В общем, один H100 на орбите - это конечно круто, но ещё не доказывает возможность построить космический датацентр на 20 гигаватт, куда целятся ребята. Но выпуск тут скорее целиком про deep tech, где полезно разделять дальнюю ставку и ближайшее проверяемое допущение. Видение может быть на десятилетие, но следующий шаг должен отвечать на очень конкретный вопрос - и иметь дату запуска 😜 #AI #Engineering #Architecture #Hardware #Infrastructure #SpaceTech #DeepTech

Материалы про AI-разработку как эволюционирующий стек готовы (Рубрика #AI4SDLC) Оформил все материалы по прямому эфиру, что был в пятницу, где я говорил про ко-дизайн железа, моделей, обвязки, инструментов, трейсов и так далее. Там я показывал как все это связано и что делают провайдеры, а что стоит делать на месте технических директоров обычных компаний - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка, полный лонгрид #AI #Management #Processes #Engineering #Software #Architecture #DistributedSystems

Waymo: семь уроков перехода от демо к физическому AI (Рубрика #Robotics) Посмотрел выступление Дмитрия Долгова на Y Combinator Startup School 2026, где разбиралась разница между эффектной демонстрацией AI и системой, которой можно доверять в физическом мире. Долгов - один из основателей Google Self-Driving Car Project, начавшегося в 2009 году и ставшего Waymo в 2016-м, а сейчас co-CEO компании. До Google он занимался автономным вождением в Toyota и работал в Stanford Racing Team над машиной Junior для DARPA Urban Challenge 2007. Он окончил МФТИ и получил PhD по компьютерным наукам в Мичиганском университете. Почти два десятилетия он прошёл с технологией путь от алгоритмов планирования до роботакси. Главная рамка доклада: для physical AI лозунг «move fast and break things» не годится - у ошибки нет кнопки undo, а цена измеряется не токенами. Ещё три отличия от digital AI: 1. Решения нужны за миллисекунды 2. Готового «интернета физического мира» с размеченными данными нет 3. Безопасность необходимо доказать до массового запуска Долгов называет следующие пункты семью уроками. По сути, они складываются в инженерную последовательность. 1️⃣ Демо - это максимум 1% работы В 2009–2010 годах команда примерно из двенадцати инженеров проехала 100 тысяч автономных миль и десять маршрутов по 100 миль без вмешательства человека. Демо заняло 18 месяцев, путь до 500 тысяч поездок в неделю — около 15 лет. Каждый следующий порядок надёжности потребовал новых архитектурных решений, резервирования и проверки длинного хвоста редких событий. 2️⃣ Выбирать нужно не самый быстрый старт, а технологическую кривую, которая дотянется до нужной надёжности Waymo объединяет камеры, LiDAR и radar: в докладе LiDAR раньше камеры замечает пешехода в пыльной буре и детей в темноте, а резервирование позволяет машине вернуться в депо, когда ветка закрывает часть сенсоров. И не стоит привязывать архитектуру к сегодняшней цене железа: Waymo уже на шестом поколении системы. 3️⃣ Нужно уметь оседлать не одну волну AI, а несколько подряд Waymo перестраивала Driver вокруг CNN (сврточных сетей), затем трансформеров, теперь VLM и world models. Сложность не в исследовательской демке, а в переносе технологии в прод, критичный к безопасности, без регрессий и с одновременным упрощением стека. По описанию компании, Waymo Foundation Model объединяет восприятие, понимание сцены, прогноз и планирование. 4️⃣ "Bitter Lesson" от Ричарда Саттона работает, но структура не обязательно ему противоречит Waymo использует structure-augmented end-to-end: learned representations дополняются явными объектами, семантическими признаками и дорожным графом. Структура не диктует машине ответ, зато помогает проверять безопасность в реальном времени и даёт сильные сигналы для reinforcement learning и evals. Чем-то это напоминает истории с детерминированными проверками типа Sonar и онтологиями 5️⃣ Симулятор для physical AI - не вспомогательный инструмент, а второй большой AI-продукт Открытый цикл (open-loop) тест спрашивает «что бы ты сделал?», закрытый цикл (closed-loop) показывает, как действие меняет мир. Waymo World Model моделирует и участников движения, и показания сенсоров. Так можно проверять синтетические редкости: остановившуюся на шоссе машину, самолёт на дороге, снег на Golden Gate Bridge или слона на перекрёстке. 6️⃣ Вокруг модели нужен маховик из трёх AI-систем: Driver действует, Simulator воспроизводит мир, Critic оценивает результат Реальные поездки делают симуляцию точнее, она генерирует трудные edge cases, критик выставляет оценку, Driver учится и возвращается на дорогу. Данные становятся преимуществом не как склад записей, а как замкнутый производственный контур. 7️⃣ Главный moat - не модель, а evals и метрики Если команда не может количественно определить good enough, она продолжает улучшать демо. Для робота проверки должны охватывать модель, сенсоры, вычислительную платформу, поведение, внешние сервисы и операции. В Waymo эту роль играет Safety and Readiness Framework. По статистике компании на 220 млн полностью автономных миль до конца марта 2026 года, Waymo Driver участвовал в авариях с тяжёлыми или смертельными травмами на 94% реже, чем ожидалось бы у людей-водителей в тех же районах. Это данные Waymo, но принцип важен: доверие строится на проверяемой эксплуатации, а не на архитектуре со слайда. Тезисы, что я забрал для себя из истории - Лучший момент physical AI часто выглядит так, будто ничего не произошло: система отработала опасную ситуацию, и пассажиры её не заметили. - Требуемое число «девяток» - продуктовый выбор: оно заранее определяет сенсоры, резервирование, симуляцию, бюджет и скорость выхода на рынок. - Спор «end-to-end или модульная система» слишком грубый. Практический ответ Waymo - обучаемая общая модель плюс ровно столько структуры, сколько нужно для масштабирования и проверки. - Safety и evals - часть продукта и накопительный актив. Модель можно повторить быстрее, чем пятнадцать лет данных, операций и доказательств надёжности. - Маховик без метрик может вращаться куда угодно. Данные дают преимущество, только когда критик отличает прогресс от красивого движения на месте. #Robotics #AI #Engineering #Architecture #Product #Bigtech

Днем ИТ Пикник, а вечером уже матч ЦСКА - Ростов. Очень насыщенный день и хочетсч спать, но раз обещал, пришлось идти и на футбол:)

Материалы по второй AMA сессии про AI-assisted Engineering с Алексеем Литвиновым про то, как внедрять AI в разработку (Рубрика #AI4SDLC) Готовы материалы с прямого эфира подкаста Code of Leadership с Алексеем (@tip_podcast): - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка #AI #Management #Processes #Engineering #Software #Architecture

AI4SDLC 2026: как AI меняет разработку ПО в России (Рубрика #AI4SDLC) Сегодня на «ИТ-Пикнике» я расскажу о нашем исследовании AI4SDLC 2026 и об общем состоянии AI в разработке софта. Мы уже прошли этап с ассистентами и теперь интересно взглянуть на то, как а помогает ли разработка с агентами не просто ускорять кодинг, но и преводить к более быстрой и устойчивой поставке продуктов. Или агенты просто переносят узкое место в постановку задач, review, тестирование, переделки и эксплуатацию? Для этого мы проводим исследование из двух основных частей 1️⃣ Обновляемое мета-исследование публикаций 2026 года. Мы собираем мировые опросы, телеметрию, продольные наблюдения, квазиэксперименты, бенчмарки агентов и индустриальные отчёты. И не складываем все цифры в одну корзину: самооценка, рабочие логи и контролируемый эксперимент дают разные доказательства. 2️⃣ Собственный русскоязычный опрос инженеров, участвующих в создании, поставке или эксплуатации ПО в командах России и СНГ. В основе лежит подход DORA с каузальным инференсом и стандартными конструктами, но мы пересобрали вопросы под тему агентной разработки, которая нас интересовала. Мы не смешиваем автодополнение, чат и фоновых агентов в один показатель «использует AI». Отдельно смотрим на задачи, частоту, глубину делегирования, автономность, права агента и параллельные потоки. Связываем это с надзором, стоимостью проверки, переделками, DevEx, обучением и пониманием кодовой базы. На уровне команды - со скоростью поставки, стабильностью, надёжностью и качеством продукта. Для руководителей есть ветка про цели организации, затраты и ROI. Почему мы верим, что это поможет увидеть состояние дел в России? Не потому, что добровольный опрос автоматически становится переписью индустрии. Мы прямо фиксируем это ограничение. Но такой дизайн позволяет собрать не истории «мы стали в десять раз быстрее», а карту практик и связей между ними. Участников набираем через несколько каналов; учитываем роль, опыт, страну работы команды, отрасль и размер организации. Сравниваем руководителей и специалистов, пользователей разных режимов AI и тех, кто почти им не пользуется. Гипотезы, правила очистки и план анализа фиксируются до просмотра результатов, а в отчёте будут видны размеры сегментов, пропуски и ограничения. Для меня важно избежать двух крайностей: не объявлять AI бесполезным по одному неудачному эксперименту и не принимать ощущение ускорения за эффективность всей инженерной системы. Если вы участвуете в разработке ПО - пройдите опрос. Нам нужны ответы не только AI-энтузиастов: опыт скептиков, редких пользователей и команд, которые ещё не перешли к агентной разработке, не менее важен. Буду благодарен, если вы отправите ссылку коллегам - инженерам, архитекторам, тимлидам и руководителям разработки. #AI4SDLC #AI #Engineering #Research #Management #Metrics

Понимание - новое узкое место в работе с AI (Рубрика #Learning) Посмотрел 20-минутное выступление Geoffrey Litt, design engineer в Notion. Его главный тезис: AI ускоряет производство изменений, но не формирование модели системы в голове. Поэтому узким местом становится уже не написание кода, а человеческое понимание. И важно оно не только для проверки результата. Агенты тоже учатся тестировать и рецензировать себя. Понимание нужно, чтобы участвовать: замечать связи, предлагать следующий ход и отвечать за развитие системы. Когда код работает, но команда уже не может объяснить, как и почему, накапливается когнитивный долг. Litt предлагает превращать AI из генератора результата в преподавателя. Кстати, я многими из этих способов пользуюсь, но не в применении к ревью PR, а изучая какую-то новую тему. Эти подходы действительно работают и помогают лучше уложить картинку у себя в голове 1️⃣ После большого изменения просить не пересказ diff, а объяснение: контекст системы → интуитивная модель → логика решения → код в осмысленном порядке; 2️⃣ Завершать разбор коротким тестом из пяти вопросов. Его правило: не отдавать код на ревью, пока сам не ответил. Такой тест - ограничитель скорости понимания; 3️⃣ Для сложной логики поручать агенту сделать «микромир»: временный отладчик, симуляцию или пошаговый интерфейс, где видно изменение состояния; 4️⃣ Обсуждать планы и объяснения в общем пространстве команды, а не в личных чатах с агентами. Иначе каждый быстро движется со своей версией реальности. В итоге, я бы свел рекомендации Джеффри к простому ритуалу: после каждой существенной AI-сессии зафиксировать, что изменилось, почему выбран этот путь, какие инварианты нельзя нарушать и что теперь умеет объяснить человек без помощи модели. Суть в том, что делегировать можно исполнение, но не владение системой. Хороший AI-процесс измеряется не только скоростью выпуска, но и тем, сохраняет ли команда способность придумать следующий шаг. #AI #AI4SDLC #Agents #Engineering #Management

Через пять минут стартует прямой эфир выпуска "Research Insights Made Simple" про AI-разработку как эволюционирующий стек. Поговорим о том, а почему одна и та же модель в двух кодинговых агентах даёт настолько разный результат? И что компании действительно стоит считать своим AI-стеком: модель, обвязку, инструменты, данные или право агента менять внутренние системы? #AI4SDLC #AI #Agents #Architecture #PlatformEngineering #Evals #Engineering

Появилась запись моего выступления на Turbo ML Conf. Сами слайды доступны на моем сайте polomodov.tech. P.S. Материалы по всем трекам все опубликованы и готовы к просмотру:) 1️⃣ Fundamental Advances & Exploratory R&D - Вконтакте | YouTube 2️⃣ Applied ML at Scale & Business Impact - Вконтакте | YouTube 3️⃣ ML Infrastructure, Platforms & Engineering Core - Вконтакте | YouTube #AI #AI4SDLC #ML #Engineering #Conference #Software

Дженсен Хуанг: от трех учебников до универсального аппроксиматора (Рубрика #AI) Посмотрел разговор Гарри Тана с Дженсеном Хуангом на Startup School 2026, опубликованный 26 июля 2026 года. Обычно такие интервью быстро превращаются в набор историй успеха, но здесь через весь разговор проходит одна инженерная привычка: вовремя признать, что прежняя модель не работает, разобраться в новой области и увидеть за отдельной технологией смену всей вычислительной системы. 1️⃣ Первая история - про ошибку, с которой началась NVIDIA. Компания хотела превратить персональный компьютер в игровую консоль и выбрала собственный алгоритм трехмерной графики. В 1995 году команда поняла, что технология фундаментально неверна, а правильного подхода внутри компании никто не знает. По рассказу Хуанга, он поехал во Fry’s, купил три учебника по OpenGL и устройству графического конвейера и отдал их инженерам. Компания, которая позже стала лидером компьютерной графики, буквально доучивалась уже после запуска и привлечения инвестиций. 2️⃣ Вторая история - про Sega. NVIDIA должна была участвовать в создании консоли после Saturn, будущей Dreamcast, но с выбранной архитектурой выполнить контракт не могла. Хуанг поехал к руководителю Sega Сёитиро Иримадзири, честно объяснил, почему проект нужно отдать другому подрядчику, и одновременно попросил деньги, без которых NVIDIA закрылась бы. По словам Хуанга, Sega выплатила $5 млн: не за готовую технологию, а потому что доверяла команде. Эти деньги дали NVIDIA время на разворот. 3️⃣ Третья история - про AlexNet. В 2012 году многие увидели в ней очень хороший классификатор изображений. Хуанг утверждает, что NVIDIA увидела другое: AlexNet была не отдельным решением для computer vision, а примером нового способа создавать программное обеспечение. Вместо того чтобы вручную описывать функцию, мы задаем глубокой нейронной сети примеры входов и выходов, а обучение подбирает внутренние параметры. Здесь стоит отдельно разобрать формулировку Хуанга про «универсальный аппроксиматор функций». Математически идея была известна задолго до AlexNet. Работы 1989 года показывали, что нейронная сеть даже с одним скрытым слоем и достаточным числом нейронов способна с любой заданной точностью приближать очень широкий класс функций на ограниченной области. Но это теорема о существовании представления. Она не говорит, что сеть удастся быстро обучить, что для этого хватит данных, что решение будет компактным или что модель правильно поведет себя за пределами обучающей выборки. Глубокие нейронные сети добавили к этой возможности практическую конструкцию. Последовательные слои учатся собирать более сложные признаки из простых, а глубина позволяет некоторые функции представить существенно компактнее, чем мелкой сети. Но по-прежнему нужны подходящая архитектура, функция потерь, данные, вычисления и способ оптимизации. Поэтому прорыв AlexNet был не в открытии самой теоремы. В 2012 году Алекс Крижевский, Илья Суцкевер и Джеффри Хинтон показали, что большую глубокую сверточную сеть можно обучить на ImageNet с помощью GPU и получить на тесте ILSVRC-2012 top-5 error 15,3% против 26,2% у лучшего конкурирующего результата. Разрыв был достаточно большим, чтобы deep learning перестал выглядеть как интересная теория и стал рабочей вычислительной платформой. Именно эту смену масштаба, кажется, и заметил Хуанг. Если сеть может учить не одну заранее запрограммированную процедуру, а разные отображения из данных, менять придется не только приложение. Меняются процессор, библиотеки, инструменты обучения, инфраструктура и затем целые прикладные отрасли. Для NVIDIA это был не новый рынок для GPU, а повод перестраивать весь стек. Остальные темы разговора я бы отметил короче: - Компанию Хуанг предлагает строить как гоночную машину под стиль ее основателя, а следующему руководителю - перенастроить ее под себя; - Главным навыком эпохи агентов он считает системное мышление, а ключевой нерешенной задачей - точное управление действиями агентов; - AI, по его мнению, автоматизирует отдельные задачи, но не обязательно уничтожает профессию целиком; приведенные в разговоре цифры занятости требуют отдельной проверки; - «ChatGPT-момент» робототехники, по его оценке, уже произошел, а следующий этап зависит от симуляции, evals и переноса навыков из симулятора в физический мир; - Фундаментальные дисциплины, способность учиться и ежедневная устойчивость для него важнее знания конкретного инструмента. Для меня главный вывод из этих историй не в том, что нужно «верить в себя». Сильная сторона Хуанга - классификация сдвига. Он увидел в учебниках не признание поражения, в деньгах Sega - время на смену технологии, а в AlexNet - не победителя соревнования, а новый способ программировать компьютеры. Инженерно это редкий навык: отличить хороший результат внутри старой категории от события, которое меняет саму категорию. #AI #Engineering #Architecture #Leadership #Robotics #Research

SonarQube Cloud: зачем агентному коду детерминированный внешний контроль (Рубрика #AI4SDLC) После поста "Sonar и звёздный час верификаторов" решил разобраться, а что именно SonarQube Cloud проверяет в коде, написанном агентами, а также почему это не еще один линтер, а что-то большее, например, гейт между тем, что «агент закончил» и «изменение можно влить». Sonar не определяет, понял ли агент задачу. Он проверяет более узкую вещь: не нарушает ли код правила безопасности, надежности и сопровождаемости. Продуктовая линейка сейчас выглядит так: - SonarQube - анализ и quality gates: Cloud работает в CI/CD, Server - в своем контуре, бесплатный SonarQube for IDE - во время написания кода. - Gitar - AI-ревьюер pull request: разбирает сбои CI, предлагает и применяет исправления. Практически это экономия внимания на рутинном PR-ревью. - Sonar Vortex - подает агенту контекст и правила через plugin, CLI или MCP и проверяет код во время генерации. Ошибки можно поймать до CI. - Remediation Agent - исправляет issues из PR или backlog и открывает проверенный PR. Это автоматизация технического долга. - Advanced Security - SCA: CVE, вредоносные зависимости, SBOM и лицензии. Это слой безопасности цепочки поставки. Почему проверки в основном детерминированные? Проверяющий слой должен работать как турникет, а не как второй собеседник. При одинаковых исходниках, версии анализатора, профиле правил и отчетах результат повторяется. Это дает контракт для человека и coding agent, короткий цикл исправления и аудит: видно правило, строку и причину отказа. Детерминированность не означает примитивность или точность. Анализатор строит модели потоков данных и путей исполнения, но они остаются приближением. Возможны ложные срабатывания и пропуски. Security Hotspots Sonar оставляет человеку: инструмент показывает чувствительное место, инженер оценивает контекст. Зеленый Quality Gate не доказывает правильность бизнес-логики или архитектуры. Я бы разделял роли так: тесты проверяют ожидаемое поведение, Sonar - известные дефектные конструкции, человек - намерение и инженерные компромиссы. Для меня главный вывод: чем дешевле генерация кода, тем важнее вынести критерии его приема из головы агента во внешний воспроизводимый контур. И защитить настройки, чтобы агент не мог «починить» красный gate снижением порога или исключением директории. P.S. Изучу еще CodeScene и дальше для своих пет проектов выберу один из этих продуктов и попробую на практике, потом поделюсь своими мыслями о том, а как они работают (благо сейчас я кода с агентами много пишу). #AI4SDLC #AI #Agents #Engineering #DevSecOps #Evals

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

Таненбаум, PagedAttention и фундамент, который не устаревает (Рубрика #Books) Разбирался с интересным paper "Efficient Memory Management for Large Language Model Serving with PagedAttention" от создателей vLLM. В 2023 году авторы посмотрели, как современные на тот момент движки инференса LLM работают с памятью, и нашли почти криминальную по нынешним временам картину (убийцей эффективности был KV-cache). Системы заранее резервировали под запрос непрерывный участок памяти исходя из максимально возможной длины последовательности. Но реальные ответы обычно короче, запросы растут динамически, память фрагментируется. По измерениям авторов, полезными данными было занято лишь 20,4–38,2% памяти KV-cache. Авторы предложили PagedAttention: разделить KV-cache на логические блоки и отображать их на физические блоки памяти, которые не обязаны лежать подряд и выделяются по мере необходимости. По сути, они перенесли в LLM serving давно знакомые операционным системам идеи виртуальной памяти и страничной организации. И тут я вспомнил, как с большим интересом читал "Современные операционные системы" Эндрю Таненбаума и Херберта Боса. Это был примерно 2017 год. Я уже год работал техническим менеджером в Тинькофф, но очень не хотел терять технические компетенции. Поэтому по выходным приезжал в офис: сначала позаниматься в фитнесе, потом - поботать технические темы. Одной из таких тем и стали операционные системы. Если говорить серьёзно, главная ценность книги не в том, что после 1100 страниц вы сможете написать своё ядро. Она даёт инженерное понимание о том, как компьютер делит ограниченные ресурсы между множеством конкурирующих программ и при этом сохраняет иллюзию, что у каждой есть собственный процессор, память, файлы и устройства. Книга последовательно разбирает: - Процессы и потоки, планирование, межпроцессное взаимодействие и синхронизацию; - Адресные пространства, виртуальную память, страничную организацию и алгоритмы замещения страниц; - Файловые системы, хранение данных и ввод-вывод; - Взаимоблокировки и способы их предотвращать, обнаруживать или переживать; - Виртуализацию и облака, многопроцессорные системы и безопасность; - Устройство UNIX, Linux, Android и Windows 8.1 как реальные примеры этих принципов. После такой книги начинаешь видеть одни и те же архитектурные ходы в совершенно разных системах: дополнительный уровень косвенности, отделение логического ресурса от физического, изоляцию, совместное использование, планирование и компромиссы между производительностью, задержкой и справедливостью. PagedAttention - отличный пример. Задача новая, железо другое, ставки выросли, а полезная абстракция приехала из учебника по операционным системам. Конечно, четвёртое издание - уже капсула времени. Windows 8.1 давно не современная система, а конкретные детали Linux, Android, безопасности и железа нужно дополнять актуальной документацией. И это точно не быстрый практикум по администрированию Linux. Но фундаментальные главы про процессы, память, файловые системы, конкуренцию за ресурсы и виртуализацию стареют гораздо медленнее конкретных API. Поэтому рекомендую Таненбаума инженерам, архитекторам и техническим руководителям. Особенно тем, кто, как и я тогда, уже отошёл от ежедневного написания кода, но не хочет терять способность разбираться, почему система тормозит, упирается в память, блокируется или плохо делит ресурсы. #Books #Engineering #Software #Architecture #OS #AI #DistributedSystems

Запускаем подкаст 3 AImigo: три взгляда на AI и разработку (Рубрика #AI) Мы запускам еженедельный подкаст про AI в разработке и не только. Вести его будем втроем: Евгений Сергеев, Алексей Литвинов и я, Александр Поломодов. У нас разный опыт и разная точка зрения, но общий интерес: понять, как AI на самом деле меняет инженерную работу, продукты и управление. Не на уровне рейтинга моделей и магических промптов, а там, где начинаются реальные кодовые базы, ограничения, ответственность и внедрение в команды. Состав для этого подобрался подходящий: 🤖Женя - Engineering Director во Flo. Женя смотрит на вопрос с позиции управления большой инженерной организацией и думает о том, как AI влияет не на отдельного разработчика, а на всю систему разработки. 🤖 Лёша - Principal Engineer и консультант по внедрению AI в разработку, ex-Lyft и ex-EPAM. Его фокус - AI-Assisted Engineering: как превратить эксперименты с coding agents в воспроизводимый процесс с контекстом, спецификациями и проверками. 🤖 Я - Technical Director & Fellow. Моя страсть - архитектура, платформенная разработка, AI4SDLC и технологические изменения на мастшабе корпорации. С каждым из нас в канале уже выходили отдельные подкасты. С Женей обсуждали, почему coding agents не отменяют экспертизу и как строить production-grade evals. С Лёшей разбирали AI-Assisted Engineering и работу агента в многоходовом диалоге. А я вообще постоянно о чем то рассказываю:) Мы будем выходить в прямой эфир раз в неделю и менять форматы: обзор новостей, глубокое погружение в одну тему, разбор практических кейсов или AMA-сессия. Самое интересное, думаю, появится на пересечении наших позиций - мы совсем не обязаны во всем соглашаться. В первом выпуске познакомимся и сверим представления о том, где сейчас находится AI-разработка. Напишите в комментариях, что вам было бы интересно обсудить именно в таком составе. Агенты? Архитектуру? Evals и метрики? Изменение ролей инженеров и руководителей? Реальные кейсы внедрения? Часть вопросов возьмем уже в первые эфиры. #AI #AI4SDLC #Engineering #Architecture #Management #Podcast

Джефф Дин покидает Google после 27 лет работы (Рубрика #Legend) Буквально пару-тройку дней назад я рассказывал про лекцию Джеффа для стартаперов из Y Combinator. Ближе к концу там была такая фраза Наконец, Дин ожидает, что в 2027 году заметно вырастет автоматизация самого ML: система будет раскладывать задачу, запускать множество экспериментов, оценивать результаты и собирать улучшенную версию. AlphaEvolve уже показывает форму такого цикла. А сегодня появляется эта новость, где Джефф и его друзья стартуют лабу "Discovery Loop!" в формате Public Benefit Corporation whose mission is to automate machine learning, science, and engineering to accelerate discoveries and progress Теперь понятно за счет чего вырастет эта автоматизация:) Ну а если серьезно, то с большим интересом буду следить за анонсами из этой новой корпорации, которую как объявил Сундар Пичай поддержит Google #AI #Agents #Engineering #Architecture #Infrastructure #Product

Приходите мы с Лешей Литвиновым стартанули прямой эфир про AI в разработке

Материалы по прямому эфиру с Артемом Бондарем про то, как внедрять AI в операционную работу (Рубрика #AI) Готовы материалы с прямого эфира подкаста Code of Leadership с Артемом (@artemonml): - Страничка выпуска - Видео: YouTube, VK Video - Аудио: Podster, Яндекс Музыка - Текст: Краткая расшифровка #AI #Management #Processes #Engineering #Software #Architecture

Гарри Тан про AI-native компанию: память важнее модели (Рубрика #AI4SDLC) Посмотрел доклад Гарри Тана, президента и CEO Y Combinator, «Every company should have a Brain» с AI Engineer World’s Fair 2026. Главный тезис: преимущество даёт не особая модель, а организация работы вокруг агентов и накопленного контекста. По собственной оценке Тана, его производительность в программировании выросла до 400 раз, а со строгими поправками — в 8–80 раз. Это не benchmark, а личная оценка. Важнее другое: условные «2x» и «100x» разработчики используют те же модели. Разница - в обвязке. Тан предлагает смотреть на агентную систему как на организацию: - Skill-файл - сотрудник с одной обязанностью; - Resolver - оргструктура, направляющая задачу; - Правила хранения - внутренние процессы; - Evals - проверка их работы (аля performance review) Неоднозначные задачи Тан предлагает отдавать модели и сейчас это это понять намерение и сделать выбор. А состояние, расчёты, ограничения и проверки можно поручить детерминированному коду. Многие сбои начинаются там, где одно пытаются заменить другим. Но даже хороший агент ограничен контекстным окном, а компания - это библиотека из переписки, встреч, решений и postmortem. Поэтому «мозг компании» у Тана - не просто поиск, а библиотека плюс библиотекарь, выбирающий нужный контекст для задачи. Свой вариант Тан развивает в открытом проекте GBrain - слое памяти и поиска для агентов с синтезом ответов, ссылками на источники и графом связей: Без источников, проверки противоречий и удаления устаревшего знания такой «мозг» превратится в свалку с хорошим поиском. Память здесь - production-инфраструктура, а не папка для всего подряд. Практический совет от Гарри - не делать одноразовую работу. Удачный результат нужно превратить в повторяемый skill и проверить через eval. Тогда организация накапливает способность, а не каждое утро начинает с амнезии. #AI #AI4SDLC #Agents #Engineering #Architecture #Management