Модель перестала быть системой

Неделя 15 июня прошла под одним сдвигом, тянувшимся через пять дней историй. Модель перестала быть системой.

Три года рабочим допущением было, что модель и есть главное — выбери лучшую, построй вокруг неё, и capability твой. На этой неделе допущение развалилось сразу с нескольких сторон. Модель выключило государство. Лидер рынка упал ниже половины рынка. Самые трудные инженерные задачи ушли от генерации вовсе. Что остаётся, когда модель — заменяемая деталь: всё вокруг неё — runtime, в котором она действует, review, принимающий её output, границы, которые ей нельзя пересекать, контекст, на котором она стоит, и люди, владеющие результатом, когда он неверен.

Это спайн недели. Не «какая модель», а «что держится, когда модель больше не фиксированная точка».

Версия на 60 секунд

Если не читать ничего больше:

• Модель теперь компонент, а не фундамент. Export control глобально выключил frontier-модель; ChatGPT упал до 46.4% доли. Строить так, будто одна модель — фиксированная точка, больше нельзя.
• Review — узкое место, и оно переполнено. По мере масштабирования AI median review time вырос на 441.5%, а 31.3% PR-ов теперь мёрджатся вообще без review. Генерация подешевела, приёмка — нет.
• Опасный долг — архитектурный, а не грязный код. Gartner ожидает, что к 2027 80% технического долга станет архитектурным. Агенты нарушают границы быстрее, чем пишут плохие строки.
• Durable-слой — это контекст и обучающая петля, та часть, которой владеешь. Curated-контекст и компаундящийся feedback переживают любую арендованную модель.
• Решает руководство. Один и тот же rollout может купить активность и потерять доверие, делавшее инженерию хорошей.

Одна строка на неделю: когда модель заменяема, система — это то, что ты построил вокруг неё.

1. Модель стала компонентом, а не фундаментом

Бóльшую часть AI-эры стратегия начиналась с модели. На этой неделе эта отправная точка стала выглядеть хрупкой сразу с трёх сторон.

Острее всего — доступ. Anthropic приостановил глобальный доступ к Fable 5 и Mythos 5 после export-control-директивы. Модель не стала хуже; она стала недоступна, и её доступность оказалась функцией государственной политики, движущейся быстрее, чем любая команда успевает re-architect. Второе — рынок: доля ChatGPT на рынке AI-ассистентов впервые упала ниже 50%, осев на 46.4% в мае против 52.8% на конце 2025-го, при Gemini 27.7% и Claude 10.3% — пользователи теперь перемещаются между ассистентами, а не стандартизируются на одном. Третье — архитектура: Android 17 выпустил AppFunctions и on-device MCP, позволив ассистенту вызывать функции приложения напрямую — что важно только если твоя система не предполагает одну модель за одним интерфейсом.

Механизм под всеми тремя один. Зависимость, которую нельзя заменить, — это зависимость, которой управляет кто-то другой, и на этой неделе этим «кем-то» оказались государство, смещающаяся база пользователей и платформа — и никто из них не читал твой roadmap. Урок не «выбери другую модель». Он в том, что слот под модель надо проектировать как слот: то, что можно заменить, не переписывая систему вокруг. Governance, evaluation, identity, memory и workflow — всё должно пережить смену модели под ними, потому что эта неделя доказала: она меняется по причинам, которые ты не контролируешь.

Operator move: найдите свою единственную несущую зависимость от модели — ту, которой смена политики, цены или outage навредит сильнее всего, — и напишите план замены именно под неё. Не «держим backup-вендора» в абстракции, а конкретный путь: что ломается, что надо абстрагировать, сколько занимает замена сегодня. Не нужна портируемость каждой зависимости; нужно, чтобы у несущей был выход прежде, чем кто-то другой решит, что выхода у вас нет.

Модель теперь — деталь, которую ты закупаешь, а не фундамент, на котором строишь. Проектируй слот, а не только выбор.

2. Review стал узким местом, и оно переполнено

Глубокий разбор недели.

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

Источник — Faros AI Engineering Report 2026, построенный на телеметрии 22,000 разработчиков из более чем 4,000 команд, сравнивающий для каждой команды период низкого внедрения AI с периодом высокого. Прирост throughput реален, и его стоит назвать прямо: epics на разработчика +66%, task throughput около +34%, PR merge rate +16%. Это половина, которая видна в демо и квартальном ревью.

Теперь другая половина. Как читает тот же отчёт Addy Osmani, median review duration вырос на 441.5%, при этом time-to-first-review и average review time оба примерно удвоились. Bugs per developer +54%. Incidents-to-PR ratio +242.7% — на каждый смёрдженный PR production-инциденты происходят теперь более чем втрое чаще относительно low-adoption baseline. Code churn — строки, переписанные вскоре после коммита, — вырос примерно вдесятеро. Acceptance rate сгенерированного AI кода поднялся с 20% до 60%. И цифра, переосмысляющая все остальные: на 31.3% больше pull request'ов теперь мёрджатся вообще без review, человеческого или агентского.

Пройдём механизм, потому что он не тот, что предполагают. Инстинкт — представить автономных агентов, мёрджащих свой код без надзора. Данные говорят иное: менее 1% PR-ов открыты агентами автономно. Это люди, использующие AI как primary authoring tool, генерируют объём быстрее, чем человеческое review успевает поглотить, — и код начинает мёрджиться непрочитанным, не по чьему-то решению, а потому что очередь никогда не пустеет. Никто не решал перестать ревьюить. Review просто перестал происходить, и это стало нормой. Это и есть тихий провал: прежнее узкое место (нельзя поставить, потому что нельзя написать код) было видимым, а это (поставили больше, чем кто-либо способен понять) невидимо, пока не приходит нагрузка инцидентов.

Деталь, которая должна тревожить дисциплинированные команды сильнее всего: отчёт обнаружил, что организации со зрелыми DevOps-практиками и сильным pre-AI performance пострадали от той же downstream-деградации, что и все. Хороший процесс не защитил, потому что был рассчитан на мир меньшего throughput. Это закон Амдала применительно к инженерии — ускорение одной стадии помогает лишь настолько, насколько остальная система успевает, а review, тестирование и реагирование на инциденты не успели.

Здесь есть реальное контр-давление, и его надо назвать, чтобы вывод не скис в догму. Ответ не «каждый PR получает полное человеческое review навсегда» — это требование ломается под объёмом, и авторы отчёта сами это говорят. Часть изменений действительно low-risk; часть может ревьюить доверенный агент; одноразовая и внутренняя работа не должна платить полный налог. Навык не «ревьюить больше». Он в том, чтобы решать, какие изменения несущие, и тратить дефицитную review-ёмкость только там. Режьте по риску: customer-facing, security-sensitive и high-blast-radius пути получают человеческие глаза; пути ниже риском могут пройти agent review; но ничто не мёрджится через отсутствие гейта. Дефицитное суждение — что заслуживает разбора, и это суждение ровно то, что нельзя сгенерировать.

Operator move: перестаньте отчитываться одним throughput и начните отчитываться долей мёрджей, прошедших реальный review-гейт, плюс трендом incidents-to-PR, на том же дашборде. Скачок epics на 66% выглядит триумфом, пока не встанет рядом с ростом incident ratio на 242%, и тогда читается как net loss. Затем задайте явное, проверяемое инструментом правило: каждый PR проходит гейт — человек, агент или оба — и ни один путь не мёрджится через ничто. Проверьте сначала репозитории внутреннего тулинга, потому что именно там живут исключения и именно там AI-объём их находит.

Полезная метрика никогда не была в том, сколько кода произвёл агент. Она в том, сколько из него команда смогла осознанно принять.

3. Опасный долг — архитектурный, а не грязный код

То, что генерация дешевеет, не только переполняет review. Оно меняет вид долга, который накапливает кодовая база.

Рамка, зашедшая на этой неделе, идёт через Gartner, цитируемый по всему новому рынку technical-debt-тулинга: архитектурный технический долг, как ожидается, составит 80% всего технического долга к 2027. Дело не в круглой цифре; дело в сдвиге категории под ней. AI-ассистенты всё лучше устраняют code-level долг — грязная функция, дублированный блок, недостающий тест. Чего они не умеют — уважать долг, живущий между системами: нарушенную границу, дублированный доменный концепт, скрытую связанность, тихо сломанную модель владения. Это напрямую связано с нитью, шедшей через инженерные сигналы недели — что агенты действуют по структуре, которую видят (имена, тесты, тикеты), упуская rationale, который не видят (почему граница существует, какое упрощение запрещено).

Механизм стоит назвать точно, потому что он инвертирует старую интуицию. Грязная функция видима и локальна; её видно в diff, и ревьюер или агент её вычистит. Сломанная граница невидима и глобальна; она проходит каждый тест, читается нормально в изоляции, и обнаруживает себя лишь месяцы спустя, когда изменение, которое должно было быть простым, оказывается затрагивающим шесть вещей, которые трогать было нельзя. Агенты делают это хуже не потому, что пишут код хуже — часто код чистый, — а потому что генерируют большие изменения быстро без системного контекста, говорящего, почему архитектура такая, какая есть. Результат — база, которая становится дешевле в дополнении и труднее в осмыслении одновременно, а это ровно профиль системы, идущей к беде.

Operator move: сделайте хотя бы одну архитектурную границу machine-checkable до того, как масштабировать агентские изменения против неё. Возьмите ограничение, нарушение которого втихую навредит сильнее всего — модуль, которому нельзя импортировать другой, слой, которому нельзя ходить в базу напрямую, границу сервиса, которая должна оставаться односторонней, — и закодируйте её как проверку в merge-пути, а не предложение в вики. Агент пересечёт границу, которую не видит. Решение — сделать границу тем, что пайплайн видит за агента.

Дешёвая часть теперь — генерировать изменение. Дорогая — удержать систему чем-то, что человек ещё способен осмыслить.

4. Durable-слой — это контекст и обучающая петля

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

Несколько сигналов указывали в одну сторону. Data-ассистент Vedder от Spotify опёрся на domain-expert-курирование — выверенные пары вопрос-SQL, бизнес-документацию, health scoring, — и показательной цифрой было то, что лишь 12.5% намайненных query-пар были приняты как достаточно хорошие, чтобы оставить. AWS выпустил agent-memory-архитектуру, относящуюся к памяти как к спроектированному слою с эпизодической, семантической и процедурной структурой, а не как к большему промпту. Под обоими — одно утверждение: ограничение полезной AI-системы не в том, какое context window ты можешь себе позволить, а в том, способна ли организация выставить правильный, доверенный, актуальный контекст в правильный момент.

Механизм, связывающий контекст с обучающей петлёй, — это владение. Модель — то, что арендуешь по токенам; когда доступ, цена или политика меняются, её нет. Но curated-контекст — лейблы, выверенные пары, захваченный rationale — и петля, улучшающая его каждый цикл (работа входит, AI помогает, человек судит, исход измеряется, суждение обновляет контекст, следующий прогон лучше), — это часть, которая остаётся. Это и часть, которую большинство rollout'ов пропускает, потому что она негламурна: кто-то должен решать, что стоит хранить, кто это валидирует и как оно остаётся истинным после следующих двадцати изменений. Acceptance rate 12.5% — это честная цена той работы, сделанная видимой: бóльшая часть того, что можно скормить системе, недостаточно хороша, и нахождение той восьмой части, что хороша, требует суждения, которое не приходит от модели.

Operator move: для одного workflow, который собираетесь отдать AI, выпишите петлю до тулинга — конкретно, что захватывается после каждого прогона и кто решает, что это было хорошо. Если ответ «ничего» и «никто», у вас нет обучающей системы; у вас тысяча изолированных взаимодействий, не оставляющих следа. Возьмите то единственное место, где работа повторяется достаточно часто, чтобы компаундирование окупилось, и инструментируйте сначала его.

Модель арендована. Curated-контекст и петля вокруг него — часть, которую организация оставляет себе.

5. Решает руководство

Каждая тема выше — проблема operating model раньше, чем проблема технологии, и яснейшие предупреждения недели были о том, что бывает, когда руководство понимает это наоборот.

Сигналы сгруппировались. Широко обсуждавшийся рассказ об инженерной культуре Meta описал агрессивную приоритизацию AI, сниженную автономию, трекинг активности и performance-давление, привязанное к видимому использованию AI, — и доказывал, что это повредило ту самую инженерную культуру, которая компании нужна, чтобы AI-работа окупилась. Отдельная нить назвала executive-failure-mode прямо: AI не выживает при magic thinking, когда лидеры хотят AI-исходов, игнорируя качество данных, реальность workflow и доказательства того, что их системы реально способны поддержать. А данные внедрения продолжали настаивать, что «все используют AI» — фикция: реальные организации — смесь power-users, occasional-users, скептиков и людей с легитимными опасениями, делящих одну компанию.

Механизм — тот, который большинство rollout'ов понимает неверно. Сильная инженерия никогда не работала на compliance; она работает на agency, ясности и владении — на людях, достаточно senior, чтобы сказать «эта автоматизация делает систему хуже», и достаточно в безопасности, чтобы быть услышанными. В момент, когда внедрение AI привязано к страху выглядеть недостаточно современным, ты теряешь ровно это — и получаешь инженеров, исполняющих использование AI вместо суждения, которое AI должен был освободить. AI не заменяет инженерную культуру; он работает поверх неё и усиливает то, что уже было. Культура высокого доверия и владения становится быстрее. Культура низкого доверия просто быстрее поставляет то, чем никто не владеет.

Operator move: прежде чем мерить внедрение AI по usage, измерьте, целы ли ещё условия для хорошей инженерии после rollout — автономия над тем, как делается работа, пространство возражать, ясное владение исходами. Если rollout купил видимую активность ценой доверия и владения, дашборд будет зеленее, пока инженерия становится хуже, и метрика это скроет. Возьмите метрику внедрения, которая трекает принятые, owned-исходы, а не счётчики использования инструментов.

Модель может сгенерировать ответ. Руководству всё ещё надо сохранить условия, при которых кто-то способен сказать, хорош ли ответ.

Counter-signals, которые стоит держать одновременно

Три напряжения, которые стоит держать живыми, и где я бы расставил вес:

Модель-компонент против того, что модель всё ещё важна. Спайн недели в том, что модель стала заменяемой, — но raw capability и compute всё ещё задают потолок, и сильнейшая модель всё ещё делает то, чего панель дешёвых не может. Оба верны. Вес: для большинства команд на большинстве работы модель уже достаточно хороша, чтобы исход решала система вокруг неё, — поэтому проектируй слот первым, а frontier-capability трактуй как случай, к которому эскалируешь, а не дефолт, на котором строишь.

Review-гейты против velocity. Более жёсткие review-гейты могут заново ввести узкое место, которое AI должен был убрать, и команда, гейтящая всё одинаково, просто отстроила стену заново. Оба реальны. Вес: failure mode в данных — подавляюще under-review, а не over-review (31.3% мёрджатся через ничто), поэтому риск, которым стоит управлять в этом году, — отсутствующий гейт, а не лишний.

Дисциплина против одноразовости. Не каждое сгенерированное изменение заслуживает тяжёлого разбора; прототипы и одноразовые скрипты должны оставаться дешёвыми. Верно. Вес: цена обращения с несущим изменением как с одноразовым куда выше цены пере-ревью одноразового, поэтому когда не уверен, какого рода изменение, эта неуверенность сама и есть сигнал притормозить.

Operator takeaway

Если вы поставляете в регулируемых системах, инфраструктурно-тяжёлых или AI-смежных продуктах, на этой неделе затвердели три вещи:

1. Проектируйте модель как слот, а не фундамент. Сделайте несущую зависимость от модели заменяемой прежде, чем политика, цена или outage решат за вас. Модель сменилась под командами на этой неделе по причинам, которых никто из них не контролировал.

2. Масштабируйте review и границы раньше генерации. Ограничение переехало к приёмке: пропускная способность review, machine-checkable архитектура, тренд incident-to-PR. Меряйте числами и откажитесь масштабировать генерацию сверх того, что они способны поглотить.

3. Владейте контекстом и культурой, потому что это части, которые остаются. Модель арендована; curated-контекст, обучающая петля и инженерная культура — нет. Rollout, тратящий доверие ради активности, — это организационный долг с AI-лейблом.

Это не прогнозы. Это описание того, куда уже сдвинулся operating ground.

Стоит понаблюдать

Несколько конкретных вещей этой недели, на которые стоит посмотреть ближе:

• Faros AI Engineering Report 2026 — acceleration-whiplash-данные на 22,000 разработчиков. Лучшая доказательная база этого года о том, что AI-объём делает downstream от генерации.
• Agentic Code Review — прочтение тех же цифр от Addy Osmani плюс практические triage-тактики (маленькие PR, читать сначала изменения в тестах, fast-fail дорогого хвоста).
• ChatGPT ниже 50% — Sensor Tower State of AI 2026; мультиассистентный рынок теперь допущение для планирования, а не прогноз.
• Архитектурный долг к 80% к 2027 (Gartner) — сдвиг категории в том, чем на деле является AI-сгенерированный долг; рынок тулинга формируется вокруг анализа уровня архитектуры, а не строк.
• Android 17 AppFunctions / on-device MCP — приложения становятся вызываемыми поверхностями для агентов; тихое, но структурное изменение в том, что должна нести permission-модель продукта.