Книжный куб

Зачем руководитель возвращается к коду — материалы выпуска (Рубрика #Leadership) Вышел 82-й выпуск Code of Leadership: 1 октября поговорили с Никитой Белокопытовым, который руководил инженерными командами в AutoScout24 и Playrix, а сейчас занимается прикладным ИИ в Bluefish. Зачем снова садиться за разработку, когда уже умеешь управлять людьми? Никита объясняет свой выбор вполне практично: как руководить командой, если её новые инструменты и даже проблемы тебе незнакомы? Обсудили: 🔸 Как техническая правота мешает стать руководителем Никита рассказал, как однажды заявил менеджеру, что хочет занять его место, и получил предложение спросить коллег, хотят ли они такого начальника. После честной обратной связи пришлось менять привычки общения. В календаре появилось ежедневное напоминание BeKind. 🔸 Почему сильнейшие программисты не первыми переходят на Cursor По наблюдению Никиты в Playrix, ускорение написания кода мало меняло работу тех, кто и так пишет быстро, а основное время тратит на обдумывание задачи. Более полезным оказался разбор багов с агентами — когда для них задали граф состояний, инструменты и изолированную среду. 🔸 Что остаётся от менеджерского опыта без подчинённых Найти владельца системы, договориться об изменении, снять препятствие, взять ответственность — всё это пригодилось Никите в инженерной роли. Он допускает, что небольшим автономным командам понадобится меньше управленческих слоёв; это его прогноз, а не готовое правило для любой компании. 🔸 Где заканчивается автономность агента В Bluefish агент берёт небольшую задачу из Jira и доводит её до PR. Но необходимость задачи определяет человек, а за изменение основной системы отвечает инженер. В другом эксперименте Никита упёрся в собственный предел проверки — пять-шесть PR в день; отдельные циклы исправлений между агентами доходили до 60 итераций. Отсюда ограничения по деньгам, времени и числу повторов. 🔸 Как погружаться в код без микроменеджмента Разобраться в системе самому полезно, но дальше нужно уметь разговаривать с командой. Иначе новые технические знания легко превращаются в новые поводы вмешиваться в чужую работу. Материалы выпуска: 📌 Страница выпуска с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект разговора Если вы после нескольких лет управления снова вернулись к разработке, расскажите: что пришлось учить заново, а какой менеджерский навык неожиданно пригодился? #CodeOfLeadership #AI4SDLC #Management #Leadership #Engineering #Product

Harness engineering: как экспериментальная команда внутри OpenAI перестраивала разработку вокруг агентов для одного из внутренних продуктов(Рубрика #AI4SDLC) Готовясь к 35-му выпуску Research Insights, изучал статью OpenAI про harness engineering. Вышла она 11 февраля 2026 года, и для того момента здесь очень много интересных и прорывных мыслей о работе инженера. Особенно если читать её через вопрос: что нужно сохранить о системе, когда сам код становится всё дешевле? Команда Райана Лопополо строила внутренний продукт, сознательно запретив себе писать код руками. По их данным, за пять месяцев получилось около миллиона строк, включая документацию и инфраструктуру, и примерно 1500 принятых PR. Инженеры занимались средой, в которой Codex мог выполнять работу. Из статьи я бы выделил четыре вещи: 1️⃣ Знание должно быть доступно агенту. Короткий AGENTS.md служит картой документации. Требования и причины решений живут в репозитории. 2️⃣ Архитектуру нужно проверять. Допустимые зависимости и границы слоёв закреплены линтерами и структурными тестами. 3️⃣ Агенту нужны глаза. Доступ к интерфейсу, логам и метрикам позволяет ему воспроизводить ошибки и проверять исправления. 4️⃣ Сложность требует регулярной работы над ее снижением. Фоновые задачи ищут отклонения и предлагают небольшие рефакторинги. Ошибки становятся поводом улучшать правила и инструменты. Мне здесь нравится перенос инженерного суждения в среду: сформулированное требование можно многократно применять и проверять. Очень рифмуется с темой моего keynote на DotNext — знание о системе должно переживать её реализацию. А у этой истории оказалось занятное продолжение. В апрельском интервью Лопополо рассказал, что работал в Frontier Product Exploration, команде корпоративных агентных продуктов. И первые полтора месяца такой разработки, по его оценке, были примерно в десять раз медленнее ручной работы. Пришлось вложиться в инструменты и контекст, прежде чем эксперимент начал окупаться. Следующим узким местом стало переключение между сессиями агентов (мы про эту проблему говорили в выпуске Research Insights #34). Так появился Symphony: он забирает задачи из Linear, запускает агентов в отдельных рабочих пространствах и доводит работу до приёмки. Человек задаёт работу и оценивает результат. Интересно, что в репозитории Symphony есть спецификация SPEC.md и экспериментальная реализация на Elixir. Можно попросить агента построить свою версию по этой спецификации. Получается вполне предметный шаг к восстановлению реализации из сохранённого знания. К сентябрю Лопополо уже работал в Google Cloud и в новом разговоре советовал вкладываться прежде всего в инструменты и контекст: переносить исправления из разовых подсказок в документацию, линтеры и тесты. При этом исходный эксперимент начинался с пустого репозитория. В апреле автор уточнял, что перед выпуском приложения оставался человеческий smoke-тест. Переносить такой процесс в зрелую систему нужно с пониманием её рисков. Приходите на 35-й выпуск Research Insights в эту пятницу: про статью поговорим подробнее — где здесь воспроизводимая инженерная практика и что нужно уметь проверять, прежде чем отдавать агентам больше работы. P.S. Не смог приложить PDF, так как просто Ctrl + P на сайте OpenAI приводит к сохранению PDF, в котором теряется часть текста - пришлось читать статью по старинке, из браузера:) #AI4SDLC #AI #Agents #Engineering #Architecture #PlatformEngineering

Заходите на прямой эфир Research Insights #34, где я расскажу про прошлогоднюю статью, в которой ребята из Anthropic делились своим опытом передачи работы между разными сессиями одного и того же агента. Этот выпуск продолжает историю про SWE-agent, что мы разбирали в выпуске #33

Warp: поправили агента. Чему научилась система? (Рубрика #AI4SDLC) Интересная история от создателя Warp, которая продолжает разбор Factory, где мы обсуждали, как организовать исполнение и проверку агентных задач, а также разбор Conductor, где мы говорили о том, а как человеку управлять несколькими исполнителями. Но после обоих остаётся вопрос: если сегодня пришлось поправить агента, что изменится в его работе завтра? Zach Lloyd, основатель и CEO Warp, предлагает сделать такие исправления материалом для улучшения всего процесса. Его доклад «Software Engineering Is Becoming Factory Engineering» прошёл на AI Engineer World's Fair 30 июня 2026 года, а отдельная запись появилась 27 сентября. По мысли Lloyd, инженер будет всё больше заниматься системой, которая производит изменения в продукте. Warp продаёт инфраструктуру для такого процесса, поэтому интерес компании понятен. Сам процесс узнаваемый: разобрать задачу, подготовить спецификацию, написать код, проверить, выпустить и наблюдать за результатом. Люди у Lloyd продолжают проверять спецификации, код и поведение продукта. Мне здесь интереснее второй цикл — работа над самим процессом. Агент делает ревью, опытный инженер исправляет его замечание. Агент-наблюдатель разбирает эту обратную связь и предлагает обновить skill — инструкцию для следующих ревью. Так исправление может пережить текущий PR и помочь другим участникам команды. Это хорошо продолжает историю Vercel d0: там повторяющиеся запросы превращались в навыки, а я задавался вопросом, кто дальше проверяет и обновляет накопленное. Warp предлагает использовать для этого в том числе замечания людей. Причём после доклада идея стала конкретнее. В июльском руководстве Warp агент уже открывает PR с изменением навыка ревью. А в документации, обновлённой 24 сентября, предлагаемые исправления связаны с неудачными запусками и требуют человеческой проверки. Здесь «самоулучшение» означает изменение инструкций и процесса; обучение весов модели из этого не следует. Со способом оценивать успех я бы поспорил. В обращении к команде Lloyd предлагает считать работу с агентом в ручном интерактивном режиме неудачей, из которой нужно извлечь урок. Цель — увеличивать долю автоматических изменений. Повторные объяснения уже известного правила хочется убрать. А совместный поиск решения для новой задачи может быть полезной работой, даже если снижает долю автоматических изменений. Здесь снова вспоминается Dex Horthy из HumanLayer с его вниманием к проектированию и пониманию системы. Я бы оценивал, какие вмешательства удалось убрать и что стало с качеством результата. Процент автономных задач сам по себе этого не покажет. Правда надо отметить, что и человеческое замечание тоже может быть ошибочным. Если сразу превратить его в общую инструкцию, завтра агент начнёт старательно повторять уже нашу ошибку. Из этого я бы забрал три практических шага: 1️⃣ Найти одну повторяющуюся правку Посмотреть последние ревью, сформулировать правило и сохранить пример ошибки. Начать с небольшого навыка, пользу которого можно проверить. 2️⃣ Проверить новую инструкцию на других задачах Сравнить старую и новую версии, включая случаи, где раньше всё работало. Принимать изменение после проверки и сохранять возможность отката. 3️⃣ Посчитать полную стоимость результата Включить время на постановку, ревью и переделки, расходы на модели и обслуживание автоматизации. Затем проверить, стало ли меньше повторных исправлений при сопоставимом качестве. #AI4SDLC #AI #Agents #PlatformEngineering #Evals

Забегаайте на прямой эфир с Андреем Димтриевым из JUG.RU, где мы обсудим, что сейчас разработчик становится менеджером, хочет он этого или нет

Conductor: как управлять оркестром агентов (Рубрика #AI4SDLC) В разборе «Несведущего маэстро» я уже писал, что меня давно интересует, как дирижёры управляют коллективами и что из этого можно перенести в разработку ПО. Теперь к людям в оркестре предлагают добавить агентов. Именно такую метафору использует Charlie Holtz, сооснователь и CEO Conductor, в докладе «Orchestras, Not Factories». Он выступал на AI Engineer World’s Fair 30 июня 2026 года, а отдельная запись вышла 27 сентября. Conductor — приложение, в котором можно управлять несколькими кодинг-агентами и работать над задачами вместе с коллегами. Holtz хочет, чтобы человек мог задавать направление, погружаться в детали и получать удовольствие от создания продукта. Агенты при этом берут на себя всё больше исполнения. И за красивой метафорой у него есть несколько вполне прикладных правил. 🔸 Пробовать новое, но не застревать в настройке По его мнению, свой рабочий процесс стоит дорабатывать там, где есть особенности продукта или команды. Универсальные улучшения крупные разработчики инструментов со временем встроят сами. Хороший повод проверить, сколько времени уходит на очередную настройку и сколько она реально экономит. 🔸 Выделять области с обязательной человеческой проверкой В Conductor их называют slop-free zones. Например, изменения миграций должен проверить человек. Документацию, инструкции для агентов и skills команда тоже готовит особенно тщательно. Мне здесь нравится сама избирательность: заранее определить места, где цена ошибки выше. Плохая инструкция, например, может повлиять сразу на множество следующих задач. 🔸 Делать знания команды доступными агентам Их внутренний Conductor Internal Agent собирает сообщения Slack, обращения из Discord и записи встреч в PostgreSQL. Агенты могут искать там информацию через SQL. Это полезная идея, но я бы отдельно подумал, как отличать обсуждение от принятого решения, находить устаревшие сведения и учитывать права доступа. Человеческое сообщение тоже может оказаться ошибочным. Дальше Holtz показывает совместную работу в облаке. Тут уже есть продолжение за пределами доклада: Conductor Cloud вышел 30 июля. Агенты работают в отдельных окружениях и продолжают задачу после закрытия ноутбука; коллеги могут подключаться к общему рабочему пространству. А 2 октября вышло приложение для iOS. Если сопоставить это с другими подходами, я бы расставил акценты так. Tereza Tížková из Factory подробнее показывает организацию исполнения и проверки. Dex Horthy из HumanLayer — участие инженера в проектировании и сохранение понимания кода. Holtz — то, как человек и команда управляют несколькими исполнителями. Эти подходы вполне можно совмещать. При этом Conductor продаёт именно такую рабочую среду, так что продуктовый интерес понятен. Сравнительных измерений скорости в докладе нет: это наблюдения основателя и демонстрация его продукта. И здесь возвращается тема разбора Zack Proser про человеческое внимание. Оркестром тоже можно утомиться управлять. Если весь день переключаешься между агентами, объясняешь одно и то же и разбираешь недоделки, новая метафора мало что меняет. Мне интереснее, какие повторяющиеся вмешательства этот процесс позволяет убрать. Отсюда три практических шага: 1️⃣ Инженеру Выбрать несколько областей, где проверка человеком обязательна, и перечитать инструкции, которые агент получает при каждом запуске. 2️⃣ Платформенной команде Проверить, может ли агент найти актуальное решение, поднять окружение и продолжить задачу без постоянных ручных подсказок. 3️⃣ Руководителю Сравнить пилот с обычным процессом: сколько времени людей уходит на постановку, переключения, проверки и переделки. При сопоставимом качестве это поможет оценить, сколько внимания освобождает работа с несколькими агентами. #AI4SDLC #AI #Agents #Engineering #Management

Материалы выпуска: как инженер учится договариваться — Сергей Киселёв (Рубрика #Leadership) Собрал материалы нашего разговора с Сергеем Киселёвым, руководителем Development Platform в MWS Cloud Platform. Эфир Code of Leadership №83 прошёл 2 октября 2026 года. Говорили о том, как сделать полезную техническую систему, которой другие команды действительно будут пользоваться: даже хороший инструмент ещё нужно встроить в их работу. У Сергея за плечами студенческая компания в Иркутске, Яндекс, Yandex Cloud и создание платформы разработки нового облака. По дороге он несколько раз менял инженерную и управленческую роли — и навык организовывать людей каждый раз оставался с ним. Обсудили: 🔸 Рост инженера и самостоятельность команды Как управленческий опыт помогает после возвращения к коду и почему Сергей считает результатом руководителя команду, которая умеет работать без его постоянного участия. 🔸 Платформу через совместную разработку Инженеры платформы приходили в продуктовые команды, помогали писать сервисы и на этих задачах проверяли общие инструменты. Go, Kotlin, развёртывание и единый API требуют договорённостей с людьми, которые тебе зачастую не подчиняются. 🔸 Найм как общую инфраструктуру Задания, первые интервью, обучение интервьюеров и внутреннее сообщество. Сергей рассказывает, как процесс, начавшийся с его команды, стал помогать соседним направлениям. 🔸 Что происходит после восстановления сервиса Кто сообщает пользователям о сбое и кто возвращается к задачам из разбора. Обещание «быть внимательнее» плохо помогает, а записанное исправление может месяцами лежать в планах. 🔸 AI-агентов внутри платформы Сергей описывает доступ к документации через MCP и перенос командных правил в инструкции для агентов. При этом ограничения на передачу пользовательских данных и вопросы дальнейшей поддержки кода остаются. Материалы выпуска 📌 Страница выпуска 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект Поделитесь, что у вас оказалось сложнее при развитии внутренней платформы: сделать инструмент или договориться о его использовании? #CodeOfLeadership #Leadership #Management #PlatformEngineering #DevOps #AI

SWE-agent или как интерфейс меняет результат / Research Insights Made Simple #33 (Рубрика #AI4SDLC) Через полчаса проведу прямой эфир Research Insights, где поговорю про статью из 2024 года «SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering» с NeurIPS 2024. В ней рассказывается про то, а что меняется, если дать той же языковой модели более удобный интерфейс для работы с репозиторием? Вместо разговора только о моделях и промптах посмотрим на действия агента и обратную связь, которую он получает. В программе будет - Поиск по коду и чтение файлов: как агент находит нужное и сохраняет ориентиры. - Многострочные правки и проверка синтаксиса: как предотвращать ошибки и восстанавливаться после них. - Управление контекстом: что показывать модели, что сокращать и что сохранять. - Результаты SWE-bench и SWE-bench Lite: с чем сравнивают SWE-agent и что показывают абляции. - Выводы для современных агентов: какие принципы стоит перенести в свою систему, а какие настройки остались частью эксперимента 2024 года. #Engineering #AI4SDLC #AI #SystemDesign #Research

Factory и HumanLayer: сколько самостоятельности отдавать агентам (Рубрика #AI4SDLC) Посмотрел интересное видео доклада Tereza Tížková, которая занимается развитием Factory. Она выступала на AI Engineer World’s Fair 30 июня, а отдельная запись вышла 27 сентября. Здесь разговор уже про то, как вокруг агентов организовать разработку целиком. Это видео продолжает линию, когда в мае я уже разбирал доклад Luke Alvoeiro из Factory про их агента Droid и режим Missions. Там работа поделена между агентами: одни планируют, другие пишут код, третьи проверяют результат. Причём условия готовности записываются до реализации, а проверяющий не должен быть автором кода. Если возвращаться к свежему докладу Терезы, то по ее мысли software factory должна собирать обратную связь, выбирать задачи, выполнять их, проверять результат и запускать следующий круг. Для этого нужны три вещи: возможность менять модели и инструменты, долгая самостоятельная работа агентов и накопление знаний о проекте. Человек задаёт направление и решает, что стоит строить. К знакомой схеме здесь добавляются несколько полезных деталей. 🔸 Деньги В Factory модель подбирают под задачу: выбирают самую дешёвую из тех, которые, по оценке системы, должны справиться. При необходимости можно перейти на более сильную. Для длинной работы важно понимать, сколько стоит весь путь до принятого результата, включая проверки и повторные попытки. 🔸 Контекст Описания всех подключённых инструментов могут забить агенту память ещё до начала работы. Factory сначала показывает короткий каталог, а подробности подгружает по необходимости. По данным компании, в исследованных сессиях с использованием MCP это сократило входные токены в среднем примерно на 15%. В группе со 100+ инструментами, чьи описания загружались по мере надобности, средняя экономия была около 51%. Так что эффект сильно зависит от того, сколько всего подключено. 🔸 Подготовка команды Документация, тесты, понятный способ запустить проект и записанные правила работы нужны и агентам. Если сборку умеет запускать только один человек, а важные договорённости живут в переписке, агенту придётся разбираться с этим заново. У Factory такая проверка готовности называется Agent Readiness. И здесь интересно вспомнить Dex Horthy и его Why Software Factories Fail. Dex тоже делает инструменты для агентной разработки. Его HumanLayer — среда, где команда обсуждает планы агентов и проверяет изменения кода. У него другой акцент: проходящие тесты ещё не говорят, насколько легко будет менять систему через полгода. Поэтому Dex предлагает заранее обсуждать требования, архитектуру и устройство кода, а затем двигаться небольшими проверяемыми частями. При этом Dex признаёт: убедительно доказать, что агенты со временем делают код сложнее для сопровождения, он пока не может. Factory показывает, как организовать самостоятельную работу агентов и проверку результата. Dex подробнее разбирает то, что сложнее проверить тестами: устройство кода и способность команды дальше его менять. У обоих есть свой продукт и свой интерес в этом разговоре. Я бы совмещал эти подходы: автоматизировать исполнение, а важные решения об устройстве системы обсуждать до того, как агент напишет код. Я бы забрал отсюда три практические вещи: 1️⃣ Инженеру Перед запуском агента записать, что должно работать и как это проверить. После — убедиться, что можешь объяснить ключевые решения в полученном коде. 2️⃣ Платформенной команде Взять один репозиторий и проверить, может ли агент сам поднять окружение, найти правила проекта и запустить тесты. Каждую ручную подсказку стоит разобрать: чего не хватает в документации или инструментах? 3️⃣ Руководителю На небольшой задаче посчитать стоимость готового изменения: модели, проверки, переделки и время людей. Сравнить с прежним процессом и отдельно посмотреть, что произошло с качеством. #AI4SDLC #AI #Agents #Engineering #Management

Один дизайнер и сотни материалов (Рубрика #AI) В этом видео «One Designer + AI. Hundreds of Deliverables» меня зацепило, как дизайнер реагирует на большой объём работы. Он не кривит нос «фу, это не как в Figma», а меняет процессы и создаёт инструменты, которые помогают этот объём вывезти. Vincent Wendy, дизайнер AI Engineer, рассказывает, как готовит материалы для конференции. По его словам, на 7000 участников и более 300 спикеров у них один дизайнер. Карточки, расписания, навигация — всё это нужно собрать, проверить и вовремя обновить. Он начинает с правил: шрифты, цвета, компоненты. Дальше вместе с Devin делает генератор карточек спикеров и инструмент для сборки расписаний из актуальных данных. Повторяющаяся работа превращается в выбор нужных данных и экспорт готового изображения. Мне нравится сам ход мысли. Если приходится снова и снова собирать похожие материалы, можно потратить часть усилий на инструмент, который поможет делать это дальше. Дизайнер знает, где именно у него уходит время и какие детали легко упустить. Из этого знания и вырастает задача для агента. А ещё в докладе есть хороший эпизод: понадобилось срочно исправить расписание, а кнопки редактирования в инструменте нет. Wendy просит Devin её добавить, меняет данные и выгружает новый PNG. Процесс продолжает меняться по мере того, как появляются реальные рабочие ситуации. Вот эта готовность пересобирать свою работу мне и интересна. Привычный инструмент остаётся полезным, но круг возможных решений расширяется. И создание небольшого приложения под собственную задачу становится частью работы дизайнера. P.S. Я упоминал этот кейс в выпуске 3 AImigo про AI-native организацию. #AI #Agents #Engineering #Product #Conference

3 AImigo S1E8: AI-native компания — материалы выпуска (Рубрика #AI4SDLC) Собрал материалы восьмого выпуска 3 AImigo «AI-native: что это значит для компании?». Эфир прошёл 2 октября 2026 года, запись опубликована 3 октября. С Алексеем Литвиновым и Евгением Сергеевым обсуждали, что должно измениться в компании, когда у каждого уже есть AI-помощник, а результат всё ещё ждёт согласования в соседнем отделе. Обсудили: 🔸 Как агенты становятся частью общей работы Алексей предлагает смотреть на взаимодействие агентов разных сотрудников, Евгений — на весь путь от намерения до результата, я — на перестройку процессов и организации. Это наши рабочие определения, а не единый стандарт AI-native. 🔸 Общий контекст и внимание человека Знания нужно поддерживать в актуальном состоянии, принятые решения — сохранять, а вопросы к человеку — ставить в очередь. Иначе ускорение агентов довольно быстро превращается в очередь к одному руководителю. 🔸 Эволюцию или революцию Я защищаю постепенные проверяемые изменения в большой компании; Алексей опасается, что так мы не успеваем за технологией. Пилоты, поддержка руководства и измерение всего пути продукта помогают проверить эффект: команда может ускориться и всё равно ждать соседние. 🔸 Готовый сервис или собственный инструмент Алексей рассказывает, как с агентом собрал систему подбора обучения за несколько часов. Евгений напоминает о готовых платёжных сервисах, а я — о поддержке и интеграциях. Несколько часов на прототип могут обернуться годами обязательств. 🔸 Куда деть освободившееся время Переобучить людей, найти новые продукты или сократить расходы? Тут мы тоже спорили: дополнительные возможности сами по себе не создают спрос на результат. Материалы выпуска: 📌 Страница выпуска 📖 Лонгрид об AI-native организации — отдельный разбор, подготовленный мной к эфиру: процессы, ответственность, проверка эффекта и первые 90 дней перехода 🎬 YouTube, VK Video 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект разговора Если уже перестраиваете работу вокруг агентов, расскажите, где сейчас упираетесь: в контекст, согласования, поддержку своих инструментов или поиск полезных задач? #AI4SDLC #AI #Management #Architecture #Podcast

В процессе подготовки к переезду начал разбирать книжки и освобождать свою библиотеку. Наткнулся на кучу уже прочитанных книг, но задержался на этой книге Скотта Пейджа "Модельное мышление" (я делал ее обзор в своем блоге). Помню, что его одноименный курс на Coursera был для меня первым году так в 2013-2014 - я прошел его и дальше на волне восторга за следующие полтора года прошел 100+ семестровых курсов на Edx и Coursera. Книга в этом плане тоже превосходна - она учит применять разные математические модели для решения задач реального мира. И автор просто мастер в том, чтобы сделать такое обучение простым и увлекательным - я всегда хотел сам уметь объяснять сложные вещи простым языком, а у меня в лучшем случае получается их объяснять сложным:) В общем, рекомендую эту книгу всем, особенно тем, кто считает математику слишком абстрактной:)

Stanford CME295, лекция 1: как текст становится вычислениями (Рубрика #AI) Первая лекция курса Stanford CME295, о котором я уже рассказывал раньше, вышла интересной - за 1 час 44 минуты Афшин и Шервин Амиди объясняют, как превратить текст в числа, связать эти числа с контекстом и собрать из этого работающую модель перевода. Сильная сторона записи — каждая новая деталь появляется как ответ на конкретную проблему. Поэтому даже у довольно внушительной схемы Transformer постепенно становится понятно назначение отдельных блоков. Дальше я расскажу про основные моменты этой лекции 1️⃣ Токены: на какие кусочки нарезать текст? Можно брать целые слова, но тогда словарь разрастается, а незнакомые слова создают проблемы. Можно брать отдельные символы, но последовательности становятся длинными и дорогими в обработке. Часто используют промежуточный вариант — части слов. BPE собирает словарь, последовательно объединяя часто встречающиеся пары. Поэтому токен не обязан совпадать со словом, а способ разбиения зависит от данных, на которых обучали токенизатор. 2️⃣ Embeddings: как придать этим кусочкам полезное числовое представление? Номера в словаре лишь различают токены. Для работы модели каждому нужен вектор — набор чисел, который обучается вместе с ней. На примере Word2vec преподаватели показывают, как обучение на текстах позволяет получить полезные связи между словами. Но фиксированного вектора недостаточно: английское bank может означать банк или берег. Контекст меняется, а исходное представление слова остаётся тем же. 3️⃣ Attention: как учитывать окружающий текст? RNN и LSTM обрабатывают последовательность шаг за шагом, обновляя внутреннее состояние. Примерно как пересказывать книгу по одной постоянно обновляемой заметке: далёкие детали удерживать сложно, а вычисления зависят от предыдущего шага. Attention даёт прямые связи между представлениями токенов. Модель вычисляет веса этих связей и смешивает информацию с учётом полученных весов. Q, K и V удобно понимать как «что ищем», «по чему сопоставляем» и «какую информацию берём». Это поясняющая метафора: внутри всё происходит через обучаемые преобразования векторов. Self-attention позволяет обновить представление токена с учётом других токенов той же последовательности. 4️⃣ Transformer: как собрать детали вместе? В исходной архитектуре encoder строит представления входного текста с учётом контекста, а decoder по одному генерирует токены перевода, обращаясь к этим представлениям и уже полученному тексту. Информация о позиции помогает учитывать порядок. Маска запрещает подсматривать будущие токены при обучении. Слои нейросети преобразуют собранную информацию, а дополнительные связи и нормализация помогают обучать глубокую модель. В конце всё это проходят на одном предложении про плюшевого медвежонка: от токенизации до вероятностей следующего токена и готового перевода. Здесь особенно удобно сверить, как отдельные механизмы работают вместе. Разбирают именно Transformer из статьи 2017 года; другие семейства моделей заявлены в следующей лекции. Сама лекция будет полезна тем, кто уже пользуется LLM и хочет понимать их устройство, разработчикам AI-приложений и всем, кто начинает системно изучать тему. Подача доступная, но векторы, умножение матриц и базовые понятия обучения нейросетей пригодятся: преподаватели доходят до формул и размерностей. Я бы смотрел с паузами, а после сквозного примера попробовал нарисовать весь путь от текста до следующего токена самостоятельно. #AI #LLM #Learning #Engineering #Architecture

Камил видит руками (Рубрика #ForKids) Читаю своему пятилетнему сыну Кириллу перед сном эту книгу и она мне нравится. Она написана легко и с юмором и дает пищу для размышлений и обсуждений с малышом. Сама книга про пятилетного мальчика Камила, ее сестренку 6 лет и маму и папу. И все вроде как обычно, но Камил - незрячий, но это не мешает ему учиться и играть, бегать и кататься на велосипеде, шутить и веселиться. Каждая история в книге выглядит как маленький эпизод из жизни маленького Камила и мы видим как папа, мама и его сестра любят Камила и именно эта любовь позволяет ему расти без жалости к самому себе. Но не все окружающие так относятся к Камилу и мы видим, что иногда это особое отношение мешает. Именно поэтому в название вынесена фраза из истории про посещение музея, где Камил видел экспонаты по своему - руками. В общем, это очень хорошая книга, рекомендую. #ForKids #ForParents

Где деньги в своих данных: цены, клиенты, ассортимент — материалы второго выпуска (Рубрика #Data) Собрал материалы второго выпуска «Где профит от данных, Лебовски?». Выпуск вышел 30 сентября 2026 года: мы с Андреем Цыбиным и Николаем Головым обсуждали, как заработать на данных внутри компании. В первом разговоре разбирались с продажей данных наружу. Теперь смотрим на то, что уже лежит в CRM, ERP, бухгалтерии и таблицах: можно пересмотреть цены, понять прибыльность клиентов или поменять ассортимент. Только после расчёта кому-то ещё придётся изменить свою работу — и разобраться, помогло ли это бизнесу. Обсудили: 1️⃣ Цены На истории Motor City Industrial разобрали, что происходит, когда подразделения назначают цены каждое по-своему, и как сведение продаж и цен помогает договориться об общем подходе. 2️⃣ Клиентов Большая выручка может скрывать большие расходы на поддержку, возвраты и время сотрудников. При этом убыточность клиента сама по себе не повод от него избавляться: есть связи между продуктами и сетевые эффекты. 3️⃣ Ассортимент Товар с небольшой собственной прибылью может приводить людей за всей остальной корзиной. Поэтому считать приходится ещё хранение, доставку, совместные покупки и заменители. 4️⃣ Разовый проект и регулярный процесс Николай предлагает начать с ограниченной задачи на доступных данных. Я возвращаю разговор к тому, какие правила останутся после проекта: цены и товары продолжат меняться, а люди — принимать решения. 5️⃣ Проверку эффекта Андрей ставит неудобный вопрос: если после изменения денег стало больше, точно ли помогло именно оно? Поговорили о наблюдении за покупателями, экспериментах и границе между корреляцией и причинностью. Кейсы взяли из публичных материалов поставщиков и консультантов. Они помогают разобрать механизм, но не раскрывают всех затрат на внедрение; наши оценки в разговоре не стоит принимать за готовую смету. Материалы выпуска: 📌 Страница с таймкодами 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Конспект на 7 минут чтения Где у вас обычно застревает работа с данными: в расчёте, в изменении процесса или в проверке результата? #Data #Product #Analytics #Management #Metrics

Как AI меняет роль техлида: запись круглого стола (Рубрика #AI4SDLC) Если агент пишет код, что остаётся техлиду — и как не превратиться в человека, который в одиночку проверяет все изменения команды? 30 сентября на Podlodka Techlead Crew мы с Рафаелом Тонаканяном из Сбера поговорили об этом. Разговор вели Игорь Антонов и Андрей Кулешов. Собрал материалы выступления у себя на сайте. Обсудили несколько вопросов, с которыми приходится разбираться, когда агенты становятся частью команды: - Как считать пользу AI с учётом времени на проверку и принятие результата? Количество токенов и сгенерированного кода само по себе мало что объясняет. - Где начинающему инженеру брать опыт, если первый вариант решения за него готовит агент? - Что проверять: сам код, постановку задачи, ход работы агента? Здесь поспорили — общего решения об отмене проверки кода у нас нет. - Что делать с очередью готовых правок и старыми задачами, которые теперь можно выполнить быстрее, но нужнее от этого они не стали? Можно [посмотреть запись на YouTube или прочитать конспект. А ещё к разговору я подготовил лонгрид со своей позицией: про архитектуру, полномочия агентов, развитие команды и проверку эффекта. Он написан до круглого стола, поэтому это моя исходная рамка для дискуссии. #AI4SDLC #Agents #Engineering #Leadership #Management

Stanford CME295: погружение в основы LLM (Рубрика #AI) Начал изучать курс Stanford CME295 — Transformers & Large Language Models, который хочется порекомендовать всем. Это отличный способ погрузиться в основы: преподаватели буквально на пальцах объясняют сложные концепции. Сначала показывают, какую проблему нужно решить, разбирают её на простом примере, а дальше уже переходят к формулам. Так гораздо легче понять, зачем в модели вообще появилась та или иная деталь. Ведут курс братья-близнецы Афшин и Шервин Амиди — преподаватели Stanford ICME в статусе Adjunct Professor. Оба учились в École Centrale Paris, затем Афшин — в MIT, а Шервин — в Stanford. В первой лекции они рассказывают и про свой индустриальный путь: Uber, Google, сейчас — Netflix. На сайте уже есть все девять лекций 2025 года, поэтому можно сразу пройти весь курс. А буквально неделю назад, 25 сентября, стартовал поток 2026 года. По словам преподавателей, содержание заметно изменится: за год появились новые подходы к обучению моделей, агентам и самой генерации текста. Программа уже показывает, куда пойдут эти изменения. Всего запланировано девять лекций, и маршрут получается довольно последовательный: 🔸 Устройство модели: токены, векторные представления, attention и Transformer. Затем — семейства LLM, контекст и способы выбирать следующий токен при генерации. 🔸 Обучение: от предварительного обучения до SFT и RLHF, LoRA, обучения с подкреплением и дистилляции. 🔸 Системы и агенты: как ускорять работу моделей, хранить промежуточные вычисления, подключать инструменты, организовывать память и управлять контекстом. 🔸 Оценка и новые направления: как проверять качество моделей и агентов, где ошибается LLM-as-a-judge, что происходит с диффузионными языковыми моделями и мультимодальностью. Кстати, в версии 2026 года системам LLM и обучению с подкреплением выделили отдельные занятия, добавили лекцию про диффузионные LLM, а в программе про агентов появились MCP, сжатие контекста, skills и plugins. Так что даже после прошлогодних записей здесь будет за чем следить. Подача доступная, хотя знакомство с линейной алгеброй, математическим анализом и базовыми понятиями машинного обучения пригодится. Формулы здесь есть, и в них стоит разбираться. На сайте доступны слайды и краткий конспект; домашних заданий у курса нет, зато есть два экзамена. В следующем посте разберу первую лекцию нового потока, запись которой вышла на этой неделе, 28 сентября. Там как раз собирают фундамент: от разбиения текста на токены до Transformer и сквозного примера перевода предложения. #AI #LLM #Learning #Engineering #Agents

Заходите на прямой эфир с Сергеем Киселевым, head of devplatform в MWS, где мы обсудим тему "Как инженер учится договариваться"