[1/2] The New SDLC: от vibe coding к agentic engineering (Рубрика #AI4SDLC)
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые ментальные модели: инструменты меняются каждую неделю, а рамка должна пережить эту смену. Разбор не поместился в один пост, поэтому их будет два:)
Авторы формулируют главный тезис как глубокий сдвиг в инженерии — не новый язык или фреймворк, а переход от написания кода к выражению намерения, когда система переводит это намерение в работающий софт. Десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь таким интерфейсом стало намерение. По данным whitepaper (на начало 2026), 85% профессиональных разработчиков регулярно используют AI-агентов, 51% — ежедневно, а около 41% нового кода уже сгенерировано AI. Цифры стоит читать как индустриальную оценку, но направление оспорить трудно.
Дальше авторы делают важную вещь — разводят два затёртых термина. Vibe coding (термин Карпатого, февраль 2025) — это когда ты «отдаёшься вайбу», описываешь желаемое на естественном языке и принимаешь, что выдал AI, а при ошибке просто копируешь её обратно в промпт. Agentic engineering — дисциплинированный конец того же спектра, где AI пишет реализацию внутри тщательно спроектированных ограничений, тестов и feedback loops, а человек держит ответственность за архитектуру, корректность и качество.
Ключевая мысль: разница не в том, используешь ли ты AI. Разница в том, сколько структуры и верификации окружает его вывод. Сказать техдиру, что «мы vibe-кодим платёжную систему» — повод для тревоги. Сказать «мы практикуем agentic engineering, где AI реализует под human-designed ограничениями, а покрытие тестами гарантирует корректность» — совсем другой разговор.
Главным различием здесь является верификация. В agentic engineering работают два механизма верификации
- Тесты проверяют детерминированную часть: на этот вход функция даёт такой выход
- Evals проверяют недетерминированную: выбрал ли агент правильную траекторию шагов, те ли инструменты, ту ли финальную планку качества
Без обоих это всегда vibe coding, как бы красиво ни были написаны промпты.
Отдельная часть документа посвящена тому, что context engineering - это настоящий инженерный навык. Качество AI-кода зависит не от хитрости промпта, а от качества контекста. Авторы выделяют шесть типов (instructions, knowledge, memory, examples, tools, guardrails) и разводят контексты на два вида
- Static context (всегда загружен, дорогой по токенам)
- Dynamic context (по требованию, дешевле)
Сам сдвиг от «prompt engineering» к «context engineering» отражает простую правду: вопрос не «как обмануть AI, чтобы он написал хороший код», а «что нужно знать новому члену команды, чтобы сделать работу хорошо, и как закодировать это знание в форму, понятную AI».
Авторы отметили, что AI сжимает SDLC неравномерно: реализация ужимается с недель до часов, но требования, архитектура и верификация остаются human-paced. Спецификация становится новым узким местом. Авторы не прячут неудобный факт: при заявленном опросами росте продуктивности на 25–39% исследование METR показало, что опытные разработчики на ряде задач тратили на 19% больше времени — из-за верификации и отладки AI-вывода. AI не убирает работу реализации, а превращает её из «писать» в «проверять и направлять».
В следующей части мы поговорим про то, что окружает модель: harness (Agent = Model + Harness), модель фабрики производства фичей, роли conductor/orchestrator и экономику agentic engineering.
P.S.
Примерно эти мысли я раскрывал в своем докладе "State of AI4SDLC" на AI Dev Conf. Там была цепочка intent → context → plan → tasks → implementation → verification ровно про то, что ускорение кодинга не ускоряет разработку целиком, а перевешивает нагрузку выше по процессу.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые ментальные модели: инструменты меняются каждую неделю, а рамка должна пережить эту смену. Разбор не поместился в один пост, поэтому их будет два:)
Авторы формулируют главный тезис как глубокий сдвиг в инженерии — не новый язык или фреймворк, а переход от написания кода к выражению намерения, когда система переводит это намерение в работающий софт. Десятилетиями интерфейсом разработчика с машиной был синтаксис, а теперь таким интерфейсом стало намерение. По данным whitepaper (на начало 2026), 85% профессиональных разработчиков регулярно используют AI-агентов, 51% — ежедневно, а около 41% нового кода уже сгенерировано AI. Цифры стоит читать как индустриальную оценку, но направление оспорить трудно.
Дальше авторы делают важную вещь — разводят два затёртых термина. Vibe coding (термин Карпатого, февраль 2025) — это когда ты «отдаёшься вайбу», описываешь желаемое на естественном языке и принимаешь, что выдал AI, а при ошибке просто копируешь её обратно в промпт. Agentic engineering — дисциплинированный конец того же спектра, где AI пишет реализацию внутри тщательно спроектированных ограничений, тестов и feedback loops, а человек держит ответственность за архитектуру, корректность и качество.
Ключевая мысль: разница не в том, используешь ли ты AI. Разница в том, сколько структуры и верификации окружает его вывод. Сказать техдиру, что «мы vibe-кодим платёжную систему» — повод для тревоги. Сказать «мы практикуем agentic engineering, где AI реализует под human-designed ограничениями, а покрытие тестами гарантирует корректность» — совсем другой разговор.
Главным различием здесь является верификация. В agentic engineering работают два механизма верификации
- Тесты проверяют детерминированную часть: на этот вход функция даёт такой выход
- Evals проверяют недетерминированную: выбрал ли агент правильную траекторию шагов, те ли инструменты, ту ли финальную планку качества
Без обоих это всегда vibe coding, как бы красиво ни были написаны промпты.
Отдельная часть документа посвящена тому, что context engineering - это настоящий инженерный навык. Качество AI-кода зависит не от хитрости промпта, а от качества контекста. Авторы выделяют шесть типов (instructions, knowledge, memory, examples, tools, guardrails) и разводят контексты на два вида
- Static context (всегда загружен, дорогой по токенам)
- Dynamic context (по требованию, дешевле)
Сам сдвиг от «prompt engineering» к «context engineering» отражает простую правду: вопрос не «как обмануть AI, чтобы он написал хороший код», а «что нужно знать новому члену команды, чтобы сделать работу хорошо, и как закодировать это знание в форму, понятную AI».
Авторы отметили, что AI сжимает SDLC неравномерно: реализация ужимается с недель до часов, но требования, архитектура и верификация остаются human-paced. Спецификация становится новым узким местом. Авторы не прячут неудобный факт: при заявленном опросами росте продуктивности на 25–39% исследование METR показало, что опытные разработчики на ряде задач тратили на 19% больше времени — из-за верификации и отладки AI-вывода. AI не убирает работу реализации, а превращает её из «писать» в «проверять и направлять».
В следующей части мы поговорим про то, что окружает модель: harness (Agent = Model + Harness), модель фабрики производства фичей, роли conductor/orchestrator и экономику agentic engineering.
P.S.
Примерно эти мысли я раскрывал в своем докладе "State of AI4SDLC" на AI Dev Conf. Там была цепочка intent → context → plan → tasks → implementation → verification ровно про то, что ускорение кодинга не ускоряет разработку целиком, а перевешивает нагрузку выше по процессу.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
❤12👍12🔥5🤣1
[2/2] The New SDLC: harness, factory model и экономика agentic engineering (Рубрика #AI4SDLC)
Продолжаю разбор майского whitepaper от Google, где в первой части мы обсуждали сдвиг от синтаксиса к намерению, и дальше спектр vibe coding → agentic engineering и context engineering. Теперь мы поговорим про то, что окружает модель и превращает её в работающего агента.
Любимая формула документа: Agent = Model + Harness. Когда начинаешь работать с агентами, есть соблазн считать систему моделью: вышла новая модель — агент поумнел, старая — поглупел. Авторы говорят, что это неверный взгляд, ведущий к неверным инвестициям. Модель — лишь один вход. Всё остальное — промпты, инструменты, политики контекста, hooks, sandboxes, суб-агенты, observability — это harness, обвязка вокруг модели, которая и даёт ей довести дело до конца. По их оценке, модель — это примерно 10%, harness — примерно 90% того, что вы ощущаете, работая с Claude Code, Cursor, Codex или Gemini CLI.
Доказательства не риторические. На бенчмарке Terminal Bench 2.0 одна команда подняла coding-агента из-за пределов топ-30 в топ-5, поменяв только harness, без смены модели. Отдельное исследование LangChain подняло score на 13.7 балла, твикая лишь system prompt, инструменты и middleware вокруг фиксированной модели. Вывод, который стоит повесить на стену: большинство сбоев агента, если разобраться честно, — это сбои конфигурации, а не модели.
Из этого вырастает factory model. Главный продукт разработчика — уже не код, а система, которая код производит: спецификации и контекст, агенты-исполнители, тесты и quality gates, feedback loops, возвращающие ошибки агенту, и guardrails. Менеджер завода не точит каждую деталь руками — он проектирует конвейер и контроль качества. Современный разработчик задаёт агентам критерии успеха, а не пошаговую инструкцию, и даёт им итерироваться.
Роль разработчика при этом раздваивается
1️⃣ Conductor — реальное время, в IDE, контроль на уровне нажатий клавиш; хорош для исследования, прототипа, изучения нового API
2️⃣ Orchestrator — асинхронно, на уровне целей, делегирование нескольким агентам, ревью результата, а не каждой строки; хорош для фич, миграций, генерации тестов.
Большинство переключается между режимами в течение дня.
Отдельно — «проблема 80%». Агент быстро генерирует около 80% кода фичи, но оставшиеся 20% (edge cases, обработка ошибок, точки интеграции, тонкая корректность) требуют глубокого контекста, которого моделям часто не хватает. Природа ошибок изменилась: от синтаксических к концептуальным — неверные предположения о бизнес-логике, пропущенные edge cases. Их труднее заметить именно потому, что код «выглядит правильно» и проходит базовые тесты.
Авторы интересно рассматривают экономику. Для лидера важнее velocity total cost of ownership. Vibe coding выглядит дёшево (низкий CapEx), но прячет высокий OpEx: token burn, постоянные циклы переспрашивания, maintenance-налог на «спагетти», security-латание. По оценке авторов, в точке пересечения vibe coding обходится в 3–10× дороже за фичу. Agentic engineering переворачивает модель: высокий CapEx (спеки, тесты, структурирование контекста) и низкий маржинальный OpEx. Context engineering и intelligent model routing (большие модели — на сложное, дешёвые — на детерминированное) становятся прямыми финансовыми рычагами.
Практическая часть «с чего начать» разложена по трём уровням
1️⃣ Разработчику: завести AGENTS.md, поставить набор skills, сделать первый агент из повторяющегося workflow, писать tests и evals до генерации кода, ревьюить каждую строку, что идёт в прод.
2️⃣ Лидеру: сделать context engineering полноценной практикой (AGENTS.md, промпты, evals, skills — как код, под ревью и версионированием) и ставить планку на eval, а не на демо.
3️⃣ Организации: вкладываться в production substrate до масштаба, принимать открытые стандарты (MCP, A2A), планировать гибридные команды человек+агент.
Вывод документа называется «Intent as the new Interface», и три принципа в нём:
1️⃣ Structure scales, vibes don't
2️⃣ AI усиливает вашу инженерную культуру — множит и сильные, и слабые стороны
3️⃣ Роль человека эволюционирует, а не исчезает
Финальная фраза
Для меня это ровно та логика, которую я разбирал в статье про agent-first IDP: Agent = Model + Harness, evals как контур качества, production substrate до масштаба — те же идеи, но на уровне платформы. Главный вывод обоих текстов один: дисциплина (specs, tests, evals, harness) — не противоположность скорости, а её условие.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Продолжаю разбор майского whitepaper от Google, где в первой части мы обсуждали сдвиг от синтаксиса к намерению, и дальше спектр vibe coding → agentic engineering и context engineering. Теперь мы поговорим про то, что окружает модель и превращает её в работающего агента.
Любимая формула документа: Agent = Model + Harness. Когда начинаешь работать с агентами, есть соблазн считать систему моделью: вышла новая модель — агент поумнел, старая — поглупел. Авторы говорят, что это неверный взгляд, ведущий к неверным инвестициям. Модель — лишь один вход. Всё остальное — промпты, инструменты, политики контекста, hooks, sandboxes, суб-агенты, observability — это harness, обвязка вокруг модели, которая и даёт ей довести дело до конца. По их оценке, модель — это примерно 10%, harness — примерно 90% того, что вы ощущаете, работая с Claude Code, Cursor, Codex или Gemini CLI.
Доказательства не риторические. На бенчмарке Terminal Bench 2.0 одна команда подняла coding-агента из-за пределов топ-30 в топ-5, поменяв только harness, без смены модели. Отдельное исследование LangChain подняло score на 13.7 балла, твикая лишь system prompt, инструменты и middleware вокруг фиксированной модели. Вывод, который стоит повесить на стену: большинство сбоев агента, если разобраться честно, — это сбои конфигурации, а не модели.
Из этого вырастает factory model. Главный продукт разработчика — уже не код, а система, которая код производит: спецификации и контекст, агенты-исполнители, тесты и quality gates, feedback loops, возвращающие ошибки агенту, и guardrails. Менеджер завода не точит каждую деталь руками — он проектирует конвейер и контроль качества. Современный разработчик задаёт агентам критерии успеха, а не пошаговую инструкцию, и даёт им итерироваться.
Роль разработчика при этом раздваивается
1️⃣ Conductor — реальное время, в IDE, контроль на уровне нажатий клавиш; хорош для исследования, прототипа, изучения нового API
2️⃣ Orchestrator — асинхронно, на уровне целей, делегирование нескольким агентам, ревью результата, а не каждой строки; хорош для фич, миграций, генерации тестов.
Большинство переключается между режимами в течение дня.
Отдельно — «проблема 80%». Агент быстро генерирует около 80% кода фичи, но оставшиеся 20% (edge cases, обработка ошибок, точки интеграции, тонкая корректность) требуют глубокого контекста, которого моделям часто не хватает. Природа ошибок изменилась: от синтаксических к концептуальным — неверные предположения о бизнес-логике, пропущенные edge cases. Их труднее заметить именно потому, что код «выглядит правильно» и проходит базовые тесты.
Авторы интересно рассматривают экономику. Для лидера важнее velocity total cost of ownership. Vibe coding выглядит дёшево (низкий CapEx), но прячет высокий OpEx: token burn, постоянные циклы переспрашивания, maintenance-налог на «спагетти», security-латание. По оценке авторов, в точке пересечения vibe coding обходится в 3–10× дороже за фичу. Agentic engineering переворачивает модель: высокий CapEx (спеки, тесты, структурирование контекста) и низкий маржинальный OpEx. Context engineering и intelligent model routing (большие модели — на сложное, дешёвые — на детерминированное) становятся прямыми финансовыми рычагами.
Практическая часть «с чего начать» разложена по трём уровням
1️⃣ Разработчику: завести AGENTS.md, поставить набор skills, сделать первый агент из повторяющегося workflow, писать tests и evals до генерации кода, ревьюить каждую строку, что идёт в прод.
2️⃣ Лидеру: сделать context engineering полноценной практикой (AGENTS.md, промпты, evals, skills — как код, под ревью и версионированием) и ставить планку на eval, а не на демо.
3️⃣ Организации: вкладываться в production substrate до масштаба, принимать открытые стандарты (MCP, A2A), планировать гибридные команды человек+агент.
Вывод документа называется «Intent as the new Interface», и три принципа в нём:
1️⃣ Structure scales, vibes don't
2️⃣ AI усиливает вашу инженерную культуру — множит и сильные, и слабые стороны
3️⃣ Роль человека эволюционирует, а не исчезает
Финальная фраза
Generation is solved. Verification, judgment, and direction are the new craft
Для меня это ровно та логика, которую я разбирал в статье про agent-first IDP: Agent = Model + Harness, evals как контур качества, production substrate до масштаба — те же идеи, но на уровне платформы. Главный вывод обоих текстов один: дисциплина (specs, tests, evals, harness) — не противоположность скорости, а её условие.
#AI #AI4SDLC #VibeCoding #Engineering #Architecture #Management
Telegram
Книжный куб
[1/2] The New SDLC: от vibe coding к agentic engineering (Рубрика #AI4SDLC)
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые…
Прочитал майский whitepaper от Addy Osmani, Shubham Saboo и Sokratis Kartakis из учебной серии Google по AI-агентам. Документ полезен не модными терминами, а тем, что собирает устойчивые…
❤13👍5🔥5
DORA ROI: как посчитать эффект AI-assisted разработки без магии (Рубрика #AI4SDLC)
Разбирался с новым отчетом DORA и Google Cloud `The ROI of AI-assisted Software Development`. Он хорошо продолжает прошлый DORA 2025 "State of AI-assisted Software Development", который я разбирал: там главным было, что AI работает как усилитель инженерной системы, а эффект зависит от семи возможностей (что я тоже разбирал отдельно). Основная мысль прошлого отчета была о том, что сильные команды от AI получают больше скорости, слабые - больше хаоса. А новый отчет предлагает оценивать изменения инженерной системы не только инженерными метриками но и на языке бизнес-кейса, бюджета и CFO.
Главная идея отчета простая: возврат инвестиций (ROI) от AI-assisted разработки нельзя считать упрощенно в виде: "купили лицензии, получили экономию". Авторы предлагают смотреть на всю систему поставки софта. Формула стандартная:
Ценность (value) они оценивают по трем компонентам.
1️⃣ Высвобожденная инженерная емкость
Важно: DORA прямо не советует превращать это в стратегию сокращения людей. Логика другая: если AI экономит разработчику часть времени, это не "минус разработчик", а
2️⃣ Дополнительная выручка от более быстрой поставки успешных фич (тех, что улучшают продуктовые метрики)
Тут авторы осторожны: не каждая фича приносит деньги, поэтому в калькуляторе есть idea success rate и консервативная оценка revenue impact.
3️⃣ Эффект стабильности: downtime, change failure rate и время восстановления после неудачного деплоя
Здесь появляется неприятная часть модели. AI может увеличить пропускную способность, но если вместе с ним растет частота сбоев (change fail rate, CFR), то часть экономического эффекта съедается. В демонстрационном калькуляторе DORA этот блок даже дает отрицательный вклад.
Затратаы авторы тоже раскладывают на отдельные компоненты
- Авторы считают прямые затраты: подписки, API/token costs, инфраструктуру, обучение и change management
- А сверху добавляют
J-curve - это полезная концепция в этом отчете, про которую часто забывают менеджеры. Сначала команда тратит время на обучение (learning curve), потом платит
Дальше авторы рисуют некоторый план того, как внедрять AI.
1️⃣ Сначала нужен context layer
Качественная Internal Developer Platform, нормальная документация, healthy data ecosystems, машинно-читаемые стандарты и понятные API
2️⃣ Потом - human-in-the-loop
Доверие к AI, context engineering, обучение людей проверять и направлять агентов
3️⃣ И только после этого имеет смысл смотреть на leading indicators
Авторы рекомендую стандартные метрики DORA (вот тут я рассказывал как фреймворк в 2026 году прирос пятой метрикой). И дополнительно метрику experiment frequency, которую они трактуют почти как финансовый: AI удешевляет стоимость маленьких продуктовых экспериментов (которые они сравнивают с финансовыми опционами). Можно быстрее собрать несколько вариантов, проверить их на пользователях и не вкладываться рано в большую, но непроверенную идею.
Итого: новый DORA ROI report полезен переходом с инженерного языка на язык бизнеса. Здесь мы не просто "внедряем AI в разработку", а меняем инженерную систему, считаем verification tax, следим за instability tax и понимаем, куда реинвестировать высвобожденную емкость.
#AI #AI4SDLC #Engineering #DevOps #Management #Metrics
Разбирался с новым отчетом DORA и Google Cloud `The ROI of AI-assisted Software Development`. Он хорошо продолжает прошлый DORA 2025 "State of AI-assisted Software Development", который я разбирал: там главным было, что AI работает как усилитель инженерной системы, а эффект зависит от семи возможностей (что я тоже разбирал отдельно). Основная мысль прошлого отчета была о том, что сильные команды от AI получают больше скорости, слабые - больше хаоса. А новый отчет предлагает оценивать изменения инженерной системы не только инженерными метриками но и на языке бизнес-кейса, бюджета и CFO.
Главная идея отчета простая: возврат инвестиций (ROI) от AI-assisted разработки нельзя считать упрощенно в виде: "купили лицензии, получили экономию". Авторы предлагают смотреть на всю систему поставки софта. Формула стандартная:
ROI = (Value - Investment) / Investment. Но интереснее то, как они предлагают считать value и investment (кстати, авторы даже выдают калькулятор, где вы сможете попробовать все эти расчеты примерить на себя).Ценность (value) они оценивают по трем компонентам.
1️⃣ Высвобожденная инженерная емкость
Важно: DORA прямо не советует превращать это в стратегию сокращения людей. Логика другая: если AI экономит разработчику часть времени, это не "минус разработчик", а
headcount reinvestment capacity - емкость, которую можно перекинуть в новые фичи, улучшение продукта, снижение долга и инновации.2️⃣ Дополнительная выручка от более быстрой поставки успешных фич (тех, что улучшают продуктовые метрики)
Тут авторы осторожны: не каждая фича приносит деньги, поэтому в калькуляторе есть idea success rate и консервативная оценка revenue impact.
3️⃣ Эффект стабильности: downtime, change failure rate и время восстановления после неудачного деплоя
Здесь появляется неприятная часть модели. AI может увеличить пропускную способность, но если вместе с ним растет частота сбоев (change fail rate, CFR), то часть экономического эффекта съедается. В демонстрационном калькуляторе DORA этот блок даже дает отрицательный вклад.
Затратаы авторы тоже раскладывают на отдельные компоненты
- Авторы считают прямые затраты: подписки, API/token costs, инфраструктуру, обучение и change management
- А сверху добавляют
J-curve cost - стоимость временной просадки на этапе внедрения.J-curve - это полезная концепция в этом отчете, про которую часто забывают менеджеры. Сначала команда тратит время на обучение (learning curve), потом платит
verification tax - налог на проверку AI-вывода, потом перестраивает pipeline, review, тестирование и правила поставки. Первая реакция системы может быть не "мы ускорились", а "у нас стало больше кода, больше ревью и больше шума". По DORA, это не обязательно провал инструмента - это цена трансформации, если ее заранее заложили в бюджет и метрики.Дальше авторы рисуют некоторый план того, как внедрять AI.
1️⃣ Сначала нужен context layer
Качественная Internal Developer Platform, нормальная документация, healthy data ecosystems, машинно-читаемые стандарты и понятные API
2️⃣ Потом - human-in-the-loop
Доверие к AI, context engineering, обучение людей проверять и направлять агентов
3️⃣ И только после этого имеет смысл смотреть на leading indicators
Авторы рекомендую стандартные метрики DORA (вот тут я рассказывал как фреймворк в 2026 году прирос пятой метрикой). И дополнительно метрику experiment frequency, которую они трактуют почти как финансовый: AI удешевляет стоимость маленьких продуктовых экспериментов (которые они сравнивают с финансовыми опционами). Можно быстрее собрать несколько вариантов, проверить их на пользователях и не вкладываться рано в большую, но непроверенную идею.
Итого: новый DORA ROI report полезен переходом с инженерного языка на язык бизнеса. Здесь мы не просто "внедряем AI в разработку", а меняем инженерную систему, считаем verification tax, следим за instability tax и понимаем, куда реинвестировать высвобожденную емкость.
#AI #AI4SDLC #Engineering #DevOps #Management #Metrics
❤7👍6🔥3
State of AI4SDLC на HighLoad++: материалы к докладу (Рубрика #AI4SDLC)
Сегодня выступил на Saint HighLoad++ 2026 с докладом “State of AI4SDLC: как AI меняет процессы разработки в крупных компаниях”. Главная мысль у меня была про то, что AI4SDLC сейчас это про перестройку инженерной системы: платформу, процессы, метрики, безопасность, экономику и саму роль инженера.
1️⃣ В первой части я показывал, что внедрение AI уже случилось, но доверие и командный эффект за ним не успевают. Кодинг ускоряется быстрее, чем поставка изменений (delivery), поэтому старые узкие места просто становятся заметнее: постановка задач, ревью, тесты, CI/CD, безопасность, релизы и работа с контекстом.
2️⃣ Во второй части разбирал, как это выглядит на масштабе крупного финтеха на 10 000+ инженеров. Тут уже не работает логика “разрешим всем хороший AI-редактор”. Нужна платформа, рассчитанная на агентов (agent-first): модельный шлюз, инструментальный MCP-шлюз, реестр возможностей, уровни доверия read -> recommend -> act, проверки качества (evals), телеметрия и модель угроз.
3️⃣ Дальше я показывал, какие блоки уже появляются в реальной инженерной среде: единый доступ к моделям, управляемый доступ агентов к внутренним инструментам, внутренний ассистент с контекстом компании, агентный режим (agent mode) на платформе разработки и доменные агенты по всему SDLC: тестирование, ревью, дизайн, безопасность, эксплуатация, миграции, data/DS и инфраструктура.
4️⃣ Отдельный был был про измерения. Считать долю AI-кода почти бесполезно: эту метрику легко раздуть, и она плохо отвечает на вопрос, стала ли инженерная система сильнее. Смотреть нужно на цепочку
Основной вывод в том, что выигрывает не команда, у которой самый модный инструмент, а команда, которая умеет превращать AI в управляемую производственную систему. С понятным базовым уровнем (baseline), владельцами, контекстом, ограничениями, проверками, наблюдаемостью и честным разговором про стоимость.
Ниже я привожу доп. материалы к этому докладу (мои статьи)
- Слайды HighLoad++
- AI4SDLC Research 2025
- From classic PDLC to AI-native
- IDP is Dead? Нет, умирает монополия GUI
- Agent-first IDP playbook
- Tg пост про spec-driven development
- Tg пост с разбором доклада Анны Громовой про метрики AI4SDLC
Подробнее про измерения (DORA / SPACE / DevEx):
- DORA ROI: как посчитать эффект AI-assisted разработки без магии
- DORA 2025 - State of AI-assisted Software Development
- DORA AI Capabilities Model
- Как незаметно DORA метрик стало не четыре, а пять
- The SPACE of Developer Productivity
- DevEx: What Actually Drives Productivity
#AI #AI4SDLC #Engineering #PlatformEngineering #DevOps #Management #Conference
Сегодня выступил на Saint HighLoad++ 2026 с докладом “State of AI4SDLC: как AI меняет процессы разработки в крупных компаниях”. Главная мысль у меня была про то, что AI4SDLC сейчас это про перестройку инженерной системы: платформу, процессы, метрики, безопасность, экономику и саму роль инженера.
1️⃣ В первой части я показывал, что внедрение AI уже случилось, но доверие и командный эффект за ним не успевают. Кодинг ускоряется быстрее, чем поставка изменений (delivery), поэтому старые узкие места просто становятся заметнее: постановка задач, ревью, тесты, CI/CD, безопасность, релизы и работа с контекстом.
2️⃣ Во второй части разбирал, как это выглядит на масштабе крупного финтеха на 10 000+ инженеров. Тут уже не работает логика “разрешим всем хороший AI-редактор”. Нужна платформа, рассчитанная на агентов (agent-first): модельный шлюз, инструментальный MCP-шлюз, реестр возможностей, уровни доверия read -> recommend -> act, проверки качества (evals), телеметрия и модель угроз.
3️⃣ Дальше я показывал, какие блоки уже появляются в реальной инженерной среде: единый доступ к моделям, управляемый доступ агентов к внутренним инструментам, внутренний ассистент с контекстом компании, агентный режим (agent mode) на платформе разработки и доменные агенты по всему SDLC: тестирование, ревью, дизайн, безопасность, эксплуатация, миграции, data/DS и инфраструктура.
4️⃣ Отдельный был был про измерения. Считать долю AI-кода почти бесполезно: эту метрику легко раздуть, и она плохо отвечает на вопрос, стала ли инженерная система сильнее. Смотреть нужно на цепочку
внедрение -> throughput -> качество/риск -> экономика: DORA, SPACE, DevEx, переделки (rework), время ревью, неудачные прогоны pipeline, время восстановления (recovery time), стоимость токенов и человеческого времени.Основной вывод в том, что выигрывает не команда, у которой самый модный инструмент, а команда, которая умеет превращать AI в управляемую производственную систему. С понятным базовым уровнем (baseline), владельцами, контекстом, ограничениями, проверками, наблюдаемостью и честным разговором про стоимость.
Ниже я привожу доп. материалы к этому докладу (мои статьи)
- Слайды HighLoad++
- AI4SDLC Research 2025
- From classic PDLC to AI-native
- IDP is Dead? Нет, умирает монополия GUI
- Agent-first IDP playbook
- Tg пост про spec-driven development
- Tg пост с разбором доклада Анны Громовой про метрики AI4SDLC
Подробнее про измерения (DORA / SPACE / DevEx):
- DORA ROI: как посчитать эффект AI-assisted разработки без магии
- DORA 2025 - State of AI-assisted Software Development
- DORA AI Capabilities Model
- Как незаметно DORA метрик стало не четыре, а пять
- The SPACE of Developer Productivity
- DevEx: What Actually Drives Productivity
#AI #AI4SDLC #Engineering #PlatformEngineering #DevOps #Management #Conference
polomodov.tech
State of AI4SDLC: как AI меняет процессы разработки в крупных компаниях — Saint HighLoad++ 2026
Исследования индустрии, AI-платформа крупного финтеха (Spirit, Nestor, T-Cover Agent) и новая работа инженера
👍8❤🔥6❤6🤔1
Cursor Compile 26: как IDE превращается в агентную платформу (Рубрика #AI4SDLC)
Посмотрел открывающий keynote с первой конференции Cursor Compile 26, опубликованный 22 июня 2026 года. Это хороший продуктовый анонс не потому, что Cursor показал еще несколько AI-возможностей, а потому что довольно честно обозначил смену категории: Cursor больше не хочет быть только AI-IDE, он хочет стать агентной платформой разработки!
В самом докладе было несколько спикеров: Michael Truell, сооснователь и CEO Cursor, Kevin Niparko и Tomas Reimers. Truell прямо говорит, что за последние месяцы Cursor стал агентным по умолчанию (agent-first): по утверждению компании, больше 95% пользователей используют Cursor прежде всего как агента, а запросов к агентам примерно в 5 раз больше, чем к вспомогательным функциям вроде Tab (это конечно утверждения вендора, но важны не числа, а тенденция). Дальше идет целая серия анонсов
1️⃣ Облачные агенты (cloud agents)
Cursor формулирует их не как “запустить агента где-то на сервере”, а как отдельную рабочую среду для агента. У него есть свой компьютер: клон репозитория, зависимости, доступы к системам сборки и внутренним инструментальным цепочкам, возможность запускать тесты, делать демо, отдавать screenshots и продолжать цикл правок. Это ровно тот слой, который в Google whitepaper "The New SDLC: от vibe coding к agentic engineering" (см. мой разбор) назывался harness: модель сама по себе не доводит задачу до production-результата, ей нужна обвязка, среда и проверка. По словам ребят, их cloud agents стали в 3 раза быстрее, достигли трех девяток надежности, а также было уже больше 6 млн запусков. Они привели пример Amplitude: миграция 20 000 React-компонентов на Tailwind через автоматизации и кастомного агента для миграций.
2️⃣ Cursor Mobile
На поверхности это выглядит как мобильное приложение, но инженерно интереснее другое: Cursor явно проектирует день разработчика, в котором агент может работать, пока человек не сидит за ноутбуком. С телефона можно видеть запущенных агентов, кто заблокирован, смотреть артефакты, аннотировать скриншоты и подталкивать агента делать работу дальше. Это хорошо ложится на прошлый разбор Zack Proser про бутылочное горлышко внимания людей: если агенты работают дольше и автономнее, главным интерфейсом становится не “написать код”, а вовремя снять блокировку и проверить результат.
3️⃣ Стратегический анонс Origin, Git-платформы, рассчитанной на агентов (agent-native Git platform)
Его представлял Tomas Reimers, сооснователь Graphite, который присоединился к Cursor после покупки Graphite в январе. Логика простая: если агенты генерируют больше строк, commits и pull requests, то Git-инфраструктура, review и CI становятся следующим bottleneck. Origin обещает Git-платформу, где люди и агенты вместе создают репозитории, управляют changes, работают через API/MCP/third-party apps, а сам слой умеет помогать с merge conflicts, CI failures и review comments.
Вот здесь у меня сильный дежавю с моими постами про GitLab Act 2 и AIDev набор данных PRs. GitLab говорил про machine-scale Git и lifecycle orchestration, AIDev предлагал смотреть на весь путь issue -> PR -> review -> CI -> merge. Cursor приходит с той же стороны, только из IDE: если агент стал основным производителем изменений, платформа должна видеть и удерживать весь след этого изменения.
4️⃣ Новая фундаментальная модель Cursor
Truell сказал, что она большая, обучается с нуля, не стартует с open source base, использует в 10-20 раз больше compute, чем прошлые модели Cursor, и должна выйти “в ближайшие недели”. Важно, что Cursor описывает ее не просто как coding model, а как модель для более широкой роли “инженерного коллеги”: инструменты, long-range planning, тестирование, клики по интерфейсу, понятный UX того, что агент изменил. Это уже борьба не только за лучший autocomplete, а за контроль над моделью, продуктом и агентной средой одновременно.
Итого: Cursor двигается ровно в ту сторону, которую я уже несколько раз описывал как Software Engineering 2.0 (в последний раз вчера в докладе на питерском Highload++). В итоге, все эти анонсированные Cursor возможности собираются в новую production-систему разработки.
#AI #AI4SDLC #Engineering #Agents #DevTools #PlatformEngineering #Management #DevEx
Посмотрел открывающий keynote с первой конференции Cursor Compile 26, опубликованный 22 июня 2026 года. Это хороший продуктовый анонс не потому, что Cursor показал еще несколько AI-возможностей, а потому что довольно честно обозначил смену категории: Cursor больше не хочет быть только AI-IDE, он хочет стать агентной платформой разработки!
В самом докладе было несколько спикеров: Michael Truell, сооснователь и CEO Cursor, Kevin Niparko и Tomas Reimers. Truell прямо говорит, что за последние месяцы Cursor стал агентным по умолчанию (agent-first): по утверждению компании, больше 95% пользователей используют Cursor прежде всего как агента, а запросов к агентам примерно в 5 раз больше, чем к вспомогательным функциям вроде Tab (это конечно утверждения вендора, но важны не числа, а тенденция). Дальше идет целая серия анонсов
1️⃣ Облачные агенты (cloud agents)
Cursor формулирует их не как “запустить агента где-то на сервере”, а как отдельную рабочую среду для агента. У него есть свой компьютер: клон репозитория, зависимости, доступы к системам сборки и внутренним инструментальным цепочкам, возможность запускать тесты, делать демо, отдавать screenshots и продолжать цикл правок. Это ровно тот слой, который в Google whitepaper "The New SDLC: от vibe coding к agentic engineering" (см. мой разбор) назывался harness: модель сама по себе не доводит задачу до production-результата, ей нужна обвязка, среда и проверка. По словам ребят, их cloud agents стали в 3 раза быстрее, достигли трех девяток надежности, а также было уже больше 6 млн запусков. Они привели пример Amplitude: миграция 20 000 React-компонентов на Tailwind через автоматизации и кастомного агента для миграций.
2️⃣ Cursor Mobile
На поверхности это выглядит как мобильное приложение, но инженерно интереснее другое: Cursor явно проектирует день разработчика, в котором агент может работать, пока человек не сидит за ноутбуком. С телефона можно видеть запущенных агентов, кто заблокирован, смотреть артефакты, аннотировать скриншоты и подталкивать агента делать работу дальше. Это хорошо ложится на прошлый разбор Zack Proser про бутылочное горлышко внимания людей: если агенты работают дольше и автономнее, главным интерфейсом становится не “написать код”, а вовремя снять блокировку и проверить результат.
3️⃣ Стратегический анонс Origin, Git-платформы, рассчитанной на агентов (agent-native Git platform)
Его представлял Tomas Reimers, сооснователь Graphite, который присоединился к Cursor после покупки Graphite в январе. Логика простая: если агенты генерируют больше строк, commits и pull requests, то Git-инфраструктура, review и CI становятся следующим bottleneck. Origin обещает Git-платформу, где люди и агенты вместе создают репозитории, управляют changes, работают через API/MCP/third-party apps, а сам слой умеет помогать с merge conflicts, CI failures и review comments.
Вот здесь у меня сильный дежавю с моими постами про GitLab Act 2 и AIDev набор данных PRs. GitLab говорил про machine-scale Git и lifecycle orchestration, AIDev предлагал смотреть на весь путь issue -> PR -> review -> CI -> merge. Cursor приходит с той же стороны, только из IDE: если агент стал основным производителем изменений, платформа должна видеть и удерживать весь след этого изменения.
4️⃣ Новая фундаментальная модель Cursor
Truell сказал, что она большая, обучается с нуля, не стартует с open source base, использует в 10-20 раз больше compute, чем прошлые модели Cursor, и должна выйти “в ближайшие недели”. Важно, что Cursor описывает ее не просто как coding model, а как модель для более широкой роли “инженерного коллеги”: инструменты, long-range planning, тестирование, клики по интерфейсу, понятный UX того, что агент изменил. Это уже борьба не только за лучший autocomplete, а за контроль над моделью, продуктом и агентной средой одновременно.
Итого: Cursor двигается ровно в ту сторону, которую я уже несколько раз описывал как Software Engineering 2.0 (в последний раз вчера в докладе на питерском Highload++). В итоге, все эти анонсированные Cursor возможности собираются в новую production-систему разработки.
#AI #AI4SDLC #Engineering #Agents #DevTools #PlatformEngineering #Management #DevEx
YouTube
Opening Keynote, Michael Truell | Compile 26
At this opening keynote of Cursor's inaugural Compile conference, co-founder and CEO Michael Truell traces Cursor's path to today. Michael, Kevin Niparko, and Tomas Reimers then announce Cursor Mobile, the Origin Git platform, and updates on a new model trained…
🔥7👍5❤4
Token burn как proof of work: почему AI-метрики легко уезжают в имитацию работы (Рубрика #AI4SDLC)
Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами (дискутируя после своего доклада "State of AI4SDLC на HighLoad++"). Поэтому я решил написать пост со своими мыслями на эту тему.
Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, соженные сотрудником токены — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность.
Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию.
Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли ревью быстрее и качественнее? Уменьшилась ли доля rework? Стало ли восстановление после инцидентов быстрее и уменьшилась ли сама частота инцидентов? Дошел ли результат до прода, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана.
Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, ревью, тесты, merge, раскатка, эксплуатация, качество и стоимость результата.
И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять.
На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом?
Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели.
Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным.
Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит.
Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, стоимостью на задачу, lead time, качеством/риском и опытом разработчиков (DevEx). Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе.
P.S.
Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом.
#AI #AI4SDLC #Engineering #Management #Metrics #DevEx
Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами (дискутируя после своего доклада "State of AI4SDLC на HighLoad++"). Поэтому я решил написать пост со своими мыслями на эту тему.
Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, соженные сотрудником токены — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность.
Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию.
Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли ревью быстрее и качественнее? Уменьшилась ли доля rework? Стало ли восстановление после инцидентов быстрее и уменьшилась ли сама частота инцидентов? Дошел ли результат до прода, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана.
Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, ревью, тесты, merge, раскатка, эксплуатация, качество и стоимость результата.
И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять.
На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом?
Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели.
Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным.
Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит.
Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, стоимостью на задачу, lead time, качеством/риском и опытом разработчиков (DevEx). Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе.
P.S.
Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом.
#AI #AI4SDLC #Engineering #Management #Metrics #DevEx
💯8❤3🔥1
Databricks про production AI: почему модель выбирают ближе концу проекта (Рубрика #AI4SDLC)
Посмотрел доклад Sandipan Bhaumik из Databricks "The Production AI Playbook: Deploying Agents at Enterprise Scale", в котором автор делился своим подходом к внедрению агентов в клиентские enterprise проекты, где надо было пройти путь от вау-эффекта на демо до продакшена:)
Автор иронично начал с того, что раньше большинство AI-проектов начиналось с вопроса "GPT или Claude?". Дальше быстро собирался красивый прототип на чистых данных, руководство радовалось, а через несколько недель в production никто не понимал, а почему агент отвечает странно, кто за это отвечает и где искать причину. Для того, чтобы не попадать в такую ситуацию он предлагает свой playbook из пяти опор
1️⃣ Evaluation (Define success before code)
Fdnjh называет их спецификацией AI-системы: до кода и до выбора модели нужно понять, что считается успехом в числах. Не просто "accuracy", а какая точность достаточна для конкретного бизнеса, сколько простых обращений должен закрыть агент, какие ошибки допустимы, где нужен человек.
2️⃣ Observability (see everything, always)
Если агент отказал клиенту, неправильно вызвал tool или три раза сходил в одну и ту же базу, это должно быть видно по шагам: intent classification, API call, поиск документа, reasoning, guardrail check, финальный ответ. Иначе в инциденте остается только гадать.
3️⃣ Data foundation (question + tracking data)
Автор делит этот пункт на данные, из которых агент отвечает пользователю, и tracking data - следы работы агента. Он отмечает, что люди прощают плохие данные, агенты нет. Человек увидит странность в отчете и переспросит. Агент уверенно даст неверный ответ.
4️⃣ Orchestration (patterns that scale)
Работу одного агента еще можно держать в голове. Пять совместно работающих агентов уже требуют паттернов, например
- Orchestrator-worker, где центральный агент раздает работу
- Choreography, где агенты слушают события и работают параллельно
- Human-in-the-loop, где человек входит в контур при низкой уверенности или рискованном действии
5️⃣ Governance (what keeps you in production)
В докладе это не только data governance (который уже должен быть как пререквизит), но в общем про управление рисками и ответственностью. Это аудит логи, проверки персональной информации, версионирование промптов, процесс над изменением моделей в проде и ответы на вопросы вида "кто отвечает, если агент сломался в 3 часа ночи".
В самом докладе автор делится кейсом чатбота для ритейл банка, где клиент Databricks потратил около 85 тысяч фунтов и 6 месяцев на PoC, который не вышел в production: никто не мог объяснить, почему система работает с низким качеством. В новом подходе команда выбрала модель только на 7-й неделе 8-недельного проекта. До этого они собрали около 200 реальных кейсов ответов людей в чатботе, описали метрики, построили пайплан для evaluation, включили трассировки и подготовили слой данных.
Шесть недель после запуска случился нормальный production-инцидент: банк обновил политику по процентным ставкам, клиенты начали ставить плохие оценки ответам чатбота, так как агент продолжал ссылаться на устаревший документ. Без трассировки это выглядело бы как "AI опять ведет себя странно". С трейсами стало видно, что новый документ по процентным ставкам не попал в векторную базу и чатбот про него не знал.
Отсюда вырастает плейбук для работы с инцидентами
- Detect - увидеть просадку через дашборд evals (оффлайн метрики) или по онлайн метрикам
- Diagnose - разобрать трейсы и понять что идет не так
- Contain - принять меры: откатить prompt, перевести поток на человека или включить circuit breaker
- Fix - поправить данные, tool call, prompt или модель
- Prevent - в финале обязательно добавить новый случай в набор evaluation, чтобы система ловила его в следующий раз
Databricks, понятно, показывает это через свои продукты: MLflow для tracing/evals/monitoring, Unity Catalog для прав и контекста, Agent Bricks и Unity AI Gateway для управления агентами, моделями, tools и доступами. Но ценность доклада, мне кажется, шире конкретной платформы.
Мне этот доклад нравится тем, что он хорошо укладывается в тему, что я рассказывал буквально вчера на Highload++, где AI начинает работать в компаниях хорошо, если с его помощью меняется производственная система. А вот если вокруг агента нет harness, наблюдаемости, данных и governance, то масштабирование быстро приведет вас от красивого демо до проблем на проде.
#AI #AI4SDLC #Engineering #Agents #Architecture #Management
Посмотрел доклад Sandipan Bhaumik из Databricks "The Production AI Playbook: Deploying Agents at Enterprise Scale", в котором автор делился своим подходом к внедрению агентов в клиентские enterprise проекты, где надо было пройти путь от вау-эффекта на демо до продакшена:)
Автор иронично начал с того, что раньше большинство AI-проектов начиналось с вопроса "GPT или Claude?". Дальше быстро собирался красивый прототип на чистых данных, руководство радовалось, а через несколько недель в production никто не понимал, а почему агент отвечает странно, кто за это отвечает и где искать причину. Для того, чтобы не попадать в такую ситуацию он предлагает свой playbook из пяти опор
1️⃣ Evaluation (Define success before code)
Fdnjh называет их спецификацией AI-системы: до кода и до выбора модели нужно понять, что считается успехом в числах. Не просто "accuracy", а какая точность достаточна для конкретного бизнеса, сколько простых обращений должен закрыть агент, какие ошибки допустимы, где нужен человек.
2️⃣ Observability (see everything, always)
Если агент отказал клиенту, неправильно вызвал tool или три раза сходил в одну и ту же базу, это должно быть видно по шагам: intent classification, API call, поиск документа, reasoning, guardrail check, финальный ответ. Иначе в инциденте остается только гадать.
3️⃣ Data foundation (question + tracking data)
Автор делит этот пункт на данные, из которых агент отвечает пользователю, и tracking data - следы работы агента. Он отмечает, что люди прощают плохие данные, агенты нет. Человек увидит странность в отчете и переспросит. Агент уверенно даст неверный ответ.
4️⃣ Orchestration (patterns that scale)
Работу одного агента еще можно держать в голове. Пять совместно работающих агентов уже требуют паттернов, например
- Orchestrator-worker, где центральный агент раздает работу
- Choreography, где агенты слушают события и работают параллельно
- Human-in-the-loop, где человек входит в контур при низкой уверенности или рискованном действии
5️⃣ Governance (what keeps you in production)
В докладе это не только data governance (который уже должен быть как пререквизит), но в общем про управление рисками и ответственностью. Это аудит логи, проверки персональной информации, версионирование промптов, процесс над изменением моделей в проде и ответы на вопросы вида "кто отвечает, если агент сломался в 3 часа ночи".
В самом докладе автор делится кейсом чатбота для ритейл банка, где клиент Databricks потратил около 85 тысяч фунтов и 6 месяцев на PoC, который не вышел в production: никто не мог объяснить, почему система работает с низким качеством. В новом подходе команда выбрала модель только на 7-й неделе 8-недельного проекта. До этого они собрали около 200 реальных кейсов ответов людей в чатботе, описали метрики, построили пайплан для evaluation, включили трассировки и подготовили слой данных.
Шесть недель после запуска случился нормальный production-инцидент: банк обновил политику по процентным ставкам, клиенты начали ставить плохие оценки ответам чатбота, так как агент продолжал ссылаться на устаревший документ. Без трассировки это выглядело бы как "AI опять ведет себя странно". С трейсами стало видно, что новый документ по процентным ставкам не попал в векторную базу и чатбот про него не знал.
Отсюда вырастает плейбук для работы с инцидентами
- Detect - увидеть просадку через дашборд evals (оффлайн метрики) или по онлайн метрикам
- Diagnose - разобрать трейсы и понять что идет не так
- Contain - принять меры: откатить prompt, перевести поток на человека или включить circuit breaker
- Fix - поправить данные, tool call, prompt или модель
- Prevent - в финале обязательно добавить новый случай в набор evaluation, чтобы система ловила его в следующий раз
Databricks, понятно, показывает это через свои продукты: MLflow для tracing/evals/monitoring, Unity Catalog для прав и контекста, Agent Bricks и Unity AI Gateway для управления агентами, моделями, tools и доступами. Но ценность доклада, мне кажется, шире конкретной платформы.
Мне этот доклад нравится тем, что он хорошо укладывается в тему, что я рассказывал буквально вчера на Highload++, где AI начинает работать в компаниях хорошо, если с его помощью меняется производственная система. А вот если вокруг агента нет harness, наблюдаемости, данных и governance, то масштабирование быстро приведет вас от красивого демо до проблем на проде.
#AI #AI4SDLC #Engineering #Agents #Architecture #Management
YouTube
The Production AI Playbook: Deploying Agents at Enterprise Scale — Sandipan Bhaumik, Databricks
A retail bank spent £85,000 over six months on a chatbot PoC that could not reach production. No one could explain why it was failing. When Sandipan Bhaumik's team got involved, they picked the model in week seven of an eight-week engagement — the first six…
👍8❤3🔥1
AWS про команды в agentic world: почему оргструктура стала частью AI-архитектуры (Рубрика #AI4SDLC)
Посмотрел доклад Stephen Brozovich из AWS "A leader's guide to advanced team structures in an agentic world". Это хороший гайд для лидеров об изменении операционной модели компании, когда рядом с людьми начинают работать агенты. Сама роль Stephen интересна - он AWS Executive in Residence и работает в Amazon с 1999 года. За это время он прошел путь от технических команд к работе с людьми, культурой и работе с организационными трансформациями. И именно про трансформации он рассказывает в этом докладе, что нацелен на CIO, CTO, бизнес-руководителей, которым нужно понять, как менять процессы, команды и governance поверх всего этого.
Stephen предлагает смотреть на эти вопросы через четыре грани: экономическую грань, грань талантов, структуры и governance.
1️⃣ Economics
Stephen предлагает не начинать с "строим все сами". Для каждого workflow нужно выбрать режим: use, compose или build
- Use - берем готовое решение
- Compose - собираем поверх frontier models, данных и собственного процесса
- Build - обучаем или серьезно донастраиваем свое. Build имеет смысл только там, где есть настоящая дифференциация бизнеса. Иначе лидер сжигает деньги раньше, чем понял собственный рабочий процесс.
2️⃣ Talent
Здесь доклад пересекается с идеей expert generalist из текста Martin Fowler и Thoughtworks: ценность смещается от человека, который быстрее всех пишет руками в одном стеке, к человеку, который понимает домен, ставит задачу агенту, оценивает результат и вовремя останавливает систему. AI усиливает не узкую специализацию саму по себе, а способность связать домен, клиента, архитектуру и проверку результата.
В этом блоке Stephen размышляет про джунов и показывает ловушку организации в форме diamond (мало сеньоров и джунов, но много мидлов): компании режут джунов ради быстрого ROI от AI, одновременно платят дороже за senior talent и выжигают будущую базу экспертизы. Для выполнения новых задач может работать перевернутая пирамида: 3-5 senior engineers плюс agents. Но вся организация должна оставаться в форме песочных часов, где есть сильный верх, тонкая середина и живой нижний слой обучения. Иначе в 2034 году seniors будет неоткуда взять (честно говоря, это обоснование похоже на благопожелание - оно направлено на общее благо, но не отвечает на вопрос, а чем джуны помогут конкретной компании )
3️⃣ Structure
Stephen приводит три вида структур
- Model A - старый IT ops: инженерия построила, потом перекинула через стену эксплуатации. В агентном мире это ломается: ticket culture убивает контекст, операторы не видят, что агент делает, не управляют моделью и данными, а runbook не покрывает недетерминированное поведение.
- Model B - интегрированные поды: 3-5 senior engineers сами создают/владеют/отвечают за run конкретных рабочих процессов end-to-end. Люди, которые написали системные промпты и инструменты агента, сами разбирают инцидент в 3 ночи. Меньше передач ответственнсоти, меньше потери контекста.
- Model C - интегрированные поды + платформа. На малом масштабе pod может выжить сам. На 10+ pod'ах начнут размножаться разные платформенные части: auth layers, observability stacks, guardrails и способы жечь AI-бюджет. Поэтому нужна общая платформа: runtime, memory, identity, observability, policy, cost controls. Но платформа не должна душить автономию pod'ов, она должна давать безопасную дорогу.
На масштабе будет работать только модель С, но с модели B можно стартовать в небольшой организации.
4️⃣ Governance
Здесь Stephen связывает Singapore Agentic AI Governance Framework и AWS AgentCore: оба сходятся вокруг одинаковых вопросов. Кто этот агент? Кто его авторизовал? Что ему разрешено? Работает ли он как ожидалось? Можно ли провести аудит?
Мне понравилась формулировка governance как running infrastructure. Не PDF с политикой, а код, который срабатывает на каждом запросе. Не просить LLM "вести себя хорошо", а проверять доступы, идентичность, инструменты и действия вне LLM-loop. Это ровно та же логика, которую я разбирал в постах про GitLab Act 2, agent-first IDP, Tailscale Aperture и Databricks production AI: скорость без identity, политик, evals, наблюдаемости и владельцев быстро превращается в риск.
И здесь доклад хорошо пересекается с моей старой темой про оргдизайн. В разборе Flo и Team Topologies я писал, что организация - это тоже архитектура: границы команд, ownership, интерфейсы, latency коммуникаций. AWS добавляет следующий слой: в agentic world оргструктура становится частью AI-архитектуры. Если агент меняет скорость исполнения, лидер должен заново спроектировать не только инструменты, но и форму команды, путь обучения людей и контур ответственности.
Для меня главный вывод такой: в следующие годы выиграют компании, у которых вокруг AI быстрее созреет операционная модель, а не просто будут розданы лицензии всем желающим.
#AI #AI4SDLC #Management #Leadership #Architecture #Agents
Посмотрел доклад Stephen Brozovich из AWS "A leader's guide to advanced team structures in an agentic world". Это хороший гайд для лидеров об изменении операционной модели компании, когда рядом с людьми начинают работать агенты. Сама роль Stephen интересна - он AWS Executive in Residence и работает в Amazon с 1999 года. За это время он прошел путь от технических команд к работе с людьми, культурой и работе с организационными трансформациями. И именно про трансформации он рассказывает в этом докладе, что нацелен на CIO, CTO, бизнес-руководителей, которым нужно понять, как менять процессы, команды и governance поверх всего этого.
Stephen предлагает смотреть на эти вопросы через четыре грани: экономическую грань, грань талантов, структуры и governance.
1️⃣ Economics
Stephen предлагает не начинать с "строим все сами". Для каждого workflow нужно выбрать режим: use, compose или build
- Use - берем готовое решение
- Compose - собираем поверх frontier models, данных и собственного процесса
- Build - обучаем или серьезно донастраиваем свое. Build имеет смысл только там, где есть настоящая дифференциация бизнеса. Иначе лидер сжигает деньги раньше, чем понял собственный рабочий процесс.
2️⃣ Talent
Здесь доклад пересекается с идеей expert generalist из текста Martin Fowler и Thoughtworks: ценность смещается от человека, который быстрее всех пишет руками в одном стеке, к человеку, который понимает домен, ставит задачу агенту, оценивает результат и вовремя останавливает систему. AI усиливает не узкую специализацию саму по себе, а способность связать домен, клиента, архитектуру и проверку результата.
В этом блоке Stephen размышляет про джунов и показывает ловушку организации в форме diamond (мало сеньоров и джунов, но много мидлов): компании режут джунов ради быстрого ROI от AI, одновременно платят дороже за senior talent и выжигают будущую базу экспертизы. Для выполнения новых задач может работать перевернутая пирамида: 3-5 senior engineers плюс agents. Но вся организация должна оставаться в форме песочных часов, где есть сильный верх, тонкая середина и живой нижний слой обучения. Иначе в 2034 году seniors будет неоткуда взять (
3️⃣ Structure
Stephen приводит три вида структур
- Model A - старый IT ops: инженерия построила, потом перекинула через стену эксплуатации. В агентном мире это ломается: ticket culture убивает контекст, операторы не видят, что агент делает, не управляют моделью и данными, а runbook не покрывает недетерминированное поведение.
- Model B - интегрированные поды: 3-5 senior engineers сами создают/владеют/отвечают за run конкретных рабочих процессов end-to-end. Люди, которые написали системные промпты и инструменты агента, сами разбирают инцидент в 3 ночи. Меньше передач ответственнсоти, меньше потери контекста.
- Model C - интегрированные поды + платформа. На малом масштабе pod может выжить сам. На 10+ pod'ах начнут размножаться разные платформенные части: auth layers, observability stacks, guardrails и способы жечь AI-бюджет. Поэтому нужна общая платформа: runtime, memory, identity, observability, policy, cost controls. Но платформа не должна душить автономию pod'ов, она должна давать безопасную дорогу.
На масштабе будет работать только модель С, но с модели B можно стартовать в небольшой организации.
4️⃣ Governance
Здесь Stephen связывает Singapore Agentic AI Governance Framework и AWS AgentCore: оба сходятся вокруг одинаковых вопросов. Кто этот агент? Кто его авторизовал? Что ему разрешено? Работает ли он как ожидалось? Можно ли провести аудит?
Мне понравилась формулировка governance как running infrastructure. Не PDF с политикой, а код, который срабатывает на каждом запросе. Не просить LLM "вести себя хорошо", а проверять доступы, идентичность, инструменты и действия вне LLM-loop. Это ровно та же логика, которую я разбирал в постах про GitLab Act 2, agent-first IDP, Tailscale Aperture и Databricks production AI: скорость без identity, политик, evals, наблюдаемости и владельцев быстро превращается в риск.
И здесь доклад хорошо пересекается с моей старой темой про оргдизайн. В разборе Flo и Team Topologies я писал, что организация - это тоже архитектура: границы команд, ownership, интерфейсы, latency коммуникаций. AWS добавляет следующий слой: в agentic world оргструктура становится частью AI-архитектуры. Если агент меняет скорость исполнения, лидер должен заново спроектировать не только инструменты, но и форму команды, путь обучения людей и контур ответственности.
Для меня главный вывод такой: в следующие годы выиграют компании, у которых вокруг AI быстрее созреет операционная модель, а не просто будут розданы лицензии всем желающим.
#AI #AI4SDLC #Management #Leadership #Architecture #Agents
YouTube
A leader’s guide to advanced team structures in an agentic world | AWS Events
As AI agents transform the workplace, organizations must adapt their structures and methodologies to harness new opportunities. The probabilistic nature of AI requires continuous iteration and intelligent oversight, creating new ways of working across business…
1❤7👍4🔥1
Внутри AI (How AI Works) (Рубрика #Books)
Прочитал по дороге во Владивосток книгу "Внутри AI. Как это работает" Рональда Кнойзеля, которая простыми словами объясняет сложные темы буквально на пальцах. Правда, надо отметить, что оргинал "How AI Works: From Sorcery to Science" вышла в 2023 году, а переводная книга вышла в 2026 году. Сам автор, Ronald T. Kneusel, является дата сатанистом, который имеет опыт в медицинском домене.
Мне показалось, что автор поставил себе задачу объяснить AI так, чтобы читатель перестал воспринимать AI как магию. Для этого Рональд начинает не с ChatGPT и не с трансформеров, а с более старой и полезной классики: регрессии, деревьев решений, случайных лесов, метода ближайших соседей и опорных векторов. Это не очень модно, но зато подход к gen AI происходит последовательно, а не рывком.
Мне понравилось объяснение про интерполяцию и экстрополяцию при обучении модели на существующих примерах. Условно, модель видит обучающую выборку, подстраивает параметры, пытается уловить устойчивый паттерн. А потом начинается самое интересное — инференс на новых данных, которых в обучающей выборке не было. И вот здесь сразу появляется практичный вопрос: модель работает внутри знакомой области или уже нет? В итоге, автор показывает, что полезно думать через интерполяцию и экстраполяцию:
— Интерполяция — это когда новый пример похож на то, что модель уже видела, и ей нужно восстановить значение между знакомыми точками
— Экстраполяция — когда мы просим модель перенести закономерность туда, где данных почти не было.
В реальной инженерной работе именно здесь часто и рождаются неприятные сюрпризы: на тестах все выглядело прилично, а в новых условиях модель начала уверенно отвечать без хорошей опоры.
После этого автор постепенно переходит к нейросетям и MLP (multi layer perceptron) хорошо показывает механику: простые вычислительные блоки, веса, слои, ошибка, обучение, повторение. Это, конечно, не заменяет курс по deep learning, но дает правильную интуицию: нейросеть не "понимает" мир в человеческом смысле, а настраивает большое число параметров под примеры. Отдельно хорошо подана глава про CNN. Автор показывает как изображение разбирается через локальные признаки, фильтры, слои и постепенную сборку более сложного представления. После такой главы начинаешь смотреть на computer vision более системно, а не только через математику.
В самом конце автор доходит до GenAI, где рассматривает генеративно-состязательные сети, диффузионные модели, большие языковые модели и того, почему текстовые системы вроде ChatGPT произвели такой сильный эффект. Книга останавливается на информации 2023 года, поэтому она скорее мостик к теме, а не актуальная история. Поэтому если нужен свежий разбор агентов, RAG, MCP, evals, наблюдаемости, production AI стека и того, как все это внедрять в компании, то стоит поискать другую книгу.
Итого, книга просто объясняет базу и напоминает, что перед разговорами про frontier models полезно понимать, что такое обучающая выборка, обобщение, ошибка, переобучение, признаки, параметры и инференс.
#Books #AI #ML #DeepLearning #GenAI #Engineering #Software #Math
Прочитал по дороге во Владивосток книгу "Внутри AI. Как это работает" Рональда Кнойзеля, которая простыми словами объясняет сложные темы буквально на пальцах. Правда, надо отметить, что оргинал "How AI Works: From Sorcery to Science" вышла в 2023 году, а переводная книга вышла в 2026 году. Сам автор, Ronald T. Kneusel, является дата сатанистом, который имеет опыт в медицинском домене.
Мне показалось, что автор поставил себе задачу объяснить AI так, чтобы читатель перестал воспринимать AI как магию. Для этого Рональд начинает не с ChatGPT и не с трансформеров, а с более старой и полезной классики: регрессии, деревьев решений, случайных лесов, метода ближайших соседей и опорных векторов. Это не очень модно, но зато подход к gen AI происходит последовательно, а не рывком.
Мне понравилось объяснение про интерполяцию и экстрополяцию при обучении модели на существующих примерах. Условно, модель видит обучающую выборку, подстраивает параметры, пытается уловить устойчивый паттерн. А потом начинается самое интересное — инференс на новых данных, которых в обучающей выборке не было. И вот здесь сразу появляется практичный вопрос: модель работает внутри знакомой области или уже нет? В итоге, автор показывает, что полезно думать через интерполяцию и экстраполяцию:
— Интерполяция — это когда новый пример похож на то, что модель уже видела, и ей нужно восстановить значение между знакомыми точками
— Экстраполяция — когда мы просим модель перенести закономерность туда, где данных почти не было.
В реальной инженерной работе именно здесь часто и рождаются неприятные сюрпризы: на тестах все выглядело прилично, а в новых условиях модель начала уверенно отвечать без хорошей опоры.
После этого автор постепенно переходит к нейросетям и MLP (multi layer perceptron) хорошо показывает механику: простые вычислительные блоки, веса, слои, ошибка, обучение, повторение. Это, конечно, не заменяет курс по deep learning, но дает правильную интуицию: нейросеть не "понимает" мир в человеческом смысле, а настраивает большое число параметров под примеры. Отдельно хорошо подана глава про CNN. Автор показывает как изображение разбирается через локальные признаки, фильтры, слои и постепенную сборку более сложного представления. После такой главы начинаешь смотреть на computer vision более системно, а не только через математику.
В самом конце автор доходит до GenAI, где рассматривает генеративно-состязательные сети, диффузионные модели, большие языковые модели и того, почему текстовые системы вроде ChatGPT произвели такой сильный эффект. Книга останавливается на информации 2023 года, поэтому она скорее мостик к теме, а не актуальная история. Поэтому если нужен свежий разбор агентов, RAG, MCP, evals, наблюдаемости, production AI стека и того, как все это внедрять в компании, то стоит поискать другую книгу.
Итого, книга просто объясняет базу и напоминает, что перед разговорами про frontier models полезно понимать, что такое обучающая выборка, обобщение, ошибка, переобучение, признаки, параметры и инференс.
#Books #AI #ML #DeepLearning #GenAI #Engineering #Software #Math
1🔥11❤7👍2
T-Meetup: R&D во Владивостоке (Рубрика #RnD)
Большую часть этой недели я провел с коллегами из RnD центра в нашем центре разработки во Владивостоке (тут очень красиво и вкусно кормят:)). А сегодня вечером в качестве прошел RnD митап, в программе которого было три доклада об отличиях RnD деятельности от просто разработки и пара конкретных кейсов реальных исследований
1) «Почему существуют задачи, которые нельзя решить обычной разработкой?» от Станислава Моисеева, директора инженерных исследований в Т-Банке (мы вместе прилетели из Москвы)
2) «Code Knowledge Graphs как память для LLM» от Михаила Бадерика, rnd инженера из нашего центра во Владивостоке
3) «Эволюционные агенты на практике: open-source и реальные задачи» от Даниал Матиенко, rnd инженера из нашего центра во Владивостоке
Про доклад Стаса я хотел рассказать отдельно, так как он в принципе рассказывал про концепцию research & development в крупных IT-компаниях, в частности в Т-Банке.
Началось все с того, что Стас показал как RnD отличается от продуктовой разработки:
— Продуктовая разработка отвечает на вопрос «что и как сделать», используя готовые «инструкции»
— R&D отвечает на вопрос «можно ли это сделать в принципе?» - это про закрытие технологических рисков путем проверки гипотез и разработки новых методов и технологий
В разных странах к RnD подходят по-разному
— США: Модель, основанная на большом капитале. Включает стартапы, корпоративные исследовательские центры (Apple — закрытый, Microsoft Research — фундаментальный, Google — гибридный) и сильные университетские лаборатории. Кстати, в конце 2023 года мы разбирали подход Google в подкасте (Стас тоже участвовал в качестве гостя) и гибридность подхода в том, что они глубоко интегрируют исследовательские команды в продуктовые процессы. Их ключевой принцип — reseasrch-команда с первого дня пишет продакшн-код, чтобы избежать отрыва исследований от практики и ускорить внедрение.
— Китай: Модель, основанная на кооперации и государственном влиянии. Характеризуется тесным сотрудничеством компаний и университетов, централизованным планированием и значительными государственными инвестициями (пример: Huawei тратит более 20% выручки на R&D).
— Россия: Исторически сильная модель с отраслевыми НИИ. Сегодня исследования все больше перемещаются внутрь крупных IT-компаний. Потребность в импортозамещении и бурное развитие ИИ стимулируют рост инвестиций в R&D.
Дальше Стас рассказал про направления инженерного RnD в Т-Банке
1. Инженерная продуктивность: Разработка инструментов на базе ИИ для повышения эффективности инженеров. Примеры: сервис для CodeReview, генератор юнит-тестов, инструмент Data Scout для автоматического сбора датасетов.
2. Анализ больших графов: Создание собственной платформы для обработки графов, которые не помещаются в оперативную память. Это необходимо для решения задач в области рекомендаций, антифрода и инфраструктурного анализа.
3. Оптимизация платформы данных: Разработка методов ускорения SQL-запросов за счет аппроксимированных вычислений на сэмплированных данных, что позволяет достигать 10-кратного ускорения при сохранении 99% точности.
4. Оптимизация логистики: Применение иерархических алгоритмов кластеризации для оптимизации маршрутов курьеров. Внедрение в 16 регионах уже позволило сократить километраж на 9%.
5. Блокчейн: Направление, связанное с анализом транзакций, выявлением мошенничества и созданием инвестиционных инструментов на базе распределенных реестров.
Завершил свой рассказ Стас тем, что для успеха R&D-команд необходимы не только бюджет и сложные задачи, но и разумные сроки, талантливая команда и культура, предоставляющая исследователям достаточную степень свободы.
Ну и если подбивать полезные идеи из доклада, что можно забрать себе, то они примерно такие
1. Оценивайте технологические риски при запуске новых продуктов
2. Интегрируйте исследования и разработку (избегайте создания оторванных исследовательских команд)
3. Изучайте открытые публикации
4. Ищите возможности для оптимизации
5. Создавайте правильную культуру
#RnD #Engineering #Software #Management #Leadership
Большую часть этой недели я провел с коллегами из RnD центра в нашем центре разработки во Владивостоке (тут очень красиво и вкусно кормят:)). А сегодня вечером в качестве прошел RnD митап, в программе которого было три доклада об отличиях RnD деятельности от просто разработки и пара конкретных кейсов реальных исследований
1) «Почему существуют задачи, которые нельзя решить обычной разработкой?» от Станислава Моисеева, директора инженерных исследований в Т-Банке (мы вместе прилетели из Москвы)
2) «Code Knowledge Graphs как память для LLM» от Михаила Бадерика, rnd инженера из нашего центра во Владивостоке
3) «Эволюционные агенты на практике: open-source и реальные задачи» от Даниал Матиенко, rnd инженера из нашего центра во Владивостоке
Про доклад Стаса я хотел рассказать отдельно, так как он в принципе рассказывал про концепцию research & development в крупных IT-компаниях, в частности в Т-Банке.
Началось все с того, что Стас показал как RnD отличается от продуктовой разработки:
— Продуктовая разработка отвечает на вопрос «что и как сделать», используя готовые «инструкции»
— R&D отвечает на вопрос «можно ли это сделать в принципе?» - это про закрытие технологических рисков путем проверки гипотез и разработки новых методов и технологий
В разных странах к RnD подходят по-разному
— США: Модель, основанная на большом капитале. Включает стартапы, корпоративные исследовательские центры (Apple — закрытый, Microsoft Research — фундаментальный, Google — гибридный) и сильные университетские лаборатории. Кстати, в конце 2023 года мы разбирали подход Google в подкасте (Стас тоже участвовал в качестве гостя) и гибридность подхода в том, что они глубоко интегрируют исследовательские команды в продуктовые процессы. Их ключевой принцип — reseasrch-команда с первого дня пишет продакшн-код, чтобы избежать отрыва исследований от практики и ускорить внедрение.
— Китай: Модель, основанная на кооперации и государственном влиянии. Характеризуется тесным сотрудничеством компаний и университетов, централизованным планированием и значительными государственными инвестициями (пример: Huawei тратит более 20% выручки на R&D).
— Россия: Исторически сильная модель с отраслевыми НИИ. Сегодня исследования все больше перемещаются внутрь крупных IT-компаний. Потребность в импортозамещении и бурное развитие ИИ стимулируют рост инвестиций в R&D.
Дальше Стас рассказал про направления инженерного RnD в Т-Банке
1. Инженерная продуктивность: Разработка инструментов на базе ИИ для повышения эффективности инженеров. Примеры: сервис для CodeReview, генератор юнит-тестов, инструмент Data Scout для автоматического сбора датасетов.
2. Анализ больших графов: Создание собственной платформы для обработки графов, которые не помещаются в оперативную память. Это необходимо для решения задач в области рекомендаций, антифрода и инфраструктурного анализа.
3. Оптимизация платформы данных: Разработка методов ускорения SQL-запросов за счет аппроксимированных вычислений на сэмплированных данных, что позволяет достигать 10-кратного ускорения при сохранении 99% точности.
4. Оптимизация логистики: Применение иерархических алгоритмов кластеризации для оптимизации маршрутов курьеров. Внедрение в 16 регионах уже позволило сократить километраж на 9%.
5. Блокчейн: Направление, связанное с анализом транзакций, выявлением мошенничества и созданием инвестиционных инструментов на базе распределенных реестров.
Завершил свой рассказ Стас тем, что для успеха R&D-команд необходимы не только бюджет и сложные задачи, но и разумные сроки, талантливая команда и культура, предоставляющая исследователям достаточную степень свободы.
Ну и если подбивать полезные идеи из доклада, что можно забрать себе, то они примерно такие
1. Оценивайте технологические риски при запуске новых продуктов
2. Интегрируйте исследования и разработку (избегайте создания оторванных исследовательских команд)
3. Изучайте открытые публикации
4. Ищите возможности для оптимизации
5. Создавайте правильную культуру
#RnD #Engineering #Software #Management #Leadership
❤7🔥7👍6
Noise: A Flaw in Human Judgment (Шум. Несовершенство человеческих суждений) (Рубрика #Books)
Дочитал недавно книгу "Шум" от трех авторов Канемана, Сибони и Санстейна, в которой уважаемые ученые говорили о том, что плохие решения возникают не только из-за bias, то есть систематического смещения, но и из-за вариативности: разные люди или один и тот же человек в разные моменты дают разные решения там, где решения должны быть одинаковыми.
Для меня эта книга далась тяжело - я ее читал больше года и это связано с парой моментов
1️⃣ Авторы затянули книгу до 500+ страниц, хотя основная содержательная часть легко умещалась в 250 страниц и она была про разложение ошибки
— на среднюю ошибку — average error или bias
— и на дисперсию — variability of error или как раз шум, с которым предлагают бороться авторы
2️⃣ Книга является совместным творчеством трех авторов и консистентного и единого авторского голоса нет. Даниэль Канеман, Нобелевский лауреат, задал рамку для книги и дал большие буквы для обложки — все-таки он автор книги "Thniking, Fast and Slow" ( я ее уже разбирал раньше). Второй автор - Оливье Сибони - больше четверти века был сотрудником McKinsey и он принес консалтингово-организационный опыт и тему качества стратегических решений в книгу. А Касс Санстейн добавил редакционной поддержки.
Если говорить про основные слои книги, то их два
1️⃣ Статистический
Если все судьи, интервьюеры или архитектурные ревьюеры в среднем правы, но каждый раз дают сильно разные ответы, система все равно не очень
2️⃣ Организационный
Большинство компаний не измеряют разброс. Они верят, что их ведущие специалисты примерно одинаково рассуждают, но это часто иллюзия.
Авторы предлагают смотреть на систему принятия решений как на процесс измерений. Если у вас десять термометров на одном столе показывают разные температуры, вы не говорите “какой интересный плюрализм мнений”; вы калибруете приборы. Авторы предлагают так же смотреть на людей в профессиональных системах принятия решений: найм, performance review, диагностика, прогнозирование, оценка рисков, стратегия.
Авторы приводят следующую типологию шума
— Level noise — один человек/судья/менеджер систематически строже или мягче другого
— Pattern noise — разные люди по-разному реагируют на разные признаки
— Occasion noise — один и тот же человек меняет judgment из-за контекста: усталость, настроение, время дня, жара, предыдущий кейс, порядок обсуждения (причем тут есть как межэкспертный шум, так и внутриэкспертный)
Интересные идеи, что показались мне полезными (правда, всего пара из них была для меня относительно новой)
1️⃣ Шум можно измерять без знания правильного ответа — для измерения смещения нужен ground truth, а шум можно оценить по степени вариативности
2️⃣ Совещания часто снижают уровень информации — громкий/важный человек, что говорит первым, может перетянуть мнение на свою сторону и мы так и не узнаем про реальные мнения остальных людей
3️⃣ Performance review — это очень шумный процесс (по статистике авторов около четверти оценки связано с фактическим уровнем performance, а остальное — шум)
4️⃣ Есть процессы для аудита шума — базовый подход в том, чтобы дать одинаковые кейсы нескольким независимым экспертам, собрать ответы, посчитать разброс и дальше оценить эффекты
5️⃣ Для принятия решений существуют гигиенические меры: независимые оценки до обсуждения, агрегирование, структурированные рубрики, сравнительные шкалы вместо абсолютных, разделение решения на подпроблемы, отложенное обращение к интуиции после предыдущих рациональных шагов.
6️⃣ Алгоритмы убирают шум, но не гарантируют справедливость: алгоритм может быть стабилен - те же входные данные дают тот же результат, но он может усилить систематическое смещение, если данные или функция оптимизации плохие.
P.S.
Подход авторов отлично укладывается в агентнизацию всех процессов — занимаясь этим, мы боремся и с системным смещением и с вариативностью.
#Thinking #SelfDevelopment #Brain #Economis #Leadership
Дочитал недавно книгу "Шум" от трех авторов Канемана, Сибони и Санстейна, в которой уважаемые ученые говорили о том, что плохие решения возникают не только из-за bias, то есть систематического смещения, но и из-за вариативности: разные люди или один и тот же человек в разные моменты дают разные решения там, где решения должны быть одинаковыми.
Для меня эта книга далась тяжело - я ее читал больше года и это связано с парой моментов
1️⃣ Авторы затянули книгу до 500+ страниц, хотя основная содержательная часть легко умещалась в 250 страниц и она была про разложение ошибки
E[(y'−y)*(y'−y)] = (E[y']−y)*(E[y']−y) + V[y']
— на среднюю ошибку — average error или bias
— и на дисперсию — variability of error или как раз шум, с которым предлагают бороться авторы
2️⃣ Книга является совместным творчеством трех авторов и консистентного и единого авторского голоса нет. Даниэль Канеман, Нобелевский лауреат, задал рамку для книги и дал большие буквы для обложки — все-таки он автор книги "Thniking, Fast and Slow" ( я ее уже разбирал раньше). Второй автор - Оливье Сибони - больше четверти века был сотрудником McKinsey и он принес консалтингово-организационный опыт и тему качества стратегических решений в книгу. А Касс Санстейн добавил редакционной поддержки.
Если говорить про основные слои книги, то их два
1️⃣ Статистический
Если все судьи, интервьюеры или архитектурные ревьюеры в среднем правы, но каждый раз дают сильно разные ответы, система все равно не очень
2️⃣ Организационный
Большинство компаний не измеряют разброс. Они верят, что их ведущие специалисты примерно одинаково рассуждают, но это часто иллюзия.
Авторы предлагают смотреть на систему принятия решений как на процесс измерений. Если у вас десять термометров на одном столе показывают разные температуры, вы не говорите “какой интересный плюрализм мнений”; вы калибруете приборы. Авторы предлагают так же смотреть на людей в профессиональных системах принятия решений: найм, performance review, диагностика, прогнозирование, оценка рисков, стратегия.
Авторы приводят следующую типологию шума
— Level noise — один человек/судья/менеджер систематически строже или мягче другого
— Pattern noise — разные люди по-разному реагируют на разные признаки
— Occasion noise — один и тот же человек меняет judgment из-за контекста: усталость, настроение, время дня, жара, предыдущий кейс, порядок обсуждения (причем тут есть как межэкспертный шум, так и внутриэкспертный)
Интересные идеи, что показались мне полезными (правда, всего пара из них была для меня относительно новой)
1️⃣ Шум можно измерять без знания правильного ответа — для измерения смещения нужен ground truth, а шум можно оценить по степени вариативности
2️⃣ Совещания часто снижают уровень информации — громкий/важный человек, что говорит первым, может перетянуть мнение на свою сторону и мы так и не узнаем про реальные мнения остальных людей
3️⃣ Performance review — это очень шумный процесс (по статистике авторов около четверти оценки связано с фактическим уровнем performance, а остальное — шум)
4️⃣ Есть процессы для аудита шума — базовый подход в том, чтобы дать одинаковые кейсы нескольким независимым экспертам, собрать ответы, посчитать разброс и дальше оценить эффекты
5️⃣ Для принятия решений существуют гигиенические меры: независимые оценки до обсуждения, агрегирование, структурированные рубрики, сравнительные шкалы вместо абсолютных, разделение решения на подпроблемы, отложенное обращение к интуиции после предыдущих рациональных шагов.
6️⃣ Алгоритмы убирают шум, но не гарантируют справедливость: алгоритм может быть стабилен - те же входные данные дают тот же результат, но он может усилить систематическое смещение, если данные или функция оптимизации плохие.
P.S.
Подход авторов отлично укладывается в агентнизацию всех процессов — занимаясь этим, мы боремся и с системным смещением и с вариативностью.
#Thinking #SelfDevelopment #Brain #Economis #Leadership
❤14👍3🔥2⚡1