Книжный куб

AI-DLC: как AWS пытается превратить SDD в операционную модель (Рубрика #AI4SDLC) Разбирался с документом "AI-Driven Development Lifecycle (AI-DLC) Method Definition", который написал Raja SP, Principal Solutions Architect из Amazon Web Services. Документ появился около года назад, а официальный AWS DevOps блогпост со ссылкой на этот whitepaper вышел 31 июля 2025 года. Интересно, что AWS представила Kiro 14 июля 2025 года как agentic IDE со spec-driven development, включающим requirements.md, design.md, tasks.md, steering files, hooks и так далее. AI-DLC появляется сразу после этого и выглядит не как отдельный инструмент, а как попытка дать Kiro/Amazon Q более взрослую методологическую рамку для enterprise-разработки. В документе формулируется разрыв между двумя крайностями и предлагается третий режим AI-DLC 1) AI-assisted development помогает в мелких задачах: код, тесты, документация 2) AI-autonomous development обещает построить приложение почти без человека, но, по мнению ребят из AWS этот подход быстро упирается в качество и контроль 3) AI-DLC предполагает, что AI ведет процесс, но человек остается владельцем намерения, риска и финального решения Основной концепт строится в реверсе направления разговора - теперь не человек постоянно просит AI "напиши мне вот это", а AI сам раскладывает intent на планы, вопросы, trade-offs, units и tasks, а люди валидируют решения в критических точках. Для того, чтобы работать по этому процессу AI-DLC — Вводит свои артефакты: Intent, Unit, Bolt, Domain Design, Logical Design, Deployment Unit — Вводит фазы Inception, Construction, Operations — Вводит ритуалы вроде Mob Elaboration и Mob Construction — Отдельно уделяется внимание DDD (domain driven design), где AI должен не просто писать код, а помогать выделять bounded contexts, user stories, ADR, тесты, инфраструктуру и deployment units. Если сравнивать с Kiro и SDD от AWS, то различие примерно такое. 1) Kiro - это продуктовый интерфейс. Его spec-flow превращает промпт в три понятных файла: requirements, design, tasks. В новых версиях есть Quick Plan, bugfix specs и параллельный запуск независимых tasks. Это практичная форма SDD для feature или bugfix внутри конкретного репозитория. SDD в формулировке Kiro - это дисциплина "сначала зафиксировать durable spec, потом дать агенту исполнять". Marc Brooker хорошо описывает спецификацию как большую картину и human-readable super prompt: она удерживает intent, делает изменения версионируемыми и снижает хаос prompt-by-prompt разработки. 2) AI-DLC предлагает не только "описать фичи для агента", а "зафиксировать как должна работать вся delivery-система, если AI стал участником SDLC". Поэтому там есть операции, риски, следы для аудита, разные глубины процесса, гейты для подтверждений людьми и идея, что рабочий процесс не должен быть жестко зашитым. Для маленькой фичи полный AI-DLC будет тяжеловат, а вот для модернизации legacy, нескольких команд, регулируемого домена он может подходить хорошо У изначального документа были и продолжения - 29 ноября 2025 года AWS опубликовала два поста: open-source adaptive workflows для AI-DLC и walkthrough для Amazon Q Developer. Там AI-DLC уже превращается из PDF в правила и steering files для агентов: Amazon Q Rules и Kiro Steering. В репозитории awslabs/aidlc-workflows стабильные релизы v1.0.0/v1.0.1 вышли 19 и 30 июня 2026 года. Дальше движение пошло еще интереснее: в README уже объявлен AI-DLC Workflows 2.0 Preview. Ветка v2 описывает подход "one core, many harnesses": Claude Code, Kiro IDE, Kiro CLI, Codex CLI. Там уже не просто набор markdown-правил, а попытка собрать workflow engine: 5 фаз, 32 стадии, 11 domain-expert agents, adaptive scopes, depth levels, test strategy levels, approval gates, two-tier knowledge system, learning loop и structured audit trail. То есть направление продолжения понятное: от методологического манифеста к исполняемой инфраструктуре разработки. Сначала whitepaper объяснял, почему старый SDLC надо переосмыслить. Потом AWS дала rules/steering, чтобы это можно было попробовать в Kiro и Amazon Q. Теперь v2 пытается сделать AI-DLC более проверяемым, переносимым между агентными harnesses и менее зависящим от ручного prompt engineering. #AI #AI4SDLC #Engineering #Architecture #DevTools #Management #Agents

QAk-QAk про AI: качество никуда не делось, оно стало важнее (Рубрика #AI4SDLC) Вышел финальный выпуск пятого сезона подкаста "QAk-QAk — и в продакшен", куда меня позвали поговорить про AI, качество и то, как встроиться в новый темп изменений. Этот выпуск мы записали еще в мае и, как по мне, он получился достаточно интересным. AI сейчас меняет само определение работы внутри SDLC. Раньше айтишники часто рассказывали другим индустриям про цифровую трансформацию (digital transformation): как оцифровать процессы, перенести данные в онлайн, ускорить бизнес. Теперь похожая волна пришла внутрь самой разработки. Мы, условно говоря, начали трансформировать сами себя. В выпуске я говорил о том, как AI влияет на качество (ведь это подкаст для quality assurance engineers) - и мне кажется, что AI не отменяет качество, а повышает цену инженерной зрелости. Если у команды уже есть контракты, тесты, нормальная архитектура, понятный контекст проекта и привычка проверять результат, агенты действительно могут дать сильный буст. Если у команды хаос, слабые границы, непонятные требования и тесты где-то рядом с религией, AI часто просто масштабирует этот хаос. В разговоре мы обсудили ценность опыта и прожитых лет - они сами по себе не мешают использовать AI-инструменты. Наоборот: опыт помогает сформулировать intent, подсказать агенту, куда смотреть, оценить план, понять, что результат выглядит неправильно, и вовремя остановить красивую, но неверную генерацию. Проблема в другом: у опытного инженера часто есть боль от того, что его привычная работа меняется. Человек хочет хорошо делать прежнюю работу, а индустрия уже поменяла ее определение. Отдельно я постарался на примере поговорить про инженерный обвяз на примере своего пет-проекта "System Design Space". Рассказ был о том, как вокруг AI-проекта постепенно нарастала обвязка: визуальные проверки, светлая и темная темы, контрастность, Lighthouse, глоссарий терминов, правила для текста, технический долг по самим проверкам. Это не история о том, как я подключил кучу MCP, скиллов или других модных инструментов, а потом пошел делать бизнес-логику. Скорее наоборот: обвязка вырастала из реальных точек контроля, где в проекте возникали ошибки или я знал, что потенциальная ошибка будет дорогой. В общем, если раньше качество часто воспринимали как отдельную фазу после разработки, то в агентной разработке проверка все сильнее уезжает влево (shift left). Тенденция к этому была и раньше в зрелых инженерных системах, но сейчас без этого вообще труба. В общем, сейчас сначала нужно понять, что именно попросили сделать, как это проверять, какие ограничения дать агенту, какие контракты не сломать, какие тесты должны стать красными до реализации. В каком-то смысле старые идеи TDD/BDD возвращаются не как методологический спор, а как практический язык управления агентами. Командам мало "попробовать AI" - им нужно понять, какую часть работы они хотят улучшить: быстрее писать код, лучше читать требования, дешевле поддерживать legacy, точнее проверять изменения, быстрее разбирать инциденты. И дальше строить контур: baseline, метрики, проверки, ответственность, человеческое review. Без этого разговор быстро превращается в соревнование по количеству сгенерированного текста и зеленых галочек. В выпуске мы затронули и более широкие риски: что будет с рынком труда, если часть работы действительно станет автономной; почему сильные команды могут ускоряться быстрее слабых; как меняется доверие, когда текст, голос и видео становятся легко генерируемыми; почему security в AI-мире становится еще напряженнее. Простых ответов там нет, и, честно говоря, мне не очень нравятся уверенные прогнозы в этой теме. Для меня практический вывод спокойнее: не надо ждать, пока кто-то сверху принесет готовую карту нового мира. Нужно самому делать маленькие эксперименты, собирать свои harness и evals, учиться делегировать агентам работу, но не делегировать им мышление и ответственность. AI хорошо усиливает систему. Поэтому главный вопрос остается старым инженерным вопросом: какую именно систему мы ему даем усилить? #AI #AI4SDLC #Engineering #QA #Management #Agents

Интересный анонс Clauds Science. Думаю, что я знаю как проведу этот вечер:)

Object Oriented Design Interview: An Insider’s Guide (Object Oriented Design. Подготовка к сложному интервью) (Рубрика #SystemDesign) Я уже как-то рассказывал про эту книгу 2025 года в  линейке “Insider’s Guide” от ByteByteGo, но недавно вышел перевод от издательства Питер причем с моим отзывом на обложке книги:) Эта книга была не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Честно признаюсь, что прочитал я ее для того, чтобы честно написать фидбек - и вот на питерском Highload++ сотрудники издательства "Питер" подарили мне эту книжку:) P.S. Сейчас я читаю книгу про AI-assisted Engineering, автор которой мне предложил написать на нее ревью. Пока прочитал около половины, но книга хорошая - буду ждать ее в бумажном виде:) #SystemDesign #OOD #Architecture #Interview #Software #Engineering

Angie Jones про автономную инженерную организацию и ее последствия (Рубрика #AI4SDLC) Посмотрел вчера выступление Angie Jones "Building an Autonomous Engineering Org", которое начинается как обычная история успеха про AI-агентов, а в конце заканчивается крайне интересными вопросами про будущее таких организаций. Сейчас Angie Jones работает VP of DevEx в Agentic AI Foundation, но в докладе она делится своим опытом работы в Block, где, по ее словам, последние пару лет участвовала в превращении инженерной организации на 3 500 человек в автономную инженерную организацию. У ребят получилось и сначала это ощущалось как реализация мечты ... пока не стало кошмаром и не закончилось сокращением половины штата, которые стали избыточны при такой автономии ... Но если возвращаться к первой части доклада, то Angie говорит о том, что AI adoption сам по себе почти ничего не доказывает. В Block уже через пару месяцев около 90% инженеров регулярно использовали Goose и Claude Code, были метрики и счета за токены, но features не доезжали до клиентов быстрее. Компания прошла стадию экспериментов внедрения, но не дошла до получения ценности. И для того, чтобы говорить о степенях движения к агентной инженерной организации (где инженеры используют AI-агентов как основной способ получать engineering outcomes) она вводит шкалу автономности инженера относительно агента — Stage 0 - AI вообще не используется в рабочем процессе — Stage 1 - autocomplete и похожие подсказки, но без agent mode — Stage 2 - чат с агентом, но без реальных PR — Stage 3 - инженер делегирует агенту задачи и проверяет результат — Stage 4 - несколько агентов работают параллельно — Stage 5 - агенту можно отдать целую задачу, и он способен выдать прод результат без постоянного вмешательства людей До Stage 3 они дошли через использование AI чемпионов, а не массовым обучением всех подряд. Jones выбрала примерно 50 инженеров из критичных команд, которые могли тратить около 30% времени на AI enablement и умели работать с недетерминированностью моделей. Мысль в том, что если стратегия зависит от того, что каждый из 3 500 инженеров сам станет продвинутым пользователем, то широкого эффекта не случится. Чемпионы сначала делали репозитории AI-ready. Это звучит скучно, но именно там начинается автономность: agents.md, claude.md, файлы с правилами, повторяемые рабочие процессы, позже скиллы для агентов, AI code reviewer и аттрибуция AI инструментов в PR. Агенту нужен контекст, правила, команды сборки и понимание, что именно в этом репозитории считается хорошим изменением. Все эти изменения были не одинаковыми для всех, а учитывали специфику: web, mobile, JVM backend, монорепозитории и маленькие сервисы требовали разных подходов. Дальше автономность стала нативной для мест, где уже рождается работа: Slack, Jira, Linear, GitHub issues. В одном примере инженер прямо в Slack спрашивает Goose про баг, агент идет в репозиторий, подтверждает проблему, предлагает варианты исправления, команда выбирает вариант, и Goose возвращается с PR. По словам Jones, цикл обсуждение -> диагностика -> согласование -> fix занял около пяти минут. Это уже не coding assistant в IDE, а участник delivery loop. Через три месяца после запуска чемпионской программы, AI-authored code вырос на 69%, reported time savings - на 37%, а автоматические PRs - в 21 раз. Stage 4 принес новый bottleneck: если инженеры запускают в 3-4 PRs больше, review ломается первым. Block подключил AI code review как обязательную часть контура: Codex на репозиториях, auto-fix loop, где один агент находит проблему, другой исправляет и коммитит изменения в PR. Плюс потребовались cloud workspaces: ноутбуки инженеров переставали выдерживать несколько параллельных агентов. Stage 5 потребовал уже не инструмента, а модели организации. Команда начала строить Builder Bot - оркестратор с машинно-читаемой мировой моделью всей компании: где какие сервисы лежат, как они связаны, какие зависимости между кодовыми базами. По словам Jones, речь шла о примерно 25 000 репозиториев. Без такой карты агент может написать локальный патч, но не может планировать изменение через несколько продуктов и систем. Технически история закончилась Stage 5 тем, что любой сотрудник мог обратиться к Builder Bot в Slack и попросить исправить баг или реализовать feature, даже без GitHub. И вот здесь доклад заканчивается увольнениями и вопросами вида: если мы дали людям возможность построить автономную инженерную организацию, могло ли это стать аргументом для того, чтобы людей стало меньше? #AI #AI4SDLC #Engineering #Agents #Management #PlatformEngineering #Leadership #Processes

Google Cloud AI agent trends 2026: рекламный, но полезный чеклист (Рубрика #AI) Прочитал отчет Google Cloud «AI agent trends 2026», который мне показался скорее вендорским подходом к продажам, а не научным исследованием. Методология основывалась на внутренних интервью Google Cloud и Google DeepMind, историях заказчиков, а также отчете Google Cloud «The ROI of AI 2025» на основе опроса "3 466 enterprise decision makers". В общем это больше похоже на сигнал о том, а куда Google Cloud хочет сдвигать своих enterprise-клиентов. Если же говорить про сами тренды AI агентов, то вот они 1️⃣ Agents for every employee Это про то, что сотрудник становится менеджером набора агентов: поставить цель, дать контекст, проверить результат. Тренд важен тем, что продуктивность будет упираться не только в модель, но и в умение людей формулировать задачи, открывать данные и контролировать качество. 2️⃣ Agents for every workflow Google описывает цифровую линию сборки: несколько агентов ведут процесс end-to-end через системы, данные и инструменты. Здесь начинается настоящая архитектура: интеграции, audit trail, MCP/A2A, права доступа и ответственность за действие. 3️⃣ Agents for your customers Вместо скриптованных агентов предлагается концепт агент-консьержа, который помнит контекст, смотрит CRM, логистику, биллинг и может проактивно решать вопрос. Для продукта это важно потому, что ценность будет в безопасном доступе к enterprise data. 4️⃣ Agents for security SOC (security operation center) должен сдвигаться от отсмотра алертов к полуавтономному циклу detection, triage, investigation, response. Тренд важный, так как агенты нужны для ускорения защиты, но одновременно требует новых правил контроля. 5️⃣ Agents for scale Купить платформу мало, но нужны обучение, новые роли, critical thinking, governance и ясные правила, что агентам можно делать. Итоговый вывод в том, что сам отчет не очень полезен сам по себе, но показывает, что агентная разработка уже доезжает в enerprise клиентов Google Cloud:) P.S. В первом комментарии будет сам pdf. #AI #Agents #Engineering #Architecture #Management

Gergely Orosz про AI в разработке: замедлиться, чтобы ускориться (Рубрика #AI4SDLC) Посмотрел keynote Gergely Orosz “Slow down to speed up: AI and software engineering” с Craft Conference, что проходила в Будапеште. Главная мысль у Gergely похожа на мои тезисы с выступления на Highload - AI упростил написание кода, но возникли вопросы доверия к этим AI изменениям. Если команда генерирует pull requests быстрее, чем умеет их понимать, проверять и связывать с продуктовым результатом, то локальное ускорение легко превращается в системное замедление. Первую часть выступления Gergely разбирает текущее состояние дел в индустрии - Историю Instagram/Meta с их инцидентом с account takeover через Meta AI. По его словам это был не просто баг, а симптом организации, где фокус на AI начал выдавливать безопасность, надежность и инженерную культуру - Дальше он рассказывает про текущее состояние дел в Anthropic и OpenAI (примеры больших AI лаб), Cursor (пример компании, что делает инструменты для инженеров), Google и Meta (bigtech с большим разнообразием внутренних инструментов), а также Uber (пример компании с полноценной инфрой для инженеров вокруг AI) Эти истории интересны, по ним видно, что индивидуальный output на разработчика действительно вырос, но продуктивность команд и качество не обязаны вырасти вместе с ним. Gergely делится данными Linear и Cursor: больше PR, больше строк кода, крупнее изменения, больше acceptance без человеческого review. Из этого видно, что кода действительно поставляется больше, но дальше он доезжает на этап ревью. И для того, чтобы это не стало бутылочным горлышком нам требуется архитектурное мышление инженерные практики вокруг тестирования, наблюдаемости, надежности, безопасности - раньше они часто были nice to have, а теперь must have. Только они позволяют как-то доверять тем объемам изменений, что сейчас стали нормой при помощи AI. Интересно, что Gergely активно хвалит Uber и рассказывает про их а внутреннюю инфраструктуру: MCP Gateway, Agent Builder, Minion, Code Inbox, risk profiles, AI code review. То есть AI там встраивают не как игрушку рядом с IDE, а как часть системы поставки ценности: маршрутизации изменений, оценки риска, review-потоки, миграций, циклов обратной связи. Отдельно Gergely активно ругает AI метрики, которые дают неправильную мотивацию сотрудникам. Если организация мерит token usage или просто adoption, люди будут максимизировать использование AI, даже когда это ухудшает результат. Это старая болезнь кривых метрик, умноженная на скорость генерации кода. Можно выглядеть очень современно и одновременно производить больше технического долга. AI не отменяет хорошую инженерию, а делает ее более ценной. Naming, границы модулей, тестируемость, понятные контракты, нормальный review, умение удалить старый код - все это становится не эстетикой, а инфраструктурой доверия. Когда код пишет агент, человеку тем более нужен способ понять: что изменилось, почему это безопасно и какие последствия будут через три месяца. Ближе к концу выступления Gergely делится рекомендациями 1️⃣ Замедляться надо не в смысле “не пользоваться AI”, а в смысле “не генерировать больше, чем можешь проверить”. Скорость должна подчиняться бутылочному горлышку (возможности ревью), а не наоборот. 2️⃣ Начинать надо не с инструмента, а с бизнес результата и слабого места процесса. Где теряется время: discovery, onboarding, review, тесты, миграции, incident response, документация, старый код? AI полезен там, где встроен в конкретную петлю обратной связи. 3️⃣ Стоит инвестировать в verification systems. Evals, тесты, статический анализ, risk profiles, наблюдаемость, staged rollout, code ownership - это способ масштабировать AI без полной потери контроля. 4️⃣ Инженеру будущего нужны навыки продакт менеджера, доменная экспертиза, архитектурный вкус и способность строить системы поверх LLM: RAG, agents, evals, workflow automation, внутренние платформы. Чем дешевле код, тем ценнее понимание, какой код вообще стоит писать. 5️⃣ AI adoption нельзя делегировать только энтузиастам и считать по лицензиям. Руководителям придется оставаться hands-on: понимать ограничения моделей, видеть реальные bottlenecks команды, защищать качество и перестраивать review. Средний слой руководителей, который только водит руками здесь не особо нужен #AI #AI4SDLC #Engineering #Software #Architecture #Management

Noise: A Flaw in Human Judgment (Шум. Несовершенство человеческих суждений) (Рубрика #Books) Дочитал недавно книгу "Шум" от трех авторов Канемана, Сибони и Санстейна, в которой уважаемые ученые говорили о том, что плохие решения возникают не только из-за 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

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 в подкасте (Стас тоже участвовал в качестве гостя) и гибридность подхода в том, что они глубоко интегрируют исследовательские команды в продуктовые процессы. Их ключевой принцип — «ресерч-команда с первого дня пишет продакшн-код», чтобы избежать отрыва исследований от практики и ускорить внедрение. — Китай: Модель, основанная на кооперации и государственном влиянии. Характеризуется тесным сотрудничеством компаний и университетов, централизованным планированием и значительными государственными инвестициями (пример: 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

Внутри 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

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

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

Token burn как proof of work: почему AI-метрики легко уезжают в имитацию работы (Рубрика #AI4SDLC) Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами. Поэтому я решил написать пост со своими мыслями на эту тему. Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, token burn per employee — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность. Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию. Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли review быстрее и качественнее? Уменьшилась ли доля rework? Стали ли incident recovery и change failure rate лучше? Дошел ли результат до production, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана. Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, review, тесты, merge, rollout, эксплуатация, качество и стоимость результата. И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять. На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом? Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели. Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным. Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит. Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, cost per task, lead time, quality/risk и DevEx. Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе. P.S. Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом. #AI #AI4SDLC #Engineering #Management #Metrics #DevEx

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

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

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-кода почти бесполезно: эту метрику легко раздуть, и она плохо отвечает на вопрос, стала ли инженерная система сильнее. Смотреть нужно на цепочку внедрение -> 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

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 разработки нельзя считать упрощенно в виде: "купили лицензии, получили экономию". Авторы предлагают смотреть на всю систему поставки софта. Формула стандартная: 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

[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️⃣ Роль человека эволюционирует, а не исчезает Финальная фраза

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

[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

Архетипы и стратегирование (Рубрика #Leadership) Вчера уже в третий раз был на обучении у Андрея Шишакова про архетипы и личное стратегирование. И тут дело не в том, что я не понимаю с первого раза, а скорее в том, что мне нравится как Андрей подает свой материал и докручивает год от года. Для меня такое обучение часто является способом еще глубже уйти в саморефлексию и получить некоторые инсайты: в первый раз я учился у Андрея в 2022 году уже после всем известных событий, второй раз в 2024 году и в третий раз сейчас. Основной контент вчерашнего обучения напоминал то, что было в 2024 году (о чем я рассказывал в трех постах "Стратегирование и самоактуализация/визионерство": 1, 2 и 3), но после этого обучения я понял, что мне надо начать ходить к психологу + пойти все-таки учиться по этому направлению + меня заинтересовала тема генеративного транса, которой закончилось вчерашнее обучение. P.S. Спасибо Наташе Лосевой, что у нас в компании отвечает за обучение руководителей, а также ее команде - это был отличный MBA Reunion день для выпускников всех наших внутренних программ MBA. А сегодня я еще поеду на день выпускника Сколково, так как наши программы были на базе этой бизнес школы. #Management #Leadership #Processes #Strategy