Технический контекст
Я зацепился здесь не за шутку про «Claude будет стараться сильнее», а за сам механизм. В CLAUDE.MD добавляют простую рамку: твой результат будет проверять Codex. И внезапно Claude начинает реже халтурить, меньше выкидывает шаги из тестирования и аккуратнее доводит задачу до конца.
С инженерной точки зрения это очень узнаваемо. Я постоянно вижу в AI implementation, что модель меняет поведение не только от инструкции «сделай лучше», а от роли, риска и ожидаемой проверки. Когда агент понимает, что его вывод не финальный, а пойдёт на внешний аудит, он чаще выбирает более консервативную траекторию.
В исходном обсуждении важная деталь была вот где: всё это работало «на чистом контексте», но у автора ещё и самописный адаптер. И я бы именно здесь поставил жирную звёздочку. Это не новость уровня «Anthropic официально выкатил новую фичу», а скорее полевой insight, который родился в реальной обвязке вокруг модели.
То есть первичный факт у нас не из документации Anthropic и не из релиз-ноута. Это наблюдение пользователя над поведением coding agent в собственной экспериментальной матрице. На дворе апрель 2026 года, и я бы честно подавал это не как доказанный закон, а как сильную гипотезу, которую стоит проверить у себя.
Почему приём вообще может работать? Потому что LLM хорошо чувствуют социальную структуру задачи. Если я пишу в системном промпте не просто «сделай качественно», а «твой код будут проверять, ошибки всплывут, решение сравнят с альтернативой», я создаю давление на полноту и самопроверку.
И да, формулировка про Codex тут не магическая. С высокой вероятностью работает не бренд, а сам факт внешнего аудитора. Сегодня это Codex, завтра другой агент, послезавтра внутренний review bot. Суть в том, что модель получает контекст ответственности.
Что это меняет для бизнеса и автоматизации
Самое интересное начинается не в промптах, а в архитектуре. Если я строю AI automation для разработки, поддержки или QA, мне уже мало просто выбрать «лучшую модель». Я думаю слоями: кто генерирует, кто проверяет, кто спорит, кто добивает тестами.
Вот тут такие мелкие трюки реально стоят денег. Один абзац в системном промпте может убрать часть ленивых ответов без апгрейда тарифа и без сложного fine-tuning. Для бизнеса это часто лучшая сделка, чем сразу накидывать больше токенов и больше агентов.
Но есть и обратная сторона. Если перегнуть с «тебя проверят, тебя сравнят, не ошибись», агент может стать медленнее, осторожнее и начать переобъяснять очевидное. Я такое ломал много раз: качество будто выросло, а throughput просел настолько, что вся автоматизация сдулась.
Поэтому я бы тестировал этот паттерн только на измеримых сценариях. Например: процент задач, где Claude действительно запускает или предлагает тесты; доля пропущенных edge cases; число итераций до рабочего PR. Без метрик это быстро превращается в красивую легенду про промпт-инженерию.
Кто выигрывает? Команды, у которых coding agents уже встроены в пайплайн и есть своя обвязка. Кто проигрывает? Те, кто ожидает, что одна фраза в CLAUDE.MD внезапно заменит нормальную AI integration, валидацию и маршрутизацию задач между агентами.
У себя в Nahornyi AI Lab мы как раз такие вещи и раскладываем по слоям: где нужен внешний критик, где хватает self-check, а где лучше вообще не пускать модель в автономию. Это уже не про магический промпт, а про AI solutions architecture, где поведение агента держится на ролях, проверках и стоимости ошибки.
Если у вас coding agent пишет код, но временами «экономит усилия» в самых дорогих местах, я бы начал именно с такой рамки внешнего аудита и A/B-проверки на ваших задачах. А если хотите не гадать по ощущениям, а собрать рабочую AI automation под ваш процесс, в Nahornyi AI Lab я помогу превратить эти эксперименты в систему, которая реально снимает рутину, а не плодит ещё один слой хаоса.