Представим обычную продуктовую задачу. Нужно добавить новую фичу. Команда описывает её через Specification-Driven Development и фиксирует сценарии, ограничения, API и критерии приёмки. Агент получает контекст, быстро пишет код, тесты и инфраструктуру. Через день, а то и раньше, почти готов результат. Но где здесь waterfall?

Если фича изолирована, команда может безопасно выкатить её под флагом, быстро увидеть пользовательский сигнал и так же быстро откатить изменение. Тогда большой агентный батч становится отличным экспериментом.

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

Здесь и далее: скрам‑мастер и аджайл коуч тождественны.

TL;DR Роль Agile Coach должна умереть, чтобы переродиться в роль Change Agent (или Organizational Architect). И работать такие спецы должны не «вечно», а проектно — как спецназ внедрения изменений. Самое главное — у роли должна наконец‑то появляться ответственность.

В посте разберем 4 утверждения: какой должна быть система работы, какие вопросы задать чтобы понять что импакт от коуча есть, почему важно делать нужные бизнесу изменения и то, что софт скилы — это новые харды.

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

Рассмотрим: на чем основан "успех" Tiny Teams, почему он на всех не натягивается, как сложность предметной области, система, ответственность и платформа влияют на возможности создания таких команд.

Спойлер: направление скорее правильное, но доказательств эффективности нет, потому что все зависит от специфики предметной области команды и сложности системы.

AI уже вошёл в работу IT- команд. Доступы выдали, обучение провели, демо показали, и как будто активность в инструментах растёт. А Lead Time (время от взятия обязательств до прода), Throughput (сколько работы команда делает) меняются гораздо медленнее. Иногда не меняются вообще.

Сопротивление AI в такой ситуации полезно читать как диагностику системы. Оно показывает место, где команда ещё не договорилась: про цель, инструмент, ответственность, безопасность или поток работы.

В первой части статьи мы пришли к выводу, что само использование ИИ не ускоряет инженерную систему. Можно вырастить MAU LLM, потом MAU API, раздать людям кодинг-агентов и всё равно не увидеть изменений в Lead Time, Throughput и Defect Rate.

Проблема в том, что локальное ускорение быстро упирается в остальной процесс. Один человек или одна роль могут начать делать свою часть быстрее, но задача всё равно ждёт требований, проверки, тестирования, согласований, соседних команд или бизнес-эксперта. Поэтому дальше мы пошли в Agentic Engineering.

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

Привет, Хабр! Меня зовут Марат Киньябулатов, я эксперт по гибким практикам и отвечаю за эффективность инженерных команд в ядре банка. В этой статье расскажу, какие гипотезы мы проверяли при внедрении ИИ, почему рост использования чатов и кодинг-агентов не равен росту скорости, какие метрики помогали отделять привычку от результата и как мы пришли к идее Agentic Engineering.

Баги — неизбежная часть разработки. 

В этой статье расскажу наш опыт: как мы внедрили Zero Bug Policy в нашем стартапе (B2B fintech) и за месяц сократили backlog с 77 до 18 багов. А главное — как это изменило культуру и отношения с клиентами.

Пока вы работаете, ваш коллега уже сжёг 210 миллиардов токенов за неделю. Это 33 Википедии. Он не написал ни строчки в продакшн — но возглавил корпоративный лидерборд и получил звание «Token Legend».

Токенмаксинг (tokenmaxxing) — это практика, при которой сотрудники компаний соревнуются за максимальное потребление токенов, превращая сам факт использования ИИ-инструментов в показатель производительности.

Рассмотрим откуда пошел термин, почему люди соревнуются и причем тут Performance Review в FAANG.

Рассуждаем на тему того, что AI-агенты радикально скукожили привычный нам цикл разработки.

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

В greenfield — минимум контроля, observability вместо code review. В brownfield — AI генерирует, человек валидирует. А там где много регуляторки ускорение есть, но и ответственность никуда не делась.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

В посте рассмотрим модель эффективной команды под названием "Учпочмак".

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

Обсудим, как диагностировать проблемы на каждой вершине "треугольника", какие таргеты поставить, а также почему несогласованность целей на масштабе нескольких команд - это главная проблема, с которой нужно бороться.

Первое крупное контролируемое исследование влияния ИИ-ассистентов на поддерживаемость кода: код, написанный с GitHub Copilot и Cursor, не стал сложнее в эволюции для других разработчиков. В двухфазном эксперименте с 151 участником (95% — практикующие специалисты) одни разработчики создавали фичи с ИИ и без, а другие — развивали чужой код, не зная его происхождения.

Результат: нет значимых различий по времени, качеству кода (CodeHealth) или покрытию тестами. При этом в первой фазе ИИ дал типичное ускорение на 31–56%. Авторы предупреждают о двух невидимых рисках — раздувании кода и когнитивном долге — которые краткосрочные метрики не захватывают.

TL;DR План «заменим разработчиков ИИ» провалился. Вот цифры

• 95% корпоративных GenAI-пилотов не дали ни доллара ROI. 

• 45% AI-кода содержит уязвимости из OWASP Top 10. 

• Набор джунов упал на 50%, а техдолг вырос в разы.

Вместо обещанной «революции» получили slop layer - код, который работает, но никто не понимает как. Senior'ы тратят 11 часов в неделю на проверку AI-галлюцинаций и работают медленнее, чем без ассистентов.

По мотивам интересного видео разобрал данные MIT, Stanford, Veracode и CodeRabbit -> что пошло не так и что с этим делать компаниям и разработчикам.

Общий объем планируемых инвестиций в ИИ-инфраструктуру к 2030 году достигнет $2.75 трлн, при этом частный капитал ($2.22 трлн) намного превосходит государственные вложения ($530 млрд). Каждая страна выбирает уникальный вектор развития, отражающий национальные приоритеты и геополитическое позиционирование.

В статье посмотрим на запланированные и уже исполненные инвестиции в ИИ-инфру по основным странам (и сравним с РФ).

Из-за экспортных ограничений США, китайские производители AI-чипов переманивают бывших сотрудников Nvidia и активно развивают свое железо.

В обзоре рассмотрим на самые перспективные стартапы в области разработки ИИ-железа (Cambricon, Baidu, Huawei, Moore Threads, Enflame, MetaX), разберем самые известные чипы этих компаний, сравним их с чипами от Nvidia и AMD.

Как использовать метрику потока Throughput и реалистично прогнозировать на основе симуляции Монте-Карло. Разберем динамику Throughput (пропускной способности) за значимые периоды времени, насколько она вариативна, посмотрим на кластеризацию по типам работы).

Разбираем метрику через обслуживание в пабе в пятничный вечер в сравнении с АйТи-командой (с паттернами и примерами). Тема довольно актуальная, так как сейчас в США и Европе расцвет прогнозирования на основе именно метрик потока и появляется много плагинов с Монте-Карло (но не все из них доступны в РФ).

За семь лет проведения воркшопов по Story Points я наблюдаю одну и ту же картину: команды изучают технику, применяют её несколько спринтов, а затем постепенно возвращаются к старым паттернам. И если на маленьких масштабах работы с одной командой или тремя кажется что Story Points прекрасный подход, на текущем масштабе — около 50 команд в IT — 60% используют Story Points, 40% не используют - я вижу совершенно иную картину. И вот что интересно: те 60%, которые используют, делают это крайне по-разному.

Причем конверсия в правильное использование Story Points 3 месяца после тренингов составляет дай бог 20%. Проблема не в самом инструменте, а в том, как мы его используем и для каких целей.

Стартапы в последние пару лет, мягко говоря, оказались между Сциллой и Харибдой. Многие бизнесы начали сжиматься (а ЦБ стран жестить), а венчурные фонды внезапно стали очень бережливыми. Как поступают стартапы в США в эпоху неопределенности? Правильно, сразу сокращают персонал и закрываются. Сегодня все уже забыли оптимизм постковидного 2021 года. 

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

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

В работе с Incident Management-фреймворком мы в инжиниринге преследовали две основные цели: довести uptime до 99,99% (в API / SDK), и всегда знать о проблеме раньше пользователей.

В наши первые дни у нас не было всеобъемлющей системы оповещения и мониторинга. А если и была, то с кучей false-positive алертов и буквально одним-двумя графами в Kibana. Поэтому начать мы решили с создания команды Network Operations Center (NOC) - как стратегического базиса для работы с предотвращением и управлением инцидентами. Мы не только достигли показателя времени безотказной работы в 99,98%, но и увеличили нашу проактивность в выявлении инцидентов заранее: с 60% до впечатляющих 95% и выше. А все благодаря не только активному участию в улучшении платформы со стороны инженерки, но еще и благодаря метрикам First Time to Respond, Time to Acknowledge, Time to Assemble, Proactive Engineering Detection Rate, Number of Critical False Positives. В этом посте я расскажу про каждую из них, какие бывают антипаттерны, как измерять и как улучшать.

В последнее время я достаточно часто использую Trello, и, должен признаться, выглядит пока Трелло как наилучший инструмент для Ретроспектив и Фидбека по Демо. Так что в этом после попробуем пройтись по теме того, как Trello соотносится с другими аналогичными для этих задач инструментами.

Инструменты

Я пользовался большим количеством инструментов, из которых можно выделить основные: Miro - как интерактивный флипчарт, с которым может взаимодействовать вся командa; Google Docs с секциями помапанными на стадии ретроспектив; Confluence (так как все мои проекты пронзены Atlassian-стеком); а также, порой, Jira (вау, это была достаточно плохая идея)!

Я думаю что все пытались нащупать тот самый инструмент, который можно применить фактически в любой области!

И вот я бы выделил основными критериями для проведения Ретро и собирания фидбека о Демо в подобных инструментах:

1. Насколько хорошо оно работает на уровне объектов (во время обсуждений). -> в идеале тут хотелось бы видеть карточки (все таки мы в физическом мире работаем со стикерами)

2. Быстрая и эффективная работа с карточками / объектами

3. Подсветка / теги для карточек / объектив (чтоб все могли), не важно как (цвет, тег, еще какая-то штука позволяющая дифференцировать карточки)

4. Перетасовка / изменение порядка карточек / объектов / айтемов

5. Как можно меньшее время, затраченное на следующую последовательность действий: создание секции (списка) -> добавление в него объектов / карточек -> тегирование / подсветка айтемов (членами команды) -> добавление комментария к айтему.