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

Окно этого выпуска: с 15 по 21 сентября 2026 года. Главный сюжет недели: агентные сценарии стало легко предлагать, но трудно обоснованно выбирать между ними. Первый прототип часто можно собрать быстро. Решение о масштабировании требует отдельной проверки: в какие сценарии вкладывать время людей, бюджет и внимание, а какие остановить до того, как они станут привычной, но бесполезной работой.

Шкала доказательности: 🟢🟢🟢 — несколько независимых крупных источников прямо подтверждают тезис; 🟡🟡⚪ — сходятся свежие отчёты, практические наблюдения и ограниченные исследования; 🔴⚪⚪ — ранний сигнал, годится для наблюдения, не для управленческого решения.

Сценарий с агентом — это ставка на ограниченную мощность команды

🟡🟡⚪

Какой AI-сценарий заслуживает ещё двух недель команды, а какой — только красивой демо-записи?

Pragmatic Engineer (2026) — инженерная рассылка Гергели ОросаПубликует разборы разработки, платформенных команд и инженерных организаций; этот выпуск основан на визите в OpenAI и интервью с семью инженерными лидерами и инженерами описал OpenAI как agentic software factory. В таком режиме предложение новых способов работы растёт очень быстро: агент может разобрать задачу, подготовить изменение, написать тесты, собрать информацию из репозитория, помочь с инцидентом. Каждая демонстрация выглядит как кандидат на масштабирование.

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

Arena HarnessTax (2026) — benchmark от Arena.aiArena.ai сравнила 21 пару model–harness на SWE-bench Lite и Terminal-Bench 2.0; это benchmark, не production telemetry даёт полезную цифру: в тестах некоторые пары model–harness при близком success rate показывали различие стоимости до 5 раз. Это не инструкция покупать самый дешёвый вариант. Это причина не считать «внедрение агента» одним решением. Модель, контекст, инструменты, повторные попытки и роль человека образуют отдельную ставку — со своей ценой и шансом на результат.

Поэтому полезная единица управления — не лицензия и не отдельный prompt, а сценарий: например, «агент готовит обновления тестов для повторяющихся дефектов» или «агент собирает первый черновик миграции зависимости». У сценария должна быть карточка инвестиционного решения: гипотеза о полезном эффекте, потолок затрат и дата следующего решения. Без этого организация не внедряет AI, а просто накапливает эксперименты, которые никто не умеет закрывать.

Рынок сравнивает модели. Руководитель выбирает конфигурацию на своих задачах

🟡🟡⚪

Вы выбираете агента по чужому рейтингу или по тому, какую работу он снимает именно у вашей команды?

Большие бенчмарки нужны рынку. Они помогают увидеть, что появилось новое поколение возможностей. Они не заменяют проверку приоритета и эффекта в конкретной организации. В одном репозитории дорогим местом будет обновление тестов. В другом — разбор дефектов на стыке сервисов. В третьем агент ускорит создание черновика и добавит столько переделок, что инвестиция не окупится.

DeltaSelect (2026) — arXiv-препринт по A/B-тестированию coding agentsМетод от 17 сентября 2026 года предлагает выбирать небольшую группу задач, которая коррелирует с полным benchmark; это ранний метод, не отраслевой стандарт предлагает разумную форму проверки: выбрать фиксированный, небольшой набор задач и сравнивать на нём текущую и новую конфигурации. Авторы отобрали 22 из 113 задач DeepSWE как компактный набор, чьи результаты устойчиво согласовывались с результатом полного benchmark. Вывод спокойный: даже внутри одного набора задач нельзя бездумно переносить общий балл на любую работу команды.

Для руководителя здесь важен не статистический трюк, а дисциплина выбора. Возьмите 10–20 задач, которые действительно повторяются в потоке: исправление дефекта, обновление теста, небольшая миграция зависимости, изменение API, рефакторинг с понятными границами. Для каждой заранее запишите: какой результат считается годным, сколько времени человека допустимо потратить, какую стоимость допускаете и какой сигнал означает, что эксперимент нужно остановить.

Оценивать нужно не абстрактного «агента», а пару: сценарий и конфигурацию. Тогда сравнение отвечает на нормальный управленческий вопрос: «Стоит ли выделить на это ещё одну долю времени и внимания команды?» Если новая конфигурация выигрывает на вашей выборке, её можно расширять. Если она убедительна только на демо или на учебной задаче, её место пока в списке наблюдения, а не в дорожной карте.

Признак зрелости — не число запусков, а умение сказать «нет»

🟡🟡⚪

Сколько AI-сценариев у вас уже работают по инерции, хотя никто не может назвать решение, ради которого их запускали?

GitHub Changelog (2026) — официальный журнал изменений GitHubGitHub — платформа разработки и владелец Copilot; changelog подтверждает продуктовые функции, без доказательства бизнес-эффекта добавил usage metrics для VS Code Agents, уровни выбора модели и запросы дополнительного бюджета по AI credits. Это полезный материал для учёта. Он не отвечает на главный вопрос: какой сценарий реально стоит масштабировать.

Число сессий, токенов, pull requests и часов, которые люди называют сэкономленными, — сигналы активности. Их самих по себе не следует принимать за эффект. Агент, который генерирует много кандидатов и занимает время сильных инженеров, может оказаться невыгодным, если время проверки и переделок превышает сэкономленное время. Дорогой сценарий может оказаться разумным, если снимает хроническую очередь, уменьшает повторяющийся ручной труд или открывает возможность, которой раньше не было.

Поэтому портфель AI-сценариев полезно обсуждать в трёх решениях, а не в одном отчёте об использовании:

  1. Масштабировать. Есть повторяемая задача, понятный эффект на работу команды или клиента и доказательство на локальной выборке.
  2. Продолжить ограниченный эксперимент. Гипотеза выглядит живой, доказательств мало; команда оставляет небольшой бюджет и конкретный следующий тест.
  3. Остановить. Нет эффекта, цена человека слишком высока или сценарий не смог показать преимущество над текущим способом работы.

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

У хорошего портфеля третья колонка не пустует. Отказ — не провал AI-программы. Это способ освободить внимание для более сильной ставки. Такой подход ограничивает стоимость затянувшегося пилота и освобождает внимание для других ставок.

Эффект AI нужно сравнивать с альтернативой для команды

🟡🟡⚪

Если бы команда не вложила этот месяц в агента, что ещё она могла бы улучшить?

James Shore (2026) — консультант и автор по инженерным практикамПишет о гибкой разработке, технических практиках и измерении software delivery; статья от 15 сентября 2026 года предлагает дизайн измерения влияния AI предлагает сравнивать похожие задачи внутри одной команды, а не объявлять успехом рост числа артефактов. Это полезно именно для портфельного решения. Агент конкурирует не с нулём. Он конкурирует с другими способами потратить ограниченное время команды: убрать повторяющийся дефект, улучшить тестовую среду, сократить ручную операцию, закрыть продуктовую гипотезу.

BairesDev Q3 Dev Barometer (2026) — опрос разработчиков и CTOBairesDev — сервисная компания разработки; отчёт основан на самооценке 705 разработчиков из 60+ стран и 41 CTO, поэтому цифры показывают восприятие, не causal-эффект показывает знакомое расхождение: разработчики сообщили в среднем о 13 часах сэкономленного coding time в неделю, 67% сказали, что тратят больше времени на ревью AI-кода, а среднее время обучения AI-инструментам достигло 9 часов в неделю. Это самоотчёты по разным вопросам, их нельзя складывать в чистый баланс часов. Они показывают, почему заявленную экономию coding time нельзя без локального измерения считать чистой экономией времени команды.

Портфельная метрика поэтому должна быть короткой и честной. Для каждого сценария нужны: изменение времени до результата на сопоставимых задачах, стоимость запуска, время человека на проверку и переделку, качество принятого результата, а затем — ожидаемый эффект для продукта или операции. Не обязательно собирать огромную панель. Достаточно, чтобы после двух недель команда могла принять одно из трёх решений: расширяем, проверяем ещё раз в узких границах или закрываем.

Что сделать в ближайшие две недели

  1. Соберите портфель, а не список инструментов. Выпишите все текущие и предложенные AI-сценарии. Для каждого укажите задачу, гипотезу ценности, владельца, потребность во времени сильных специалистов и дату следующего решения.

  2. Если контекст команды ограничен, начните не более чем с двух сценариев. Остальные не запрещайте — поставьте в очередь. Лимит защищает от ситуации, когда пять пилотов одновременно съедают контекст команды и ни один не даёт доказательства.

  3. Для первого цикла сделайте локальный набор из 10–20 задач. Выберите повторяющиеся рабочие задачи, определите критерии годности и сравнивайте текущий способ с новой конфигурацией на одном наборе.

  4. Задайте потолок инвестиций. Сюда входят не только расходы на модель, а полная цена эксперимента: подготовка, проверка результата, исправления и повторные попытки. Когда потолок достигнут, сценарий идёт на решение. Продление допустимо только при заранее записанном промежуточном критерии; иначе — остановка или возврат в очередь.

  5. Проведите короткий разбор инвестиционного решения. Например, через две недели — или после заранее заданного объёма работ — спросите: что изменилось в работе команды или для клиента; что стоило получить этот эффект; расширяем, оставляем в ограниченном эксперименте или закрываем.

Что ещё почитать

Вопрос выпуска: какой ваш AI-сценарий вы готовы закрыть через две недели, если он не покажет ценность лучше альтернативного использования времени команды?

Human Loop Weekly выходит раз в две недели, по понедельникам.

📱 Telegram: @predictableteam
🌐 Website: maratkee.com