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

Окно этого выпуска: после 7 сентября и до утра 14 сентября 2026 года по Екатеринбургу. Главный сюжет недели простой: AI-агенты перестали быть только «помощником разработчика в редакторе». Они входят в кодовую базу, песочницы, очереди ревью, журналы действий и инфраструктурные правила. Значит, управлять нужно маршрутом, по которому агентное изменение становится рабочим результатом: от запроса и песочницы до ревью, журнала действий и решения человека.

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

Код-ревью превращается в сортировку риска

🟡🟡⚪

Сколько изменений ваша команда реально должна читать глазами, если часть кода уже написана AI?

На этой неделе тема ревью пришла сразу из двух мест. Pragmatic Engineer (2026) — инженерная рассылкаПрактическая рассылка Гергели Ороса про разработку, платформенные команды и управление инженерными организациями разобрал, как команды переосмысляют code review. Leadership in Tech (2026) — еженедельная подборка для инженерных лидеровРассылка про инженерное лидерство, организационный дизайн и практики командной разработки отдельно вынесла тезис: мы не должны читать весь этот код одинаково внимательно.

Сигнал управленческий. Ревью долго жило как универсальный ритуал: каждый pull request проходит через человека, человек ловит баги, учит автора, держит архитектурную память. AI увеличивает объём изменений и снижает цену создания черновика. Очередь к ревьюеру растёт быстрее, чем способность ревьюера держать контекст.

Значит, первый вопрос меняется. Раньше менеджер спрашивал: «Почему ревью идёт долго?» Теперь полезнее спросить: «Какие изменения заслуживают дорогого человеческого внимания?» Рутинный рефакторинг, форматирование, обновление документации, простые тесты и зависимость без широкого эффекта должны проходить через автоматические проверки раньше человека. Изменения в расчётах денег, правах доступа, данных клиентов, схемах, интеграциях и аварийных путях должны получать ревьюера с доменным знанием.

Одна очередь ревью для всех pull requests становится скрытым налогом. В ней рядом лежат мелкие безопасные правки и изменения, способные сломать продакшен. AI делает этот налог заметным, потому что увеличивает количество черновиков. Система ревью начинает работать как первичная сортировка обращений в больнице: сначала отделить лёгкое от опасного, затем отправить врача туда, где его решение меняет исход.

Практическая граница важна. Свежие рассылки дают сильный практический сигнал, не эксперимент с контрольной группой. Поэтому вывод не «отменяем ревью». Вывод суше: ревью нужно проектировать как маршрут риска. Автоматические проверки стоят перед человеком. Человек смотрит туда, где нужна ответственность, контекст и решение о цене ошибки.

Небольшая AI-команда жизнеспособна только при сохранённой ответственности за результат

🟡🟡⚪

Если AI помогает писать больше кода, какую работу выполняли люди, которых теперь хочется убрать из состава?

LeadDev (2026) — медиа для инженерных лидеровПубликует материалы о менеджменте разработки, командах, платформах и организационных практиках описал свежий кейс: MetaКрупная технологическая компания, владелец Facebook, Instagram, WhatsApp и собственной AI-инфраструктуры пробовала строить небольшие AI-ориентированные инженерные группы. В материале есть важная деталь: рост code changes оказался быстрее роста shipped features, incidents тоже вошли в разговор. Это та самая ловушка, где метрика активности выглядит как прогресс.

Jellyfish State of Engineering Management 2026 — ежегодный отчёт engineering intelligence платформыJellyfish собирает данные и опросы инженерных организаций; отчёт 2026 основан на 636 респондентах даёт фон: AI уже используется не только для написания кода. В отчёте 49% респондентов называют code review сценарием применения AI, рядом с 53% для написания кода. Это означает, что AI входит в обе стороны цикла: создаёт изменение и помогает его проверять.

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

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

Короче: вопрос размера команды нужно задавать через работу, которую команда обязана закрыть. Кто понимает домен? Кто принимает риск? Кто смотрит спорный pull request? Кто отвечает за ошибку после релиза? Если ответы ясные, AI помогает уменьшить состав или перераспределить роли. Если ответы размыты, сокращение превращает локальную экономию в системный риск.

Запуск Agents API переводит AI-adoption в инфраструктурное управление

🟡🟡⚪

Кто владеет агентом, когда он получает репозиторий, песочницу, инструменты и журнал действий?

10 сентября OpenAI представила Agents API — официальный продуктовый запускOpenAI — разработчик ChatGPT, API-моделей и инструментов для агентной разработки; запуск описывает публичную beta Agents API. Технические пересказы, включая MarkTechPost (2026) — технологическое медиаПубликует новости и объяснения по AI-инструментам, моделям и инфраструктуре, выделили ключевую деталь: Codex-подобный агентный контур теперь можно вызывать через API с сессиями, инструментами, окружением и событиями.

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

В открытых материалах важны ограничения. Beta означает отдельный заголовок API и нестабильность интерфейса. Технические разборы указывают на выбор hosted, self-hosted и partner sandbox, ограничение data residency США на старте и отсутствие Zero Data Retention для этого режима. Официальные документы OpenAI во время подготовки частично не открывались из-за 403, поэтому эти детали я учитываю как продуктовый сигнал и требование проверки, не как окончательный контракт для любой компании.

Один API-вызов может скрывать пять управленческих решений: где исполняется код, какие файлы доступны, какие команды разрешены, сколько стоит сессия, кто читает журнал действий. Если компания воспринимает это как покупку ещё одного AI-инструмента, она пропускает главный слой: агентный runtime становится частью инженерной операционной системы.

Практический ход простой. На каждый агентный сценарий нужен владелец: продуктовая команда, платформенная команда или группа, отвечающая за разработку при помощи AI-инструментов. Владелец фиксирует разрешённые репозитории, тип песочницы, доступ к секретам, правила записи логов, лимит расходов и путь остановки. Это скучная таблица. Именно такие скучные таблицы потом спасают от ситуации, где агент «просто помогал» и внезапно изменил то, за что никто не считал себя ответственным.

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

Хорошая первая метрика здесь не ROI. Слишком рано. Хорошая первая метрика — доля агентных запусков, где заранее известны владелец, разрешённая зона, лимит расходов, журнал действий и человек, принимающий финальное решение. Это скучный процент готовности процесса. Именно он показывает, может ли организация вообще безопасно масштабировать агентные сценарии.

Маршрут агента важнее красивого финального ответа

🟡🟡⚪

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

9 сентября вышли две полезные preprint-работы. AgentAudit — arXiv-исследованиеarXiv — открытый архив препринтов; статья ещё не равна рецензированной публикации предлагает проверять доверие к агенту по полному жизненному циклу: планирование, выбор инструмента, выполнение, память, безопасность, поведение в сложных ситуациях. IBIB — arXiv-исследование про enterprise-бенчмаркиРабота предлагает протокол измерения систем по serving route, output contract и harness вместо одного названия модели говорит похожую вещь другим языком: в корпоративной среде важно измерять serving route — конкретный маршрут обслуживания запроса, включая модель, точность, контракт вывода, инструменты и обвязку.

Это важный поворот для управленческой метрики. Таблица «модель X набрала Y» становится слишком грубой. Две команды могут использовать один и тот же бренд модели, получить разные результаты из-за маршрута: другой провайдер, другая точность, другой prompt harness, другой набор инструментов, другой способ обработки файлов. Снаружи это всё выглядит как «мы используем GPT-5». Внутри это разные производственные системы.

AgentAudit прямо полезен для инженерного управления, потому что переводит разговор о доверии в наблюдаемые следы. Агент мог дать правильный ответ случайно, через опасный инструмент, с лишним доступом к памяти или с ошибочным планом, который повезло не довести до аварии. Обычная метрика pass/fail такой риск прячет.

IBIB добавляет вторую половину. Если оценка не фиксирует маршрут обслуживания, повторить результат нельзя. В статье есть протокольная логика: binding gates, manifests, locked tasks, assertions. Для обычного руководителя это можно перевести проще: любой scorecard по AI должен хранить итоговый балл вместе с конфигурацией, путём запроса и правилами проверки.

18 аудированных benchmark suites в IBIB — ранний сигнал о направлении. До финального отраслевого стандарта ещё далеко. Оценка AI в организации будет всё меньше похожа на выбор «какая модель умнее» и всё больше на аудит рабочей системы: кто дал задачу, где она исполнилась, какие инструменты включались, кто проверял, какой след остался.

Эта логика хорошо стыкуется с ревью и командной структурой выше. Если агент работает в чужой песочнице, результат оценивает один набор правил. Если та же задача идёт через внутреннюю среду с другими зависимостями и доступами, риск меняется. Если scorecard хранит только «модель справилась», менеджер не видит, что именно изменилось: модель, prompt, набор инструментов, права доступа, версия репозитория или критерии проверки. В живой инженерной системе это разные причины и разные действия.

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

Что сделать на этой неделе

  1. Разделить очередь ревью по риску. Введите минимум три класса pull requests: низкий риск, обычный риск, высокий риск. Для каждого класса заранее определите автоматические проверки, минимального ревьюера и stop-condition.

  2. Поставить автоматические проверки перед человеком. Форматирование, секреты, зависимости, статический анализ, покрытие тестами и базовая сборка должны отсеивать мусор до попадания в человеческую очередь.

  3. Проверить состав AI-команды через ответственность. Перед экспериментом с меньшим составом заполните четыре поля: домен, независимые экспертизы, цена ошибки, система поддержки вокруг команды.

  4. Описать агентный runtime как инфраструктуру. Для каждого сценария зафиксируйте владельца, песочницу, разрешённые инструменты, доступ к данным, хранение логов, бюджет и путь остановки.

  5. Расширить AI-scorecard. Добавьте route, harness, sandbox, trace retention и evaluator. Если в отчёте есть только название модели и итоговый процент, он ещё не годится для управленческого решения.

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

Вопрос недели: если завтра у вас появится agent runtime с доступом к репозиторию, кто в организации сможет одной фразой сказать, где он работает, что ему разрешено и кто отвечает за результат?

Подписывайтесь на @predictableteam. Архив выпусков и длинные разборы — на maratkee.com.