T-Meetup: R&D во Владивостоке (Рубрика #RnD)
Большую часть этой недели я провел с коллегами из RnD центра в нашем центре разработки во Владивостоке (тут очень красиво и вкусно кормят:)). А сегодня вечером в качестве прошел RnD митап, в программе которого было три доклада об отличиях RnD деятельности от просто разработки и пара конкретных кейсов реальных исследований
1) «Почему существуют задачи, которые нельзя решить обычной разработкой?» от Станислава Моисеева, директора инженерных исследований в Т-Банке (мы вместе прилетели из Москвы)
2) «Code Knowledge Graphs как память для LLM» от Михаила Бадерика, rnd инженера из нашего центра во Владивостоке
3) «Эволюционные агенты на практике: open-source и реальные задачи» от Даниал Матиенко, rnd инженера из нашего центра во Владивостоке
Про доклад Стаса я хотел рассказать отдельно, так как он в принципе рассказывал про концепцию research & development в крупных IT-компаниях, в частности в Т-Банке.
Началось все с того, что Стас показал как RnD отличается от продуктовой разработки:
— Продуктовая разработка отвечает на вопрос «что и как сделать», используя готовые «инструкции»
— R&D отвечает на вопрос «можно ли это сделать в принципе?» - это про закрытие технологических рисков путем проверки гипотез и разработки новых методов и технологий
В разных странах к RnD подходят по-разному
— США: Модель, основанная на большом капитале. Включает стартапы, корпоративные исследовательские центры (Apple — закрытый, Microsoft Research — фундаментальный, Google — гибридный) и сильные университетские лаборатории. Кстати, в конце 2023 года мы разбирали подход Google в подкасте (Стас тоже участвовал в качестве гостя) и гибридность подхода в том, что они глубоко интегрируют исследовательские команды в продуктовые процессы. Их ключевой принцип — reseasrch-команда с первого дня пишет продакшн-код, чтобы избежать отрыва исследований от практики и ускорить внедрение.
— Китай: Модель, основанная на кооперации и государственном влиянии. Характеризуется тесным сотрудничеством компаний и университетов, централизованным планированием и значительными государственными инвестициями (пример: Huawei тратит более 20% выручки на R&D).
— Россия: Исторически сильная модель с отраслевыми НИИ. Сегодня исследования все больше перемещаются внутрь крупных IT-компаний. Потребность в импортозамещении и бурное развитие ИИ стимулируют рост инвестиций в R&D.
Дальше Стас рассказал про направления инженерного RnD в Т-Банке
1. Инженерная продуктивность: Разработка инструментов на базе ИИ для повышения эффективности инженеров. Примеры: сервис для CodeReview, генератор юнит-тестов, инструмент Data Scout для автоматического сбора датасетов.
2. Анализ больших графов: Создание собственной платформы для обработки графов, которые не помещаются в оперативную память. Это необходимо для решения задач в области рекомендаций, антифрода и инфраструктурного анализа.
3. Оптимизация платформы данных: Разработка методов ускорения SQL-запросов за счет аппроксимированных вычислений на сэмплированных данных, что позволяет достигать 10-кратного ускорения при сохранении 99% точности.
4. Оптимизация логистики: Применение иерархических алгоритмов кластеризации для оптимизации маршрутов курьеров. Внедрение в 16 регионах уже позволило сократить километраж на 9%.
5. Блокчейн: Направление, связанное с анализом транзакций, выявлением мошенничества и созданием инвестиционных инструментов на базе распределенных реестров.
Завершил свой рассказ Стас тем, что для успеха R&D-команд необходимы не только бюджет и сложные задачи, но и разумные сроки, талантливая команда и культура, предоставляющая исследователям достаточную степень свободы.
Ну и если подбивать полезные идеи из доклада, что можно забрать себе, то они примерно такие
1. Оценивайте технологические риски при запуске новых продуктов
2. Интегрируйте исследования и разработку (избегайте создания оторванных исследовательских команд)
3. Изучайте открытые публикации
4. Ищите возможности для оптимизации
5. Создавайте правильную культуру
#RnD #Engineering #Software #Management #Leadership
Большую часть этой недели я провел с коллегами из RnD центра в нашем центре разработки во Владивостоке (тут очень красиво и вкусно кормят:)). А сегодня вечером в качестве прошел RnD митап, в программе которого было три доклада об отличиях RnD деятельности от просто разработки и пара конкретных кейсов реальных исследований
1) «Почему существуют задачи, которые нельзя решить обычной разработкой?» от Станислава Моисеева, директора инженерных исследований в Т-Банке (мы вместе прилетели из Москвы)
2) «Code Knowledge Graphs как память для LLM» от Михаила Бадерика, rnd инженера из нашего центра во Владивостоке
3) «Эволюционные агенты на практике: open-source и реальные задачи» от Даниал Матиенко, rnd инженера из нашего центра во Владивостоке
Про доклад Стаса я хотел рассказать отдельно, так как он в принципе рассказывал про концепцию research & development в крупных IT-компаниях, в частности в Т-Банке.
Началось все с того, что Стас показал как RnD отличается от продуктовой разработки:
— Продуктовая разработка отвечает на вопрос «что и как сделать», используя готовые «инструкции»
— R&D отвечает на вопрос «можно ли это сделать в принципе?» - это про закрытие технологических рисков путем проверки гипотез и разработки новых методов и технологий
В разных странах к RnD подходят по-разному
— США: Модель, основанная на большом капитале. Включает стартапы, корпоративные исследовательские центры (Apple — закрытый, Microsoft Research — фундаментальный, Google — гибридный) и сильные университетские лаборатории. Кстати, в конце 2023 года мы разбирали подход Google в подкасте (Стас тоже участвовал в качестве гостя) и гибридность подхода в том, что они глубоко интегрируют исследовательские команды в продуктовые процессы. Их ключевой принцип — reseasrch-команда с первого дня пишет продакшн-код, чтобы избежать отрыва исследований от практики и ускорить внедрение.
— Китай: Модель, основанная на кооперации и государственном влиянии. Характеризуется тесным сотрудничеством компаний и университетов, централизованным планированием и значительными государственными инвестициями (пример: Huawei тратит более 20% выручки на R&D).
— Россия: Исторически сильная модель с отраслевыми НИИ. Сегодня исследования все больше перемещаются внутрь крупных IT-компаний. Потребность в импортозамещении и бурное развитие ИИ стимулируют рост инвестиций в R&D.
Дальше Стас рассказал про направления инженерного RnD в Т-Банке
1. Инженерная продуктивность: Разработка инструментов на базе ИИ для повышения эффективности инженеров. Примеры: сервис для CodeReview, генератор юнит-тестов, инструмент Data Scout для автоматического сбора датасетов.
2. Анализ больших графов: Создание собственной платформы для обработки графов, которые не помещаются в оперативную память. Это необходимо для решения задач в области рекомендаций, антифрода и инфраструктурного анализа.
3. Оптимизация платформы данных: Разработка методов ускорения SQL-запросов за счет аппроксимированных вычислений на сэмплированных данных, что позволяет достигать 10-кратного ускорения при сохранении 99% точности.
4. Оптимизация логистики: Применение иерархических алгоритмов кластеризации для оптимизации маршрутов курьеров. Внедрение в 16 регионах уже позволило сократить километраж на 9%.
5. Блокчейн: Направление, связанное с анализом транзакций, выявлением мошенничества и созданием инвестиционных инструментов на базе распределенных реестров.
Завершил свой рассказ Стас тем, что для успеха R&D-команд необходимы не только бюджет и сложные задачи, но и разумные сроки, талантливая команда и культура, предоставляющая исследователям достаточную степень свободы.
Ну и если подбивать полезные идеи из доклада, что можно забрать себе, то они примерно такие
1. Оценивайте технологические риски при запуске новых продуктов
2. Интегрируйте исследования и разработку (избегайте создания оторванных исследовательских команд)
3. Изучайте открытые публикации
4. Ищите возможности для оптимизации
5. Создавайте правильную культуру
#RnD #Engineering #Software #Management #Leadership
❤7🔥7👍6
Noise: A Flaw in Human Judgment (Шум. Несовершенство человеческих суждений) (Рубрика #Books)
Дочитал недавно книгу "Шум" от трех авторов Канемана, Сибони и Санстейна, в которой уважаемые ученые говорили о том, что плохие решения возникают не только из-за bias, то есть систематического смещения, но и из-за вариативности: разные люди или один и тот же человек в разные моменты дают разные решения там, где решения должны быть одинаковыми.
Для меня эта книга далась тяжело - я ее читал больше года и это связано с парой моментов
1️⃣ Авторы затянули книгу до 500+ страниц, хотя основная содержательная часть легко умещалась в 250 страниц и она была про разложение ошибки
— на среднюю ошибку — average error или bias
— и на дисперсию — variability of error или как раз шум, с которым предлагают бороться авторы
2️⃣ Книга является совместным творчеством трех авторов и консистентного и единого авторского голоса нет. Даниэль Канеман, Нобелевский лауреат, задал рамку для книги и дал большие буквы для обложки — все-таки он автор книги "Thniking, Fast and Slow" ( я ее уже разбирал раньше). Второй автор - Оливье Сибони - больше четверти века был сотрудником McKinsey и он принес консалтингово-организационный опыт и тему качества стратегических решений в книгу. А Касс Санстейн добавил редакционной поддержки.
Если говорить про основные слои книги, то их два
1️⃣ Статистический
Если все судьи, интервьюеры или архитектурные ревьюеры в среднем правы, но каждый раз дают сильно разные ответы, система все равно не очень
2️⃣ Организационный
Большинство компаний не измеряют разброс. Они верят, что их ведущие специалисты примерно одинаково рассуждают, но это часто иллюзия.
Авторы предлагают смотреть на систему принятия решений как на процесс измерений. Если у вас десять термометров на одном столе показывают разные температуры, вы не говорите “какой интересный плюрализм мнений”; вы калибруете приборы. Авторы предлагают так же смотреть на людей в профессиональных системах принятия решений: найм, performance review, диагностика, прогнозирование, оценка рисков, стратегия.
Авторы приводят следующую типологию шума
— Level noise — один человек/судья/менеджер систематически строже или мягче другого
— Pattern noise — разные люди по-разному реагируют на разные признаки
— Occasion noise — один и тот же человек меняет judgment из-за контекста: усталость, настроение, время дня, жара, предыдущий кейс, порядок обсуждения (причем тут есть как межэкспертный шум, так и внутриэкспертный)
Интересные идеи, что показались мне полезными (правда, всего пара из них была для меня относительно новой)
1️⃣ Шум можно измерять без знания правильного ответа — для измерения смещения нужен ground truth, а шум можно оценить по степени вариативности
2️⃣ Совещания часто снижают уровень информации — громкий/важный человек, что говорит первым, может перетянуть мнение на свою сторону и мы так и не узнаем про реальные мнения остальных людей
3️⃣ Performance review — это очень шумный процесс (по статистике авторов около четверти оценки связано с фактическим уровнем performance, а остальное — шум)
4️⃣ Есть процессы для аудита шума — базовый подход в том, чтобы дать одинаковые кейсы нескольким независимым экспертам, собрать ответы, посчитать разброс и дальше оценить эффекты
5️⃣ Для принятия решений существуют гигиенические меры: независимые оценки до обсуждения, агрегирование, структурированные рубрики, сравнительные шкалы вместо абсолютных, разделение решения на подпроблемы, отложенное обращение к интуиции после предыдущих рациональных шагов.
6️⃣ Алгоритмы убирают шум, но не гарантируют справедливость: алгоритм может быть стабилен - те же входные данные дают тот же результат, но он может усилить систематическое смещение, если данные или функция оптимизации плохие.
P.S.
Подход авторов отлично укладывается в агентнизацию всех процессов — занимаясь этим, мы боремся и с системным смещением и с вариативностью.
#Thinking #SelfDevelopment #Brain #Economis #Leadership
Дочитал недавно книгу "Шум" от трех авторов Канемана, Сибони и Санстейна, в которой уважаемые ученые говорили о том, что плохие решения возникают не только из-за bias, то есть систематического смещения, но и из-за вариативности: разные люди или один и тот же человек в разные моменты дают разные решения там, где решения должны быть одинаковыми.
Для меня эта книга далась тяжело - я ее читал больше года и это связано с парой моментов
1️⃣ Авторы затянули книгу до 500+ страниц, хотя основная содержательная часть легко умещалась в 250 страниц и она была про разложение ошибки
E[(y'−y)*(y'−y)] = (E[y']−y)*(E[y']−y) + V[y']
— на среднюю ошибку — average error или bias
— и на дисперсию — variability of error или как раз шум, с которым предлагают бороться авторы
2️⃣ Книга является совместным творчеством трех авторов и консистентного и единого авторского голоса нет. Даниэль Канеман, Нобелевский лауреат, задал рамку для книги и дал большие буквы для обложки — все-таки он автор книги "Thniking, Fast and Slow" ( я ее уже разбирал раньше). Второй автор - Оливье Сибони - больше четверти века был сотрудником McKinsey и он принес консалтингово-организационный опыт и тему качества стратегических решений в книгу. А Касс Санстейн добавил редакционной поддержки.
Если говорить про основные слои книги, то их два
1️⃣ Статистический
Если все судьи, интервьюеры или архитектурные ревьюеры в среднем правы, но каждый раз дают сильно разные ответы, система все равно не очень
2️⃣ Организационный
Большинство компаний не измеряют разброс. Они верят, что их ведущие специалисты примерно одинаково рассуждают, но это часто иллюзия.
Авторы предлагают смотреть на систему принятия решений как на процесс измерений. Если у вас десять термометров на одном столе показывают разные температуры, вы не говорите “какой интересный плюрализм мнений”; вы калибруете приборы. Авторы предлагают так же смотреть на людей в профессиональных системах принятия решений: найм, performance review, диагностика, прогнозирование, оценка рисков, стратегия.
Авторы приводят следующую типологию шума
— Level noise — один человек/судья/менеджер систематически строже или мягче другого
— Pattern noise — разные люди по-разному реагируют на разные признаки
— Occasion noise — один и тот же человек меняет judgment из-за контекста: усталость, настроение, время дня, жара, предыдущий кейс, порядок обсуждения (причем тут есть как межэкспертный шум, так и внутриэкспертный)
Интересные идеи, что показались мне полезными (правда, всего пара из них была для меня относительно новой)
1️⃣ Шум можно измерять без знания правильного ответа — для измерения смещения нужен ground truth, а шум можно оценить по степени вариативности
2️⃣ Совещания часто снижают уровень информации — громкий/важный человек, что говорит первым, может перетянуть мнение на свою сторону и мы так и не узнаем про реальные мнения остальных людей
3️⃣ Performance review — это очень шумный процесс (по статистике авторов около четверти оценки связано с фактическим уровнем performance, а остальное — шум)
4️⃣ Есть процессы для аудита шума — базовый подход в том, чтобы дать одинаковые кейсы нескольким независимым экспертам, собрать ответы, посчитать разброс и дальше оценить эффекты
5️⃣ Для принятия решений существуют гигиенические меры: независимые оценки до обсуждения, агрегирование, структурированные рубрики, сравнительные шкалы вместо абсолютных, разделение решения на подпроблемы, отложенное обращение к интуиции после предыдущих рациональных шагов.
6️⃣ Алгоритмы убирают шум, но не гарантируют справедливость: алгоритм может быть стабилен - те же входные данные дают тот же результат, но он может усилить систематическое смещение, если данные или функция оптимизации плохие.
P.S.
Подход авторов отлично укладывается в агентнизацию всех процессов — занимаясь этим, мы боремся и с системным смещением и с вариативностью.
#Thinking #SelfDevelopment #Brain #Economis #Leadership
❤14👍3🔥2⚡1
Gergely Orosz про AI в разработке: замедлиться, чтобы ускориться (Рубрика #AI4SDLC)
Посмотрел keynote Gergely Orosz “Slow down to speed up: AI and software engineering” с Craft Conference, что проходила в Будапеште. Главная мысль у Gergely похожа на мои тезисы с выступления на Highload - AI упростил написание кода, но возникли вопросы доверия к этим AI изменениям. Если команда генерирует pull requests быстрее, чем умеет их понимать, проверять и связывать с продуктовым результатом, то локальное ускорение легко превращается в системное замедление.
Первую часть выступления Gergely разбирает текущее состояние дел в индустрии
- Историю Instagram/Meta с их инцидентом с account takeover через Meta AI. По его словам это был не просто баг, а симптом организации, где фокус на AI начал выдавливать безопасность, надежность и инженерную культуру
- Дальше он рассказывает про текущее состояние дел в Anthropic и OpenAI (примеры больших AI лаб), Cursor (пример компании, что делает инструменты для инженеров), Google и Meta (bigtech с большим разнообразием внутренних инструментов), а также Uber (пример компании с полноценной инфрой для инженеров вокруг AI)
Эти истории интересны, по ним видно, что индивидуальный output на разработчика действительно вырос, но продуктивность команд и качество не обязаны вырасти вместе с ним. Gergely делится данными Linear и Cursor: больше PR, больше строк кода, крупнее изменения, больше acceptance без человеческого review. Из этого видно, что кода действительно поставляется больше, но дальше он доезжает на этап ревью. И для того, чтобы это не стало бутылочным горлышком нам требуется архитектурное мышление инженерные практики вокруг тестирования, наблюдаемости, надежности, безопасности - раньше они часто были nice to have, а теперь must have. Только они позволяют как-то доверять тем объемам изменений, что сейчас стали нормой при помощи AI.
Интересно, что Gergely активно хвалит Uber и рассказывает про их а внутреннюю инфраструктуру: MCP Gateway, Agent Builder, Minion, Code Inbox, risk profiles, AI code review. То есть AI там встраивают не как игрушку рядом с IDE, а как часть системы поставки ценности: маршрутизации изменений, оценки риска, review-потоки, миграций, циклов обратной связи.
Отдельно Gergely активно ругает AI метрики, которые дают неправильную мотивацию сотрудникам. Если организация мерит token usage или просто adoption, люди будут максимизировать использование AI, даже когда это ухудшает результат. Это старая болезнь кривых метрик, умноженная на скорость генерации кода. Можно выглядеть очень современно и одновременно производить больше технического долга.
AI не отменяет хорошую инженерию, а делает ее более ценной. Naming, границы модулей, тестируемость, понятные контракты, нормальный review, умение удалить старый код - все это становится не эстетикой, а инфраструктурой доверия. Когда код пишет агент, человеку тем более нужен способ понять: что изменилось, почему это безопасно и какие последствия будут через три месяца.
Ближе к концу выступления Gergely делится рекомендациями
1️⃣ Замедляться надо не в смысле “не пользоваться AI”, а в смысле “не генерировать больше, чем можешь проверить”. Скорость должна подчиняться бутылочному горлышку (возможности ревью), а не наоборот.
2️⃣ Начинать надо не с инструмента, а с бизнес результата и слабого места процесса. Где теряется время: discovery, onboarding, review, тесты, миграции, incident response, документация, старый код? AI полезен там, где встроен в конкретную петлю обратной связи.
3️⃣ Стоит инвестировать в verification systems. Evals, тесты, статический анализ, risk profiles, наблюдаемость, staged rollout, code ownership - это способ масштабировать AI без полной потери контроля.
4️⃣ Инженеру будущего нужны навыки продакт менеджера, доменная экспертиза, архитектурный вкус и способность строить системы поверх LLM: RAG, agents, evals, workflow automation, внутренние платформы. Чем дешевле код, тем ценнее понимание, какой код вообще стоит писать.
5️⃣ AI adoption нельзя делегировать только энтузиастам и считать по лицензиям. Руководителям придется оставаться hands-on: понимать ограничения моделей, видеть реальные bottlenecks команды, защищать качество и перестраивать review. Средний слой руководителей, который только водит руками здесь не особо нужен
#AI #AI4SDLC #Engineering #Software #Architecture #Management
Посмотрел keynote Gergely Orosz “Slow down to speed up: AI and software engineering” с Craft Conference, что проходила в Будапеште. Главная мысль у Gergely похожа на мои тезисы с выступления на Highload - AI упростил написание кода, но возникли вопросы доверия к этим AI изменениям. Если команда генерирует pull requests быстрее, чем умеет их понимать, проверять и связывать с продуктовым результатом, то локальное ускорение легко превращается в системное замедление.
Первую часть выступления Gergely разбирает текущее состояние дел в индустрии
- Историю Instagram/Meta с их инцидентом с account takeover через Meta AI. По его словам это был не просто баг, а симптом организации, где фокус на AI начал выдавливать безопасность, надежность и инженерную культуру
- Дальше он рассказывает про текущее состояние дел в Anthropic и OpenAI (примеры больших AI лаб), Cursor (пример компании, что делает инструменты для инженеров), Google и Meta (bigtech с большим разнообразием внутренних инструментов), а также Uber (пример компании с полноценной инфрой для инженеров вокруг AI)
Эти истории интересны, по ним видно, что индивидуальный output на разработчика действительно вырос, но продуктивность команд и качество не обязаны вырасти вместе с ним. Gergely делится данными Linear и Cursor: больше PR, больше строк кода, крупнее изменения, больше acceptance без человеческого review. Из этого видно, что кода действительно поставляется больше, но дальше он доезжает на этап ревью. И для того, чтобы это не стало бутылочным горлышком нам требуется архитектурное мышление инженерные практики вокруг тестирования, наблюдаемости, надежности, безопасности - раньше они часто были nice to have, а теперь must have. Только они позволяют как-то доверять тем объемам изменений, что сейчас стали нормой при помощи AI.
Интересно, что Gergely активно хвалит Uber и рассказывает про их а внутреннюю инфраструктуру: MCP Gateway, Agent Builder, Minion, Code Inbox, risk profiles, AI code review. То есть AI там встраивают не как игрушку рядом с IDE, а как часть системы поставки ценности: маршрутизации изменений, оценки риска, review-потоки, миграций, циклов обратной связи.
Отдельно Gergely активно ругает AI метрики, которые дают неправильную мотивацию сотрудникам. Если организация мерит token usage или просто adoption, люди будут максимизировать использование AI, даже когда это ухудшает результат. Это старая болезнь кривых метрик, умноженная на скорость генерации кода. Можно выглядеть очень современно и одновременно производить больше технического долга.
AI не отменяет хорошую инженерию, а делает ее более ценной. Naming, границы модулей, тестируемость, понятные контракты, нормальный review, умение удалить старый код - все это становится не эстетикой, а инфраструктурой доверия. Когда код пишет агент, человеку тем более нужен способ понять: что изменилось, почему это безопасно и какие последствия будут через три месяца.
Ближе к концу выступления Gergely делится рекомендациями
1️⃣ Замедляться надо не в смысле “не пользоваться AI”, а в смысле “не генерировать больше, чем можешь проверить”. Скорость должна подчиняться бутылочному горлышку (возможности ревью), а не наоборот.
2️⃣ Начинать надо не с инструмента, а с бизнес результата и слабого места процесса. Где теряется время: discovery, onboarding, review, тесты, миграции, incident response, документация, старый код? AI полезен там, где встроен в конкретную петлю обратной связи.
3️⃣ Стоит инвестировать в verification systems. Evals, тесты, статический анализ, risk profiles, наблюдаемость, staged rollout, code ownership - это способ масштабировать AI без полной потери контроля.
4️⃣ Инженеру будущего нужны навыки продакт менеджера, доменная экспертиза, архитектурный вкус и способность строить системы поверх LLM: RAG, agents, evals, workflow automation, внутренние платформы. Чем дешевле код, тем ценнее понимание, какой код вообще стоит писать.
5️⃣ AI adoption нельзя делегировать только энтузиастам и считать по лицензиям. Руководителям придется оставаться hands-on: понимать ограничения моделей, видеть реальные bottlenecks команды, защищать качество и перестраивать review. Средний слой руководителей, который только водит руками здесь не особо нужен
#AI #AI4SDLC #Engineering #Software #Architecture #Management
YouTube
Slow down to speed up: AI and software engineering
AI agents are writing code pretty much everywhere. And yet, most teams and companies are not seeing that dramatic productivity gains… or are they? Keynote at Craft Conference, on 4 June 2026, in Budapest, Hungary: https://craft-conf.com/2026
Timestamps:…
Timestamps:…
👍10❤4🔥2
Google Cloud AI agent trends 2026: рекламный, но полезный чеклист (Рубрика #AI)
Прочитал отчет Google Cloud «AI agent trends 2026», который мне показался скорее вендорским подходом к продажам, а не научным исследованием. Методология основывалась на внутренних интервью Google Cloud и Google DeepMind, историях заказчиков, а также отчете Google Cloud «The ROI of AI 2025» на основе опроса "3 466 enterprise decision makers". В общем это больше похоже на сигнал о том, а куда Google Cloud хочет сдвигать своих enterprise-клиентов.
Если же говорить про сами тренды AI агентов, то вот они
1️⃣ Agents for every employee
Это про то, что сотрудник становится менеджером набора агентов: поставить цель, дать контекст, проверить результат. Тренд важен тем, что продуктивность будет упираться не только в модель, но и в умение людей формулировать задачи, открывать данные и контролировать качество.
2️⃣ Agents for every workflow
Google описывает цифровую линию сборки: несколько агентов ведут процесс end-to-end через системы, данные и инструменты. Здесь начинается настоящая архитектура: интеграции, audit trail, MCP/A2A, права доступа и ответственность за действие.
3️⃣ Agents for your customers
Вместо скриптованных агентов предлагается концепт агент-консьержа, который помнит контекст, смотрит CRM, логистику, биллинг и может проактивно решать вопрос. Для продукта это важно потому, что ценность будет в безопасном доступе к enterprise data.
4️⃣ Agents for security
SOC (security operation center) должен сдвигаться от отсмотра алертов к полуавтономному циклу detection, triage, investigation, response. Тренд важный, так как агенты нужны для ускорения защиты, но одновременно требует новых правил контроля.
5️⃣ Agents for scale
Купить платформу мало, но нужны обучение, новые роли, critical thinking, governance и ясные правила, что агентам можно делать.
Итоговый вывод в том, что сам отчет не очень полезен сам по себе, но показывает, что агентная разработка уже доезжает в enerprise клиентов Google Cloud:)
P.S.
В первом комментарии будет сам pdf.
#AI #Agents #Engineering #Architecture #Management
Прочитал отчет Google Cloud «AI agent trends 2026», который мне показался скорее вендорским подходом к продажам, а не научным исследованием. Методология основывалась на внутренних интервью Google Cloud и Google DeepMind, историях заказчиков, а также отчете Google Cloud «The ROI of AI 2025» на основе опроса "3 466 enterprise decision makers". В общем это больше похоже на сигнал о том, а куда Google Cloud хочет сдвигать своих enterprise-клиентов.
Если же говорить про сами тренды AI агентов, то вот они
1️⃣ Agents for every employee
Это про то, что сотрудник становится менеджером набора агентов: поставить цель, дать контекст, проверить результат. Тренд важен тем, что продуктивность будет упираться не только в модель, но и в умение людей формулировать задачи, открывать данные и контролировать качество.
2️⃣ Agents for every workflow
Google описывает цифровую линию сборки: несколько агентов ведут процесс end-to-end через системы, данные и инструменты. Здесь начинается настоящая архитектура: интеграции, audit trail, MCP/A2A, права доступа и ответственность за действие.
3️⃣ Agents for your customers
Вместо скриптованных агентов предлагается концепт агент-консьержа, который помнит контекст, смотрит CRM, логистику, биллинг и может проактивно решать вопрос. Для продукта это важно потому, что ценность будет в безопасном доступе к enterprise data.
4️⃣ Agents for security
SOC (security operation center) должен сдвигаться от отсмотра алертов к полуавтономному циклу detection, triage, investigation, response. Тренд важный, так как агенты нужны для ускорения защиты, но одновременно требует новых правил контроля.
5️⃣ Agents for scale
Купить платформу мало, но нужны обучение, новые роли, critical thinking, governance и ясные правила, что агентам можно делать.
Итоговый вывод в том, что сам отчет не очень полезен сам по себе, но показывает, что агентная разработка уже доезжает в enerprise клиентов Google Cloud:)
P.S.
В первом комментарии будет сам pdf.
#AI #Agents #Engineering #Architecture #Management
Google Cloud
AI agent trends 2026 report
How are businesses putting AI agents to work? We interviewed Google experts and surveyed 3,466 global execs to find out. Uncover the 5 major trends you need to define your business strategy in 2026. Download the research and prepare your company today.
❤4👍1🔥1
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. Это звучит скучно, но именно там начинается автономность:
Дальше автономность стала нативной для мест, где уже рождается работа: Slack, Jira, Linear, GitHub issues. В одном примере инженер прямо в Slack спрашивает Goose про баг, агент идет в репозиторий, подтверждает проблему, предлагает варианты исправления, команда выбирает вариант, и Goose возвращается с PR. По словам Jones, цикл
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
Посмотрел вчера выступление 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
YouTube
Building an Autonomous Engineering Org - Angie Jones, Agentic AI Foundation
Nearly every enterprise company has a mandate to convert its existing engineering org into an autonomous one.
Buying the frontier models and tools is not enough. Everything about how we deliver software must change: from design, to development, to deployment.…
Buying the frontier models and tools is not enough. Everything about how we deliver software must change: from design, to development, to deployment.…
🔥11❤6👍1
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
Я уже как-то рассказывал про эту книгу 2025 года в линейке “Insider’s Guide” от ByteByteGo, но недавно вышел перевод от издательства Питер причем с моим отзывом на обложке книги:) Эта книга была не про высокоуровневый system design, а про более низкоуровневый объектно-ориентированный дизайн (OOD, object-oriented design), где идеи превращаются в классы, интерфейсы, состояния, потоки выполнения и так далее. Честно признаюсь, что прочитал я ее для того, чтобы честно написать фидбек - и вот на питерском Highload++ сотрудники издательства "Питер" подарили мне эту книжку:)
P.S.
Сейчас я читаю книгу про AI-assisted Engineering, автор которой мне предложил написать на нее ревью.
Пока прочитал около половины, но книга хорошая - буду ждать ее в бумажном виде:)
#SystemDesign #OOD #Architecture #Interview #Software #Engineering
1👍19❤8🔥5👎1
Интересный анонс публичной беты Claude Science. Думаю, что я знаю как проведу этот вечер:)
YouTube
Introducing Claude Science (now in beta)
Introducing Claude Science, a new research app from Anthropic now in public beta.
It runs analyses, searches databases, and traces steps from data wrangling to validation. Every artifact ships with the exact code, environment, and conversation that produced…
It runs analyses, searches databases, and traces steps from data wrangling to validation. Every artifact ships with the exact code, environment, and conversation that produced…
🔥7❤2🤩2
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
Вышел финальный выпуск пятого сезона подкаста "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
Yandex Music
Генерация всего
Track
1👍8❤6🔥2🥱1
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, включающим
В документе формулируется разрыв между двумя крайностями и предлагается третий режим 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. В репозитории
Дальше движение пошло еще интереснее: в 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
Разбирался с документом "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
1🔥8❤6👍4
Евгений Кокуйкин про 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 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
YouTube
AI Dev Podcast #7 / Безопасность, агенты и будущее разработки / Евгений Кокуйкин
В этом выпуске говорим о том, какие риски несёт использование агентов. Разбираем уязвимости open source, контроль качества агентных систем, экономику токенов и новые угрозы в SDLC.
Гости — основатель HiveTrace Евгений Кокуйкин (@kokuykinи) технический директор…
Гости — основатель HiveTrace Евгений Кокуйкин (@kokuykinи) технический директор…
❤7👍4🔥2
Сегодня записывал интервью в рамках подкаста Code of Leadership со своим коллегой Даниэлем Левинишниковым из нашего AI Центра.
Мы успели поговорить про карьерный путь Даниэля, критерии хорошего AI продукта, как выглядит запуск такого продукта в корпорации, как выстроен менеджмент большой командой ML/AI специалистов, про лидерство в эпоху перемен и так далее. Пока интервью в обработке, но уже есть шортс про то, что middle management уже в опасности:) Кстати, примерно об этом я рассказывал в статье "От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)"
P.S.
На неделе опубликую интервью целиком:)
Мы успели поговорить про карьерный путь Даниэля, критерии хорошего AI продукта, как выглядит запуск такого продукта в корпорации, как выстроен менеджмент большой командой ML/AI специалистов, про лидерство в эпоху перемен и так далее. Пока интервью в обработке, но уже есть шортс про то, что middle management уже в опасности:) Кстати, примерно об этом я рассказывал в статье "От AI-native разработки к AI-native организации (с примерами из опыта бигтехов)"
P.S.
На неделе опубликую интервью целиком:)
YouTube
Middle management в опасности: компании станут плоскими (Интервью с Даниэлем Левинишниковым)
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
👍3🔥3❤2
Шурик в Матрице. Полный фильм (Рубрика #Films)
Эта короткометражка просто топчик - супер-микс истории Матрицы, нашего контекста и героев из советских фильмов прошлого. В итоге, получается очень-очень круто. Рекомендую к просмотру, если еще не видели:)
Эта короткометражка просто топчик - супер-микс истории Матрицы, нашего контекста и героев из советских фильмов прошлого. В итоге, получается очень-очень круто. Рекомендую к просмотру, если еще не видели:)
YouTube
Шурик в Матрице. Полный фильм
Полная версия сериала «Шурик в матрице»: восемь эпизодов, в которых классика советской комедии Гайдая встречается с мифологией «Матрицы». Шурик — Нео, Нина из «Кавказской пленницы» — Нинити, а в роли Смита — товарищ Саахов.
Автор и исполнитель Leo Gagua.…
Автор и исполнитель Leo Gagua.…
😁7🔥5👍1