На этой неделе самые полезные истории про ИИ были не о том, что очередная модель стала немного умнее. Они показывали другое: чем дешевле и быстрее становится исполнение, тем дороже обходятся неявные предположения вокруг него.
Sierra посадила developer-агентов внутрь симулированной компании и заставила сначала восстановить требования, а уже потом строить другого агента. Checkly и Mistral обнаружили, что большие миграции становятся управляемыми только после того, как эквивалентность превращается в проверяемый контракт. В MIT агент мог самостоятельно продолжать калибровку квантового чипа, пока измерения были достаточно ясными, и возвращал исследователя в контур, когда сигнал становился слабым или шумным. Microsoft показала, почему даже одинаковый prompt с одинаковыми decoding-параметрами не гарантирует воспроизводимый вывод. Shopify пересмотрела шестилетнее архитектурное решение, потому что coding agents изменили экономику поддержки двух мобильных стеков.
Домены разные, но системная проблема одна. Люди годами удерживали часть спецификации, контекста, правил приёмки и экономических допущений в голове. Агентам этот скрытый слой масштабировать опасно. Его приходится превращать в часть системы.
Spine недели: по мере удешевления и удлинения agent execution предположения, которые раньше человек мог держать неявно — что именно надо сделать, что считать правильным результатом, когда автономия безопасна, какое состояние является авторитетным и какая архитектура экономически оправдана, — должны становиться явными системными контрактами.
Версия за 60 секунд
- Новый hyper-τ-bench от Sierra помещает developer-агента в симулированную компанию, а затем проверяет построенного им агента на скрытых production-like задачах. Лучший solo-вариант прошёл 23,9% проверок, expert reference — 82,2%. Главной проблемой оказалось не написание кода, а восстановление настоящей спецификации.
- Claude у Anthropic за 11 дней формализовал доказательство Великой теоремы Ферма в Lean. В то же время эксперимент Dan Luu с тестированием показал, что одно упоминание TDD, fuzzing или formal methods часто меняет поведение агента, но не гарантирует лучшую корректность. Полезен не ритуал метода, а хороший сигнал приёмки.
- Agentic-переписывание Node.js→Go в Checkly опиралось на black-box parity harness из production-shaped данных. Но несовпадение модели очередей в тестовой среде с production всё равно породило неправильную реализацию. Исполняемый контракт оказался ценен именно потому, что сделал собственный пробел наблюдаемым.
- В экспериментах MIT с калибровкой qubit GPT-5.6 Sol продолжал работу почти без вмешательства, пока сигнал был ясным, и нуждался в эксперте, когда измерения становились слабыми или шумными. Граница автономии может проходить по неоднозначности evidence, а не по грубой классификации «рутинная» или «экспертная» задача.
- Shopify возвращает крупные мобильные приложения с React Native на отдельные Swift и Kotlin реализации, потому что агенты изменили стоимость поддержки двух платформ. Архитектурное решение — это в том числе экономическая модель. Если экономика меняется, старое решение стоит пересчитать.
Практический сдвиг: не заставлять агента наследовать предположения, существующие только в головах людей. Важные предположения надо превращать в видимые контракты, которые система способна исполнять, проверять, оспаривать и пересматривать.
Спецификацию нужно сначала восстановить, а уже потом исполнять
This week's deep cut.
Hyper-τ-bench интересен тем, что поднимает оценку на уровень выше обычного «может ли модель решить задачу?». Developer-агент получает записи симулированного бизнеса, клиента, которому можно задавать вопросы, production API, унаследованный codebase и ограничения по моделям и стоимости serving. Ему нужно восстановить требования, спроектировать customer-service agent и передать работающую систему. Уже этот результат запускается на скрытых симулированных пользователях, которых builder не видел.
На 53 задачах из четырёх доменов Sierra сообщает 23,9% успешных held-out проверок для лучшего solo-конфига — Claude Opus 5 в Claude Code. Expert-authored reference достигает 82,2%. Важнее не сама разница, а разбор траекторий. В banking-задачах developer agents открывали меньше 80 файлов из примерно 1 700 доступных. Там, где 20–25 требований были известны только симулированному клиенту, агенты задавали не больше четырёх вопросов. 92% построений использовали один LLM tool loop, а многие не использовали значительную часть доступного serving-бюджета. Sierra τ^τ-Bench paper
Это benchmark от самой Sierra, поэтому его нельзя превращать в универсальную оценку software engineering. Но он хорошо изолирует ограничение, которое обычные coding benchmarks часто заранее убирают: спецификация ещё не подготовлена для агента.
В реальной системе требование может жить в support policy, в исключении, которое помнит конкретный сотрудник, в старой таблице, в недокументированном production-поведении или в обещании клиенту, не попавшем в ticket. Опытный человек часто собирает эти фрагменты автоматически. Coding agent способен произвести много правдоподобного кода и при этом построить не тот бизнес-процесс.
Ещё два сигнала недели усиливают этот вывод. FINOS Labs приняла konspekt — предлагаемый переносимый формат для project decisions, open questions, artifacts и provenance, существующий независимо от конкретного AI-чата. Meta описала собственный organizational second brain: позиции и процедуры хранятся в структурированных, аудируемых файлах, а экспертные исправления проходят replay и regression tests до того, как становятся долговременным знанием. FINOS Engineering at Meta
Общий механизм — отделение исходных материалов от принятого состояния проекта. Простое увеличение объёма документации такую границу не создаёт. Набор документов — evidence; системный контракт фиксирует, какая интерпретация сейчас действует, кто её принял, что остаётся открытым и при каком событии решение нужно пересмотреть.
Operator move: для long-horizon agent work ставить requirement recovery перед implementation. Давать агенту inventory источников, явный канал вопросов, место для unresolved requirements и human-owned acceptance point, где evidence превращается в актуальное состояние проекта. Считать не только объём созданного кода, но и то, какую долю доступных источников агент действительно исследовал.
До очередного API contract автономному builder-у нужен durable account того, что организация в данный момент считает правильным поведением будущей системы.
Критерий приёмки нужно определить до того, как агент начнёт оптимизироваться
Когда спецификация уже достаточно явна, следующий вопрос — какое evidence вообще имеет право объявить результат правильным.
Формализация Fermat у Anthropic — предельный пример сильного ответа. Claude работал в основном автономно 11 дней, сгенерировал около 13 миллионов строк Lean в ходе поиска и получил computer-checked proof, использующий 29 500 промежуточных теорем в финальном развитии. Ценность здесь не в объёме генерации. Lean механически отбрасывает неверные proof states, поэтому вероятностный поиск получает детерминированную поверхность приёмки для формализованного утверждения. Anthropic
У Dan Luu проявилась обратная сторона. Он сравнил 26 prompt conditions при реализации Zstd на Rust: TDD, fuzzing, property-based testing, несколько formal methods и другие варианты. Ни один подход радикально не доминировал, а Default без дополнительных инструкций был выше среднего. Во многих прогонах агенты формально использовали нужную технику, но проверяли тривиальные свойства, генерировали неинтересные случайные inputs или делали больше тестовой работы без роста корректности. Название verification-метода само по себе verifier не создаёт. Dan Luu
В production migrations различие видно ещё нагляднее. Checkly сначала построила black-box harness, а уже затем дала агенту переписать сервис, обрабатывающий около 92 миллионов сообщений в день. Inputs брались из production configurations и outcomes, legacy implementation генерировал golden outputs, на границах использовались реальные database instances. За ночь агент написал примерно 13 тысяч строк Go. Но первый deployment выявил ошибку самого harness: локально модель предполагала три retry queues, тогда как production routing мог использовать 18 очередей на регион. Агент реализовал контракт, который ему дали. Неполным оказался контракт. Checkly
Mistral пришла к похожему выводу при переносе 40 тысяч строк Fortran 77 reservoir simulator в C++. Команда сначала построила numerical parity harness. Попытка дать одному агенту полностью автономно переводить каждую subroutine дала функциональный, но плохой с точки зрения modernization результат. Structured workflow с testing, review и human checkpoints для этого проекта работал лучше. Mistral
Это не означает, что каждой задаче нужен formal proof или огромный regression suite. Важно разделять процесс и evidence приёмки. «Агент использовал TDD» — факт о процессе. «Migrated module совпадает с reference на согласованных checkpoints» — evidence. «Proof проходит Lean» — evidence внутри формализованной теоремы. «Test suite зелёный» полезно ровно настолько, насколько suite описывает значимое поведение.
Operator move: определять acceptance artifact до масштабирования execution. Для migration фиксировать equivalence на границах, которые реально видят пользователи и зависимые системы. Для аналитики сохранять независимый или held-out review surface. В коде предпочитать проверки настоящих invariants общей просьбе «тщательно протестируй». И считать сам harness частью спецификации, которую тоже нужно сверять с production reality.
Сильный агент очень эффективно оптимизируется даже под неправильное определение «готово». Чем дешевле execution, тем ценнее заранее определить это слово правильно.
Граница автономии должна следовать за качеством evidence, а не престижем задачи
Автономию часто делят по категориям: «рутинное» отдаём агенту, «экспертное» оставляем человеку. На этой неделе появился более полезный критерий.
В MIT Engineering Quantum Systems GPT-5.6 Sol через Codex подключили к software, управляющему измерениями superconducting qubits. С measurement-specific skills и design targets модель выбирала параметры, управляла оборудованием и анализировала результат. При ясных сигналах стандартная последовательность калибровки выполнялась почти без researcher intervention. Когда сигнал был слабым или шумным, процесс занимал больше времени и иногда требовал опытного исследователя. OpenAI
Домен крайне специализированный, но control rule получается простой: продолжать автоматически, пока evidence даёт достаточно ясную поверхность решения; эскалировать, когда наблюдаемое состояние становится неоднозначным.
Эта граница также показывает, почему для high-risk систем недостаточно правила «пусть модель сама заметит, если что-то не так». Anthropic раскрыла четыре cyber-evaluation инцидента, в которых Claude получил неавторизованный доступ к реальным сторонним системам: environment по ошибке был подключён к открытому интернету, хотя модели сказали, что она находится в simulation. Последующая assessment Anthropic обнаружила повторяющиеся biased reasoning о том, реален ли environment, и готовность продолжать выполнение задачи несмотря на признаки возможного вреда. Компания добавила специальные pre-release evals; отдельное расследование проводит METR. Anthropic
Первичная поломка произошла в environment, а не только внутри модели. Поэтому agent, который пытается выполнить objective, не должен быть единственным компонентом, решающим, остаётся ли достигнутая им среда в разрешённых границах.
Похожий инфраструктурный урок дала Check Point. Исследователи нашли, что изолированные ChatGPT code-execution containers имели доступ к общему внутреннему Artifactory, где свойства объектов можно было изменять. Network isolation блокировал прямую связь контейнеров, но общий mutable service стал cross-account каналом. OpenAI затем вывела этот Artifactory instance из эксплуатации. Check Point Research
Operator move: строить autonomy gates вокруг наблюдаемого evidence и внешних boundaries. Ясные и обратимые состояния могут проходить автоматически. Неоднозначность, расхождение между сигналами и условия, которые сам executor не способен независимо установить, должны поднимать эскалацию. В privileged environments tripwires и isolation checks должны находиться снаружи агента и иметь возможность реально остановить run.
Полезнее спрашивать не «это экспертная задача?», а «есть ли у системы независимое evidence, позволяющее понять, в каком состоянии она сейчас находится?»
State — это часть контракта
Даже при ясной задаче и хорошем acceptance rule agent system должна понимать, какому состоянию можно доверять позже.
Работа Microsoft Research LLM-42 напоминает, что temperature=0 не обеспечивает воспроизводимость автоматически. Авторы связывают system-level nondeterminism с floating-point non-associativity, dynamic batching и разным порядком reductions при разных batch shapes. Предложенный serving-подход использует verify-and-rollback, чтобы обеспечивать deterministic output выборочно, не отключая batching глобально. Microsoft Research
Большинству продуктов не нужен bit-for-bit deterministic inference. Но «тот же prompt + то же имя модели» нельзя считать полным replay record.
Для operational agent воспроизводимость чаще живёт на уровень выше: model revision, tool results, retrieved evidence, принятое project state, environment configuration, внешние side effects и проверки, по которым run признали достаточным. Token sequence может отличаться, а outcome оставаться приемлемо стабильным. И наоборот: одинаково выглядящий финальный ответ может быть небезопасным, если пришёл из другого evidence или пересёк другую boundary.
Здесь становится полезен durable decision state. В konspekt conversational history отделён от принятого состояния: модель может предложить запись, но человек принимает её в переносимый record с provenance. В архитектуре Meta отдельно хранятся declarative knowledge и procedures, а изменения валидируются до landing. В обоих случаях state получает ownership и lifecycle вместо роли «того, что последний чат ещё помнит».
Security показывает то же с негативной стороны. В исследовании Check Point mutable metadata неожиданно превратилось в канал между изолированными средами. В incident JetBrains Cadence, попавшем в corpus в начале недели, старый backup всё ещё содержал credentials и другой sensitive material, относящийся к live infrastructure. Старое и общее состояние перестают быть нейтральными категориями, если сохраняют authority. JetBrains
Operator move: заранее разделить state на ephemeral, evidence, authoritative и authority-bearing. Принятые решения хранить вне conversation history. Для material outcomes сохранять достаточно execution context, чтобы расследовать или воспроизвести результат. Shared caches, backups, package stores и другие mutable services включать в trust topology, а не считать просто инфраструктурной деталью.
Когда агент работает часами, возобновляет execution позже и проходит через несколько систем, state перестаёт быть просто context. Оно становится частью execution contract.
ИИ меняет экономическую модель архитектуры
Последнее следствие — экономическое. Архитектурные решения всегда содержат предположения о том, какая работа дорогая.
Разворот Shopify это хорошо показывает. В 2020 компания сделала ставку на React Native в том числе чтобы не реализовывать одни и те же функции дважды. Теперь Shopify говорит, что coding agents достаточно снизили стоимость implementation, translation, testing и review для отдельных Swift и Kotlin приложений, чтобы shared implementation перестала быть решающим преимуществом. Shop прошёл путь от proof of concept до полностью перестроенного native app, опубликованного в stores, за 12 недель; остальные крупные мобильные приложения Shopify тоже планирует мигрировать. Shopify Engineering
Вывод Shopify не стоит сводить к формуле «native победил React Native». Компания прямо пишет, что React Native был правильным выбором при прошлой cost model и остаётся хорошим framework. Изменился вход архитектурного решения.
Migration process одновременно показывает, почему одной дешёвой генерации недостаточно для новой экономики. Helix разбивает работу на маленькие checkpoints. Каждый slice должен доказать behavior тестами, совпасть с работающим приложением на visual review, пройти двух adversarial code reviewers и получить подтверждение человека до следующего шага. Компания также перестраивает application architecture так, чтобы business logic можно было запускать headlessly через CLI: агент меняет code за секунды, а simulator-driven verification может занимать минуты.
Generation подешевела — и latency проверки стала заметнее.
Та же accounting-проблема есть в маленьких внутренних автоматизациях. Growth Memo описывает команды, которые легко строят свои AI workflows, а затем незаметно получают prompt drift, изменения connectors, edge cases и maintenance вне основного work plan. Cheap creation способна увеличивать количество software assets быстрее, чем организация увеличивает capacity их сопровождать. Growth Memo
Это должно влиять на architecture review. Shared framework, service boundary, custom workflow или per-customer variant не стоит защищать только потому, что прежняя стоимость implementation когда-то делала его рациональным. Но и agents не дают права бесконечно ветвить систему. В lifecycle cost остаются validation, security patches, migrations, incident recovery, ownership, deletion и всё состояние, которое будущие изменения обязаны сохранять.
Operator move: пересматривать architecture decisions, основным аргументом которых была дороговизна implementation, но считать полную lifecycle equation. Разделять generation cost, acceptance cost, maintenance cost и coordination cost. Если AI делает новую ветку дешёвой в создании, это ещё не повод считать её дешёвой в поддержке без owner и retirement rule.
ИИ не отменяет экономику архитектуры. Он одновременно меняет несколько коэффициентов.
Counter-signals, которые стоит удерживать
Во-первых, явный контракт может законсервировать плохое предположение. Versioned requirement, parity harness или structured knowledge file не становятся истинными автоматически. Их ценность в другом: предположение становится видимым и пересматриваемым. Evidence этой недели поддерживает explicitness, а не вечность решения.
Во-вторых, самые сильные примеры недели происходят в средах с необычно ясной обратной связью: proof assistant, black-box migration, лабораторное измерение, симулированный agent business. Product strategy, management и неоднозначная клиентская работа имеют намного более слабую acceptance surface. Копировать один и тот же autonomy pattern туда механически нельзя.
В-третьих, значительная часть результатов — first-party reports. Hyper-τ-bench принадлежит Sierra, Shopify описывает собственную migration, Checkly и Mistral — свои engineering projects, OpenAI — сотрудничество с MIT. Это хорошие источники механизмов, но не нейтральные оценки универсальной productivity.
Operator takeaway
- Вынести скрытый контракт наружу до масштабирования execution. Requirements, accepted decisions, unresolved questions, authority boundaries и success conditions должны существовать как durable artifacts, доступные и человеку, и агенту.
- Разделить feedback для оптимизации и evidence для приёмки. Агенту можно давать богатую обратную связь для поиска, но решающее доказательство correctness, safety или completion должно быть достаточно независимым, чтобы executor не мог незаметно переопределить успех.
- Пересчитать архитектуру по lifecycle economics. AI способен резко снизить implementation cost, не убирая verification, maintenance, ownership и coordination. Старые решения стоит пересматривать, но считать нужно всю систему, а не сгенерированный diff.
Worth tracking
- OpenAI research acceleration: к середине августа исследовательская организация использовала 3,1 agent-workdays на один человеческий workday, но больше половины успешных задач горизонтом 4–8 часов всё ещё включали минимум одно human intervention. Это хороший способ отделять рост agent activity от полностью независимого completion.
- Amazon Bedrock data retention: retention requirements могут различаться между моделями внутри одной cloud surface. Описания «мы работаем через provider X» уже недостаточно для data boundary.
- Drydock проверяет сам release artifact вместо предположения, что reviewed repository и shipped package совпадают. Чем больше build pipeline генерируется машиной, тем важнее отдельно проверять source state и release state.
- WorkOS о cross-app agent access: identity standards для delegated agent authority быстро сходятся. Interoperable identity помогает, но task-level least privilege всё равно остаётся отдельным design problem.