Книжный куб

Stanford CME295, лекция 2: что изменилось внутри Transformer (Рубрика #AI) Появилась запись второй лекции курса про трансформеры и LLM. Причем если в разборе первой лекции мы дошли от токенизации до Transformer из статьи 2017 года, то во второй Афшин и Шервин Амиди показывают, как из этой конструкции получаются современные LLM. И здесь уже интересно проверить себя: насколько хорошо за знакомыми аббревиатурами помнишь, а что они реально значат и почему они появились. За 1 час 43 минуты авторы разбирают семейства BERT и GPT, баланс размера модели и обучающих данных, изменения архитектуры и способы генерации. Я бы выделил несколько моментов. 🔸 MoE: большая модель не обязана использовать все веса для каждого токена. Вместо одного feed-forward блока ставят несколько «экспертов», а роутер выбирает, какие из них задействовать. Причём выбор делается для каждого токена. Но в этой схеме возникает занятная проблема с обучением таких моделей: эксперты, которых выбрали в начале обучения, получают больше обновлений, становятся лучше и выбираются ещё чаще. Остальные простаивают. Это routing collapse; в лекции объясняют, как дополнительный штраф за дисбаланс помогает распределять нагрузку. Хороший пример того, сколько работы скрывается за простой картинкой с роутером. 🔸 RoPE: зачем вообще вращать векторы? Здесь особенно хороша подача. Сначала позиционные представления объясняют через стрелки часов с разными частотами, потом доходят до поворотов query и key. В их скалярном произведении появляется зависимость от разницы позиций токенов. Так становится понятно, как порядок текста учитывается прямо в attention. Знать расшифровку RoPE (Rotary Position Embedding) и понимать, откуда взялся поворот, — довольно разные уровни знакомства с темой. 🔸 Attention приходится укладывать в память. При генерации ключи и значения предыдущих токенов можно сохранять и использовать повторно. Но чем длиннее текст, тем больше памяти нужно. Отсюда GQA (Grouped-Query Attention): несколько query-голов используют общие ключи и значения. Ещё один приём — sliding window attention, где каждый слой смотрит только на ближайшие токены. При этом через несколько слоёв информация доходит из-за границ одного окна. Преподаватели хорошо связывают это с рецептивным полем свёрточных сетей. 🔸 Даже temperature = 0 не обещает одинаковых ответов. После разных подходов к генерации токена в виде greedy decoding, beam search, top-k и top-p разбирают тонкость, которую легко пропустить. Сервер объединяет запросы в пакеты, и изменение размера пакета может менять порядок вычислений. У чисел с плавающей точкой результат сложения зависит от порядка операций; небольшие расхождения могут повлиять на выбор токена. Поэтому воспроизводимость зависит и от реализации инференса. Подробности есть в разборе Thinking Machines, на который ссылаются в лекции. 🔸 Корректный JSON можно обеспечить на этапе выбора токенов. Guided decoding ограничивает допустимые продолжения согласно нужному синтаксису. На каждом шаге модель выбирает среди разрешённых токенов. Это объясняет, что стоит за гарантией формата; правильность самих данных внутри JSON всё равно нужно проверять. В финале коротко проходят контекстное окно, context rot, обучение на примерах в промпте и техники рассуждения. Полезное напоминание: способность вместить длинный текст ещё не гарантирует, что модель надёжно использует каждую его часть. Даже если вы уже знаете, как работает LLM, запись стоит посмотреть ради этих связей. После неё удобно открыть схему знакомой модели и объяснить, зачем там MoE, RoPE или GQA, где экономят вычисления, где память и от чего зависит получившийся ответ. А объяснение RoPE вполне заслуживает отдельной паузы с карандашом. P.S. Я уже много раз читал статьи и разные книги на эту тему, но тут подача конечно хороша - можно вспомнить основы и получше уложить их в голове. #AI #LLM #Learning #Engineering #Architecture

Обновление по сегодняшнему прямому эфиру с Павлом Голубевым, Principal FDE Manager в Microsoft, а также автором канала @corporateAI: - Оказалось, что я промахнулся при назначении прямого эфира на Youtube - мы с Пашей договаривались на четверг, но я почему-то поставил эфир на среду. - Поэтому приходите завтра в 11:30 и все будеn. А пока можете посмотреть а что мы обсуждали год назад и как остановились в самом конце на переходе к схеме с FDE (forward deploy engineers), о которой будем разговаривать с Пашей завтра. Мои извинения тем, кто хотел посмотреть э

AI и платформа данных — материалы выпуска №37 Research Insights Made Simple (Рубрика #Data) Материалы выпуска #37 Research Insights Made Simple уже доступны. 12 октября 2026 года поговорили с Николаем Головым о том, как подключить AI ко всем данным организации и какую инженерную работу скрывает обещание «единой платформы». Дать агенту доступ к нескольким базам — ещё не значит получить согласованный ответ. Где-то данные приезжают с задержкой, где-то большой JOIN гоняет их между системами, а где-то удобство заканчивается на счёте за облако. Обсудили: - Четыре подхода из схемы Николая: классическое хранилище с подготовленными витринами, федеративные запросы, универсальную СУБД и общий слой хранения для разных движков. - Что остаётся за обещанием zero-ETL: копии, задержки, восстановление после сбоев и выбор таблиц, которые всё-таки придётся переносить. - Как эти подходы смешиваются у Microsoft, AWS, ClickHouse и Google и какие компромиссы возникают при совмещении транзакций и аналитики в Oracle и SAP HANA. - Куда движутся Databricks и Snowflake, объединяя аналитику с PostgreSQL. По оценке Николая, компоненты ещё собираются в общую систему — считать задачу решённой рано. - Почему открытый формат не освобождает от эксплуатации: частые небольшие записи в Iceberg, множество файлов и ограничения объектного хранилища никуда не исчезают. Материалы: - Страница выпуска с таймкодами - Видео: YouTube, VK Видео. - Аудио: Podster, Яндекс Музыка, [Apple Podcasts - Текстовый конспект разговора. Если уже подключаете агентов к корпоративным данным, расскажите, где упёрлись: в доступ к источникам, смысл показателей, свежесть или стоимость запросов? #Data #DataEngineering #Databases #Architecture #PlatformEngineering #AI

Материалы выпуска 3 AImigo S1E9: границы автономности (Рубрика #AI4SDLC) Собрал материалы девятого выпуска первого сезона 3 AImigo — «Что можно доверить AI-агенту? Границы автономности». 9 октября 2026 года мы с Евгением Сергеевым и Алексеем Литвиновым обсуждали, что именно делегируем агенту и сколько нашей работы остаётся за кадром, когда он вроде бы действует самостоятельно. Обсудили: 🔸 От действия до зоны ответственности Выполнить команду, решить задачу и отвечать за результат под ключ — разные договорённости. Для каждой нужны свои критерии, контекст и полномочия. 🔸 Почему быстрая генерация упирается в согласования Евгений рассказал об автоматизации выпуска контента во Flo Health. Если экспертные требования появляются только на последней проверке, ускорение подготовки ещё не ускоряет весь процесс. 🔸 Где заканчивается удачный эксперимент Перенос игры с iOS на Android через сравнение в эмуляторах и создание подкастовых обложек. По словам Евгения, агент перенёс игру примерно за пять часов без вмешательства. Но в этом опыте не было немедленной публикации в магазине и ответственности перед пользователями — это существенная граница примера. 🔸 Как пересматривать накопленные инструкции Алексей рассказал об экспериментах с их сокращением после обновления модели. Убирать лишнее полезно, если есть свои задачи и критерии, по которым видно, что качество сохранилось. 🔸 Какой контекст переживёт следующую сессию Причины архитектурных решений и ограничения нужно сохранять. При этом слишком подробная инструкция может заранее закрыть агенту пространство поиска. 🔸 Как посчитать реальную самостоятельность Подготовка правил, проверки, вмешательства, неудачные попытки и восстановление входят в стоимость принятой задачи. Часы работы агента сами по себе не показывают ни размер решённой задачи, ни пользу для человека. В финале поговорили о том, как это меняет работу инженеров и руководителей. Здесь у нас разные ожидания: устройство и масштаб организации пока слишком важны, чтобы обещать всем один сценарий. Материалы выпуска: 📌 Страница выпуска с таймкодами 📖 Лонгрид по теме выпуска 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект Расскажите в комментариях про задачу, которую уже отдаёте агенту целиком. На каком шаге вам всё-таки приходится возвращаться? #AI4SDLC #Agents #Engineering #Management #3AImigo

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

Factory: инженеры становятся менеджерами — а кто тогда остаётся инженером, способным проверить их исполнителей? (Рубрика #AI4SDLC) Название с обложки 18-минутного доклада Davis Palmie, инженера Factory, хорошо продолжает нашу тему dark factories. На AI Engineer World's Fair 2026 он описывает систему, которая превращает баг-репорты и обратную связь пользователей в production-код. Человек задаёт направление и управляет агентами. Звучит как повышение, но давайте посмотрим на должностную инструкцию:) 1️⃣ Управлять всей цепочкой Palmie считает, что написание кода давно не главное узкое место. Изменения ждут ревью, баги нужно воспроизвести, документация устаревает, продуктовые решения теряются между командами. Его software factory связывает эти этапы: сигнал → диагностика → план → код и тесты → ревью → выкладка → наблюдение за результатом. Обратная связь возвращается в следующий цикл. Это развитие factory model из The New SDLC: инженер строит систему, которая производит изменения. 2️⃣ Подготовить среду У Factory восемь направлений agent readiness: линтеры и форматирование, сборка, тесты, документация, воспроизводимые окружения, модульность, наблюдаемость и безопасность. Агенту нужны понятные команды, актуальные инструкции и доступ к контексту за пределами репозитория. Всё это полезно и людям. Плюс возможность выбирать модель под задачу и размещать исполнение в пределах своей инфраструктуры. 3️⃣ Включать автономность постепенно Начать с диагностики инцидента: агент читает alert из Sentry, собирает traces и отправляет вывод в Slack. Инженер проверяет и решает, что делать. Сначала каждый этап получает владельца и контроль, потом цепочка замыкается. Это рифмуется с нашим Loop Engineering: проверяющий должен уметь вовремя сказать «нет». И вот здесь обложка оказывается смелее содержания. Palmie прямо говорит, что точное исполнение не предотвращает плохой дизайн: архитектура, стратегия и допуск изменений по-прежнему требуют людей. Поэтому с докладом Dex Horthy у него больше общего, чем кажется. Dex описывал, как HumanLayer перестала следить за изменениями своей lights-off factory и во время инцидента столкнулась с кодом, который уже плохо понимала. Его аргумент: тесты проверяют «работает сейчас», а цена плохого проектирования проявляется через месяцы. Менеджерская часть работы действительно растёт: постановка, приоритеты, делегирование, обратная связь. Но как проверить решение, если перестал понимать систему? В доклада Geoffrey Litt это и есть новое узкое место: AI ускоряет изменения, а человеческая модель системы отстаёт. Назначить инженера проверяющим ещё не значит дать ему время разобраться. Метрики Palmie предлагает полезные: время от сигнала до production, число человеческих вмешательств, время восстановления, срок жизни кода и стоимость PR. Для меня число вмешательств требует оговорки: оно может падать и потому, что всё работает, и потому, что люди перестали проверять. Сопоставимое качество здесь обязательно. Но интересно, а что продаёт компания Factory? На сайте компании эта картина превращается в платформу: Droid для работы с кодом, автоматизации, маршрутизация моделей, Mission Control, ревью и обновляемая документация. Для организаций — интеграции и управление доступом. Компания продаёт инструменты, через которые можно организовать и контролировать работу агентов. В Missions это особенно видно: оркестратор разбивает цель на задачи, исполнители работают со свежим контекстом, отдельные агенты проверяют результат, состояние хранится в общих файлах. Роли и проверки становятся частью продукта. Так что «Engineers become managers» — ещё и объяснение, зачем покупать Factory: если теперь управляешь агентами, тебе предлагают рабочее место для этого управления. А способность оценить архитектуру и понять, что именно получилось, инженер приносит с собой. #AI4SDLC #AI #Agents #Engineering #Management #DevTools

Harness Engineering: знакомые идеи под одной обложкой (Рубрика #Books) У O’Reilly есть книга Nicole Koenigstein "Harness Engineering". Пока это early release, всего две главы, но я ей заинтересовался после наших разборов harness для Research Insights. У меня возник вопрос, а сколько нового даёт книга человеку, который уже читал исходные статьи? Мой предварительный ответ: большая часть концептуальной основы этих двух глав уже есть в материалах, которые мы обсуждали. Книга собирает её в последовательное объяснение устройства агентной системы. И качество этой сборки ещё предстоит оценить. Вот где идеи пересекаются: 🔸 Модель сама по себе ещё не рабочий агент В Research Insights #33 про SWE-agent мы разбирали, как инструменты, интерфейс и обратная связь меняют результат той же модели. Книга начинает с этого же общего тезиса и показывает его на разборе инцидента. 🔸 Контекст заканчивается, задача продолжается В #34 про долгоживущих агентов — список функций, журнал прогресса, git и передача работы следующей сессии. Во второй главе книги эта проблема получает более общий язык: состояние задачи должно переживать вызов модели и процесс. 🔸 Цикл должен уметь отклонить результат В разборе Loop Engineering мы уже проходили путь от промпта и контекста к обвязке, проверке и сохранению состояния. В книге модель предлагает откат сервиса, а код исполнения блокирует действие без разрешения. Просьба «соблюдай правила» превращается в проверяемое ограничение. 🔸 Инженер проектирует среду и обратную связь Это пересекается с кейсом OpenAI, который я разбирал для #35: знания доступны агенту, границы закреплены проверками, ошибки возвращаются в процесс. Это сопоставление идей. По двум главам я не могу установить, какие именно статьи использовала автор. Но читателю наших разборов знакомая основа будет хорошо видна. При этом у книги есть полезная добавка. Во второй главе отдельно разобраны checkpoint, история событий и записи внешних эффектов. Где продолжить работу, что произошло и какое действие нельзя случайно выполнить второй раз — три разных вопроса. Ещё есть разделение идентификатора задачи и права доступа к ней. Такая детализация делает обзор ближе к проектированию системы. А вот чего мне пока не хватает — проверки применимости рецептов. В своём лонгриде об эволюции harness я отдельно разбирал, как меняются его части вместе с моделью. В продолжении Anthropic автор убирает принудительные сбросы контекста и затем спринты по мере перехода к более сильным моделям. Права доступа остаются обязанностью системы; конкретная процедура планирования требует пересмотра. А в завтрашнем выпуске #38 с разбором "An Empirical Study of Harness Design for Coding Agents", о которой я уже писал, есть экспериментальный подход к оценке разных частей харнесса и как они влияют на итоговый результат. В книге пока преобладает перспектива улучшения обвязки при фиксированной модели. Отключение проверок на записанной последовательности ответов хорошо объясняет механизм, но ещё не измеряет выигрыш на реальных задачах. К тому же обещанные ноутбуки по присланной версии проверить нельзя: в начале глав сказано, что GitHub-репозиторий появится позже. Поэтому сейчас я вижу перспективную систематизацию знакомого материала. Если вы пропустили нашу серию, книга может дать удобный вход. Если следили за разборами, первые две главы скорее помогут разложить знания по полочкам. От следующих жду работающего кода, трудных случаев восстановления и объяснения, когда очередной элемент harness стоит усложнения системы. #Books #AI4SDLC #Agents #Architecture #Engineering #ResearchInsights

Материалы выпуска Research Insights #36: обвязка для долгой разработки (Рубрика #AI4SDLC) Доступны материалы сольного выпуска Research Insights Made Simple от 9 октября 2026 года — «Проектирование обвязки для длительной (автономной) разработки приложений». В нём разобрал инженерный пост Anthropic: как довести приложение до работающего результата, если исполнитель слишком легко соглашается, что уже всё готово. Кстати, сам paper я уже разбирал раньше В выпуске разобрал: 🔸 Зачем разделять создание и оценку Планировщик разворачивает запрос в спецификацию, генератор пишет приложение, оценщик проходит пользовательские сценарии. Но отдельного проверяющего тоже приходится учить замечать существенные проблемы. 🔸 Когда договариваться о готовности Контракт спринта задаёт объём и критерии приёмки до реализации. Для дизайна нужны ещё и понятные критерии качества с примерами: последняя итерация не обязательно лучшая. 🔸 Что дает дополнительный бюджет В примере Anthropic прямой запуск конструктора ретро-игр занял около 20 минут и стоил $9, но основные функции не работали. С обвязкой — 6 часов и $200, зато результат полнее. Бюджеты разные: это демонстрация возможностей, а не доказательство универсальной экономии. 🔸 Что делать после смены модели В описанном переходе к Opus 4.6 автор проверяет компоненты по одному и отказывается от спринтов. Пользу каждой роли и ограничения нужно измерять заново. 🔸 Чего оценщик не замечает В браузерной музыкальной студии он видит интерфейс, API и базу, но не слышит звук. Проверка кнопки Play ещё не говорит, что с музыкой всё хорошо. Отдельно обсудил границу упрощения: часть обвязки компенсирует слабости модели, а часть ограничивает риск её действий. Улучшение исполнителя само по себе не отменяет контроль полномочий. Материалы выпуска: 📌 Страница выпуска с таймкодами 📊 Слайды 📖 Лонгрид об эволюции агентных оболочек 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект #AI4SDLC #Agents #Evals #Engineering #ResearchInsights #RnD

Приходите на прямой эфир с Колей Головым про то, как добавить AI к дата-платформам

Meet Pi: The Minimalist, Self-Modifying Coding Agent (Рубрика #AI4SDLC) У кодинг-агентов есть неприятное свойство: инструмент обновился, а привычный рабочий процесс вокруг него вдруг поломадся. В 11-минутном фильме CultRepo создатель Pi Марио Цехнер объясняет, почему решил собрать своего агента. Его ставка — маленькое, понятное ядро, поведение которого можно контролировать, и расширения под конкретную работу. У этой позиции есть биография. Цехнер рассказывает о libGDX и RoboVM, о поглощениях и закрытии проекта. Армин Ронахер, второй собеседник фильма, связывает будущее Pi с открытой основой для инструментов. Поэтому разговор о минимализме здесь еще и про то, кому принадлежит управление собственным рабочим процессом. Техническое объяснение Цехнер начинает предельно просто: запрос к LLM → вызовы инструментов → исполнение → результаты обратно модели. Повторяем, пока модель не выдаст ответ без новых вызовов. В его описании Pi собран из четырех пакетов: 1) слой работы с моделями и провайдерами, включая перенос контекста и нормализацию ответов; 2) терминальный интерфейс; 3) ядро агентного цикла; 4) кодинг-агент, который соединяет предыдущие три. Дальше возникает самая интересная мысль: агент умеет писать код — значит, можно попросить его написать недостающую возможность для самого себя. Ронахер описывает именно такой опыт с расширениями и навыками. «Самомодификация» из названия фильма здесь означает создание программных дополнений и инструкций. Переобучение модели в этом механизме не описано. Мне в этом подходе интересен перенос сложности. Можно держать основу небольшой, а нужные возможности собирать вокруг нее. Но кто-то все равно должен понимать, как эти дополнения взаимодействуют. По документации Pi, расширения — исполняемые модули с правами процесса агента. Маленькое ядро само по себе не решает вопрос границ доступа. Цехнер дает и несколько громких ориентиров. По его словам, Shopify использует Pi примерно для 50% задач агентного кодинга, а на OpenRouter Pi занимает четвертое место, но в фильме нет деталей, чтобы подтвердить или опровергнуть эти заявления. Самая полезная часть начинается с 7:53. Цехнер критикует гонку за количеством агентов и потраченных токенов и требует читать код, понимать решения и отвечать за последствия. Ронахер добавляет очень узнаваемый сценарий: успел собрать и разослать что-то за 15 минут, но сам еще не попробовал. Скорость есть. Ценность пока предстоит доказать. Мне кажется, что Pi стоит рассматривать как ставку на инструмент, который можно приспособить к себе и разобраться в его устройстве. #AI4SDLC #AI #Agents #Architecture #Engineering #DevTools

Материалы выпуска Research Insights #35: среда для агентов (Рубрика #AI4SDLC) Собрал материалы сольного выпуска Research Insights Made Simple от 8 октября 2026 года — «Инженерия обвязки: среда для агентов». Разобрал опыт команды OpenAI, которая поручила Codex весь код внутреннего продукта и дальше описала это в статье "Harness engineering", которую я уже разбирал. В выпуске разобрал: 🔸 Что агенту нужно знать о проекте Решения из переписки и голов инженеров должны стать доступными исполнителю. Короткий AGENTS.md помогает найти архитектуру, планы и требования; огромная инструкция быстро устаревает. 🔸 Как дать агенту проверить собственную работу Отдельный экземпляр приложения, браузер, логи, метрики и трассы. Иначе пожелание «сделай быстрее» так и останется пожеланием. 🔸 Как превратить архитектуру в обратную связь Проверяемые границы модулей и линтеры, которые объясняют, что нарушено и как исправить. Внутри этих границ у агента остаётся свобода реализации. 🔸 Откуда берётся технический долг Агент копирует и удачные, и неудачные паттерны. Повторяющиеся замечания можно превращать в правила и небольшие фоновые исправления. 🔸 Чем измерять результат Принятые задачи, время людей, дефекты и стоимость прогонов. А в эпилоге — Symphony и переход от ручного управления сессиями к координации задач. Если читать оригинальную статью, то команда оценивает ускорение примерно в десять раз. Это оценка авторов для нового внутреннего продукта, без контрольной группы; она не доказывает такой же эффект в существующей системе. Переносить отдельные механизмы стоит с проверкой на своих задачах. Материалы выпуска: 📌 Страница выпуска с таймкодами 📊 Слайды 📖 Лонгрид об эволюции агентных оболочек 🎬 YouTube, VK Видео 🎧 Podster, Яндекс Музыка, Apple Podcasts 📝 Текстовый конспект Если вы уже перестраивали репозиторий под агентов, расскажите, где оказался главный пробел: в знаниях, инструментах или проверке результата? #AI4SDLC #Agents #Engineering #PlatformEngineering #ResearchInsights

Паша и папа (Рубрика #ForKids) Вместе с младшим сыном, Кириллом, прочитали эту книгу с зарисовками из жизни обычной семьи, где есть детсадовец Паша, а также мама и папа. Мне книга очень понравилась - в ней мама в отличие от других книг почти не присутствует и мы видим чисто мужские взаимоотношения достаточно самостоятельного Паши и его папы. Перед нами пролетают картины посещения цирка или уборки дома, игры в работу и путешествий, болезни папы и готовки праздничного кекса для мамы. В общем, читать эту книгу очень приятно, рекомендую. P.S. Я купил эту книгу, потому что у меня старшего сына зовут Пашей, но я с ним не проводил так много времени - когда он был примерно в том же возрасте, что герой этой книги, мы с Пашиной мамой разошлись и мой Паша остался жить со своей мамой. Теперь вот с Кириллом наверстываю упущенное, а Паша уже вырос и учится в универе:) #ForParents #ForKids #Family

FDE: кто отвечает за то, чтобы AI заработал у клиента | Code of Leadership с Павлом Голубевым (Рубрика #Management) 14 октября в прямом эфире Code of Leadership поговорим про Forward Deployed Engineering — работу инженеров, которые погружаются в задачи заказчика и доводят решение до работающего результата. В гостях — Павел Голубев, Principal AI FDE Manager в Microsoft, автор Telegram-канала Corporate AI. За его плечами — промышленный консалтинг, оптимизация цепочек поставок, Data Science в Beat и EPAM, проекты для клиентов Azure в Европе, на Ближнем Востоке и в Африке. Павел работал и руководителем, и инженером на Principal IC-треке, поэтому обсудим обе стороны: как самому внедрять AI и как руководить людьми, которые этим занимаются. В прошлом выпуске с Пашей мы уже добрались до темы FDE и договорились вернуться к разговору. Теперь хочется разобраться, что за это время изменилось в самой работе и ответственности инженера. У FDE интересная задача: отвечать за результат, когда данные, процессы, доступы и значительная часть решений находятся у других людей. Причём заказчик тоже не один человек: у руководителя, пользователя и службы безопасности могут быть совершенно разные представления об успешном внедрении. Написать код в такой ситуации — только часть работы. Обсудим: — Чем FDE отличается от консультанта, solution architect и инженера продуктовой команды? — Как выглядит путь от «хотим внедрить AI» до системы, которой действительно пользуются? — Как договориться о критериях успеха и удержать границы проекта, когда запросы продолжают расти? — Что AI меняет в стоимости внедрения и где по-прежнему приходится долго разбираться с людьми и процессами? — Как FDE Manager распределяет инженеров между проектами, проверяет качество и помогает в сложных ситуациях? — Кому подходит эта роль, какие навыки нужны для входа и когда компании вообще не нужен FDE? Попробуем пройти одно внедрение по шагам: от исходного запроса до запуска и дальнейшей поддержки. Поговорим о решениях, компромиссах и о том, кто отвечает за систему после ухода команды. Приходите, если внедряете AI, руководите инженерной командой или присматриваетесь к FDE как к следующему шагу в карьере. И приносите вопросы — оставим на них время в эфире! #Architecture #DistributedSystems #AI #AI4SDLC #Management #Leadership #Engineering

FDE: кто отвечает за то, чтобы AI заработал у клиента (Рубрика #Management) 14 октября в прямом эфире Code of Leadership поговорим про Forward Deployed Engineering — работу инженеров, которые погружаются в задачи заказчика и доводят решение до работающего результата. В гостях — Павел Голубев, Principal AI FDE Manager в Microsoft, автор Telegram-канала Corporate AI (https://t.me/corporateAI). За его плечами — промышленный консалтинг, оптимизация цепочек поставок, Data Science в Beat и EPAM, проекты для клиентов Azure в Европе, на Ближнем Востоке и в Африке. Павел работал и руководителем, и инженером на Principal IC-треке, поэтому обсудим обе стороны: как самому внедрять AI и как руководить людьми, которые этим занимаются. В прошлом выпуске с Павлом мы уже добрались до темы FDE и договорились вернуться к разговору. Теперь хочется разобраться, что за это время изменилось в самой работе и ответственности инженера. У FDE интересная задача: отвечать за результат, когда данные, процессы, доступы и значительная часть решений находятся у других людей. Причём заказчик тоже не один человек: у руководителя, пользователя и службы безопасности могут быть совершенно разные представления об успешном внедрении. Написать код в такой ситуации — только часть работы. Обсудим: — Чем FDE отличается от консультанта, solution architect и инженера продуктовой команды? — Как выглядит путь от «хотим внедрить AI» до системы, которой действительно пользуются? — Как договориться о критериях успеха и удержать границы проекта, когда запросы продолжают расти? — Что AI меняет в стоимости внедрения и где по-прежнему приходится долго разбираться с людьми и процессами? — Как FDE Manager распределяет инженеров между проектами, проверяет качество и помогает в сложных ситуациях? — Кому подходит эта роль, какие навыки нужны для входа и когда компании вообще не нужен FDE? Попробуем пройти одно внедрение по шагам: от исходного запроса до запуска и дальнейшей поддержки. Поговорим о решениях, компромиссах и о том, кто отвечает за систему после ухода команды. Приходите, если внедряете AI, руководите инженерной командой или присматриваетесь к FDE как к следующему шагу в карьере. И приносите вопросы — оставим на них время в эфире! P.S. Этот выпуск продолжит тему книжки про FDE, о которой я писал вчера. #AI4SDLC #Agents #Evals #Engineering #SystemDesign #Software

AI и платформа данных / Как подключить AI ко всей совокупности данных организации (Рубрика #Data) 12 октября в Research Insights Made Simple снова встречаемся с Колей Головым и в прямом эфире продолжаем разговор про платформы данных. В этот раз разберём, как объединить операционные базы, аналитику и AI-агентов и можно ли при этом избавиться от привычного зоопарка интеграций. На картинке всё выглядит заманчиво: оставляем PostgreSQL для транзакций, изменения из остальных систем отправляем через CDC в объектное хранилище, сверху ставим Lakehouse и подключаем агентов через MCP. Данные собраны, инструменты доступны, можно задавать вопросы. Правда, между «сложили всё в S3» и «агент правильно понял бизнес» ещё помещается довольно много инженерной работы :) Посмотрим, как к этой задаче подходят Databricks, Snowflake, ClickHouse, Microsoft Fabric, Google, AWS и Oracle. У кого-то объединение происходит на уровне хранения, у кого-то через репликацию и общие запросы, а кто-то собирает всё внутри одной СУБД. За похожими словами про единую платформу скрываются разные архитектуры и разные ограничения. Поговорим о том: - Где проходят границы между OLTP, аналитикой и агентным бэкендом; - Что на практике означают «одна копия данных» и zero-ETL; - Когда CDC и Lakehouse упрощают жизнь, а когда добавляют ещё одну систему, за которой надо следить; - Какую роль могут играть PostgreSQL, DuckLake и S3 в собственной платформе; - Что нужно агенту помимо доступа к таблицам: определения показателей, права, контекст и возможность проверить результат. Коля — Николай Голов, директор по продукту одной из датаплатформ, доступных на российском рынке. Раньше он руководил дата-платформами в Avito и ManyChat, преподаёт базы данных и системы хранения в Harbour.Space. Так что обсудим и устройство технологий, и практику построения платформ, которые потом кому-то поддерживать. Хочется понять, какую сложность эти подходы действительно убирают и какая просто переезжает в другое место. Выпуск будет полезен архитекторам, инженерам данных и руководителям, которые выбирают платформу или подключают AI к существующим данным. Приходите 12 октября и приносите свои вопросы и грабли. #Architecture #DistributedSystems #AI #AI4SDLC #Management #Leadership #Engineering

The Forward Deployed Engineer — Paden Gayle (Рубрика #Books) Paden Gayle начал писать книгу "The Forward Deployed Engineer" и на сайте O’Reilly сейчас доступны две главы: книга ещё пишется и выходит в формате Early Release. Но по этим главам у меня уже ощущение, что получится хорошая книга. Особенно понравились части про ответственность и согласование позиций разных стейкхолдеров. FDE (Forward Deployed Engineer) — инженер, которого поставщик технологии встраивает в работу компании-заказчика. Он выясняет, какую проблему нужно решить, договаривается об объёме работ, строит систему и доводит её до production. Автор сравнивает эту роль с основателем внутри чужой компании. Масштаб ответственности похожий, а вот данные, инфраструктура, правила безопасности и люди принадлежат заказчику. Мне понравилась точность этого противоречия: отвечать за результат приходится в среде, которой ты не управляешь. Если для запуска нужен доступ, согласование или решение другого человека, твоя работа — найти этого человека и довести вопрос до решения. Лично выполнять всё при этом совершенно необязательно. А дальше начинается интересное: у «заказчика» оказывается несколько несовпадающих представлений об успехе. - Тому, кто выделил бюджет, нужен экономический эффект. - Руководителю процесса — понятные изменения и работающая команда. - IT и безопасности — контролируемые доступы, данные и последствия ошибок. - Пользователям — чтобы исчезла конкретная ручная возня. - Внутреннему инициатору проекта — результат, за который он уже поручился перед коллегами. В книге есть хороший приём: описать одно и то же решение на языке каждого из них, причём все описания должны быть правдой. Если одному обещаем работу без участия человека, а другому — обязательное подтверждение каждого шага, проблема уже в устройстве решения. Усреднить пожелания или выполнить просьбу самого громкого человека тут недостаточно. И ответственность вполне совместима с границами. Автор подробно разбирает, как фиксировать объём работ, исключения, обязанности заказчика и проверяемые критерии готовности. Например, в книге есть такой критерий: пятничная выгрузка, занимавшая четыре часа вручную, автоматически появляется в общей папке к девяти. Сразу понятно, что принимать и кто может это проверить. Отдельно интересна экономика этой позиции. Почему на неё есть спрос? Заказчику нужен работающий процесс в его системах, с его данными и ограничениями. По мысли автора, AI удешевляет написание кода, а выбор правильной задачи, согласования и ответственность остаются сложными. Когда реализация ускоряется, эти вопросы становятся ещё заметнее. Вдобавок теперь дешевле быстро построить и совершенно ненужную штуку :) Откуда предложение? Для поставщика AI такой инженер помогает превратить возможности продукта в результат, ради которого клиент продолжит платить. По логике книги, с кодинг-агентами один инженер может брать работу, раньше требовавшую небольшой команды: индивидуальное внедрение становится экономически доступнее. Это уже оформляется в отдельные направления бизнеса: AWS объявила о вложении $1 млрд в FDE. Со стороны инженера я вижу привлекательность в самостоятельности, прямой обратной связи от пользователей и возможности влиять на весь путь от задачи до результата. Цена такой самостоятельности — переговоры, неопределённость и чужие ограничения. Совместить сильную инженерию с умением держать этот контекст непросто. Пока это рекомендация первых двух глав. Но уже сейчас книга выглядит полезной и для техлидов, и для инженеров, которым приходится договариваться о том, что вообще стоит строить. За продолжением хочется следить. Теги: #Books #AI #Engineering #Management #Product

YC Paper Club: что дальше после LLM + GPU? (Рубрика #AI) Интересное видео для тех, кто хочет узнать, а что там дальше после LLM + GPU :) В YC Paper Club собрали разговор про вычисления на свете, нейроморфные чипы и живые нейроны. У четырёх участников складывается общая рамка: следующий скачок эффективности ИИ может потребовать одновременно другого железа, другой архитектуры моделей и другого способа обучения. 1️⃣ François Chaubard, ведущий из Focal Systems, начинает с того, что GPU, backpropagation и современные модели развивались вместе. Поэтому алгоритм, который плохо выглядит на GPU, может оказаться интересным при другой стоимости операций. Он исследует обучение без обратного прохода: немного меняем веса в случайном направлении, сравниваем результаты и решаем, куда двигаться. Для больших моделей таких проб нужно слишком много. Его подход SOMA — разбить модель на небольших экспертов, чтобы уменьшить шум оценки. А дальше возникает ставка: если прямые проходы станут очень дешёвыми, например в оптике, экономика такого обучения изменится. Прогноз Chaubard об отказе от backpropagation через десять лет стоит воспринимать именно как исследовательскую ставку. 2️⃣ Ilker Oguz, исследователь оптических вычислений из EPFL, теперь постдок в Stanford, показывает, где эта идея встречается с физикой. Свет проходит через оптические элементы и выполняет нужное преобразование. Но вокруг него остаются память, калибровка, нелинейные операции и преобразования электрических сигналов в оптические и обратно. На них выигрыш может закончиться. В его эксперименте с диффузионной генерацией изображений алгоритм подстроили под оптику: одни и те же веса многократно используются на последовательных шагах. Так ограничение устройства становится принципом построения алгоритма. Пока демонстрация ограничена MNIST и Fashion-MNIST, а расчёт экономии энергии предполагает пассивные фиксированные элементы; прототип использует программируемый модулятор. 3️⃣ Alok Vasudev, инженер по образованию и партнёр венчурной фирмы Standard, добавляет полезный скепсис к попыткам скопировать мозг. Его устройство и способы обработки информации эволюционировали вместе. Перенос отдельного механизма на кремний ещё не переносит его эффективность. По его оценке, ближе к практике решения, которые сближают память и вычисления, сокращая перемещение данных. А более буквальное воспроизведение работы мозга остаётся исследовательским направлением. Здесь хороший вопрос к любому нейроморфному проекту: какое конкретное ограничение помогает снять сходство с биологией? 4️⃣ Sean Cole, автор алгоритмов эксперимента с Cortical Labs, доводит эту историю до живых клеток, управляющих Doom. Цифровой кодировщик превращает состояние игры в электрическую стимуляцию, клетки отвечают импульсами, декодер переводит их в действия. И тут самая интересная деталь. По словам Cole, ранний декодер получился настолько мощным, что мог играть даже при обнулённых сигналах от клеток. Команда уменьшила его до простого линейного считывания и провела проверки, чтобы убедиться, что сигналы нейронов действительно нужны для результата. Иначе можно получить впечатляющую демонстрацию, в которой всю полезную работу выполняет обычный компьютер. Итого: это интересное видео про исследования, что не относятся к текущему мейнстриму, но у которых интересные перспективы. #AI #Hardware #Research #Engineering