Книжный куб

SWE-Together: как мерить кодинг-агентов диалогово, а не в один ход (Рубрика #AI4SDLC)

Прочитал свежую статью "SWE-Together: Evaluating Coding Agents in Interactive User Sessions" от команды запрещенной в России компании "Meta" (arXiv, 29 июня 2026). Авторы бьют в слабое место почти всех бенчмарков кодинг-агентов: они статичные. Агент получает полную постановку задачи сразу и оценивается по финальному коду. А реальная работа с агентом устроена иначе - это диалог, где пользователь раскрывает намерение постепенно, уточняет требования и поправляет ошибки по ходу. В общем и целом, авторы хотели проверить гипотезу того, что сильной модели нужно меньше вмешательств пользователя во время работы (и это реально подтвердилось)

Вообще, проблемы с бенчами классические: один насыщаются и перестают различать топовые модели (можно глянуть мой разбор выступления про SWE-rebench). Также бенчи не всегда измеряют именно то, как с ними взаимодействуют инженеры. Собственно, SWE-Together (лидерборд, github) как раз и пробует уйти от одноходовой постановки (single-turn) к диалогу (multi-turn), режиму который более похож на реальную работу с агентами.

Интересна процедура сбора датасета
- На входе было 11,260 реальных сессий пользователей с кодинг-агентами (четыре открытых датасета с Hugging Face: DataClaw, Pi-staging, Hyperswitch, SWE-chat)
- На выходе получили 109 воспроизводимых задач уровня репозитория, что дает конверсию в 0.97%
- Посередине были жесткие фильтры: нужно восстановимое состояние репозитория, ясная цель, проверяемый исход, а финальное изменение должно быть в основном написано агентом, а не человеком
- Каждая задача на выходе - это песочница с зафиксированным коммитом, окружением и верификаторами.

Самая интересная инженерная часть в этом бенче - это симулятор пользователя. Он нужен так как исходную сессию нельзя проиграть дословно: новый агент пойдет другим путем, и реплики исходного пользователя потеряют смысл. Поэтому LLM-симулятор заякорен на намерения из исходной сессии, но реагирует на живую траекторию оцениваемого агента: после каждого хода он принимает одно решение - промолчать, задать вопрос, перенаправить агента, добавить требование или попросить проверить внешний артефакт. В слепом тесте аннотаторы не смогли отличить симулятор от живых пользователей: 46% "принятия за человека" при случайном уровне 50%, разница статистически незначима (аля пройден модифицированный тест Тьюринга).

Оценка тоже сделана с оглядкой на известную болезнь: фиксированные тесты искажают оценку в обе стороны - узкие цепляются за случайные детали реализации, широкие требуют поведения, которого никто не просил. Здесь финальное состояние репозитория оценивает агентный судья по зафиксированному заранее набору критериев (frozen rubric): взвешенные поведенческие цели формируются один раз, офлайн, до и независимо от любых кандидатов, а потом одинаково применяются ко всем моделям. Оценивается поведенческая полнота, а не похожесть на исходный патч.

На выходе у нас есть еще метрика User Correction, которая показывает сколько раз пользователю пришлось явно поправить агента (плюс мягкие подталкивания с весом 0.2) по дороге к результату. Два агента с одинаковым финальным баллом могут стоить пользователю очень разных усилий.

Результаты по семи моделям в общей обвязке (harness) opencode.
- Claude Opus 4.8 лидирует: pass@1 63%, средний балл судьи 0.801 и минимум корректировок - 1.38 за сессию, но и самый большой расход output+reasoning токенов (74k на задачу)
- GPT-5.5 второй по среднему баллу судьи (0.763) и самый экономный: 29.9k токенов и 10.7 минут на задачу
- Способность и число корректировок связаны почти линейно: корреляция Пирсона "−0.92".
В итоге, гипотеза о том, что сильной модели нужно меньше вмешательств пользователя получила количественное подтверждение - в рамках этого бенчмарка. Забавная деталь: моделей самой Meta в таблице нет.

В общем, авторы бенча смогли померить налог на верификацию результатов работы агента (через метрику User Correction). AI удешевил производство кода, но не доверие к изменениям, и "сколько раз человеку пришлось направлять агента" - неплохая оценка этого доверия. Практически это означает две вещи
1️⃣ Оценивать агентов стоит парой метрик - успех плюс стоимость руления, а не одним pass@1
2️⃣ Ваши собственные сессии с агентами - готовое сырье для таких проверок качества (evals): пайплайн «сессия → задача» в статье описан подробно, код открыт.

P.S.
Смежный whitepaper "SWE-Interact" от Scale AI, вышедший в тот же день, что SWE-Together, рассмотрен в следующем посте.

#AI #AI4SDLC #Engineering #Agents #Evals #Research

Matt Pocock про agent skills: как не свалиться в skill hell (Рубрика #AI4SDLC)

Посмотрел выступление Matt Pocock на AI Engineer "Building Great Agent Skills: The Missing Manual", в котором скиллы обсуждаются как инженерные артефакты: с классификацией, ценой поддержки и понятным критерием качества. Главная мысль, которую я оттуда забрал: хороший skill нужен, чтобы получить предсказуемый процесс из вероятностной системы. Не одинаковый ответ каждый раз, а одинаковый способ работы: когда подключаться, что прочитать, какие шаги пройти, где остановиться, что считать завершением. Такой подход лучше, чем стандартный взгляд на skills как на склад полезных инструкций, при котором быстро начинается skill hell: десятки файлов, пересекающиеся правила, старые заметки, непонятные триггеры, и в итоге агент то не вызывает нужный skill, то тащит в контекст лишнее, то преждевременно объявляет работу законченной.

У Pocock полезная рамка начинается с invocation - как skill вообще вызывается.
1️⃣ Model-invoked skill
У скилла есть описание, которое модель видит заранее и по которому может сама решить: "да, сейчас это нужно". За это надо платить контекстом, так как описание постоянно занимает место. Поэтому такой skill оправдан, только если агент действительно должен сам до него дотянуться.
2️⃣ User-invoked skill
Он не висит в контексте и вызывается человеком вручную. Это экономит токены и внимание модели, но перекладывает нагрузку на пользователя: нужно помнить, что такой skill существует. Если таких ручных skills стало слишком много, появляется отдельный router skill - не магический диспетчер, а человеческая карта, которая помогает выбрать нужный путь.

Дальше идет внутренняя анатомия skill. В ней, по сути, два вида материала:
1️⃣ Steps - действия, которые агент должен выполнить в порядке.
2️⃣ Reference - правила, определения, примеры, справка, которую агент читает по необходимости.

Хороший skill не обязан быть только процедурой. Он может быть набором reference-правил, как чеклист ревью. Или наоборот - почти чистой последовательностью шагов. Важно другое: материал должен лежать на правильном уровне информационной иерархии
- То, что нужно в каждом запуске, остается в SKILL.md
- То, что нужно только в отдельных ветках, уезжает в отдельные файлы и подгружается через context pointers
Это не просто экономия токенов, а способ не размазывать внимание агента.

В шагах должен быть определен критерий окончания - completion criterion, так агент отличит "готово" от "почти готово". "Разберись с проблемой" - плохой критерий. "Проверь все измененные модели, перечисли найденные расхождения и укажи, какие тесты это покрывают" - уже рабочее ограничение. Чем мутнее граница завершения, тем выше риск раннего завершения, когда агент зафиналит работу чрезмерно поспешно.

Отдельно Matt уделяет много внимания использованию leading words (например, название паттернов или архитектурных концепций). Это короткие слова-якоря, которые уже есть в предобучении модели и помогают стабилизировать поведение: не длинная повторяющаяся инструкция, а компактный термин, вокруг которого собирается нужный способ думать. Хороший leading word одновременно помогает invocation - агент чаще понимает, когда skill нужен, - и execution - агент внутри skill держится одного режима работы.

Ну и напоследок Matt говорит о том, как подчищать скиллы (pruning), так как они деградируют как документация: туда легче добавить новую строчку, чем удалить старую. Так появляются повторы, циклы и нерабочие инструкции.

Практический вывод отсюда простой: skill - это не промпт, а маленький продуктовый интерфейс к поведению агента. У него есть стоимость discoverability, стоимость поддержки, границы ответственности и failure modes. Его нужно проектировать почти как API:
- Понятный trigger;
- Один источник истины для каждого правила;
- Проверяемые completion criteria;
- Разделение steps и reference;
- Progressive disclosure для редких веток;
- Регулярная чистка no-op и устаревших инструкций.

#AI #AI4SDLC #Engineering #Agents #Software #Management

GitLab AI Accountability Report: код уже генерируют быстрее, чем умеют контролировать (Рубрика #AI4SDLC)

Разбирался с GitLab 2026 AI Accountability Report, который компания выпустила 23 июня 2026 года. Этот отчет хорошо продолжает линию GitLab Act 2, DORA ROI и недавнего Stack Overflow Pulse Survey: AI уже ускорил генерацию кода, но узкое место переехало в контроль, проверку и ответственность.

Исследование провел The Harris Poll для GitLab: 1 528 разработчиков и закупщиков в шести странах. Это важно читать как вендорский опрос, а не как независимый отчет, но результаты получились интересными: по данным GitLab, 91% организаций уже используют два или больше AI coding tools, 78% говорят, что разработчики стали быстрее писать и коммитить код, 60% считают ROI выше ожиданий. Если читать только эти числа, то видим оптимистичный взгляд на внедрение ... но ребята из GitLab приготовили нам AI парадокс: 79% респондентов согласны, что индивидуальная продуктивность разработчиков выросла, но общий процесс поставки софта ускорился не так уж сильно. То есть локальная скорость генерации не равна скорости поставки изменений. Код появляется быстрее, а очередь переезжает в review, валидацию, безопасность, комплаенс, развертывание и поддержку. Тут есть пара красивых цифр
1️⃣ 85% согласны, что AI сдвинул бутылочное горлышко от написания кода к его ревью и валидации.
2️⃣ 84% считают, что самая большая проблема с AI-генерированным кодом - не создание, а управление тем, что происходит с ним после генерации.

Это почти идеальная формулировка взрослого AI4SDLC - может ли инженерная система ответить на три вопроса про любую строку сгенерированного AI кода:
1) Откуда она взялась
2) Что должна была сделать
3) Кто отвечает за нее в production
Именно так GitLab определяет AI accountability

И тут у нас появляется разрыв между теорией и практикой (почти как в анекдоте про миллионеров). По данным GitLab, 87% уверены, что команда за 24 часа определит, участвовал ли код, сгенерированный AI, в прод инциденте. Но среди организаций, у которых за последний год уже был инцидент, 34% не смогли этого сделать. Причины выглядят примерно так
- 43% не могут надежно отличить AI-сгенерированный код от кода, написанного людьмы, в своей кодовой базе
- 40% упираются в фрагментированные инструменты;
- 39% работают с системами, которые не отслеживают происхождение кода;
только 28% говорят, что их SDLC-инструменты полностью интегрированы через общие данные и рабочие процессы.

Блок про governance тоже показательный. GitLab пишет, что 92% сталкиваются с какими-то governance challenges вокруг AI-кода, а 80% согласны: организация внедрила AI инструменты быстрее, чем разработала политики управления ими. 83% уже считают накопление AI-кода риском, которым нужно управлять сейчас; 44% называют это топовым технологическим риском.

Практически я бы забирал из отчета не вывод "купите governance tools" (хотя GitLab был бы не против такого вывода). Скорее важно спросить себя
- А можем ли мы для AI-сгенерированного изменения восстановить задачу, контекст, инструмент, автора/оператора, diff, review, тесты, security checks, approval, релиз, владельца сервиса и последствия в production?
- Если не можем, то скорость генерации уже стала обязательством, которое в моменте может как повышение продуктивности инженеров, а через полгода станет техническим долгом.

P.S.
Разбор исследования GitlLab есть на нашем сайте ai4sdlc-research.space, где вскоре мы заново запустим наше исследование AI4SDLC на этот раз про проникновение агентов в процессы разработки.

#AI #AI4SDLC #Engineering #DevSecOps #Management #Governance #Agents

DeepSeek в действии (DeepSeek in Action) (Рубрика #Books)

Наконец-то дочитал книгу "DeepSeek в действии", с которой все вышло забавно - она 1 июля 2025 года в ДМК Пресс, переводчиком был В. Яценков, а оригинал называется "DeepSeek in Action: LLM Deployment, Fine-Tuning, and Real-World Projects" от китайской "Лаборатории искусственного интеллекта будущего". Я прочитал первую часть почти сразу - буквально за пару дней после получения, а дальше она надолго зависла в стопке. А все дело в том, что она состоит из двух неодинаковых по качеству блоков

1️⃣ Почему DeepSeek вообще стал инженерным событием
В первом разбирается базовая архитектура Transformer и те доработки DeepSeek, которые полтора года назад всколыхнули индустрию: MoE, механизм внимания, оптимизация памяти и вычислений, обучение с переменной разрядностью, распределенная оптимизация. Это именно тот слой, ради которого книгу стоило открыть.
2️⃣ Как использовать API DeepSeek
Здесь авторы рассказывают банальщину про то, как генерировать тексты, решать математические задачи, писать код, собирать чат-клиенты. Я понимаю, зачем такие главы нужны массовому читателю, но читать их в 2026 году скучно. Вокруг LLM API все быстро становится commodity: endpoint, ключ, запрос, ответ, немного кеширования, очередное демо.

А вот первая часть достойна краткого упоминания, так как именно там авторы рассказывают про инженерные фокусы, что сейчас уже выглядят стандартом

1️⃣ MoE (mixture of experts) вместо плтоных (dense) моделей
У модели может быть очень много параметров, но для конкретного токена активируется только часть экспертов. В DeepSeek-V3, по technical report, всего 671B параметров, но активируются 37B. Масштаб растет, а вычисление остается разреженным.
2️⃣ Multi-head Latent Attention, MLA
Обычный Transformer на длинном контексте упирается в KV-cache: нужно хранить ключи и значения прошлых токенов, и это быстро становится дорогим по памяти. MLA сжимает Key-Value cache в latent vector. Это дает сильное сокращение KV-cache и рост throughput.
3️⃣ Auxiliary-loss-free load balancing
Авторы уходят от вспомогательного loss для балансировки экспертов, чтобы не портить качество основной задачи
4️⃣ Multi-token prediction
Это когда модель на обучении предсказывает не только следующий токен, а несколько следующих. Это попытка выжать больше качества и скорости из самой training objective.
5️⃣ Инженерные моменты
Авторы использовали FP8/mixed precision, распределенное обучение, параллелизм и коммуникация между GPU. По отчету DeepSeek-V3, модель предобучали на 14.8T токенов, а полный training обошелся в 2.788M H800 GPU hours. Эти цифры стоит читать как утверждение из технического отчета авторов, но именно они объясняют, почему DeepSeek так громко прозвучал: индустрия увидела не только качество модели, а заявку на другую экономику обучения.

На фоне такой первой части книги оставшиеся 250 страниц про использование API выглядят просто как текстовый заполнитель, который не ясно зачем читать:) особенно сейчас. И это показывает, что AI-книги устаревают не просто быстро, а еще и неравномерно. Даже сейчас архитектурная часть этой книги выглядит полезной, а остальное уже нет.

P.S.
Забыл упомянуть, что теперь ребята из ДМК Пресс переводят много китайских технических книг напрямую - у меня целая пачка сейчас в todo листе лежит, а пару я взял с собой в отпуск, так что может дальше напишу про рекомендательные системы на основе LLM:)

#Books #AI #DeepSeek #LLM #Engineering #Software #SystemDesign

Microsoft Frontier Company: AI-внедрение становится отдельной индустрией (Рубрика #AI4SDLC)

Разбирался со свежим анонсом Microsoft Frontier Company от 2 июля 2026 года, в котором Microsoft объявила новую бизнес-единицу на $2.5B и 6 000 экспертов, которых будут встраивать к клиентам для внедрения AI. Кажется, что этим анонсом Microsoft почти прямым текстом признает, что главное бутылочное горлышко корпоративного AI уже не в доступе к моделям, а в способности превратить AI в рабочую производственную систему.

Новая структура Microsoft Frontier Company - это отдельный операционный бизнес внутри Microsoft, который должен помогать клиентам делать Frontier Transformation: выбирать рабочие сценарии, проектировать AI-системы, внедрять их в реальные процессы и потом постоянно улучшать по бизнес-метрикам. Компания заявляет, что это "больше, чем FDE": не только forward deployed engineers, а смесь индустриальной экспертизы, менеджмента изменений, непрерывных улучшений и AI инжиниринга корпоративного уровня.

Механика похожа на старую идею Palantir FDSE (Forward-Deployed Software Engineer), но в масштабе гиперскейлера. Инженеры и отраслевые специалисты Microsoft должны работать рядом с командами клиента: ко-дизайн, ко-инновации, деплой решений и их дальнейшие улучшения. В качестве ранних примеров Microsoft приводит LSEG Workspace, Land O'Lakes, Unilever и Novo Nordisk. Партнерский слой тоже встроен сразу: Accenture, Capgemini, EY, KPMG, PwC и другие.

Цель у анонса в том, чтобы перевести клиентов из режима "мы купили доступ к моделям и сделали пилот" в режим "у нас есть измеримый ROI, governance, безопасность, понятная экономика и контур улучшения". В июньских текстах Microsoft это называлось Intelligence + Trust: с одной стороны, компания должна накапливать свой IQ - данные, процессы, экспертизу, решения; с другой - видеть, управлять, защищать и считать стоимость AI-систем через Agent 365, Foundry, Microsoft IQ, Entra, Purview, Defender и FinOps.

Отдельный продающий момент - это защита "customer IQ". Microsoft обещает, что данные, IP и конкурентное преимущество клиента не будут использоваться для обучения моделей так, чтобы превращать его дифференциацию в коммодити для всех остальных. Плюс компания говорит про гетерогенную открытую платформу с моделями от разных провайдеров: OpenAI, Anthropic, Microsoft AI, open source и специализированные модели под конкретные сценарии.

Интересно, что "открытая и model-diverse" платформа не отменяет того, что control plane, identity, observability, cost management, контекст и workflow могут оказаться глубоко завязаны на Microsoft stack. То есть vendor lock-in смещается: раньше он был в облаке и лицензиях, теперь он может быть в графе корпоративного контекста, агентных политиках, evals, т рейсах и привычках команд.

Индустриально это не одиночный ход
- 4 мая Anthropic вместе с Blackstone, Hellman & Friedman и Goldman Sachs объявила AI-native enterprise services firm
- 11 мая 2026 OpenAI объявила Deployment Company с FDE и $4B+ начальных инвестиций
- 30 июня AWS объявила $1B в Forward Deployed Engineering, чтобы встраивать тысячи экспертов к клиентам и доводить agentic AI до production
- Microsoft 2 июля отвечает масштабнее и ближе к своему сильному месту: enterprise platform + партнерская сеть + продажи + compliance.

Отсюда несколько последствий.

1️⃣ Consulting и systems integration входят в новую фазу
Accenture и другие интеграторы и консалтинговые фирмы не исчезают, но им придется работать не поверх нейтрального IT-рынка, а внутри платформенных экосистем OpenAI, Anthropic, AWS и Microsoft. Часть маржи и ownership за transformation layer будут забирать сами AI-поставщики.
2️⃣ Для компаний-клиентов "AI strategy" перестает быть презентацией про кейсы применения
Им теперь продают истории про операционную модель работы. Объясняют кто владеет агентами, где живет контекст, кто пишет evals, как считаются затраты, кто разрешает tool calls, как обновления выкатываются в production, что остается внутри компании после ухода внешней команды.
3️⃣ Меняется роль инженера
Ценным становится не только умение писать код или prompts, а связка domain + architecture + security + product thinking + change management. Forward deployed engineering в AI-эпоху - это не "консультант с ноутбуком", а человек, который может зайти в сложный бизнес-процесс, понять реальные ограничения, собрать production-систему и оставить после себя воспроизводимый pattern.

В общем, мы видим как рынок идет в сторону уровня развертывания решений. И кто сумеет встроить AI в реальные workflows, защитить корпоративные знания, измерить эффект и не отдать весь IQ поставщику, тот и получит преимущество. А кто просто купит внешний "AI transformation" как услугу, рискует получить красивый пилот и зависимость от чужой инженерной памяти.

#AI #AI4SDLC #Engineering #Agents #Bigtech #Management #Architecture

Dylan Patel про AI-inference и про ко-дизайн софта и железа как залог кратного роста (Рубрика #AI)

Посмотрел выпуск Sequoia Training Data с Dylan Patel, основателем SemiAnalysis: "Why Hardware-Software Co-Design Is AI's Real 100x". Вообще, я слежу за работами этой компании (например, я разбирал их крутую статью "The Great GPU Shortage"). Это интервью с основателем компании было взято буквально на днях и классно подсвечивает, что улучшения в возможностях genAI систем основаны на совместном дизайне моделей и железа: модель, kernels, runtime, сеть, память, чип и дата-центр нельзя оптимизировать как независимые детали. Отдельный рост в "2x" в моделях, "2x" в ядрах (kernels) и "2x" в железе могут дать не 8-кратный рост, а скачок на порядок больше (100x), если модели и железj проектируются вместе. Или, наоборот, хороший чип может выглядеть слабым, если модель и софт под него не подходят (аля новые модели на старых чипах).

Самый конкретный пример в выпуске - InferenceX, живой benchmark SemiAnalysis для inference. По словам Patel, point-in-time бенчи быстро устаревают: модели меняются почти каждую неделю, PyTorch, vLLM, SGLang, драйверы и inference-оптимизации обновляются постоянно, а одно измерение через месяц уже плохо описывает рынок. Поэтому InferenceX каждый день прогоняет модели на разных типах железа и строит не одну цифру "кто быстрее", а кривую throughput / interactivity.

Это интересный взгляд на баланс пропускной способности и скорости токенов на пользователя - у пакетных задач и интерактивных кодинговых агентов разные экономики
- Если пользователь ждет ответ в цикле обратной связи, то задержка дорогая: можно платить больше за fast mode, спекулятивный декодинг или меньший размер батча
- Если нужно ночью прогнать пачку документов, важнее tokens per second на единицу железа, а не мгновенная реакция.
Итого, оценивать "лучшую модель" и "лучшую железку" стоит относительно рабочих нагрузок, бюджета задержек и цены ошибки.

Дальше Patel интересно рассакзывает про топовые лабы и по его мнению OpenAI, Anthropic, Google и DeepSeek расходятся не только по качеству моделей, но и по архитектурной форме. Различаются значимые компоненты
- Размеры матриц для перемножения
- Структура внимания (attention)
- Структура экспертов в MoE (mixture of experts)
- Топология сети и пропускная способность памяти
- и так далее
В итоге, все это определяет где модель будет работать хорошо
По мнению Patel DeepSeek лучше ложится на Nvidia/Hopper/Blackwell-подобный мир (а теперь и Ascend от Huawei), TPUs сильны в других классах моделей, а Google оптимизирует Gemini под свои поколения TPU. В итоге, мы видим как модели становятся неотделимы от железа, на котором они будут жить.

Отсюда следует интересный взгляд на преимущества (moat) Nvidia, которое сегодня не сводится к тому, что все используют CUDA. Модели уже неплохо помогают писать кастомные ядра, а большие лаборатории давно могут форкнуть PyTorch или собрать свою инфраструктуру. Но важно, что все открытые модели, inference-провайдеры, RL-компании и downstream-экосистема часто оказываются оптимизированы под Nvidia просто потому, что там уже лежит масса рабочих моделей и обвязки. Если у Google появится сопоставимая открытая модельная экосистема под TPU, то ситуация может сместиться.

Мне кажется, это хороший антидот к простым разговорам про AI-железо. Каждый крупный игрок ищет оптимум для себя в связке model architecture + infrastructure software + silicon + power. Специализированный чип может быть прекрасным на одном участке пайплайна и неудачным через год, если архитектура моделей уехала в другую сторону. Поэтому стандартное железо для вычислений остается в мейнстриме не из-за лени рынка, а потому что даже большие лаборатории не всегда знают, какие модели будут запускать через год.

Патель дает интересные оценки и прогнозы, которые выглядят полезными для понимания этого рынка
- Стоимость inference на единицу качества падает примерно на 60x в год. Смысл в том, чтобы сравнивать надо не просто цену токена, а стоимость достижения сопоставимого уровня качества.
- Интеллект на Ватт растет не на 60x, но примерно на 40x в год
- Inference станет одним из крупнейших рынков в мире, возможно больше нефти. Это завязано на то, что ценность работы, которую AI сможет выполнять, станет огромной долей экономики
- К 2030 году OpenAI + Anthropic, по его прогнозу, могут иметь более 100 GW компьюта совместно, а потом к этому празднику жизни добавятся Meta, Google и остальные.
- К 2040 году inference deployments могут измеряться уже тераваттами, что следует из предыдущих прогнозов
- В 2030 году датацентры в космосе будут почти не важны: меньше 1% железа под инференс, а вот к 2040 году они займут потенциально больше половины инкремента компьюта

Итого, главный вывод из интервью такой, что AI-инфраструктура окончательно становится системной инженерией. Нельзя отдельно выбрать модель, отдельно купить железо, отдельно настроить serving и потом удивляться экономике. Нужно описывать классы задач, latency/cost curve, качество ответа, размер контекста, сетевые ограничения, доступную мощность, capital constraints и только потом решать, где нужен fast mode, где batch, где GPU, где TPU, где своя обвязка.

На практике это означает, что при построении AI продукта стоит мерить не "стоимость токена" вообще, а стоимость полезной работы на конкретном рабочем процессе. В одном месте дорогой быстрый токен окупается, потому что сокращает человеческий цикл обратной связи. В другом месте он просто сжигает бюджет.

#AI #Engineering #Architecture #Infrastructure #Bigtech #Software #SystemDesign

Stack Overflow Pulse Survey: AI-агенты уже в работе, но еще не автономны (Рубрика #AI4SDLC)

Разбирался с новым Stack Overflow Pulse Survey про agentic AI. Исследование вышло 27 мая 2026 года и опирается на опрос 1 100 разработчиков, проведенный в конце апреля. Основной результат в том, что агенты стали популярнее, но популярность растет не через полную автономию, а через довольно жесткий человеческий контрль (с human in the loop).

Доля респондентов, которые используют AI-агентов на работе с любой частотой, выросла с 31% в Developer Survey 2025 до 59% по сравнению с результатами большого опроса StackOverflow 2025 года. Приложил картинку из отчета, на которой тренд очень заметен.

Правда, 63% респондентов редко или никогда не разрешают агентам работать полностью автономно, а 60% блокируют неутвержденные системные изменения. То есть реальная картина пока не выглядит так, что агент сам делает работу от начала до конца - агент стартует работу, но права на действие остаются ограниченными. Он может писать, предлагать, искать, объяснять, собирать черновик решения. Но когда начинает менять состояния системы, появляется человек, approval, diff, CI, policy или другой gate. И это хорошо ложится в тренд про цикл верификации, который я упоминал раньше.

Интересно, что 68% респондентов предпочитают предсказуемые конфигурации с одним агентом, а не сложные мульти-агентные системы. Среди текущих агентных рабочих процуессов 69% респондентов используют одного агента (на иллюстрации указано 69%, а в тексе исследования 68% - хз кому верить:) ), 17% - несколько специализированных агентов, 16% - несколько пересекающихся или координируемых агентов. В общем, рынок любит красивые схемы с роем агентов, но практики пока выбирают одного агента, понятную задачу, видимый результат и меньше координационной магии.

Ежедневное использование отмечают 40% full-stack разработчиков, 52% архитекторов и 50% топ-менеджеров (senior executives, что попали в опрос StackOverflow - а это обычно инженерные лидеры). Но это самооценка аудитории пульс-опроса Stack Overflow, а не общая информация по индустрии. Самые устойчивые барьеры тоже ожидаемые: точность и безопасность. Траты стали менее болезненным ограничением: доля тех, кто считает стоимость барьером, снизилась с 53% в Developer Survey 2025 до 38% в пульс-опросе. А вот точность и безопасность остаются главными рисками, хотя доля сильно соглашающихся тоже снизилась: для точности с 57% до 47%, для безопасности с 56% до 44%.

Интересно, что AI достаточно полезен, чтобы стать стандартом де-факто, но пока недостаточно надежен, чтобы убрать human-in-the-loop. Деньги становятся операционным вопросом, а качество, безопасность и ответственность - архитектурным. Инструментальный ландшафт узнаваемый: GitHub Copilot, Claude Code, OpenAI Codex, Cursor, Replit, Lovable, v0, LangChain, LangGraph, OpenAI Agents SDK. Но для меня самый интересен интерес к observability/evals tooling - пользователи чаще хотят расширять использование таких инструментов, чем уже активно применяют их. Если агент становится частью production-системы разработки, ему нужны не только промпты и доступ к репозиторию. Нужны права, логи, evals, следы аудита, откаты, политики, ответственность и понятный способ доказать, что действие было безопасным.

P.S.
Разбор исследования StackOverflow есть на нашем сайте ai4sdlc-research.space, где вскоре мы заново запустим наше исследование AI4SDLC на этот раз про проникновение агентов в процессы разработки.

#AI #AI4SDLC #Agents #Engineering #Software #Management

Code of Leadership S2E3: Как создавать AI-продукты с Даниэлем Левинишниковым (Рубрика #AI)

Вышел новый выпуск моего подкаста Code of Leadership с Даниэлем Левинишниковым — продуктовым лидером, который занимается AI-продуктами в Т-Банке. Получился разговор не только про AI, но и про то, как вообще строить продукты в большой компании, как управлять командами на масштабе и что будет происходить с продуктовыми ролями в ближайшие годы. Кстати, у Даниэля есть свой канал https://t.me/tldrdaniel

Основными темами выпуска стали:
- Что такое AI-продукт и чем он отличается от обычного digital-продукта.
- Почему красивая AI-демка еще не означает, что продукт можно масштабировать.
- Как понять, нужен ли в задаче AI, или достаточно более простой эвристики.
- Какие метрики смотреть в AI-продуктах: cost saving, допродажи, user effort, evals и качество моделей.
- Почему в большой компании главная проблема не собрать прототип, а добиться качества на масштабе.
- Как устроены гейты, OKR и «венчурная» логика управления продуктовым портфелем.
- Почему лидеру в AI важны насмотренность, готовность быстро пивотиться и умение закрывать проекты без sunk cost fallacy.
- Как структурировать R&D, чтобы он не превращался в хаос.
- Почему FOMO в AI сейчас во многом оправдано.
- Что будет с продуктовыми командами, middle management и границами между ролями в мире AI-native разработки.

Отдельно интересно получилось про будущее команд. Даниэль считает, что продуктовые роли будут все сильнее схлопываться: продуктам придется глубже разбираться в разработке, аналитике и ML, а инженерам — в бизнесе, продукте и дистрибуции. Команды станут меньше, сильнее и более плоскими, а ценность «просто менеджмента» без сильных hard skills будет снижаться.

В финале обсудили переоцененные и недооцененные AI-тренды, ассистентов, автоматизацию supply в разных индустриях, Lovable, Cursor, moat в AI-продуктах, роль доменных знаний, network, дистрибуции и скорости.

В общем, мне кажется, что это хороший выпуск для продактов, инженеров, тимлидов, EM, руководителей и всех, кто пытается понять, как делать не просто AI-демки, а настоящие AI-продукты.

Выпуск доступен в разным местах: Youtube, VK Video, Podster.fm, Ya Music.

#AI #ProductManagement #Leadership #Management #AIProducts #Engineering #Startups #ML #LLM #CodeOfLeadership

System Design Space (Рубрика #Architecture)

Последние месяцы мало рассказывал про свой пет-проект system-design.space, но я не переставал над ним работать:)
По-факту, было 3 основных трека

1️⃣ Улучшение языка изложения - я хотел избавиться от runglish по всему сайту. Многие из вас говорили о том, что это мешает изучению материалов. В итоге, я сделал специальный подход с терминологическим словарем и рефакторингом проекта. Сейчас термин в первый раз внутри главы сопровождается английским термином в скобках + при наведении можно посмотреть расшифровку. Дальше по главе он идет уже на русском. Это касается почти всех терминов, но акронимы все равно остаются на английском

2️⃣ Добавление покрытия материалов по разным темам в основном вокруг проектирования ML/AI систем

3️⃣ Сборка книжки и подача ее в издательство - теперь у меня есть черновик, который возможно превратится в книгу.
В книге пока три основные части
- Принципы найма и проведения собесов в bigtech - мои статьи про найм у нас
- Принципы проектирования - тут тоже я пилил статьи и даже обучающие курсы по архитектуре
- Задачи на проектирование из домена ML/AI, описание и решение которых оформлено в том стиле, что мы используем внутри себя (по 7-шаговому фрймворку). Я выбрал задачки из этого домена для того, чтобы читатели разобрались на практике с тем, как работают эти технологии и что там нет магии, понимали их ограничения и рабочие режимы, а также лучше понимали как встраивать эти возможности в свои сервисы.
В книге есть еще 3 приложения
- Разборы других материалов на тему system design (книг и курсов)
- Немного про документалки о технологиях и зачем их смотреть
- Терминологический словарь
А в конце еще есть список ссылок на литературу

#SystemDesign #Architecture #Software #DistributedSystems #UX #Interview

AI Research OS: как second brain становится памятью для агентов (Рубрика #AI4SDLC)

Посмотрел выступление Paul Iusztin из Decoding AI (соавтор книги "LLM Engineer's Handbook") и Louis-François Bouchard из Towards AI (автор книги "Building AI Systems for Production") на канале AI Engineer: "Turn 10,994 Notes Into Memory". Оно мне зашло тем, что ребята решали проблему, с которой я сталкиваюсь часто сейчас: исследования на разные темы копятся, документы раскиданы по разным источникам и собирать контекст под новый вопрос не очень сложно. Я с этой проблемой борюсь разными способами, а тут авторы предложили свой, который я планирую попробовать.

Но сама постановка проблемы у авторов звучит как организация информации в том виде, который будет удобен для повторного использования в исследованиях. Codex, Claude Code, ChatGPT или NotebookLM могут быстро помочь с отдельной задачей, но если каждый новый сеанс заново восстанавливает источники, выводы и открытые вопросы, знания по исследованию не накапливается.

Для решения этой проблемы авторы создали проект "AI Research OS". По сути, это локальный слой памяти между вашим second brain и агентной обвязкой (agent harness). Не очередной чат с большим контекстным окном и не тяжелая RAG-инфраструктура с vector database. Идея более приземленная: обычные файлы, Markdown, index.yaml, сырые источники и wiki-слой, который агент может читать, пополнять и проверять.

Архитектура там простая и скучная:
- На входе - Obsidian, Readwise, NotebookLM, GitHub-репозитории, YouTube-транскрипты, ссылки, PDF и локальные файлы
- Система складывает неизменяемые raw-источники, строит индекс, а сверху генерирует wiki: страницы источников, concepts, entities, comparisons, overview, synthesis, open questions и log
- Агент сначала читает индекс, потом краткую wiki-страницу, потом производные страницы и только при необходимости лезет в полный raw-документ.

Интересно, что Paul отмечает, что его second brain с заметками в Obsidian работает как долговременная память и immutable snapshot (LLM не должен переписывать личные заметки). Вместо этого под конкретный проект создается отдельная research-wiki. В итоге имеем
- Second brain как архив архив
- Проектная wiki как рабочая память, из которой потом можно писать статью, делать слайды, разбирать кодовую базу или продолжать исследование через месяц.

Авторы сравнивают свой подход (через простое хранение файлов в репе) с другими
- NotebookLM полезен для чтения набора источников, но авторы считают его менее удобным для agent-native и coding-сценариев
- Vector database и полноценный RAG нужны в продуктовых системах, но для личного исследовательского OS это часто слишком много инфраструктуры (я кстати, сейчас тут в своем пет-проекте копаюсь, но там реально много движущихся частей получается)

Если вы решите попробовать подход авторов, то реализация открыта на GitHub под MIT-лицензией. В репозитории есть skills /research, /research-distill, /research-lint, /research-render, примеры с deep research, ingest GitHub-репозиториев и ingest обычных ссылок. По README, для старта нужен uv, Claude Code или Codex, а внешние CLI для Obsidian, Readwise и NotebookLM подключаются по мере необходимости. Для первых экспериментов с репозиториями и ссылками не нужно сразу тащить весь личный архив.

Отдельно авторы говорят о том, что в проекте они не планировали строить SaaS и есть задел для улучшений: не хватает коннекторов вроде Google Drive, Notion и Slack, слабее проработаны source provenance, оценка устаревания источников и memory compaction. Но в проекте видно, как устроена система, где можно вмешаться и что адаптировать под свой процесс.

P.S.
Выступление авторов мне понравилось, думаю, что потрогаю их систему и посмотрю как она работает для моих сценариев.

#AI #AI4SDLC #Engineering #Research #Software #Architecture

Шурик в Матрице. Полный фильм (Рубрика #Films)

Эта короткометражка просто топчик - супер-микс истории Матрицы, нашего контекста и героев из советских фильмов прошлого. В итоге, получается очень-очень круто. Рекомендую к просмотру, если еще не видели:)

Сегодня записывал интервью в рамках подкаста Code of Leadership со своим коллегой Даниэлем Левинишниковым из нашего AI Центра.
Мы успели поговорить про карьерный путь Даниэля, критерии хорошего AI продукта, как выглядит запуск такого продукта в корпорации, как выстроен менеджмент большой командой ML/AI специалистов, про лидерство в эпоху перемен и так далее. Пока интервью в обработке, но уже есть шортс про то, что middle management уже в опасности:) Кстати, примерно об этом я рассказывал в статье "От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)"

P.S.
На неделе опубликую интервью целиком:)

Евгений Кокуйкин про AI Security - AI Dev Podcast (Рубрика #AI4SDLC)

Посмотрел подкаст с AI Dev Conf, в котором участвовали Евгений Кокуйкин, Андрей Дмитриев и я. Мы поговорили о том, что происходит с безопасностью разработки, когда у нас кодяру начинают писать не только люди, но и агенты с разными инструментами, доступами и правами на изменения. Если говорить про гостя, то Евгений Кокуйкин - это CEO HiveTrace, со-основатель Raft, руководитель AI Security Lab в ИТМО и участник OWASP Agentic Security. То есть это точка зрения практика AppSec/AI security, который видит и технологию, и поверхность атаки.

Главная мысль выпуска крутится вокруг того, что в агентной разработке безопасность становится частью архитектуры процесса: кто действует, от чьего имени, какие права получает, что логируется, где нужен approval и как быстро можно откатиться. Наше общение можно разделить на отдельные блоки

1️⃣ Почему coding agents вообще так быстро продвинулись
В обычных GenAI-приложениях трудно понять, насколько ответ хорош: пользователь поставил палец вверх или вниз, но это слабая обратная связь. В разработке иначе. У нас уже есть компиляторы, линтеры, тесты, git-история, баг-трекеры, CI/CD и код-ревью. Можно взять старый баг, восстановить состояние репозитория, дать агенту задачу и проверить решение теми же тестами. SDLC уже содержит заготовку для evals. Отсюда растёт автономность. Агент может решить задачу, получить обратную связь от тестов, перезапустить попытку, передать изменения на ревью. Для внешнего клиента режим "попробуйте ещё раз" выглядел бы странно, а внутри разработки retry, тесты и ревью становятся нормальной частью контура.

Но дальше начинается неприятная часть. Если агент становится участником SDLC, его нельзя воспринимать как безобидную подсказку в IDE. Он похож на внутреннего сотрудника или сервисный аккаунт: identity, доступы, токены, возможность читать репозитории, дергать API, смотреть логи, иногда деплоить или помогать с инцидентами. Проблема service accounts и раньше была болезненной, но агентная разработка умножает её на порядок.

Часто разговоры про AI security быстро уезжают в область prompt injection, jailbreaks и красивых атак на модель. Но во многих реальных сценариях ломается более скучный слой: права доступа, секреты, supply chain, разделение dev/stage/prod, аудит действий и зависимости. Евгений приводил примеры из мира coding assistants, MCP-серверов, Postmark, LiteLLM и других supply-chain историй. Паттерн здесь прост: если агент или его инструмент подтянул заражённую зависимость, обычные unit tests могут ничего не заметить.

2️⃣ Экономика и метрики
Бизнесу легко пообещать "заменим половину разработки агентами", но реальность сложнее. Нужно считать не только токены и GPU, но и платформу: gateway, routing между моделями, sandboxing, аутентификацию, авторизацию, квоты, наблюдаемость. А бенефит нельзя сводить к количеству AI-кода: интереснее смотреть на конкретные job'ы внутри SDLC - миграции, багфиксы, ревью, тесты, инциденты, повторяемые изменения.

3️⃣ Надёжность
Если SRE-агент в 2 часа ночи может собрать анамнез инцидента, это полезно. Если он может сам перезапускать сервисы, менять конфигурацию или выполнять план восстановления, это уже другой класс риска. Если каждое опасное действие агента уезжает на senior approval, узкое место просто переехало к самым загруженным людям. Значит, нужны более тонкие политики риска: что агент может делать сам, где нужен второй контур проверки, где требуется изоляция среды, а где действие запрещено всегда.

4️⃣ Ответственность
Мы обсуждали агента почти как классическую пару принципала и агента (из теории управления): человек или компания задаёт цель, агент действует от их имени, а дальше появляются misalignment, побочные действия и вопрос "кто отвечает?". Эта логика из менеджмента теперь просачивается в технический контур одного инженера и его агентов.

Для инженеров главный вывод такой: AI security в SDLC - это не отдельная "галочка ИБ", а проектирование производственной системы. Нужны evals, threat modeling, least privilege, sandboxing, разделение сред, audit trail, model routing, контроль секретов, политика для non-human identities и наблюдаемость агентных действий.

И ещё более практично: если в компании появляются кодинговые агенты, то не стоит начинать с вопроса "какую модель выбрать", а с карты прав и последствий. Что агент читает? Что пишет? Какие инструменты вызывает? Может ли он достать данные? Может ли деплоить? Кто увидит его действия? Как остановить, откатить и расследовать результат? Без этих вопросов "ускорение разработки" очень легко превращается в ускорение риска.

#AI #AI4SDLC #Security #Engineering #Architecture #DevSecOps #Agents

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

Интересный анонс публичной беты Claude 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