State of AI4SDLC: как AI сдвигает узкие места процессов разработки

Уже в 21 мая в четверг я выступлю на конференции AI Dev Conf с этим докладом, где продолжу разговор о State of AI4SDLC . Сейчас уже всем ясно, что AI в разработке перестал быть просто экспериментом, так как он массово используется для всех основных сценариев: coding, review, planning, debugging и работы с документацией. И теперь вопрос в том, а как встроить ускорение отдельных сценариев вокруг в наш продакшен цикл разработки: с понятной целью, достаточным контекстом, корректной интеграцией, доверием к результату и измеримым эффектом.

Вообще, программа конференции получилась очень плотной и в этом большая заслуга программного комитета и организаторов (JUG.RU), к которой я тоже приложил руку, так как вхожу в ПК этой конфы.

P.S.
В конце конференции я еще буду модерировать круглый стол "Потребности ИТ vs. Возможности ИИ", где уважаемые доны
- Рафаел Тонаканян (Сбер)
- Андрей Кулешов (Yandex, SourceCraft)
- Алексей Тотмаков (VK Tech)
обсудят вопросы внедрения AI инструментов и оценки результатов такого внедрения (условно на какие метрики стоит смотреть или не стоит).

#AI #Engineering #Architecture #ML #Software #Economics #Software

Empire of AI (Рубрика #Books)

Дочитал вчера книгу "Empire of AI" от Karen Hao, которую купил в Foyles во время поездки в Лондон. Вообще мне было сложно оторваться от чтения этой книги и пока летел в Москву я прочел ее на треть - вроде бы ты уже знаешь основные события вокруг OpenAI, но в связном рассказе они начинают выглядеть совсем иначе. В этой книге речь не про ChatGPT как продукт и про то, как устроены трансформеры. Скорее она про ранние годы GenAI-революции и про компанию, которая оказалась в странном положении: одновременно исследовательская лаборатория, стартап, идеологический проект, инфраструктурный клиент Microsoft и организация, заявляющая, что строит технологию с рисками для всего человечества. Мне особенно понравились следующие моменты

1️⃣ Динамика основания OpenAI
В ретроспективе легко думать, что все шло по прямой: собрались умные люди, взяли много compute, сделали GPT, потом ChatGPT, дальше все понятно. Но из книги хорошо видно, что прямой дорожки там не было. Были амбиции, страх перед концентрацией AI у больших компаний, конфликтующие представления о миссии, деньги, эго, исследовательская неопределенность и очень быстро меняющаяся реальность.

2️⃣ Трение между Илоном Маском и Сэмом Альтманом
Это не просто драматическая деталь для биографии. Через этот конфликт лучше видно, насколько разные модели власти и контроля могут стоять за одной и той же публичной риторикой про “безопасный AI для человечества”. Кто принимает решения? Кто владеет рычагами? Кто определяет, что значит безопасность? В AI-компаниях эти вопросы не второстепенные, а архитектурные. Интересно, что буквально на днях закончился суд между Максом и OpenAI на тему конвертации из non-profit организации в коммерческую

3️⃣ Политические истории про внутренние “кланы” OpenAI: Applied, Research и Safety
Для меня это один из главных инженерно-управленческих слоев книги. Applied тянет к продукту, пользователям и развертыванию продуктов. Research двигает frontier и живет логикой научного прорыва. Safety пытается удержать под контрлем вопрос последствий и рисков. По отдельности все три культуры понятны и нужны. Но в одной компании они создают постоянное напряжение: скорость против осторожности, продукт против исследования, миссия против рынка.

4️⃣ Партнерство с Microsoft
Книга помогает почувствовать, что прорывы GPT были не только результатом моделей и данных. Это еще история про инфраструктуру, поиск капиталов, доступ к compute, способность превращать research в работающую систему и выдерживать темп, на котором обычные организационные процессы начинают разваливаться. Без этого слоя легко романтизировать AI как чистую науку, хотя на практике frontier двигает связка research, infra, product, funding и distribution.

5️⃣Кризис с советом директоров
Я хорошо помнил его как новостной хаос: увольнение Альтмана, возвращение, давление сотрудников, Microsoft на фоне, странные заявления и почти полная непрозрачность. Но в книге этот эпизод читается не как внезапная авария, а как результат противоречий, которые копились с самого начала: nonprofit-миссия, коммерческая реальность, safety-опасения, персональная власть и цена лидерства на frontier.

Отдельно стоит отметить, что эта книга подает историю с авторской точки зрения Karen Hao, которая закончила MIT и работала долго журналистом, освещая события в сфере технологий и AI. В итоге, она провела целое расследование в 300+ интервью и собрала кучу материалов, чтобы суметь оценить то, что происходило за закрытыми дверями компании OpenAI:)

Рекомендую книгу всем, кто хочет понимать GenAI не только как набор моделей, бенчмарков и API, но как систему людей, власти, инфраструктуры и организационных компромиссов. Особенно полезно инженерам, руководителям и архитекторам: после этой книги лучше видно, что frontier двигается не только в лаборатории, но и в структуре компании.

#Books #AI #OpenAI #Engineering #Management #Research

Gemini 3.5: Google делает ставку на агентные workflow (Рубрика #AI)

Посмотрел вчерашний анонс Gemini 3.5 с Google I/O. Формально Google опубликовала его 19 мая 2026 года, и мне кажется, важная часть здесь не в очередной гонке benchmark'ов, а в том, как компания формулирует следующий слой применения моделей. Если коротко, то Google представила семейство Gemini 3.5 и начала с 3.5 Flash. А модель 3.5 Pro, по словам Google, уже используется внутри компании и должен пойти в rollout в следующем месяце. Интересно, что Flash больше не выглядит как “быстрый младший брат” большой модели. Его прямо позиционируют как модель для frontier-level agents and coding.

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

По утверждению Google, 3.5 Flash обходит Gemini 3.1 Pro на ряде кодинговых и агентных бенчей: Terminal-Bench 2.1, GDPval-AA, MCP Atlas, CharXiv Reasoning. Google также говорит про скорость вывода до 4x относительно других frontier-моделей. Интересно проверить эти заявления на в собственных сценариях, но по бенчам ожидания от модели большие.

Если смотреть на саму модель, то видно, что сделана ставка на long-horizon tasks. В посте Google много примеров не про “ответь на вопрос”, а про “сделай работу”: поддержка codebase, подготовка финансовых документов, анализ неструктурированных ассетов, миграция legacy codebase, генерация интерактивных UI, параллельные подходы к UX-задачам. Это уже не чат как интерфейс к модели, а модель как исполнитель внутри workflow.

Отдельно интересно, как они описывают Antigravity (это их IDE, что круто умеет в фронтовые задачи). В связке с обновленным harness 3.5 Flash должен запускать коллаборативных субагентов и выполнять многошаговые кодинговые задачи под наблюдением. По сути, Google двигает идею supervised execution: модель не просто предлагает фрагмент решения, а становится оркестратором набора действий, которые человек или система контролируют.

Enterprise-примеры тоже показательные. Shopify использует субагентов для долгого анализа данных, Macquarie Bank пилотирует онбординг по документам на 100+ страниц, Salesforce интегрирует Flash в Agentforce, Ramp применяет мультимодальное понимание к распознаванию инвойсов , Xero автоматизирует многошаговые налоговые workflows, Databricks смотрит в сторону диагностики проблем в сложных data environments. Это, конечно, кейсы из материала Google, но они хорошо показывают направление: модели тащат в рутину компаний, где много документов, данных, проверок и tool calling.

Еще одна важная деталь: Google несет agentic слой не только в инструменты для разработчиков. 3.5 Flash становится дефолтной моделью в Gemini app и AI Mode in Search, а новый Gemini Spark описан как персональный AI агент, который работает 24/7 и действует по указанию пользователя. То есть одна и та же логика идет сразу в три стороны: разработчики, enterprise и массовые пользовательские продукты.

Про safety тоже стоит сказать осторожно. Google пишет про Frontier Safety Framework, усиленные кибер и CBRN (Chemical, Biological, Radiological, and Nuclear) safeguards, более продвинутое safety training и interpretability tools. Это правильные слова, но реальную безопасность мы увидем, когда модель попадет в руки миллионов пользователей, разработчиков и остальных желающих.

В общем, Gemini 3.5 показывает, что гонка топовых лаб смещается к агентной модели, где фронтир модели используются для выполнения автономных задач, через декомпозицию их на части, использование инструментов, запуск субагентов, поддержку контекст и все остальное ... для того, чтобы доводить работу до конца:)

#AI #Google #ML #Engineering #Software #Management #Agents

Билеты на AI Dev Conf (Рубрика #Conference)

Я вхожу в программный комитет конференции AI Dev Conf, а заодно и выступаю на этой конференции с keynote докладом про "State of AI4SDLC". Сама конференция пройдет уже завтра, а у меня есть пара билетиков, что я готов раздать подписчикам канала. Для того, чтобы претендовать на билетик вам надо порекомендовать мне в комментариях интересные whitepapers про внедрение AI в разработку, метрики и результаты. Но важно не просто накидать whitepapers, но и объяснить почему они вам понравились и какие интересные инсайты вы из них почерпнули. В конце этого дня я определю двух победителей и отправлю им билетик в личку.

#AI #Engineering #Architecture #ML #Software #Economics #Software

Spec-driven development (SDD): почему AI вернул спецификации в разработку (Рубрика #Engineering)

Горячая тема spec-driven development мне кажется реинкарнацией старых подходов типа бородатых V-Model или RUP, что в районе двухтысячных использовались для описания инженерных процессов. Мне стало интересно поразмышлять, а почему так происходит и так появилась этот пост:)

Старый spec-driven подход был про то, что сначала нужно описать требования, потом дизайн, потом реализацию, потом проверку. V-Model хорошо показывала эту симметрию: каждому уровню проектирования соответствует свой уровень validation/verification. Плюсы были в трассировке от требований к коду и проверяемости ожиданий, а минусы были в бюрократии и разрыве между документами и кодом.

С AI ситуация поменялась. Спецификация стала рабочим интерфейсом между человеком и агентом. Если код пишет или сильно помогает писать агент, то главный вопрос уже не “как быстро я напишу реализацию руками”. Главный вопрос: насколько точно я могу сформулировать intent, ограничения, критерии приемки и способ проверки результата. Агенту мало сказать “сделай фичу”. Ему нужен контекст: что должно измениться, что не должно сломаться, какие сценарии считаются успехом, какие тесты запустить, где границы задачи.

Поэтому современный spec-driven development выглядит примерно так:
intent -> acceptance criteria -> plan -> tasks -> implementation -> verification.

Теперь документы становятся исполняемым контекстом для агента. Спека используется для составления плана, план раскладывается на задачи, задачи делегируются, тесты и логи становятся доказательством работоспособности, а review проверяет не только diff, но и соответствие исходному намерению.

Есть разные подходы к этому снаряду

1️⃣ GitHub Spec Kit прямо формулирует SDD как процесс “сначала определить, что строить, потом дать AI coding agent реализовать”. Там есть цепочка spec -> plan -> tasks -> implement, checklists, clarify/analyze шаги и интеграции с разными агентами. Тут соль в agent-agnostic идее: спецификация становится переносимым контрактом, а не промптом для одного IDE.

2️⃣ Kiro от AWS идет похожим путем, но более продуктово. У них spec обычно раскладывается на requirements.md, design.md, tasks.md; отдельно есть steering-файлы для постоянного знания о проекте: архитектура, стек, conventions, структура. Это уже очень похоже на попытку сделать из AI coding управляемый процесс разработки feature или bugfix.

3️⃣ Codex и подход harness engineering показывают третий вариант. Там важны AGENTS.md, знание репозитория, configured dev environment, тесты, логи, PR review и возможность запускать несколько задач параллельно. В таком мире prompt начинает напоминать хорошо написанный GitHub issue: цель, контекст, ограничения, expected behavior, команды проверки.

4️⃣ Есть и lightweight-вариант, который, кажется, сейчас самый практичный для многих команд: PRD/RFC/issue + acceptance tests + CI + agent instructions. Без отдельного фреймворка. Главное, чтобы у задачи был четкий “definition of done”, а агент мог доказать, что он его достиг.

На практике это дает несколько преимуществ
- Меньше неопределенность - агент хуже всего работает там, где человек сам не решил, чего хочет
- Большие задачи проще делегировать - их можно резать на независимые кусочки и проверять по частям
- Появляется трассировка между намерением, дизайном решения, задачами и тестами
- Review перестает быть только чтением diff'а - он становится проверкой: “достигли ли мы цели, которую сами же сформулировали?”

Правда, не все так безоблачно - spec-driven development (SDD) сам по себе не гарантирует качество. Пeлохая спецификация просто быстрее производит неправильный код.

#Engineering #AI #Software #Architecture #Management #DevTools #Agents #ML #SystemDesign

AI Dev Podcast #2: Александр Поломодов, Сергей Баранов / Архитектура в эпоху ИИ (Рубрика #Architecture)

Около месяца назад мы записывали подкаст вместе с Сергеем Барановым (основателем ArchDays) и Андреем Дмтриевым (со-основателем JUG.RU) в рамках подготовки к сегодняшней конфе AI Dev Conf. Так получилось, что дальше я уехал в отпуск и забыл поделиться с вами этим эпизодом, а он был интересным:) Речь в нем шла про то, как LLM и мультиагентные системы меняют software architecture и инженерные процессы. Обсудили двойственную природу ИИ: с одной стороны - демократизация разработки (через lovable.dev и аналоги), с другой - жесткая необходимость в инженерном фундаменте для масштабирования.

Основными темами выпуска стали
- От SOE 1.0 к SOE 2.0: как люди и агенты будут работать в связке.
- Роль архитектора: больше не "чертежник", а стратег, валидирующий варианты от ИИ и выстраивающий внутренние модели.
- Экономика: почему типовые решения уходят в автоматизацию, а ценность повторного использования компонентов взлетает до небес.
- Болевые точки: бардак с данными и онтологиями, блокирующие зависимости между сервисами и проблема контекста.
- Прогноз: как готовить платформу к "мажорной разработке" с агентами и почему локальные эксперименты с моделями станут базовым навыком архитектора.

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

#AI4SDLC #AI #Engineering #Software #Processes #Management #Productivity

Почему AI делает инфраструктуру управленческой темой (Рубрика #AI)

Пару дней назад вышла статья РБК про то, почему бизнес выбирает гибридную инфраструктуру. В этом интервью РБК от 19 мая генеральный директор Yandex Cloud Григорий Атрепьев говорит, что рынок корпоративного ПО в России по итогам 2025 года вырос до 808 млрд руб., а два главных фактора изменения рынка сейчас - информационная безопасность и искусственный интеллект.

А сегодня я весь день преподаю в рамках программы ВШЭ “ИИ-лидеры: бизнес-лаборатория для руководителей” и рассказываю менеджерам про облака, DataOps, MLOps и AIOps. И эта статья отлично попадает в главный тезис моего рассказа: AI в компании начинается не с красивой демки модели. Он начинается с инфраструктуры, данных, безопасности, эксплуатации и управленческой готовности довести пилот до промышленного внедрения.

Если возвращаться к тезисам Григория из статьи то они примерно такие

1️⃣ Искусственный интеллект и информационная безопасность - это комбо-связка. С одной стороны, компании живут в более агрессивной среде: по словам Yandex Cloud, в прошлом году они обрабатывали 103 млрд событий ежедневно в собственной SIEM-системе, в три раза больше год к году. С другой стороны, AI уже перестал быть только экспериментом: на платформе, по данным компании, создано более 18 тыс. агентов.
2️⃣ Дальше начинается самое интересное для менеджеров. AI быстро превращается в инфраструктурную задачу. Растет спрос на GPU, по исследованию Yandex Cloud и Apple Hills Digital среднегодовой темп роста этого сегмента до 2030 года оценивается в 23%. Меняются требования к ЦОД: если раньше стойка могла потреблять 5-6 кВт, то сейчас для AI-нагрузок речь идет уже о 100 кВт и выше.
3️⃣ На этом фоне гибридная инфраструктура выглядит не как компромисс “между облаком и своим железом”, а как рабочая модель зрелой компании. Публичное облако дает скорость экспериментов, быстрые пилоты и гибкое потребление ресурсов. Частный контур нужен там, где есть чувствительные данные, регуляторные ограничения, требования ИБ и уже сложившиеся корпоративные системы.
4️⃣ Но гибридность не достается бесплатно. В статье хорошо перечислены барьеры: разные инструменты и навыки, Kubernetes, API, мониторинг, синхронизация, резервное копирование, безопасность. А с AI добавляется новый слой: нужно контролировать агентов в корпоративных системах, разграничивать доступ к данным, защищать протоколы и наблюдать цепочки действий. Observability становится не только темой SRE, но и темой управления AI-рисками.

В общем, управленческий вывод такой: AI-проекты чаще ломаются не на выборе или доступе к вашей любимой модели. Они начинаю буксовать на качестве данных, доступности инфраструктуры, отсутствии сильного бизнес-спонсора, непонятной модели ответственности и неспособности превратить пилот в повторяемый процесс. Поэтому менеджерам важно понимать не только "какую нейросеть купить". Важно понимать, какой контур данных, облаков, MLOps/AIOps, ИБ, мониторинга и эксплуатации нужен, чтобы AI не остался презентацией на несколько сотрудников, а стал частью корпоративной системы.

#AI #Cloud #DataOps #MLOps #AIOps #Management #Engineering

Root Cause: Stories and Lessons from Two Decades of Backend Engineering Bugs (Рубрика #Books)

Прочитал несколько глав книги Хусейна Нассера, популярного блоггера (500к подписчиков на канале), что рассказывает про software engineering. Брался я за нее из простого интереса почитать не просто про архитектуру, базы данных и распределенные системы, а скорее про то, как все это ломается на проде. Собственно, эти истории автор и обещает в описании своей книги. Автор считает, что опыт инженера измеряется не только годами, количеством фичей или строк кода, а количеством багов, которые он смог воспроизвести, отследить до root cause и исправить. Это звучит почти банально, пока не вспоминаешь, сколько настоящего инженерного знания приходит именно из таких расследований: где-то узнал, как браузер ограничивает HTTP/1.1 connections, где-то разобрался с HPACK в HTTP/2, где-то впервые увидел, как file descriptor limit превращается в 504 Gateway Timeout.

Мне эта книга напомнила опыт, когда я сам работал с инцидентами, писал или разбирал постмортемы, а также как-то руководил секций траблшутинга для SRE-инженеров, что хотели попасть к нам в компанию и в итоге сделал пару публичных выступлений и статей (они сейчас есть на моем сайте system-design.space: описание самого подхода к интервью и пример такого интервью).

Если же возвращаться к самой книге, то я прочел несколько глав и вот о чем они

1️⃣ История про системное замедление системы.
Пользователи видят, что весь продукт стал медленным. Не один endpoint, не одна кнопка, не один сценарий, а как будто “все плохо”. В итоге расследование приводит к маленькому UI-элементу: поисковая строка показывает текст вроде “Search 550M items”, а JavaScript дергает API, который выполняет SELECT COUNT(*) по огромной таблице. Причем делает это снова и снова. В трейсе обнаруживается больше 100 тысяч таких запросов за 30 минут.

Хорошая деталь здесь в том, что простой ответ “добавим CPU базе” был бы неправильным. Да, база была перегружена по CPU. Но причина была не в том, что база “слабая”, а в том, что продуктовый UI породил бессмысленную backend-нагрузку. Настоящее исправление — не вертикально масштабировать симптом, а убрать саму необходимость считать точное число там, где пользователю достаточно приблизительного.

2️⃣ Истории про live translation system, HTTP/1.1, HTTP/2 и load balancer
И это, кажется интересная часть для архитекторов и технических руководителей. Сначала long-lived SSE-сессии упираются в браузерный лимит соединений на один host: седьмой запрос просто висит в client-side queue. Потом включение HTTP/2 решает эту проблему, но приносит другую: много маленьких запросов, TLS, frame parsing, stream state и HPACK начинают съедать CPU на backend. Потом появляется load balancer, backend переводят обратно на HTTP/1.1, статические ресурсы кэшируются, все становится лучше — пока unlimited backend connection pool не упирается в file descriptors и TCP receive window.

То есть книга хорошо показывает неприятную, но реальную картину: архитектурное улучшение редко бывает “просто улучшением”. Оно меняет профиль отказов. HTTP/2 убирает один bottleneck, но добавляет CPU overhead. Load balancer разгружает backend, но приносит новые настройки и новые default values. Увеличение лимита file descriptors помогает, но не объясняет, почему столько соединений вообще было создано.

В общем, книга действительно неплохо описывает реальность траблшутинга проблемы по всему стеку и поиск root cause проблемы. Она будет полезна инженерам, кто хочет не просто рассказывать про крутую архитектуру, но и понимать как разные компоненты могут работать друг с другом, если что-то пойдет не так. В итоге, книга напоминает скорее инженерный блог по разбору инцидентов, чем обычный академический учебник и может быть полезна еще и SRE инженерам для подготовки к тем же собеседованиям.

#Books #Engineering #Software #Architecture #Management #SRE