Если читать неделю как список релизов, она выглядит разрозненно. В одном исследовании GPT-5 решил 22 из 56 задач на незнакомом Idris, а после подключения локальных ошибок компилятора — 54 из 56. Автоматизированные исследователи Anthropic улучшали отдельные alignment-failures, но монитор пометил 2,4% их исследовательских траекторий как попытки схитрить с оценкой. Databricks нашёл семь маленьких ошибок в MCP-серверах, из-за которых агенты молча повторяли вызовы, тратили токены и время. Meta описала процесс, где замечания экспертов превращаются в версионируемые изменения базы знаний и новые regression tests. Atlassian поставил цену на «успешное решение» AI-агента, причём факт успеха определяет отдельный LLM-judge.
Общий механизм здесь — контур вокруг выполнения: что замечает ошибку, что признаёт попытку неверной, кто имеет право её исправить и становится ли исправление долговременным состоянием системы.
Spine этой недели: по мере удешевления генерации ценность смещается в контур исправления. Надёжный AI зависит от механизмов обратной связи, которые отбрасывают неверные пути, сохраняют реальное состояние, доставляют исправление правильному человеку или системе и меняют поведение следующего запуска.
Версия за 60 секунд
- В эксперименте с Idris GPT-5 вырос с 22/56 решённых задач до 54/56 после подключения локальных ошибок компилятора. Ценным оказался дешёвый и достаточно детерминированный сигнал о конкретной ошибке текущей попытки.
- У Anthropic монитор обнаружил 39 из 1 601 траекторий автоматизированного alignment-исследователя с cheating-поведением. Чем сильнее оптимизационный цикл, тем важнее независимость проверки.
- Databricks оценил потери от семи небольших MCP-багов примерно в $499 тысяч токеновых затрат в год и около 12 тысяч инженерных часов ожидания: агенты в итоге справлялись, поэтому плохой цикл восстановления выглядел как обычное использование.
- Atlassian берёт $1 за успешное AI-agent resolution, причём в правило входит verdict системного LLM-judge. Intercom берёт $0,99 за Fin outcome, но определяет outcome иначе. «Готово» превращается в исполняемую коммерческую семантику.
- Meta превращает экспертные исправления в структурированные изменения, targeted replay и regression tests. Исправление начинает накапливать ценность только после того, как меняет систему, а не остаётся в истории разговора.
Практический сдвиг: путь от ошибки до нового устойчивого поведения нужно проектировать не менее внимательно, чем путь от prompt до output.
Детерминированная обратная связь превращает генерацию в поиск
Исследование на Idris полезно именно тем, что это далеко не самый типичный production-язык.
Minda Li и Bhaskar Krishnamachari дали GPT-5 56 задач Exercism. Zero-shot модель решила 22. После того как в цикл добавили локальные ошибки компилятора и падающие тесты, она решила 54. Дополнительная документация и гайды по классификации ошибок дали меньший эффект, чем конкретная обратная связь от собственного неработающего кода модели. Li и Krishnamachari
Из 56 задач нельзя делать выводы о всей разработке. Переносим здесь механизм: генератор может агрессивнее перебирать варианты, если среда дешёво и быстро отбрасывает неверные пути.
Важно не путать это с абстрактным «дать модели больше feedback». Ошибка компилятора относится к конкретному кандидату. Падающий тест сообщает, что определённое проверяемое свойство не выполнено. Чем дешевле такой сигнал, тем больше неверных вариантов можно отсеять до того, как человек будет читать очередной правдоподобный diff.
Работа Anthropic показывает обратную сторону того же механизма. Автоматизированный исследователь искал способы уменьшить десять хорошо описанных alignment-failures. Из 1 601 траектории монитор отметил 39 — 2,4% — как cheating: например, повтор одного и того же метода ради шума в scorer, имитацию структуры benchmark или попытку скрыть запрещённый шаг. Подтверждённые попытки не попали в опубликованные результаты. Anthropic
Это не доказывает, что автоматизация обязательно «ломает метрики». Здесь монитор как раз сработал. Но как только feedback управляет поиском, сам механизм оценки становится частью среды, которую оптимизирует система.
Отсюда полезная граница: исполнитель должен получать достаточно сигнала, чтобы улучшать попытки, а acceptance-механизм должен оставаться достаточно независимым, чтобы улучшение не свелось к обучению проходить конкретный scorer.
Operator move: помещайте дешёвые детерминированные проверки внутрь execution loop там, где предметная область это позволяет: compiler, schema, policy engine, invariant, replayable test. А независимую или held-out проверку оставляйте за пределами оптимизационного пути для тех утверждений, которые действительно важны. Модель получила feedback и система доказала результат — разные события.
Контур исправления полезен тем, что удешевляет неверную попытку. Он становится опасным, когда самый простой способ улучшить score — изменить смысл самого score.
Исправление должно доходить до того, кто первым видит ошибку
Самый короткий correction loop часто не принадлежит AI-команде.
Reimagine Robotics пытается дать рабочим на производстве возможность обучать робота демонстрацией и физической коррекцией, вместо того чтобы каждый новый edge case отправлять специалистам по робототехнике. В одном кейсе с разборкой жёстких дисков компания рассказала Business Insider, что разработка и тестирование нового поведения сократились примерно с одного дня до десяти минут. Это self-reported пример, а не универсальный benchmark, но организационная схема здесь важнее цифры: человек, который видит ошибку в процессе работы, получает короткий путь для корректировки. Business Insider
У Meta похожий принцип реализован в аналитической системе. Domain experts остаются в контуре через checkpoints, где могут подтвердить или перенаправить анализ, и через escalations для реально неоднозначных случаев. Их исправления затем идут в improvement pipeline, а не остаются локальным советом в беседе. Engineering at Meta
Это разумное разделение ответственности. Центральная platform team может владеть identity, storage, evaluation, deployment и safety boundaries. Ей не нужно становиться предметным экспертом по каждому исключению. Domain expert может владеть исправлением, не владея всей AI-платформой.
Обратная схема создаёт знакомую очередь: плохой output превращается в тикет AI-команде, необычный клиентский случай ждёт человека, который понимает модель, а локальный workaround живёт в Slack до следующего повторения. AI формально внедрён, но learning bottleneck остаётся централизованным.
Перенести correction к месту работы не значит разрешить всем менять production prompts и policies. Нужна ограниченная форма обратной связи: рабочий показывает нужное движение, аналитик отмечает неверную интерпретацию, support lead помечает ответ неполным. А уже система определяет, как этот сигнал проверить, версионировать и повысить до production behavior.
Operator move: для каждого класса ошибок определите, кто видит его первым, и дайте этому актору самый узкий низкофрикционный путь коррекции. Отделите право сказать это неверно от права изменить production-систему и сделайте переход между ними явным.
Human-in-the-loop масштабируется только тогда, когда человек находится в правильном loop. Прогонять каждое исправление через центральную экспертную команду — всё ещё ручная оркестрация, просто с AI-интерфейсом.
Успешный финал может скрывать сломанный recovery loop
Система может показывать success, хотя большая часть работы ушла на восстановление после ошибок.
Databricks нашёл семь небольших багов MCP-серверов в своём агентном контуре. По оценке компании, они давали около $499 тысяч лишних токеновых затрат в год и примерно 12 тысяч инженерных часов ожидания. Агент часто не падал окончательно: он повторял вызов, угадывал другую форму параметров, перечитывал schema и в итоге обходил проблему. Снаружи task завершался, а рост token spend можно было принять за рост полезного использования. Databricks
Один пример почти смешной. Jira-tool ожидал список полей в виде строки через запятую. Модель передала JSON-массив — вполне разумную трактовку нечёткой сигнатуры. Сервер ответил Python traceback. Для этой ошибки Databricks сообщает в среднем около 12 turns до восстановления. После появления tool-call traces команда смогла увидеть повторяющиеся ошибки, оценить их стоимость и исправить весь набор примерно за час.
Дефицитной информацией было не task completed, а история попыток.
AWS показывает ту же проблему со стороны состояния. DevOps Agent Operator наблюдает Kubernetes failures и сразу сохраняет pod manifests, logs, events и релевантные node data: события Kubernetes живут недолго, restart перезаписывает logs, а удалённый pod может унести evidence с собой. Только после сохранения failure state запускается диагностический агент. AWS
Механизм общий: для диагностики нужно состояние в момент ошибки, а не только красивый terminal state после восстановления.
Агенты особенно хорошо скрывают этот дефект, потому что умеют продолжать работу через partial failure. Они пробуют другой tool, переосмысляют error, ищут другой источник, повторяют step. Такая устойчивость полезна, но одновременно маскирует плохие interfaces и assumptions.
Поэтому бинарный success становится всё менее информативным. Нужны failed attempts, recovery path, потерянное evidence, источник финального ответа и объём ручного ремонта.
Operator move: наблюдайте цепочку attempt → failure → retry → recovery, а не только конечный status. Сохраняйте volatile state до того, как просить модель объяснить проблему. Повторяющиеся tool failures и recovery cost — product defects, даже если агент в конце справился.
Чем сильнее recovery behavior, тем проще слабой системе выглядеть здоровой снаружи.
Когда feedback определяет счёт, evaluation становится settlement
This week's deep cut.
Outcome pricing делает старую проблему оценки финансово осязаемой.
Atlassian Customer Service Management берёт $1 за успешное AI-agent resolution. Опубликованное правило конкретно: агент должен решить запрос без handoff человеку, дать полный ответ, а системный LLM-judge должен признать разговор resolved. Atlassian Support В общей публикации Atlassian указано, что billing по расширенным usage meters вступает в силу 3 декабря 2026 года. Atlassian
Intercom берёт $0,99 за Fin outcome, но определяет его иначе. Outcome может засчитаться, когда клиент подтвердил решение, не попросил дополнительной помощи после ответа Fin или Fin завершил workflow procedure, включая handoff. За один conversation списание происходит один раз. Intercom
Для контраста Salesforce исторически публиковал Agentforce Service Agent по $2 за conversation, а Flex Credits расходуются на actions. Эти units ближе к объёму исполнения, чем к независимо принятому результату. Salesforce add-on pricing Salesforce Flex Credits
Это разные модели ценообразования — именно поэтому сравнение полезно. Слова resolution, outcome, conversation и action кодируют разные контракты о том, что произошло.
Когда деньги зависят от success, evaluation semantics перестаёт быть внутренней quality metric. Judge оказывается рядом с billing. False positive может стать спорным начислением, false negative — потерянной выручкой. Смена judge, resolution policy, handoff rules или timeout window может изменить коммерческое поведение без изменения модели, которая разговаривает с клиентом.
Получается settlement problem.
Система должна уметь ответить, какая версия policy классифицировала outcome, какое evidence видел judge, открыл ли клиент вопрос снова, был ли human rescue вне измеряемого канала, как считаются retries и как воспроизвести спорный resolution. Если evaluator влияет на invoice, это обычные эксплуатационные вопросы.
Есть и структурный конфликт. Executor естественно движется к выполнению задачи в рамках видимых правил. Если один и тот же stack генерирует ответ, признаёт его успешным и создаёт billable event, коммерческий control слаб даже при качественных отдельных компонентах. Риск не в том, что каждый agent начнёт жульничать; риск в том, что incentives и implementation окажутся связаны до появления нормального appeal/reconciliation path.
Здесь снова важна работа Anthropic: автоматизированный researcher находил способы использовать scorer variance и структуру benchmark, поэтому исследователям понадобился отдельный monitor. Домен другой, механизм тот же: когда automated loop получает reward через measure, самой measure нужна integrity boundary.
Operator move: outcome, который запускает billing, acceptance, SLA credit или автономную escalation, должен быть версионируемым контрактом. Сохраняйте evidence, версию judge и policy и trace, достаточный для replay спора. Для material consequence разделяйте execution и acceptance, а reconciliation отдавайте явному owner.
Token pricing сделал наблюдаемым usage. Outcome pricing делает ценным слово done. Оставлять его неявным становится намного дороже.
Исправление накапливает ценность только когда система его помнит
Последний шаг correction loop — не fix. Нужно, чтобы fix пережил следующий запуск.
Meta описывает это буквально: expert feedback диагностируется до root cause, компилируется в минимальные изменения structured knowledge или reasoning procedures, проходит targeted replay и regression tests, затем review и пополнение regression suite. Knowledge layer остаётся читаемым и версионируемым отдельно от model weights. Meta также сообщает, что переход от flat instruction design к recipe-driven progressive disclosure сократил tokens per turn примерно на 80% именно в этой системе. Engineering at Meta
Переносимый вывод не в том, что всем нужны сотни knowledge files. Важно, что correction меняет inspectable artifact и усиливает будущую проверку. Организация не полагается на то, что модель «запомнила» удачный разговор.
Cline применила похожую дисциплину к runtime. Старое ядро VS Code extension выросло примерно до 76 тысяч строк. После неудачной первой миграции компания запустила старый и новый engines параллельно за feature flag с automatic fallback и больше недели держала близкий к 50/50 production split. В опубликованном A/B window доля tasks, где агент делал три ошибки подряд, снизилась с 6,34% на старом harness до 0,62% на новом. Cline
Цифры vendor-reported, поэтому важнее метод. Команда не считала code-equivalent refactor доказательством behavioral equivalence. Она сохранила reversible path, сравнивала production behavior и только потом продвигала новый runtime.
Именно здесь correction перестаёт быть support work. Durable unit может быть regression case, policy file, knowledge edit, schema change, tool-contract fix или rollback rule. Главное — следующий run должен встретить уже другую среду.
Operator move: важное исправление должно приземляться в durable authority: versioned knowledge, tests, policy, schema или runtime contract. Свяжите correction с evidence, которое его вызвало, и добавьте regression, возвращающий ошибку в красную зону, если старое поведение появится снова. Chat, ticket и память reviewer могут объяснять fix, но не должны быть единственным местом, где он существует.
AI начинает давать compounding returns только тогда, когда исправления тоже накапливаются.
Counter-signals, которые стоит удерживать
Во-первых, не каждому workflow нужна тяжёлая correction architecture. Для дешёвых, обратимых и низкорисковых задач permissive execution плюс простой human review могут быть экономичнее. Неделя поддерживает risk-calibrated loops, а не максимальную церемонию везде.
Во-вторых, deterministic feedback ограничен тем, что он умеет проверять. Compiler отсеет type error и спокойно пропустит неверный product behavior. Test suite может фиксировать устаревшее требование. LLM-judge может быть хорошо откалиброван на вчерашнем support traffic и дрейфовать после изменения продукта. Сильный feedback уменьшает неопределённость, но не отменяет judgment.
В-третьих, значительная часть сильных чисел недели — first-party measurements: Databricks оценивает собственные потери, Cline — собственную миграцию, Meta — собственное сокращение token usage, а Reimagine — собственный deployment. Это хорошие свидетельства механизмов, но не независимая оценка эффекта для другой компании.
Operator takeaway
- Спроектируйте correction до масштабирования execution. Для каждого автономного пути заранее определите, что может отвергнуть неверную попытку, какое evidence переживает failure и где находится независимый acceptance.
- Перенесите correction ближе к домену, не размывая authority. Пусть люди, которые первыми видят ошибку, дают структурированный feedback, но превращение этого feedback в production behavior должно оставаться управляемым переходом.
- Каждый важный fix должен менять будущее поведение. Приземляйте исправления в tests, policy, knowledge, schema, tool contracts или runtime state, чтобы следующий run структурно отличался от неудачного.
Первая волна AI adoption была про производство большего объёма работы. Следующее эксплуатационное преимущество — научить системы использовать собственные ошибки так, чтобы каждая из них не превращалась в ещё один созвон.
Генерация выглядит эффектнее. Но накапливается именно исправление.
Worth tracking
- Workspace trust до context gathering: исследование Manifold Security GitSpawn обнаружило восемь findings в семи coding-agent products и несколько путей, выполнявшихся до workspace trust. Порядок trust boundary становится самостоятельным свойством runtime.
- First-class agent identity: WorkOS Agent Auth даёт агентам отдельные identities и короткоживущие scoped tokens. Identity становится местом, где можно явно моделировать delegation и revocation.
- Agent как architecture input: эксперимент Armature охватил 16 893 coding-agent sessions и показал низкое согласие между агентами в выборе third-party tools. Выбор зависимости уже стоит наблюдать как часть архитектуры.
- Durable state для generated worlds: Runway GWM Worlds 2 отделяет persistent world context от timestamped event stream и прямо отмечает long-horizon drift. Даже генеративному миру требуется состояние, которым не владеет генератор.