https://github.com/obra/superpowers/releases/tag/v5.0.6

Значимое событие в области харнеса отыгрывает за лагерь сокращения старых обвесов мультиагентности.
Автор superpowers выпилил мультиагентное ревью, со словами что чеклист самопроверки справляет лучше и быстрее.

# Масленников разобрал лагери обвесов харенса
https://habr.com/ru/articles/1058676/

Причем мои наблюдения подтверждают что "минималисты" которых он выделил зачастую приверженцы SDD. Я у многих приверженцев готовых SDD фреймворков, на которых они строят слой харнеса поверх базовой шины контекста узнавал что они не упарываются в мультиагентность.

# Мой взгляд на мультиагентность:
1. Многие сабагенты которые мы делали в 2025ом - стали не нужны. Часто мы их делали т.к. не влезали в контекстное окно, да и в эпоху когда скилов не было. Бездумное следование старым привычкам - зло.
2. Мои наблюдения (eval еще не выкатили чтобы сказать замеры), показывают достаточно неплохое качество замыкание на чеклисте самопроверки из SDD при работе в 1 поток.

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

Собственно есть разные поинты когда нужно идти в мультиагентов, когда нет.
Например базовые правила что мелкие подзадачи с большим выводом и малым вводом можно делегировать чтобы экономить окно. И в недавних патчах агенты вроде claude code / codex даже начали САМИ это делать без ручных оптимизаций.

Один из поинтов когда стоит нарезать мультиагентов вручную выразил Николай Сенин на AgenticDevConf и который я тоже нахожу весьма неплохим (скрин ниже).
Еще поинт из того же доклада про то что иногда делегирование подзадач дает просто лишнюю потерю токенов т.к. нужно многим подагентам объяснять один и тот же контекст.

Существует очень много разные точек роста харнеса, и мультиагентность лишь одна из многих инженерных практик для его прокачки. Возможно прокачка вашей SDD шины даст больше эффекта.

Немного про измерение эффективности от внедрения AI в SDLC

Количество часов разговоров с коллегами в отрасли на эту тему за последний год я бы мог исчислить десятками)
Например пол года назад тут с коллегами из Т-Банк, Яндекс и WB (FunSun) или пару недель назад в круглом столе про ФОТ. Или под новый год на митапе smallTech.
Также много разговоров с коллегами в кулуарах Saint Haighload++, TeamLeadConf, Sber Arch.Meethup и еще многих других.
Кстати так сложилось что практически не обсуждали на Agentic Dev Conf, там как будто бы у людей другой вайб, сильно больше тех кто уже обосновал для бизнеса эффективность.

Я бы разделил следующие фазы этого дискуссии.

# ФАЗА 1:
А ТОЧНО ЛИ УСКОРЯЕТСЯ САМ ПРОЦЕСС РАЗРАБОТКИ?

## Лагерь сомневающихся в ускорении
В многом коллеги ссылаются на какие нибудь среднерыночные исследования, но берут конечно те, которые подчеркивают их картину мира, игнорируя отчеты и кейсы других компаний. Здесь мне кажется стоит разбирать кейсы, практический опыт и результаты конкретных компаний и потенциал воспроизводимости тх опыта. Это точно полезнее средних опросов по больнице.

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

На мой взгляд в таких случаях правильный вопрос: а стоит ли параллелить решение вопросов. Иногда можно на AI рельсах пересобрать новомодные tiny team это как раз способ и перезагрузить проржавевшие старые процессы.
А с AI флагом сейчас можно как раньше с agile флагом ломать многие преграды внутри корпоративных укладов.

Третий довод: что упираемся в когнитивные возможности человека на валидацию (многие об в т.ч. Никита в канале SE Materials подсвечивает риск).
Я бы тут прокомментировал что большую часть когнитивных возможностей должен решать harness. Предел конечно же есть, однако на мой взгляд этот предел точно х2-х3 выше чем работа в старых парадигмах. Запуская harness в 2-3 потока с высоким уровнем автономности (работа часами с самопроверкой до результата), ты можешь поочередно решить 2-3 задачи тогда когда решал за это время условно 0.5.
Но тема большая в т.ч. если раскрывать мультипоточность работы разработчика в новых реалиях.

## Лагерь адоптеров

Можно поделить на тех кто нашел способ доказать ускорение на пилотах в определенных командах. Я видел разные пилоты в корпорациях за последние пол года

1. Внедрение в greenfield проект. Берут greenfield проект, оцениваются конвенциональными способами разработки в год (верифицируют оценку другими старыми командами). И потом эффективно делают его за пару месяцев.
Примеров видел много, вот публичный кейс x5, доклады Александра Поломодова (Тбанк) в т.ч. на последнем Highload++ рассказывает об успехе таких команд, много данных в кулуарах конференций. Да и в целом кажется про успехи в greenfield не рассказывал только ленивый.

2. Внедрение в brownField проекты
Это уже интереснее т.к. было много споров что вот на старых то проектах внедрить нельзя. Но пилоты многих показали что и тут можно добиваться значимых результатов.
На Agentic Dev Conf и грядущем TeamLead Conf Siberia коллеги из райфа показывают такие пилоты и их успех в разных не связанных вертикалях.
Есть и много других проектов, и в т.ч. мы в в Вебпрактик видим ускорение в т.ч. в brownfield проектах, если правильно работать с контекстом и правильно затачивать под это harness.
Причем как про микросервисную (могу говорить про десятки/сотни) так про монолитную brownfield архитектурой.

Т.е. в лагере адоптеров есть много кейсов когда они доказали эффективность бизнесу через прирост производительности разработка в конкретных метриках.

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

# ФАЗА 2:
ТРАССИРОВКА ЭФФЕКТОВ ОТ УСКОРЕНИЯ НА БИЗНЕС

Когда обе стороны принимают факт что разработка ускорилась, или сторона сомневающихся условно принимает довод что разработка ускорилась.

И один из ключевых вопросов который задают: а точно ли ускорение разработки дает эффект в бизнесе.
Измеримый сквозной throuthput. В идеале в финансах.

И тут ловушка в которую попадает этот вопрос: что даже в мире без ai в большинстве команд не могут однозначно сказать на сколько те или иные гипотезы беклога определенного продукта повлияли на сквозную пользу для бизнеса который выразился в финансовом результате. Могут быть какие нибудь промежуточные метрики, но на сколько они точно влияют на конечный бизнес результат сложно.

Да, есть кейсы когда это можно трассировать прозрачно как ускорение переработки беклога дает прозрачный бизнес результат. Но померить влияние на финансы какой нибудь команды в микросервисной архитектуре порой весьма непростая задача)

И тогда 2 сценария
а) У вас есть возможность доказать бизнесу что беклог действительно конвертируется в ценность и ускорение переработки беклога = польза.
б) У вас идут сценарии доказания через сохранение скорости беклога, но сокращение ресурсов.

===
В целом в правильном споре стоит разделять уровени, и спорить на каждой конкретно: разработчик / команда / поток доставки / бизнес
Часто в спорах идет перепрыгивания с уровня на уровень, причем не осознанное.

На мой взгляд эффективность разработки доказана давно. Лето 2026 славится тем что уже к этому моменту за весну многие корпорации откатали свои пилоты и пришли с публичными результатами о которых могут заявлять. Сейчас все начинают думать как масштабировать этот опыт и решать те боли с которыми столкнулись в процессе.

Нельзя не уважить лагерь тех кто говорит подходить аккуратнее и утверждают что можно получить ускорение больше классическими методами поиска узких мест без AI, особенно если у вас накопился большой ворох проблем и те самые 10% написания кода происходяи в результате огромного количества блокеров. Но имхо эти процессы нужно параллелить. Чтобы к тому моменту когда вы разошьете старые проблемы, не оказалось что вы с самом начале перевода производства на новые рельсы.

Несмотря на то что я уже лет 20 живу в Ростове-на-Дону, корнями я из Урала и Сибири. Отец военный и, родившись на Урале, я успел пожить в нескольких сибирских городах)
Но в душе я сибиряк и до сих пор говорю что "у нас в сибири", хотя по логике уже должен был давно перестать)

Радостно что в Сибири тоже проходят движуха, и в этот раз я немного помог ближайшему TeamLead Сибирь, проходящему в Новосибирске с подготовкой нескольких докладов в AI треке)

Кажется будет прям неплохо, если собираетесь посетить забирайте промокод от члена ПК: PODDUBNY

https://teamleadconf.ru/siberia/2026

P.S. Фирменный стиль конфы с мишками у них огонь)

Сегодня вечером поделюсь про матрицы зрелости у коллеги на канале)

По сути обновленный контент моего доклада с хайлоада про матрицы зрелости и инженерные вызовы построения автономности.

Приходите кому интересно, онлайн трансляция

Как используют клод при производстве деталей)
Выводы в конце содержат флешбеки к ит =)

https://youtube.com/shorts/kTBf_8743aA?si=KNqGfRMHRU2SrUq3

Я вечером со своими агентами =)

Интересные скилы для визуализации архитектуры.
1. https://github.com/tt-a1i/archify
2. https://github.com/cathrynlavery/diagram-design