Token burn как proof of work: почему AI-метрики легко уезжают в имитацию работы (Рубрика #AI4SDLC)
Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами (дискутируя после своего доклада "State of AI4SDLC на HighLoad++"). Поэтому я решил написать пост со своими мыслями на эту тему.
Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, соженные сотрудником токены — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность.
Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию.
Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли ревью быстрее и качественнее? Уменьшилась ли доля rework? Стало ли восстановление после инцидентов быстрее и уменьшилась ли сама частота инцидентов? Дошел ли результат до прода, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана.
Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, ревью, тесты, merge, раскатка, эксплуатация, качество и стоимость результата.
И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять.
На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом?
Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели.
Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным.
Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит.
Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, стоимостью на задачу, lead time, качеством/риском и опытом разработчиков (DevEx). Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе.
P.S.
Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом.
#AI #AI4SDLC #Engineering #Management #Metrics #DevEx
Все чаще я думаю про моду на token maximizing и метрики вроде "сколько токенов сжег сотрудник". В этом есть забавная, но неприятная рифма с proof of work в крипте: человек предъявляет не результат, а доказательство потраченного вычисления. Смотри, я сжег достаточно токенов — значит, работал правильно. Буквально вчера в кулуарах Highload++ обсуждал это с другими экспертами (дискутируя после своего доклада "State of AI4SDLC на HighLoad++"). Поэтому я решил написать пост со своими мыслями на эту тему.
Я понимаю почему соженные токены на сотрудника являются соблазнительной метрикой: она простая, технически собираемая и хорошо выглядит на дашборде для топ-менеджров. Еще легко посчитать лицензии, MAU, число запросов, соженные сотрудником токены — все это быстро складывается в график adoption. Одна проблема - adoption напрямую не свяан с ценностью (outcome или value, если говорить по английски). Вообще, активность — это не результат, а token burn — это не инженерная производительность.
Похожая логика уже была в старой управленческой культуре, где "мерилом работы считают усталость" как в песне Nautilus Pompilius. Кто позже ушел, тот больше старался. Кто чаще был на встречах, тот вовлеченнее. Кто отправил больше писем, тот продуктивнее. Теперь та же рамка легко переезжает в AI: кто сжег больше токенов, тот вроде бы лучше использует новую технологию.
Но сами по себе токены ничего не говорят о системе разработки. Сократился ли cycle time? Стал ли ревью быстрее и качественнее? Уменьшилась ли доля rework? Стало ли восстановление после инцидентов быстрее и уменьшилась ли сама частота инцидентов? Дошел ли результат до прода, клиентов и денег? Если на эти вопросы ответа нет, token burn превращается в корпоративный proof of work. Мы доказываем, что вычисление было потрачено. Но не доказываем, что ценность была создана.
Правильная рамка, мне кажется, другая: не proof of work, а proof of value. Не "сколько токенов сожгли", а "какую ценность получили за эту вычислительную работу". Для AI4SDLC это означает смотреть на весь контур: постановка задачи, контекст, генерация, ревью, тесты, merge, раскатка, эксплуатация, качество и стоимость результата.
И вот здесь начинается взрослая и неприятная часть. Value нужно уметь измерять.
На уровне всей компании можно посмотреть в финансовую отчетность: выручка, маржинальность, затраты, рост, удержание клиентов. Но дальше начинается атрибуция. Как честно разложить вклад на подразделения, команды, людей, платформы, фичи и изменения в SDLC? Что считать эффектом AI, что эффектом хорошего менеджмента, что сезонностью, а что просто удачным релизом?
Для этого нужны baseline до внедрения, нормальная карта процесса, ownership метрик, связка DORA/SPACE/DevEx с экономикой, качество данных и договоренность о том, какие решения мы принимаем по этим числам. Нужна управленческая зрелость, а не только новый счетчик в биллинге модели.
Именно поэтому token maximizing так привлекателен. Он дешевле организационно. Не надо договариваться, что такое value. Не надо чистить грязные данные. Не надо связывать инженерные метрики с продуктовым результатом. Не надо признавать, что эффект AI в одной команде может быть отличным, во второй нулевым, а в третьей отрицательным.
Можно просто поставить цель: увеличиваем потребление токенов на сотрудника. Авось и так прокатит.
Если подбивать итоги по моей позиции, то я считаю token burn полезен как техническая и финансовая телеметрия, но опасен как управленческая цель. Его нормально смотреть рядом с adoption, стоимостью на задачу, lead time, качеством/риском и опытом разработчиков (DevEx). Но как только сожженные токены сами становятся доказательством хорошей работы, организация начинает оптимизировать не результат, а видимость деятельности. AI-метрики становятся взрослыми только там, где компания готова отвечать на неудобный вопрос: не сколько вычисления мы потратили, а что именно стало лучше в реальной производственной системе.
P.S.
Про наш подход можете почитать мой разбор выступления Анны Громовой из Т-Банка на конфе AI Dev Conf буквально месяц назад, где она рассказывала что и как мы измеряем и почему считаем это верным подходом.
#AI #AI4SDLC #Engineering #Management #Metrics #DevEx
💯8❤3🔥1
Databricks про production AI: почему модель выбирают ближе концу проекта (Рубрика #AI4SDLC)
Посмотрел доклад Sandipan Bhaumik из Databricks "The Production AI Playbook: Deploying Agents at Enterprise Scale", в котором автор делился своим подходом к внедрению агентов в клиентские enterprise проекты, где надо было пройти путь от вау-эффекта на демо до продакшена:)
Автор иронично начал с того, что раньше большинство AI-проектов начиналось с вопроса "GPT или Claude?". Дальше быстро собирался красивый прототип на чистых данных, руководство радовалось, а через несколько недель в production никто не понимал, а почему агент отвечает странно, кто за это отвечает и где искать причину. Для того, чтобы не попадать в такую ситуацию он предлагает свой playbook из пяти опор
1️⃣ Evaluation (Define success before code)
Fdnjh называет их спецификацией AI-системы: до кода и до выбора модели нужно понять, что считается успехом в числах. Не просто "accuracy", а какая точность достаточна для конкретного бизнеса, сколько простых обращений должен закрыть агент, какие ошибки допустимы, где нужен человек.
2️⃣ Observability (see everything, always)
Если агент отказал клиенту, неправильно вызвал tool или три раза сходил в одну и ту же базу, это должно быть видно по шагам: intent classification, API call, поиск документа, reasoning, guardrail check, финальный ответ. Иначе в инциденте остается только гадать.
3️⃣ Data foundation (question + tracking data)
Автор делит этот пункт на данные, из которых агент отвечает пользователю, и tracking data - следы работы агента. Он отмечает, что люди прощают плохие данные, агенты нет. Человек увидит странность в отчете и переспросит. Агент уверенно даст неверный ответ.
4️⃣ Orchestration (patterns that scale)
Работу одного агента еще можно держать в голове. Пять совместно работающих агентов уже требуют паттернов, например
- Orchestrator-worker, где центральный агент раздает работу
- Choreography, где агенты слушают события и работают параллельно
- Human-in-the-loop, где человек входит в контур при низкой уверенности или рискованном действии
5️⃣ Governance (what keeps you in production)
В докладе это не только data governance (который уже должен быть как пререквизит), но в общем про управление рисками и ответственностью. Это аудит логи, проверки персональной информации, версионирование промптов, процесс над изменением моделей в проде и ответы на вопросы вида "кто отвечает, если агент сломался в 3 часа ночи".
В самом докладе автор делится кейсом чатбота для ритейл банка, где клиент Databricks потратил около 85 тысяч фунтов и 6 месяцев на PoC, который не вышел в production: никто не мог объяснить, почему система работает с низким качеством. В новом подходе команда выбрала модель только на 7-й неделе 8-недельного проекта. До этого они собрали около 200 реальных кейсов ответов людей в чатботе, описали метрики, построили пайплан для evaluation, включили трассировки и подготовили слой данных.
Шесть недель после запуска случился нормальный production-инцидент: банк обновил политику по процентным ставкам, клиенты начали ставить плохие оценки ответам чатбота, так как агент продолжал ссылаться на устаревший документ. Без трассировки это выглядело бы как "AI опять ведет себя странно". С трейсами стало видно, что новый документ по процентным ставкам не попал в векторную базу и чатбот про него не знал.
Отсюда вырастает плейбук для работы с инцидентами
- Detect - увидеть просадку через дашборд evals (оффлайн метрики) или по онлайн метрикам
- Diagnose - разобрать трейсы и понять что идет не так
- Contain - принять меры: откатить prompt, перевести поток на человека или включить circuit breaker
- Fix - поправить данные, tool call, prompt или модель
- Prevent - в финале обязательно добавить новый случай в набор evaluation, чтобы система ловила его в следующий раз
Databricks, понятно, показывает это через свои продукты: MLflow для tracing/evals/monitoring, Unity Catalog для прав и контекста, Agent Bricks и Unity AI Gateway для управления агентами, моделями, tools и доступами. Но ценность доклада, мне кажется, шире конкретной платформы.
Мне этот доклад нравится тем, что он хорошо укладывается в тему, что я рассказывал буквально вчера на Highload++, где AI начинает работать в компаниях хорошо, если с его помощью меняется производственная система. А вот если вокруг агента нет harness, наблюдаемости, данных и governance, то масштабирование быстро приведет вас от красивого демо до проблем на проде.
#AI #AI4SDLC #Engineering #Agents #Architecture #Management
Посмотрел доклад Sandipan Bhaumik из Databricks "The Production AI Playbook: Deploying Agents at Enterprise Scale", в котором автор делился своим подходом к внедрению агентов в клиентские enterprise проекты, где надо было пройти путь от вау-эффекта на демо до продакшена:)
Автор иронично начал с того, что раньше большинство AI-проектов начиналось с вопроса "GPT или Claude?". Дальше быстро собирался красивый прототип на чистых данных, руководство радовалось, а через несколько недель в production никто не понимал, а почему агент отвечает странно, кто за это отвечает и где искать причину. Для того, чтобы не попадать в такую ситуацию он предлагает свой playbook из пяти опор
1️⃣ Evaluation (Define success before code)
Fdnjh называет их спецификацией AI-системы: до кода и до выбора модели нужно понять, что считается успехом в числах. Не просто "accuracy", а какая точность достаточна для конкретного бизнеса, сколько простых обращений должен закрыть агент, какие ошибки допустимы, где нужен человек.
2️⃣ Observability (see everything, always)
Если агент отказал клиенту, неправильно вызвал tool или три раза сходил в одну и ту же базу, это должно быть видно по шагам: intent classification, API call, поиск документа, reasoning, guardrail check, финальный ответ. Иначе в инциденте остается только гадать.
3️⃣ Data foundation (question + tracking data)
Автор делит этот пункт на данные, из которых агент отвечает пользователю, и tracking data - следы работы агента. Он отмечает, что люди прощают плохие данные, агенты нет. Человек увидит странность в отчете и переспросит. Агент уверенно даст неверный ответ.
4️⃣ Orchestration (patterns that scale)
Работу одного агента еще можно держать в голове. Пять совместно работающих агентов уже требуют паттернов, например
- Orchestrator-worker, где центральный агент раздает работу
- Choreography, где агенты слушают события и работают параллельно
- Human-in-the-loop, где человек входит в контур при низкой уверенности или рискованном действии
5️⃣ Governance (what keeps you in production)
В докладе это не только data governance (который уже должен быть как пререквизит), но в общем про управление рисками и ответственностью. Это аудит логи, проверки персональной информации, версионирование промптов, процесс над изменением моделей в проде и ответы на вопросы вида "кто отвечает, если агент сломался в 3 часа ночи".
В самом докладе автор делится кейсом чатбота для ритейл банка, где клиент Databricks потратил около 85 тысяч фунтов и 6 месяцев на PoC, который не вышел в production: никто не мог объяснить, почему система работает с низким качеством. В новом подходе команда выбрала модель только на 7-й неделе 8-недельного проекта. До этого они собрали около 200 реальных кейсов ответов людей в чатботе, описали метрики, построили пайплан для evaluation, включили трассировки и подготовили слой данных.
Шесть недель после запуска случился нормальный production-инцидент: банк обновил политику по процентным ставкам, клиенты начали ставить плохие оценки ответам чатбота, так как агент продолжал ссылаться на устаревший документ. Без трассировки это выглядело бы как "AI опять ведет себя странно". С трейсами стало видно, что новый документ по процентным ставкам не попал в векторную базу и чатбот про него не знал.
Отсюда вырастает плейбук для работы с инцидентами
- Detect - увидеть просадку через дашборд evals (оффлайн метрики) или по онлайн метрикам
- Diagnose - разобрать трейсы и понять что идет не так
- Contain - принять меры: откатить prompt, перевести поток на человека или включить circuit breaker
- Fix - поправить данные, tool call, prompt или модель
- Prevent - в финале обязательно добавить новый случай в набор evaluation, чтобы система ловила его в следующий раз
Databricks, понятно, показывает это через свои продукты: MLflow для tracing/evals/monitoring, Unity Catalog для прав и контекста, Agent Bricks и Unity AI Gateway для управления агентами, моделями, tools и доступами. Но ценность доклада, мне кажется, шире конкретной платформы.
Мне этот доклад нравится тем, что он хорошо укладывается в тему, что я рассказывал буквально вчера на Highload++, где AI начинает работать в компаниях хорошо, если с его помощью меняется производственная система. А вот если вокруг агента нет harness, наблюдаемости, данных и governance, то масштабирование быстро приведет вас от красивого демо до проблем на проде.
#AI #AI4SDLC #Engineering #Agents #Architecture #Management
YouTube
The Production AI Playbook: Deploying Agents at Enterprise Scale — Sandipan Bhaumik, Databricks
A retail bank spent £85,000 over six months on a chatbot PoC that could not reach production. No one could explain why it was failing. When Sandipan Bhaumik's team got involved, they picked the model in week seven of an eight-week engagement — the first six…
👍8❤3🔥1
AWS про команды в agentic world: почему оргструктура стала частью AI-архитектуры (Рубрика #AI4SDLC)
Посмотрел доклад Stephen Brozovich из AWS "A leader's guide to advanced team structures in an agentic world". Это хороший гайд для лидеров об изменении операционной модели компании, когда рядом с людьми начинают работать агенты. Сама роль Stephen интересна - он AWS Executive in Residence и работает в Amazon с 1999 года. За это время он прошел путь от технических команд к работе с людьми, культурой и работе с организационными трансформациями. И именно про трансформации он рассказывает в этом докладе, что нацелен на CIO, CTO, бизнес-руководителей, которым нужно понять, как менять процессы, команды и governance поверх всего этого.
Stephen предлагает смотреть на эти вопросы через четыре грани: экономическую грань, грань талантов, структуры и governance.
1️⃣ Economics
Stephen предлагает не начинать с "строим все сами". Для каждого workflow нужно выбрать режим: use, compose или build
- Use - берем готовое решение
- Compose - собираем поверх frontier models, данных и собственного процесса
- Build - обучаем или серьезно донастраиваем свое. Build имеет смысл только там, где есть настоящая дифференциация бизнеса. Иначе лидер сжигает деньги раньше, чем понял собственный рабочий процесс.
2️⃣ Talent
Здесь доклад пересекается с идеей expert generalist из текста Martin Fowler и Thoughtworks: ценность смещается от человека, который быстрее всех пишет руками в одном стеке, к человеку, который понимает домен, ставит задачу агенту, оценивает результат и вовремя останавливает систему. AI усиливает не узкую специализацию саму по себе, а способность связать домен, клиента, архитектуру и проверку результата.
В этом блоке Stephen размышляет про джунов и показывает ловушку организации в форме diamond (мало сеньоров и джунов, но много мидлов): компании режут джунов ради быстрого ROI от AI, одновременно платят дороже за senior talent и выжигают будущую базу экспертизы. Для выполнения новых задач может работать перевернутая пирамида: 3-5 senior engineers плюс agents. Но вся организация должна оставаться в форме песочных часов, где есть сильный верх, тонкая середина и живой нижний слой обучения. Иначе в 2034 году seniors будет неоткуда взять (честно говоря, это обоснование похоже на благопожелание - оно направлено на общее благо, но не отвечает на вопрос, а чем джуны помогут конкретной компании )
3️⃣ Structure
Stephen приводит три вида структур
- Model A - старый IT ops: инженерия построила, потом перекинула через стену эксплуатации. В агентном мире это ломается: ticket culture убивает контекст, операторы не видят, что агент делает, не управляют моделью и данными, а runbook не покрывает недетерминированное поведение.
- Model B - интегрированные поды: 3-5 senior engineers сами создают/владеют/отвечают за run конкретных рабочих процессов end-to-end. Люди, которые написали системные промпты и инструменты агента, сами разбирают инцидент в 3 ночи. Меньше передач ответственнсоти, меньше потери контекста.
- Model C - интегрированные поды + платформа. На малом масштабе pod может выжить сам. На 10+ pod'ах начнут размножаться разные платформенные части: auth layers, observability stacks, guardrails и способы жечь AI-бюджет. Поэтому нужна общая платформа: runtime, memory, identity, observability, policy, cost controls. Но платформа не должна душить автономию pod'ов, она должна давать безопасную дорогу.
На масштабе будет работать только модель С, но с модели B можно стартовать в небольшой организации.
4️⃣ Governance
Здесь Stephen связывает Singapore Agentic AI Governance Framework и AWS AgentCore: оба сходятся вокруг одинаковых вопросов. Кто этот агент? Кто его авторизовал? Что ему разрешено? Работает ли он как ожидалось? Можно ли провести аудит?
Мне понравилась формулировка governance как running infrastructure. Не PDF с политикой, а код, который срабатывает на каждом запросе. Не просить LLM "вести себя хорошо", а проверять доступы, идентичность, инструменты и действия вне LLM-loop. Это ровно та же логика, которую я разбирал в постах про GitLab Act 2, agent-first IDP, Tailscale Aperture и Databricks production AI: скорость без identity, политик, evals, наблюдаемости и владельцев быстро превращается в риск.
И здесь доклад хорошо пересекается с моей старой темой про оргдизайн. В разборе Flo и Team Topologies я писал, что организация - это тоже архитектура: границы команд, ownership, интерфейсы, latency коммуникаций. AWS добавляет следующий слой: в agentic world оргструктура становится частью AI-архитектуры. Если агент меняет скорость исполнения, лидер должен заново спроектировать не только инструменты, но и форму команды, путь обучения людей и контур ответственности.
Для меня главный вывод такой: в следующие годы выиграют компании, у которых вокруг AI быстрее созреет операционная модель, а не просто будут розданы лицензии всем желающим.
#AI #AI4SDLC #Management #Leadership #Architecture #Agents
Посмотрел доклад Stephen Brozovich из AWS "A leader's guide to advanced team structures in an agentic world". Это хороший гайд для лидеров об изменении операционной модели компании, когда рядом с людьми начинают работать агенты. Сама роль Stephen интересна - он AWS Executive in Residence и работает в Amazon с 1999 года. За это время он прошел путь от технических команд к работе с людьми, культурой и работе с организационными трансформациями. И именно про трансформации он рассказывает в этом докладе, что нацелен на CIO, CTO, бизнес-руководителей, которым нужно понять, как менять процессы, команды и governance поверх всего этого.
Stephen предлагает смотреть на эти вопросы через четыре грани: экономическую грань, грань талантов, структуры и governance.
1️⃣ Economics
Stephen предлагает не начинать с "строим все сами". Для каждого workflow нужно выбрать режим: use, compose или build
- Use - берем готовое решение
- Compose - собираем поверх frontier models, данных и собственного процесса
- Build - обучаем или серьезно донастраиваем свое. Build имеет смысл только там, где есть настоящая дифференциация бизнеса. Иначе лидер сжигает деньги раньше, чем понял собственный рабочий процесс.
2️⃣ Talent
Здесь доклад пересекается с идеей expert generalist из текста Martin Fowler и Thoughtworks: ценность смещается от человека, который быстрее всех пишет руками в одном стеке, к человеку, который понимает домен, ставит задачу агенту, оценивает результат и вовремя останавливает систему. AI усиливает не узкую специализацию саму по себе, а способность связать домен, клиента, архитектуру и проверку результата.
В этом блоке Stephen размышляет про джунов и показывает ловушку организации в форме diamond (мало сеньоров и джунов, но много мидлов): компании режут джунов ради быстрого ROI от AI, одновременно платят дороже за senior talent и выжигают будущую базу экспертизы. Для выполнения новых задач может работать перевернутая пирамида: 3-5 senior engineers плюс agents. Но вся организация должна оставаться в форме песочных часов, где есть сильный верх, тонкая середина и живой нижний слой обучения. Иначе в 2034 году seniors будет неоткуда взять (
3️⃣ Structure
Stephen приводит три вида структур
- Model A - старый IT ops: инженерия построила, потом перекинула через стену эксплуатации. В агентном мире это ломается: ticket culture убивает контекст, операторы не видят, что агент делает, не управляют моделью и данными, а runbook не покрывает недетерминированное поведение.
- Model B - интегрированные поды: 3-5 senior engineers сами создают/владеют/отвечают за run конкретных рабочих процессов end-to-end. Люди, которые написали системные промпты и инструменты агента, сами разбирают инцидент в 3 ночи. Меньше передач ответственнсоти, меньше потери контекста.
- Model C - интегрированные поды + платформа. На малом масштабе pod может выжить сам. На 10+ pod'ах начнут размножаться разные платформенные части: auth layers, observability stacks, guardrails и способы жечь AI-бюджет. Поэтому нужна общая платформа: runtime, memory, identity, observability, policy, cost controls. Но платформа не должна душить автономию pod'ов, она должна давать безопасную дорогу.
На масштабе будет работать только модель С, но с модели B можно стартовать в небольшой организации.
4️⃣ Governance
Здесь Stephen связывает Singapore Agentic AI Governance Framework и AWS AgentCore: оба сходятся вокруг одинаковых вопросов. Кто этот агент? Кто его авторизовал? Что ему разрешено? Работает ли он как ожидалось? Можно ли провести аудит?
Мне понравилась формулировка governance как running infrastructure. Не PDF с политикой, а код, который срабатывает на каждом запросе. Не просить LLM "вести себя хорошо", а проверять доступы, идентичность, инструменты и действия вне LLM-loop. Это ровно та же логика, которую я разбирал в постах про GitLab Act 2, agent-first IDP, Tailscale Aperture и Databricks production AI: скорость без identity, политик, evals, наблюдаемости и владельцев быстро превращается в риск.
И здесь доклад хорошо пересекается с моей старой темой про оргдизайн. В разборе Flo и Team Topologies я писал, что организация - это тоже архитектура: границы команд, ownership, интерфейсы, latency коммуникаций. AWS добавляет следующий слой: в agentic world оргструктура становится частью AI-архитектуры. Если агент меняет скорость исполнения, лидер должен заново спроектировать не только инструменты, но и форму команды, путь обучения людей и контур ответственности.
Для меня главный вывод такой: в следующие годы выиграют компании, у которых вокруг AI быстрее созреет операционная модель, а не просто будут розданы лицензии всем желающим.
#AI #AI4SDLC #Management #Leadership #Architecture #Agents
YouTube
A leader’s guide to advanced team structures in an agentic world | AWS Events
As AI agents transform the workplace, organizations must adapt their structures and methodologies to harness new opportunities. The probabilistic nature of AI requires continuous iteration and intelligent oversight, creating new ways of working across business…
1❤7👍4🔥1
Внутри AI (How AI Works) (Рубрика #Books)
Прочитал по дороге во Владивосток книгу "Внутри AI. Как это работает" Рональда Кнойзеля, которая простыми словами объясняет сложные темы буквально на пальцах. Правда, надо отметить, что оргинал "How AI Works: From Sorcery to Science" вышла в 2023 году, а переводная книга вышла в 2026 году. Сам автор, Ronald T. Kneusel, является дата сатанистом, который имеет опыт в медицинском домене.
Мне показалось, что автор поставил себе задачу объяснить AI так, чтобы читатель перестал воспринимать AI как магию. Для этого Рональд начинает не с ChatGPT и не с трансформеров, а с более старой и полезной классики: регрессии, деревьев решений, случайных лесов, метода ближайших соседей и опорных векторов. Это не очень модно, но зато подход к gen AI происходит последовательно, а не рывком.
Мне понравилось объяснение про интерполяцию и экстрополяцию при обучении модели на существующих примерах. Условно, модель видит обучающую выборку, подстраивает параметры, пытается уловить устойчивый паттерн. А потом начинается самое интересное — инференс на новых данных, которых в обучающей выборке не было. И вот здесь сразу появляется практичный вопрос: модель работает внутри знакомой области или уже нет? В итоге, автор показывает, что полезно думать через интерполяцию и экстраполяцию:
— Интерполяция — это когда новый пример похож на то, что модель уже видела, и ей нужно восстановить значение между знакомыми точками
— Экстраполяция — когда мы просим модель перенести закономерность туда, где данных почти не было.
В реальной инженерной работе именно здесь часто и рождаются неприятные сюрпризы: на тестах все выглядело прилично, а в новых условиях модель начала уверенно отвечать без хорошей опоры.
После этого автор постепенно переходит к нейросетям и MLP (multi layer perceptron) хорошо показывает механику: простые вычислительные блоки, веса, слои, ошибка, обучение, повторение. Это, конечно, не заменяет курс по deep learning, но дает правильную интуицию: нейросеть не "понимает" мир в человеческом смысле, а настраивает большое число параметров под примеры. Отдельно хорошо подана глава про CNN. Автор показывает как изображение разбирается через локальные признаки, фильтры, слои и постепенную сборку более сложного представления. После такой главы начинаешь смотреть на computer vision более системно, а не только через математику.
В самом конце автор доходит до GenAI, где рассматривает генеративно-состязательные сети, диффузионные модели, большие языковые модели и того, почему текстовые системы вроде ChatGPT произвели такой сильный эффект. Книга останавливается на информации 2023 года, поэтому она скорее мостик к теме, а не актуальная история. Поэтому если нужен свежий разбор агентов, RAG, MCP, evals, наблюдаемости, production AI стека и того, как все это внедрять в компании, то стоит поискать другую книгу.
Итого, книга просто объясняет базу и напоминает, что перед разговорами про frontier models полезно понимать, что такое обучающая выборка, обобщение, ошибка, переобучение, признаки, параметры и инференс.
#Books #AI #ML #DeepLearning #GenAI #Engineering #Software #Math
Прочитал по дороге во Владивосток книгу "Внутри AI. Как это работает" Рональда Кнойзеля, которая простыми словами объясняет сложные темы буквально на пальцах. Правда, надо отметить, что оргинал "How AI Works: From Sorcery to Science" вышла в 2023 году, а переводная книга вышла в 2026 году. Сам автор, Ronald T. Kneusel, является дата сатанистом, который имеет опыт в медицинском домене.
Мне показалось, что автор поставил себе задачу объяснить AI так, чтобы читатель перестал воспринимать AI как магию. Для этого Рональд начинает не с ChatGPT и не с трансформеров, а с более старой и полезной классики: регрессии, деревьев решений, случайных лесов, метода ближайших соседей и опорных векторов. Это не очень модно, но зато подход к gen AI происходит последовательно, а не рывком.
Мне понравилось объяснение про интерполяцию и экстрополяцию при обучении модели на существующих примерах. Условно, модель видит обучающую выборку, подстраивает параметры, пытается уловить устойчивый паттерн. А потом начинается самое интересное — инференс на новых данных, которых в обучающей выборке не было. И вот здесь сразу появляется практичный вопрос: модель работает внутри знакомой области или уже нет? В итоге, автор показывает, что полезно думать через интерполяцию и экстраполяцию:
— Интерполяция — это когда новый пример похож на то, что модель уже видела, и ей нужно восстановить значение между знакомыми точками
— Экстраполяция — когда мы просим модель перенести закономерность туда, где данных почти не было.
В реальной инженерной работе именно здесь часто и рождаются неприятные сюрпризы: на тестах все выглядело прилично, а в новых условиях модель начала уверенно отвечать без хорошей опоры.
После этого автор постепенно переходит к нейросетям и MLP (multi layer perceptron) хорошо показывает механику: простые вычислительные блоки, веса, слои, ошибка, обучение, повторение. Это, конечно, не заменяет курс по deep learning, но дает правильную интуицию: нейросеть не "понимает" мир в человеческом смысле, а настраивает большое число параметров под примеры. Отдельно хорошо подана глава про CNN. Автор показывает как изображение разбирается через локальные признаки, фильтры, слои и постепенную сборку более сложного представления. После такой главы начинаешь смотреть на computer vision более системно, а не только через математику.
В самом конце автор доходит до GenAI, где рассматривает генеративно-состязательные сети, диффузионные модели, большие языковые модели и того, почему текстовые системы вроде ChatGPT произвели такой сильный эффект. Книга останавливается на информации 2023 года, поэтому она скорее мостик к теме, а не актуальная история. Поэтому если нужен свежий разбор агентов, RAG, MCP, evals, наблюдаемости, production AI стека и того, как все это внедрять в компании, то стоит поискать другую книгу.
Итого, книга просто объясняет базу и напоминает, что перед разговорами про frontier models полезно понимать, что такое обучающая выборка, обобщение, ошибка, переобучение, признаки, параметры и инференс.
#Books #AI #ML #DeepLearning #GenAI #Engineering #Software #Math
1🔥11❤7👍2
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:…
👍9❤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.…
🔥10❤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
👍17❤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
👍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
🔥5❤4✍1