Книжный куб

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

Comparing AI Coding Agents: A Task-Stratified Analysis of Pull Request Acceptance (Рубрика #AI4SDLC) Прочитал этот paper, который показывает почему ranking агентов без учета типа задачи не очень и полезен. Эта статья показывает, что правильным ответом на привычный вопрос "какой coding agent лучший?" является it depends:) Для своего анализа они взяли набор PR с GitHub под названием AIDev, про который я рассказывал недавно. А дальше они анализировали merge rate, но не просто общий, а учитывая, что один агент может чаще получать документационные задачи, другой - багфиксы и features. В итоге, их нельзя сравнивать как будто они получали одинаковую нагрузку. Саму работу выполнили Giovanni Pinna, Jingzhi Gong, David Williams и Federica Sarro из University of Trieste, King's College London и University College London. Сама статья была принята в MSR '26 Mining Challenge Track и по сути это наблюдательное исследование, а не эксперимент с рандомизацией, поэтому здесь мы можем увидеть корреляции, а не причинно-следственные связи. Методология выглядела так 1️⃣ Авторы взяли подмжество AIDev-POP, то есть AI-generated pull request'ы из GitHub-репозиториев с 100+ звезд. Из 33 596 PR оставили 7 156: только закрытые PR, только MIT/Apache-2.0 репозитории, и только те PR, где перед закрытием был хотя бы один ревью или коммент не от автора. Успех определили как acceptance rate: PR был merged или не был merged. 2️⃣ Дальше началось самое полезное. Авторы не просто сравнили OpenAI Codex, GitHub Copilot, Devin, Cursor и Claude Code одной таблицей. Они разложили PR по типам задач: docs, feat, fix, test, refactor, chore, build, ci, perf и т.д. Потом отдельно смотрели динамику по неделям, task distribution и pairwise-сравнения внутри типов задач. Какие получились результаты 1️⃣ Глобальные цифры выглядят соблазнительно: OpenAI Codex - 77.9% acceptance, Cursor - 74.5%, Claude Code - 71.9%, GitHub Copilot - 68.0%, Devin - 61.6%. Правда, без контекста эту таблицу правильно не прочитать. У Claude Code в выборке всего 139 PR, у Devin - 2 252, у Copilot - 2 194. Нагрузки тоже разные: Copilot чаще сидит в fix-задачах, Claude Code - в features, Cursor имеет более короткий концентрированный период наблюдения. 2️⃣ Главный результат для меня не в победителе, а в масштабе вмешивающегося фактора (confounding variable). Тип задачи дает разницу сильнее, чем многие различия между агентами. Chore-задачи в их выборке принимают в 84.0% случаев, perf - в 55.4%; между категориями получается 29 п.п. Среди массовых задач docs дают 82.1%, а features - 66.1%. То есть агент, которому чаще достаются docs, может выглядеть "умнее" просто потому, что у него легче workload. 3️⃣ По временной динамике заметнее всего Devin: авторы видят у него единственный устойчивый положительный тренд, +0.77% acceptance rate в неделю за 32 активные недели, примерно от 60% к 80%. Но сами же осторожно пишут, что причинность отсюда не следует: это может быть улучшение модели, обучение пользователей, изменение типов задач, концентрация в других репозиториях или все вместе. 4️⃣ По task-stratified сравнению картина становится менее удобной для leaderboard-а. Codex стабильно силен по категориям: от 59.6% до 88.6%, особенно fix и refactor. Claude Code лидирует в docs и features, но часть этих клеток маленькая, поэтому обобщать рискованно. Cursor хорошо выглядит в fix/test-сценариях. Значимые различия после Bonferroni-коррекции (учета множественных сравнений) в основном всплывают именно в fix и feat, а не во всех задачах подряд. Отдельно стоит обсудить ограничения Acceptance rate - это не качество кода. Merged PR может принести баг, техдолг или security issue. Public GitHub не равен enterprise-разработке. Репозитории с разной культурой review могут принимать или отклонять PR по своим правилам. Repository-level clustering в Chi-square тестах явно не моделируется. Task labels приходят из AIDev pipeline, а не из ручной разметки каждого PR. И выборки по агентам несимметричны по времени и размеру. Но именно поэтому paper полезная. Она учит не выбирать агента по общей красивой цифре, а строить метрики внедрения правильно. Если команда внедряет coding agents, я бы забрал отсюда практическое правило: любая внутренняя аналитика должна быть разбита по задачам (task-stratified). Сравнивайте не "агент A против агента B", а docs к docs, bugfix к bugfix, tests к tests, feature к feature. Отдельно смотрите review load, число комментариев, размер diff, CI, rollback, static analysis, найденные дефекты и поддержку после merge. #AI #AI4SDLC #Engineering #Research #Agents #Software #Evals

Хард & софт: Как создавался российский рынок информационных технологий (Рубрика #Books) Прочитал эту книгу Бориса Щербакова, которая рассказывает историю зарождения ИТ в России, но это скорее ироничная автобиографичная книга про то, как управленческие практики больших компаний выглядели на практике в 90х года. Это рассказ человека, который работал в Hewlett-Packard, Verysell, «Партии», Oracle и Dell, стоял у истоков российского ИТ-рынка и адаптировал западные управленческие подходы к местному контексту. Несколько моментов, которые украшают книгу 1️⃣ Корпоративное управление здесь показано не как набор правильных слов, а как социальная технология. Целеполагание сверху вниз, каскадирование задач, годовые планы, review, ранжирование сотрудников, типологии личностей - все это в абстрактном виде звучит как набор тем из MBA программы. Но автор забавно рассказывает о том, как такие практики попадали в конкретные компании, на конкретных людей и в экономическую турбулентность. Часть из них не работала или работала не так как ожидалось - и автор показывает, что такие инструменты работают только вместе с культурой, доверием и здравым смыслом. 2️⃣ Забавно читать про большие корпоративные механики, которые многие из нас видели уже в более позднем, почти нормализованном виде. Например, performance review с распределением 10% - 80% - 10%: сверху лучшие, посередине основная масса, снизу те, с кем нужно что-то делать. На бумаге это выглядит жестко, но понятно. В жизни сразу появляются вопросы: кто реально оценивает, как люди играют в систему, что делать с сильной командой, где все выше среднего, и как не превратить управленческий инструмент в ежегодный театр. 3️⃣ В книге хорошо чувствуется, что импорт практик почти никогда не бывает буквальным. Нельзя просто взять американский или европейский management playbook, перевести на русский и получить работающую компанию. Нужно учитывать рынок, дефициты, привычки, недоверие, скорость изменений, людей, связи и компромиссы эпохи. В этом смысле книга не столько учит “как правильно управлять”, сколько показывает, как руководитель думает, когда готового ответа нет. На эту тему интересно почитать про различия между культурами, что часто влияет не успешность тех или иных практик (об этом много в книге "The Culture Map" ("Карта культурных различий"), о которой я уже рассказывал) 4️⃣ Байки из 90-х здесь не декоративные. Да, они про время, которое давно прошло: ранний компьютерный бизнес, западные компании, первые профессиональные менеджеры, рынок, который еще только собирал себя из фрагментов. Но именно через эти истории видно, как в индустрии появляется управленческая ткань: продажи, партнерства, ответственность за результат, борьба за людей, попытка построить правила там, где вчера правил еще почти не было. Мне понравилось, что Щербаков пишет без позы человека, который сейчас объяснит всем единственно верный способ руководить. Скорее он делится опытом и рефлексией: где помогала дисциплина, где спасал юмор, где корпоративная методология работала, а где приходилось включать интуицию и разговаривать с людьми как с людьми. Прада, некоторые сюжеты читаются как память о давно ушедшей эпохе, а не как прямой рецепт на 2026 год:) #Books #Management #Software #History #Engineering #Product

WebMCP: How every website talks to agents — Tara Agyemang, Google Chrome(Рубрика #AI) Интересное выступление Tara Agyemang из Google Chrome про WebMCP. Зацепило не само появление нового browser API, а более практичная мысль: нормальное управление браузерным flow для агентов может быть устроено не через “посмотри на экран и угадай, куда кликнуть”, а через явные инструменты, которые сайт сам отдает агенту. Я реально чувствую, что это может быть интересной возможностью. Сейчас браузерный агент часто делает дорогую работу: читает DOM, смотрит accessibility tree, берет screenshot, угадывает визуальную структуру, вычисляет координаты и кликает. А потом ломается, потому что сверху загрузился баннер и все съехало. Это впечатляет как multimodal reasoning, но инженерно выглядит как обходной путь. WebMCP предлагает другой способ. Сайт объявляет tools: например search_concerts, purchase_ticket, filter_results или submit_application. У каждого tool есть имя, описание и schema параметров. Агент не угадывает назначение кнопки по пикселям, а видит меню допустимых действий. В демо Tara показывает это на игре-лабиринте и сайте с билетами: агент не “тыкает” в интерфейс, а последовательно вызывает инструменты страницы, при этом UI остается синхронизированным. Мне кажется, что тут прослеживается аналогия с accessibility фичами для повышения доступности для людей - когда интерфейс сделан только для зрячего человека с мышкой, другому исполнителю приходится восстанавливать смысл из внешних признаков. WebMCP выглядит как accessibility-слой для агентов: сайт объясняет не только как он выглядит, но и какие действия в нем реально существуют. Важно, что Tara не продает WebMCP как замену обычному MCP. По ее объяснению, MCP обычно про server-side интеграции: агент идет в отдельный backend tool/API. WebMCP - про client-side браузерный контекст. Нужна открытая вкладка или webview, tools живут на странице, а пользователь видит состояние и может возвращать управление себе. Это human-in-the-loop workflow внутри привычного web UI. Технически есть два пути. 1️⃣ Declarative API подходит для HTML forms: добавляешь атрибуты, браузер собирает schema из полей 2️⃣ Imperative API нужен для сложных flow: через JavaScript регистрируешь tool и внутри execute вызываешь существующую логику приложения. В документации Chrome это progressive enhancement, а не переписывание сайта под агентов. Статус стандарта пока ранний, и это важно не перепутать. WebMCP описан как proposed web standard; текущая спецификация опубликована Web Machine Learning Community Group как Draft Community Group Report, то есть это еще не W3C Standard и не документ на W3C Standards Track. Google анонсировал early preview 10 февраля 2026 года, а origin trial доступен с Chrome 149. Если спрашивать про GA честно, я бы разделял два ответа. Для Chrome implementation Chrome Status сейчас показывает origin trial на M149-M156 и стадию ship с M157 для Desktop, Android и WebView. С учетом перехода Chrome на двухнедельный release cycle с M153 8 сентября 2026 года, M157 ориентировочно попадает на начало ноября 2026 года, если план не сдвинется. Но это не значит, что “веб-стандарт вышел в GA” в широком смысле: спецификация еще обсуждается, API меняется, а межбраузерная история будет зависеть от обратной связи и реализации другими браузерами. Практический вывод такой: если у продукта есть сложные flow - покупка, заявка, support, booking, диагностики, многошаговые настройки, - стоит уже сейчас думать, какие действия в них являются “инструментами”, а какие просто визуальным оформлением. Хороший semantic HTML, accessibility, быстрые страницы и понятные states остаются базой. WebMCP добавляет следующий слой: безопасную и наблюдаемую ручку управления вместо мучения мультимодальной модели. Мне кажется, именно такие вещи будут отличать зрелую agent-ready платформу от красивой демки. Не “агент научился кликать как человек”, а “система дала агенту правильные интерфейсы и оставила человеку контроль”. P.S. Потом попробую поразбираться с этими возможностями в своих публичных проектах типа system-design.space или polomodov.tech:)) #AI #Agents #Web #Software #Architecture #Engineering

Your Attention Is the Bottleneck, Not Your Agents — Zack Proser, WorkOS (Рубрика #AI4SDLC) Посмотрел на днях доклад Zack Proser из WorkOS, который говорит про AI выгорание от работы с агентами. Думаю, что вам знакомо ощущения от работы с Claude или Codex, когда вроде бы сделано больше, чем раньше, но к середине дня ты уже выжат. Я сам реально начал это чувствовать, когда целый день управляешь агентами. Нужно сформулировать задачу, удержать контекст, выбрать границы, проверить результат, потом еще раз объяснить, где агент промахнулся. Формально скорость выше. Но ощущения flow, которое раньше появлялось, когда садишься писать сложный документ или кодишь нетривиальную фичу, почти нет. Вместо потока получается день менеджера: много переключений контекста, принятия решений и контроля за тем, что делают агенты Собственно, главный тезис Зака из презентации как раз про это: агенты перестают быть узким местом, а человеческое внимание остается конечным ресурсом. По его словам, если дать агентам контекст, критерии проверки и инструменты, они могут крутиться почти бесконечно. Но человек все равно должен понять, что задача решена, качество достаточное, а решение совпадает с продуктовой и инженерной реальностью. В докладе есть хороший пример из его работы в Applied AI-команде WorkOS. В Slack-боте для внутренних блог-постов сломался sentence case: бот портил акронимы вроде SSO. Вместо прыжков между Slack, Linear, терминалом и браузером Proser дал Claude Code доступ к Slack и Linear через MCP, попросил исправить баг и проверить результат в том же контуре. Важная деталь здесь не "агент написал код", а "агент дошел до завершенного verification loop". Дальше Зак предлагает оптимизировать свою работу по слоям 1️⃣ Signal layer Если Slack или Linear для вас главный источник переключений, не обязательно открывать их самому. Агент может читать mentions, DM, tickets, дедуплицировать запросы и вытаскивать только то, что действительно требует внимания. Это не отменяет коммуникацию, но защищает фокус от случайного шума. 2️⃣ Voice-first flow Зак говорит, что голосом регулярно выдает около 184 слов в минуту, и это помогает быстрее запускать несколько рабочих веток в Claude Code, Cursor или Codex. Но для меня важна оговорка: голос не снимает необходимости думать. Он снижает трение между намерением и постановкой задачи. Если intent мутный, агент быстрее построит не то. 3️⃣ Remote control и "shower principle" Часть хороших решений приходит не в IDE, а на прогулке или в душе, когда мозг выходит из жесткого focus mode. Раньше отойти от стола означало остановить работу. Proser показывает другой режим: утром загрузить агентов задачами, задать им контекст и проверки, потом уйти от стола и с телефона направлять их, когда появляется более ясная мысль. Не уверен, что это всем подойдет, но мысль ценная: продуктивность не равна сидению перед экраном. 4️⃣ Safety и verification gates Зак формулирует это почти как инженерное правило: скорость требует безопасности. Минимальный gate - lint, build, unit tests. Следующий - проверка через браузер: агент сам проходит сценарий и убеждается, что, например, login не сломан. Еще выше - critic pass, когда отдельный агент сверяет результат с набором правил. Здесь агентная разработка перестает быть промптингом и становится процессом. Отдельно мне понравилась идея weekly pass по истории агентных сессий. У Claude Code разговоры сохраняются локально в JSONL, и Proser предлагает регулярно отдавать их агенту с вопросом: где мы тратили лишние thinking tokens, где снимали неоднозначность, каких skills, MCP-серверов или шаблонов не хватало. Мы обычно выбрасываем контекст работы после мержа, хотя именно там лежит карта повторяющихся потерь внимания. Есть и смешной, но точный эпизод про Oura Ring через MCP: агент может напомнить, что ты плохо спал и не стоит брать вторую половину плана. На фоне "burnout turbo", как Proser описывает бездумное ускорение LLM-ами, даже такая пауза становится частью операционной модели. В Q&A к докладу был важный вопрос про обучение людей. Ответ Proser я бы сформулировал так: не делегируй AI то, чего сам еще не понимаешь. Если ты учишься, тебе все еще нужно руками пройти боль, построить ментальные модели и научиться ловить плохие решения. AI может ускорять обучение и объяснять пробелы, но не должен украсть базовую инженерную мышцу. #AI #AI4SDLC #Engineering #Software #Management #DevEx #Process

Stop Making Models Bigger, Make Them Behave — Kobie Crawford, Snorkel (Рубрика #AI) Посмотрел 20-минутный доклад Kobie Crawford из Snorkel AI с конференции AI Engineer London (10 апреля 2026). Это редкий доклад, который идет против привычного «новая модель больше и умнее». Главная мысль простая и неудобная для гонки параметров: возможности модели ограничены не столько архитектурой и числом параметров, сколько качеством данных и задач, на которых она дообучалась. А для агентов, которые ходят в инструменты, узкое место часто не reasoning, а tool discipline - дисциплина обращения с инструментами. Самый показательный пример - финансовый анализ с tool use. По материалам Snorkel, дообученная reinforcement learning'ом Qwen3-4B обошла Qwen3-235B при разнице в размере примерно 1/60. На их бенчмарке SnorkelFinance маленькая модель набрала 59.7% против 51.37% у большой (цифры из других публикаций Snorkel). Среда для обучения - FinQA: RL-окружение из 290 экспертных вопросов по 22 публичным компаниям, сделанное вместе с командой rLLM из UC Berkeley и выложенное в OpenEnv. По заявлению авторов, один прогон стоил меньше $500 на 8xH100 и удваивал pass@1. Что значит tool discipline на практике. Большие генералисты отлично рассуждают, но плохо дисциплинированы в инструментах: галлюцинируют имена колонок, игнорируют ограничения схемы и генерируют SQL, который возвращает бессмысленный результат. Лечится это не большей моделью, а привычками - сначала исследовать таблицы и схему, валидировать данные перед следующим шагом, ретраить и само-исправляться при ошибке. Маленькую модель именно этому и научили через RL. Дальше доклад обобщает это в идею, которую Snorkel называет task fidelity: не все обучающие задачи одинаково полезны. Они вводят четыре критерия приемки 1) achievability (решаема) 2) non-triviality (нетривиальна) 3) functional correctness (решение реально работает) 4) reliability (оценка воспроизводима) По их данным, дообучение на «хороших» задачах дало +6.2 п.п. к доле проходящих тестов, а на «плохих» - всего +1.1: примерно пятикратная разница только за счет качества данных. Отдельно отмечу, что все это рассказ по материалами Snorkel - компании, которая продает курирование данных, так что интерес у нее прямой. Бенчмарк свой, домен узкий (финансовый tool use поверх SQL), и переносимость на другие агентные задачи - открытый вопрос. Но если поверить ребятам на слово, то кажется, что маленькая дообученная модель с хорошим окружением и дисциплиной обращения с инструментами может оказаться дешевле и надежнее гиганта - особенно там, где агент работает со схемами и API. Для AI4SDLC это прямой сигнал: вкладываться не только в выбор модели, но и в качество задач и в guardrails, по которым агент ходит в инструменты. P.S. Я уже разбирал доклад на похожую тему "Everything I Learned Training Frontier Small Models - Maxime Labonne, Liquid AI" #AI #AI4SDLC #Engineering #Research #Agents #Data #Software

AIDev: Studying AI Coding Agents on GitHub (Рубрика #AI4SDLC) Прочитал короткую статью о том, как изучать coding agents по реальным PR, а не по демкам. В ней представлен публичный датасет, по которому agentic software engineering можно изучать не по демкам, а по следам реальных pull request'ов. Авторы - Hao Li, Haoxiang Zhang и Ahmed E. Hassan из Queen's University. Это хороший сигнал доверия: группа Hassan давно работает в empirical software engineering и mining software repositories. Paper подана на arXiv 9 февраля 2026 года и связана с MSR 2026 Mining Challenge; данные выложены на Hugging Face и Zenodo, код и ноутбуки - на GitHub. Набор данных AIDev агрегирует 932 791 pull request, которые авторы относят к Agentic-PR: PR, созданным coding agents. В выборке пять инструментов: OpenAI Codex, Devin, GitHub Copilot, Cursor и Claude Code. Эти PR распределены по 116 211 репозиториям и связаны с 72 189 разработчиками; cutoff - 1 августа 2025 года. Для глубокого анализа есть поднабор: 33 596 PR из 2 807 репозиториев с более чем 100 звездами. Там уже есть review comments, review verdicts, commit-level diffs, связанные issues, timeline событий и автоматическая классификация типа задачи по Conventional Commits. Методологически это dataset paper с главным результатом в виде инфраструктуры для интересных вопросов вида: - Кто использует агентов (джуны, мидлы, сеньоры) - Какие PR проходят review и merge - Совпадает ли описание PR с diff - Lобавляют ли агенты тесты - Какие security/quality-паттерны всплывают в agent-authored code Для меня здесь самый интересный сдвиг в единице измерения. В AI4SDLC долго мерили либо completion в IDE, либо synthetic benchmark вроде «реши issue». AIDev предлагает смотреть на весь lifecycle: issue -» PR -» commits -» review -» comments -» CI/merge/close -» дальнейшая судьба изменения. Это гораздо ближе к реальной инженерной системе. Практическое применение тут довольно прямое. Если компания внедряет кодинговых агентов, то ей стоит строить похожую внутреннюю телеметрию. Не «сколько строк сгенерировано» и не «сколько лицензий активировано», а что происходит с agent-authored PR: размер diff, доля тестов, время до review, число замечаний, merge rate, rollback/hotfix, security findings, соответствие conventions и CI. Отдельно отмечу, что датасет построен по публичному GitHub, поэтому enterprise-разработка и закрытые репозитории почти наверняка выглядят иначе. Качество выводов зависит от того, насколько надежно определены agent-authored PR для каждого инструмента; в короткой версии paper этот слой описан недостаточно подробно. Поднабор PR из репозиториев с 100+ звездочек тоже смещает картину в сторону заметных open-source проектов. P.S. Дальше расскажу про несколько интересных статей, что опираются на инсайты, что были добыты из этого датасета. #AI #AI4SDLC #Engineering #Research #Agents #Software #DevOps #Processes

AI Dev Podcast #3 / Как сделать Code Review инструмент / Опыт Т-Банка (Рубрика #AI4SDLC) Послушал свежий выпуск AI Dev Podcast, где мои коллеги из Т-Банка — Надежда Егошина и Георгий Мкртчян — рассказывают ведущим Андрею Дмитриеву (ко-фаундеру jug.ru и автору канала @dmitrievandrey8) и Андрею Буракову (автору канала @another_sa), как у нас сделали AI Code Review. Слушал с особым интересом: тема близкая, да и ребята рассказывают про реальный путь, не сильно приукрашивая. Кстати, это один из доменных агентов, что встроен в общий pipeline разработки и доступен всем командам в компании. Команда зашла со стороны вопроса «что инженер на самом деле делает на ревью?» и выделила 12 аспектов — архитектура, конкурентность, тестируемость и так далее. Но ценнее другое: главная задача ревьюера — понять, сделал ли человек то, что было в задаче. Поэтому инструмент интегрирован с таск-трекером и Confluence, читает требования, смотрит не на голый дифф, а на изменения в контексте всего репозитория, и в саммари раскладывает задачу на требования: что реализовано, что нет и что сделано «сверх задачи». Больше всего в этом случае мне нравится, что это отличный пример совместной работы R&D и платформенных команд. Первую версию собрали исследователи: проресёрчили рынок, взяли open-source, сильно переделали — получился сервис, куда вставляешь ссылку на merge request и получаешь комментарии бота. А дальше продукт передали в платформенную команду, которая стала поднимать качество за счёт знания того, как реально устроены процессы ревью в разных командах, и глубокого погружения в домен. По-моему, это правильная модель: R&D быстро проверяет гипотезы, платформа превращает прототип в продукт масштаба всего IT. Отдельно порадовала инженерная честность в оценке. Контуров два. Offline — собственный бенчмарк: методологию подсмотрели в статье ByteDance (я её в своё время разбирал тут), а сам бенчмарк собрали, пропарсив свой GitLab. Online — лайки и дизлайки на конкретные комментарии и A/B-тесты. И прямой ответ на вопрос «на сколько сократили баги и время ревью»: пока заявить не можем, продукт недавно вышел из прототипа. На фоне общего хайпа такая аккуратность подкупает. Есть ещё два интересных момента 1️⃣ Доверие как продукт: сейчас инженер делает двойную работу, сначала валидирует ревьюера, потом сам ревьюит MR, и для авторевью у команды жёсткое требование — обязательная валидация человеком. Если слепо аппрувить за ботом, багов станет больше, а не меньше 2️⃣ Интересный тезис Георгия: дообучать модели сейчас смысла нет, они пробовали — улучшения минорные или в минус, а сила в грамотной экосистеме вокруг предобученных LLM. Тезис верен в контексте этой задачи в Т-Банке, но это не универсальное правило (лучше проверять в каждом конкретном случае) В общем, из подкаста видно, что локальное ускорение этапов сдвигает работу дальше по пайплану - Ускоряешь генерацию кода — узкое место едет в ревью - Ускоряешь ревью — нагрузка едет в тестирование - Ускоряешь тестирование — весело может стать в operations Ну и тут AI Code Review показан как перестройка всего цикла разработки, где активом остаются контекст, доверие и человек в контуре. #AI #AI4SDLC #CodeReview #Engineering #Product #Management

Как я сейчас пишу longreads на важные для меня темы (Рубрика #Writing) Решил поделиться рецептом того, как сейчас пишу важные и сложные для меня статьи на технические темы. Из последнего это статьи «IDP is Dead? Нет, умирает монополия GUI» и «Agent-first IDP: как платформы к агентам готовят бигтехи и облака». - Для меня все начинается обычно с того, что какой-то вопрос становится достаточно важным с точки зрения работы или своего внутреннего проекта - Дальше это все доходит до потребности с этим разобраться и выработать какой-то план или стратегию достижения цели - Обычно у меня к тому моменту есть ряд опыт + открытые вопросы + примерный план что делать, который я рассказывал людям, чье мнение и фидбек для меня ценны - Дальше я ухожу делать deep research обычно сразу в трех инструментах от Anthropic, OpenAI и Perplexity - обычно у меня есть определенное мнение + research questions + опорные тезисы + статьи, которые я вкидываю как обязательные к рассмотрению - Дальше изучаю результаты, делаю факт-чекинг и читаю/смотрю приведенные источники - Обычно самое интересное рождается в тех местах, где разные сервисы расходятся - это повод задать доп. вопросы + попросить кросс-ревью - Дальше у меня в голове собирается некоторый план того, как двигаться в нужную сторону и дальше я обычно пишу тезисный план, который отдаю внешнему сервису - Дальше делаю ревью документа сам + несколько итераций ревью с разными моделями - Потом делаю визуализации нужных моментов для финальной статьи - я очень люблю схемы и визуализацию основных моментов На выходе у меня обычно получается md, pdf и html версия статьи, которую я финально прогоняю через ревью и корректирую если требуется. Ну и в самом финале идет публикация самой статьи, причем в зависимости от платформы это может быть как простой процесс, так и сложный (например, в Medium движке нет таблиц и других важных элментов, поэтому приходится много вставлять изображениями). P.S. Такой процесс помогает мне разбираться в теме и всего за часиков 8 рабочих можно сделать статью, которую я бы раньше писал неделю. Но основная ценность не просто в статье, а в интеграции новых знаний в свою картину мира - раньше это требовало сильно больше усилий. #Writing #Research #Productivity

Agent-first IDP: как платформы к агентам готовят бигтехи и облака (Рубрика #PlatformEngineering) Написал продолжение к эссе про внутренние платформы. В прошлый раз в тексте «IDP is Dead? Нет, умирает монополия GUI» я разбирал, почему внутренняя платформа теряет монополию своего GUI и превращается в платформу для агентов — слой возможностей, к которому обращаются не только люди, но и агенты. Это было про «почему». Новый текст — про «как». И в новой статье я специально не ушёл в футурологию. Playbook собран на публичных инженерных материалах компаний, которые уже столкнулись с агентным потреблением платформ: внутренние платформы Block, Uber, LinkedIn, Spotify и доработки публичных облаков — AWS, Azure, Google Cloud. Логика простая: когда внутренние платформы бигтехов и облака независимо сходятся вокруг одних и тех же инженерных решений, это уже не мода, а новый слой платформенной архитектуры. Из чего этот слой складывается: - Уровни зрелости L0 → L4: от GUI-only до управляемой агентной поверхности; - Три слоя, которые легко перепутать: модельный шлюз, инструментальный шлюз и реестр возможностей; - Идентичность агента: агент — субъект доступа от имени пользователя, а не общий сервисный аккаунт «для AI»; - Уровни доверия: read → recommend → act; - Доменные агенты там, где сырой доступ к логам, IAM или SQL опасен; - Evals и телеметрия агентных сценариев вместо MAU портала; - Отдельная модель угроз: prompt injection, tool poisoning, data exfiltration и не только. В конце я привожу примерный квартальный план на 30/60/90 дней и список того, чего делать точно не стоит. Главный вывод такой: бигтехи и облака не дали готовую инструкцию, которую можно скопировать, но уже показали устойчивую архитектурную сходимость. Внутренним платформам не нужно изобретать этот путь заново — нужно признать, что их главный новый пользователь уже не открывает портал. Подробнее можно прочитать в моем блоге #AI #AI4SDLC #PlatformEngineering #Engineering #Architecture #Management

SDLC с AI взгляд через метрики - Анна Громова @ AI Dev Conf (Рубрика #AI4SDLC) Посмотрел майское выступление Анны Громовой из Т-Банка с конференции AI Dev Conf. Мы с Аней часто обсуждаем метрики эффективности AI по работе, поэтому мне особенно полезно, что появилась запись, на которую теперь можно давать ссылку: это актуальный и глубокий разбор того, как мы подходим к этой теме у себя в компании. Главная мысль там очень практичная: AI в разработке нельзя нормально оценить, если вы не понимаете сам процесс поставки кода. Количество лицензий, MAU, запросов к ассистенту или сгенерированных строк может быть полезным сигналом adoption, но не отвечает на главный вопрос: стал ли SDLC быстрее, надежнее и дешевле для реального production-результата. Аня начинает с фреймворков, которые многие знают по отдельности, но редко собирают вместе - DORA - это метрики конвейера: lead time for changes, deployment frequency, recovery time, change failure rate; в докладе рядом с ними обсуждается и unplanned work. То есть как быстро и насколько стабильно команда довозит изменения до production. - SPACE и DevEx добавляют человеческую сторону: удовлетворенность, коммуникации, flow, cognitive load, feedback loops. Потому что разработка - это не только pipeline, но и люди внутри него: ждут review, переключают контексты, ходят на встречи, разбираются с новым проектом и ищут доступы. Кстати, я раньше уже подробно рассказывал про все эти подходы DORA, SPACE, DevEx. Мне нравится, что в выступлении Аня не остановилась на теории, а показала реальные метрики: onboarding time, время до первого MR, pipeline time, testing time, review time, rework, размер MR, доля падающих pipeline, incident recovery, опросы разработчиков. То есть не у нас нет единой магической метрики продуктивности, а карта процесса, по которой можно искать узкие места. Например, если вырос lead time, причина может быть не в том, что разработчики стали медленнее. Может оказаться, что у людей слишком долго оформляются доступы, документация плохо помогает при onboarding, новые end-to-end тесты замедлили pipeline или MR стали слишком большими и зависают на review. И вот здесь AI становится интересным не как “ускоритель кодинга”, а как вмешательство в конкретные участки SDLC. AI review может сократить ожидание первой реакции и часть рутинных итераций по стилю, опечаткам и простым багам. AI в дебаге проблем может быстрее сводить логи, код и симптомы к гипотезе о ключевой причине. Генерация юнит тестов закрывает скучную, но важную работу, до которой часто не доходят руки, и через это влияет на качество pipeline и change failure rate. Но важная оговорка: если ускорить только написание кода, бутылочное горлышко просто переедет дальше. Сначала senior не успевает проверять сгенерированный код. Потом упираемся в флакающие тесты и CI/CD. Потом в тестовые окружения, релизный процесс или платформенные лимиты. AI не чинит слабую инженерную систему сам по себе, он часто просто ярче подсвечивает ее ограничения. По словам Анны, в Т-Банке у AI-амбассадоров увидели снижение median merge time на 12% и lead time на 30%. Это не универсальный бенч и не обещание “просто добавьте воды AI и получите минус 30%”: в докладе отдельно проговаривается, что за скобками остаются особенности репозиториев, связность и сложность кода. Но как пример правильного разговора про эффект AI это ценно: не “люди стали чаще нажимать кнопку”, а “что произошло с delivery-процессом”. Из доклада ясно, что для осмысленного внедрения AI нужен baseline до старта, регулярный сбор метрик, связь количественных данных с опытом разработчиков и понимание, какую часть процесса мы действительно хотим улучшить. И еще важнее - не влюбляться в одну метрику. Adoption нужен, но сам по себе он ничего не доказывает. Throughput нужен, но без quality/risk можно просто быстрее производить проблемы. Экономика нужна, но без инженерного контекста легко начать оптимизировать стоимость токенов вместо стоимости результата. Практически это означает: прежде чем спорить, какой AI-инструмент лучше, стоит честно описать свой SDLC. Где у вас теряется время? Где ломается feedback loop? Где review превращается в очередь? Где CI/CD съедает выигрыш от генерации кода? Где разработчики чувствуют cognitive load, а граф метрик показывает то же самое? Тогда разговор про AI становится взрослым. Не “магия ускорила разработку”, а “мы изменили конкретный участок инженерной системы, увидели такой эффект, проверили риски и поняли, где следующий bottleneck”. #AI #AI4SDLC #Engineering #DevOps #Management #Metrics #Software #Processes

What if the network was the sandbox? — Remy Guercio, Tailscale (Рубрика #AI4SDLC) Посмотрел этот доклад Remy Guercio из Tailscale с конфы AI Engineer, 1 июня 2026, где разговор шел про то, как запускать AI агентовв организацию, если им нужны ключи, доступы, MCP tools и иногда production-данные. Сам Remy Guercio занимается стратегическими проектам в Tailscale, который многие знают как "удобный VPN на WireGuard". Но сама компания давно позиционирует себя шире - как платформа для связи с нулевым доверием (zero trust) и основанная на identity. То есть сеть, где устройство, пользователь, workload или CI job подключаются не как безымянный IP, а как сущность с identity, группами, тегами и политиками доступа. На этом фоне Tailscale теперь заходит в AI governance через Aperture. Это продукт, сейчас в beta, который работает как AI gateway: стоит между вашими агентами/LLM-клиентами и провайдерами моделей вроде OpenAI, Anthropic, Google или самостоятельно развернутых OpenAI-совместимых решений. И главная идея доклада такая: если сеть на базе WireGuard уже умеет надёжно понимать, кто именно делает запрос, зачем класть настоящий API key внутрь sandbox'а с агентом? Обычная модель выглядит так. Мы запускаем агента в контейнере, VM, GitHub Actions runner или другом sandbox. Вроде бы он изолирован. Но чтобы он был полезным, мы кладем внутрь разрешения: API key к Anthropic/OpenAI, OAuth token, доступ к tool'ам, иногда секреты к внутренним сервисам. Получается странная конструкция: sandbox ограничивает среду исполнения кода, но access control живет внутри этой же среды. Если агент работает долго, утащит ключ, обойдет обертку или начнет ходить напрямую, sandbox уже мало помогает. Guercio предлагает инверсию: вынести AuthN/AuthZ на сетевой слой. Агенту не дают настоящий ключ. Ему дают только base_url на Aperture и, по сути, пустую заглушку вместо provider API key, чтобы существующий LLM-клиент продолжил работать. Сам Aperture живет в tailnet (Tailscale network), хранит ключи провайдерову себя, видит identity входящего соединения и решает: этому пользователю, устройству, CI job или tagged agent можно идти к такой модели, с таким лимитом и такими правилами. Если доступ запрещен или quota исчерпана, агенту нечего "попробовать в другом месте": ключа у него никогда не было. Это и есть "network as sandbox" в практическом смысле. Не "контейнеры больше не нужны", конечно. Контейнер или VM все еще нужны для filesystem, process isolation и выполнения кода. Но сетевой слой становится границей разрешений: кто может вызвать модель, какой агент может ходить к какому endpoint'у, сколько он может потратить, какие tool calls видны в аудите. Что Tailscale предлагает из коробки. 1️⃣ Aperture как продукт: единый AI gateway для организации. Он убирает раздачу API keys по ноутбукам, devcontainer'ам и CI; маршрутизирует запросы к разным провайдерам по model name; логирует запросы, ответы, tool use, bash-команды, MCP-вызовы, токены и стоимость; позволяет задавать budgets, quotas, ограничения по пользователям, группам, агентам и моделям; умеет отправлять события во внешние системы через webhooks для security, audit и compliance. 2️⃣ Aperture CLI как open source tooling: launcher для coding agents, который конфигурирует Claude Code, Codex, Gemini CLI, OpenCode, GitHub Copilot CLI и другие инструменты на работу через Aperture. Важная деталь: это не новый coding agent, а слой настройки и подключения к gateway. Репозиторий открыт, но сам проект помечен как alpha. 3️⃣ tsnet как open source библиотека: Go-библиотека, позволяющая встроить Tailscale прямо в программу. То есть ваш внутренний MCP server, proxy, admin endpoint или собственный agent gateway может сам стать node'ой в tailnet и читать identity вызывающего клиента без отдельной OAuth-интеграции. Это сильная часть истории: Aperture — продукт, но underlying pattern можно повторять внутри своих платформенных сервисов. Плюс у Tailscale открыт значительный кусок клиентского кода: tailscaled и tailscale CLI живут в GitHub-репозитории. Это не значит, что весь Tailscale как SaaS лежит open source, но для платформенных команд важно другое: примитивы вокруг клиента и tsnet можно изучать, расширять и использовать в своей инфраструктуре. Почему это важно для production AI. 1) Это убирает проблему утекания ключей. Пока AI в компании живет как набор личных токенов в IDE, CI secrets и локальных конфигов, никакого production governance нет. 2) Это дает нормальную атрибуцию и наблюдаемость без переписывания агента. Для production мало знать, что "Claude что-то сделал". Нужно знать, какой пользователь, какой agent, какой CI workflow, какая модель, какой function call, какой MCP-запрос, какая bash-команда, сколько токенов, какая стоимость и какой результат. 3) Это делает AI rollout управляемым для security, platform и finance. Можно разрешить дешевую модель всем, дорогую — отдельным группам, background agents — с жесткими лимитами, PR review bot — только в конкретном repo scope, а подозрительные tool calls отправлять webhook'ом в security-систему. 4) Это показывает, куда движется инфраструктура агентов. Production AI — это не только evals, prompts и RAG. Это еще и identity, policy, audit, cost control, routing, secrets management и observability. Главный вывод для меня: sandbox для агента — это не только место, где он запускается. Это еще и место, где живут его разрешения. Если разрешения лежат внутри sandbox'а, агент потенциально владеет собственными ключами. Если разрешения вынесены в identity-aware network и gateway, агент становится гораздо менее опасным: он может действовать, но не может унести с собой право действовать. #AI #AI4SDLC #Security #PlatformEngineering #DevOps #Architecture

State of AI4SDLC на AI Dev Conf: как AI свдигает узкие места процессов разработки (Рубрика #AI4SDLC) Появилась запись моего доклада с AI Dev Conf 2026. Главная мысль простая. AI-ассистенты сделали кодинг быстрее, но это не ускорило разработку целиком. Узкое место не исчезло, а переехало вверх по процессу: к качеству постановки задачи, к проверке результата и к операционной модели инженерной организации. В докладе разбираю этот сдвиг по шагам: - почему генерация кода перестает быть бутылочным горлышком; - зачем спецификация и контекст становятся важнее скорости набора кода; - какую роль начинают играть evals как способ доверять результату; - что меняется при переходе от ассистентов, которые помогают человеку, к агентам, которые сами двигают задачу; - и куда в итоге смещается работа инженера и инженерного руководителя. P.S. Уже доступны записи всех докладов конференции в плейлисте AI Dev Conf 2026 #AI #AI4SDLC #Engineering #Agents #Conference #Software #Management

Turbo ML Conf 18 июля: приходите на State of AI4SDLC (Рубрика #AI4SDLC) 18 июля в Москве пройдет Turbo ML Conf - конференция Т-Банка для тех, кто расширяет границы ML и превращает идеи в работающие продукты. Я выступаю там с докладом “State of AI4SDLC: как AI сдвигает узкие места процессов разработки” - и заодно расскажу, почему туда стоит прийти на весь день. Сначала про доклад. AI в разработке уже стал повседневностью: кодинг, ревью, планирование, дебаггинг. Но ускорение отдельных шагов само по себе не делает разработку быстрее - узкое место просто переезжает в другую часть процесса. Поговорим о том, как встроить это ускорение в цикл разработки: с понятными целями, контекстом, доверием к результату и измеримым эффектом. А в завершении обсудим будущее разработки с AI: evals, цели и AI-driven SDLC. Теперь про конференцию. Это один насыщенный офлайн-день и три параллельных трека: - Fundamental Advances & Exploratory R&D - архитектуры моделей, interpretability, safety, reasoning; - Applied ML at Scale & Business Impact - внедрение ML в продукты, GenAI и пользовательский опыт; - ML Infrastructure, Platforms & Engineering - данные, обучение, inference и инфраструктура. Собственно, мой доклад будет в этом треке Мне нравится, что за один день можно пройти весь стек: от research до production и платформ. В программе много крутых додкладов, а также будет демо-зона с ML-продуктами и решениями партнеров (CV, RecSys, NLP), а также будет стенд с демками наших агентов, где я скорее всего и проведу часть времени после доклада. Ну и отдельно стоит отметить отличный нетворкинг - у нас собирается сильная аудитория - ML-инженеры, разработчики, исследователи и AI-продакты с опытом от двух лет. А вечером будет afterparty с DJ-сетом, где разговоры из кулуаров обычно и превращаются в самое ценное. Когда и где: 18 июля, Москва, ДК “Серп и Молот”. Участие по заявке: мест ограниченное количество и заявки модерируются, так что лучше зарегистрироваться заранее. Приходите послушать про AI4SDLC и поговорить про то, куда движется разработка с AI, - буду рад увидеться лично. #AI #AI4SDLC #ML #Engineering #Conference #Software

Building OpenCode with Dax Raad: разговор с создателем open-source coding agent'а (Рубрика #AI4SDLC) Посмотрел свежий выпуск The Pragmatic Engineer, где Gergely Orosz разговаривает с Dax Raad, создателем OpenCode. Выпуск интересен не только историей продукта. Это редкий случай, когда автор одного из самых быстрорастущих AI coding tools последовательно отказывается продавать магию и говорит про AI с заметным скептицизмом. Но начать надо с того, что OpenCode - это open-source coding agent, который начинался как terminal-based инструмент, а потом дорос и до GUI. По словам Dax, продукт вырос примерно с 650 тысяч до почти 8 миллионов MAU за несколько месяцев, а ежедневно им пользуется около миллиона человек. Цифры впечатляют, но история за ними интереснее. 1️⃣ Самый показательный эпизод - блокировка от Anthropic. Когда Anthropic закрыла OpenCode возможность работать через подписки Claude, со стороны это выглядело как угроза существованию продукта. Dax описывает ровно обратное: команда развернулась к OpenAI и другим провайдерам моделей, и этот эпизод стал ускорителем роста, а не ударом. Урок, который Dax из этого выводит, звучит почти как продуктовый манифест: правильное позиционирование важнее скорости исполнения. OpenCode выиграл не потому, что его harness был лучшим - Dax честно признает, что первые месяцы тот был просто good enough. Он выиграл, потому что первым занял категорию open-source coding agent, которую никто не успел застолбить. "Get positioning right and the world just keeps handing you wins" - его формулировка. Сначала позиция и market share, потом дошлифовка качества. 2️⃣ Про бизнес-модель он тоже рассказывает достаточно прямо. Зарабатывает компания через OpenCode Zen, и Dax спокойно раскладывает экономику inference: GPU - это капитальный актив, который амортизируется, а токены продаются, по его оценке, с маржой до 90% в зависимости от модели. На фоне разговоров про "AI убыточен для всех" полезная оптика, хотя стоит помнить, что это оценка человека, который на inference зарабатывает. 3️⃣ Самая горячая часть выпуска посвящена продуктивности. Dax говорит примерно так: до AI он тратил 95% энергии на размышления о том, что делать, и 5% на само исполнение. Сейчас - 96% на размышления и 4% на исполнение. Формально улучшение, но день ко дню работа ощущается такой же тяжелой. AI убирает doing, но не убирает thinking, а узким местом всегда было именно мышление. Уверенные предсказания о будущем AI он вообще называет формой self-reassurance: люди обычно предсказывают преимущество для собственной группы. 4️⃣ Отдельно мне понравился блок про инженерную культуру. Dax описывает картину, которая многим знакома: инженеры, которым важно качество, тонут в slop PRs от коллег, которым оно не важно, и выгорают на разгребании. Второе наблюдение тоньше: AI снимает психологическое трение - чувство вины за срезанный угол, и tech debt начинает копиться незаметно. Но есть и симметричный плюс: рефакторинг агентами стал дешевым, и этим стоит пользоваться агрессивнее, чем мы привыкли. Забавно, что в этой логике возвращаются "энтерпрайзные" паттерны вроде domain-driven design: им снова находится применение как guardrails - и для джунов, и для агентов. 5️⃣ Карьерный совет Dax простой: future-proof комбинация - это солидные знания в software engineering плюс глубокая доменная экспертиза. Инженеры систематически недооценивают вторую часть. Для меня главный вывод такой: когда создатель инструмента, выросшего на волне AI coding, говорит, что AI меняет меньше, чем кажется, это стоит слушать внимательнее, чем презентации вендоров. Узкое место смещается не в генерацию кода, а в мышление, качество и владение доменом. Туда и стоит инвестировать. #AI #AI4SDLC #Engineering #Management #Product #Software #Architecture

BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike — Michal Cichra, Safe Intelligence (Рубрика #AI4SDLC) Разбирался с докладом Michal Cichra из Safe Intelligenc, с которым он выступал на AI Engineer Europe 2026 в Лондоне 8-10 апреля 2026. Доклад мне понравился тем, что автор рассмотрел как агенты ломают неявные договоренности команд и что с этим делать. Например, человек может помнить, почему мы выбрали именно такую границу сервиса, почему не стали тащить зависимость в core, почему этот edge case важен для продукта, а тот можно отложить. Агент этого не помнит. Новый инженер через три месяца тоже часто не помнит. А markdown-спека, которая лежит отдельно от кода и проверок, быстро превращается в музей намерений. Главная мысль доклада, как я ее понял: команде нужно фиксировать не только требования, но и решения. Причем так, чтобы их могли читать люди, использовать AI-агенты и проверять автоматические контуры. Здесь хорошо складываются три знакомых артефакта, которые зрелые инженерные команды использовали и до AI 1️⃣ Product Requirements Document (PRD) отвечает за product intent Какую проблему решаем, для кого, какие user journeys считаются критичными, что будет считаться успехом. Это не просто "описание фичи для менеджеров", а источник контекста о том, зачем вообще существует изменение. 2️⃣ Architecture Decision Record (ADR) фиксирует архитектурный выбор Какие варианты рассматривали, какой trade-off приняли, почему это решение сейчас лучше альтернатив, какие ограничения оно накладывает на будущую разработку. Для AI-агента это особенно важно: иначе он будет оптимизировать локальный diff, не понимая архитектурной цены. 3️⃣ Behavior-Driven Development (BDD) связывает намерение с поведением Хороший сценарий на человеческом языке описывает не внутреннюю реализацию, а ожидаемый outcome: given конкретный контекст, when происходит действие, then система должна вести себя так-то. В идеале это еще и executable check, а не просто красивая формулировка в wiki Получается связка: why -> decision -> expected behavior -> verification. И вот это, кажется, важнее самой аббревиатурной игры в названии доклада. Проблема не в том, что у команд мало документов. Проблема в том, что документы часто не являются рабочим контуром разработки. Если PRD никак не связан с acceptance scenarios, ADR не виден агенту в момент изменения кода, а BDD-сценарии не запускаются в CI, то система живет в двух реальностях. В одной реальности у нас есть красивые намерения. В другой - агент или человек быстро меняет код и проходит пару локальных тестов. Cichra делает акцент именно на этом разрыве: prompt-based workflow может быть продуктивным, но плохо сохраняет architectural consistency, boundaries и reviewability на масштабе. Поэтому нужны machine-readable specifications, ADR и closed testing loops. Мне кажется, это практичная мысль для команд, которые пробуют coding agents не как игрушку, а как часть SDLC. Review в таком мире должен проверять не только "хороший ли diff". Он должен отвечать на вопросы: соответствует ли изменение исходному product intent, не нарушает ли оно уже принятое архитектурное решение, покрыто ли важное поведение проверяемым сценарием, есть ли evidence, что система действительно ведет себя как задумано. И это меняет роль документации. Она перестает быть архивом, который открывают перед квартальным планированием. Она становится интерфейсом между людьми, агентами и проверками. Практически это можно начать легковесно. Для важной фичи держать рядом короткий PRD с problem/goal/user journeys. Для нетривиальных технических решений писать ADR не на десять страниц, а на один экран: context, decision, consequences. Для критических сценариев добавлять BDD-like acceptance checks и запускать их там же, где команда уже проверяет код. Важен не формат ради формата. Важно, чтобы решение можно было восстановить через несколько недель, дать его агенту как контекст и проверить, что реализация не уехала от исходного смысла. #AI #AI4SDLC #Engineering #Architecture #Software #DevTools