Три идеи из новостей об агентах, превращённые в проверки: что взяли в harness и что оставили

За одну неделю три идеи об AI-агентах облетели все каналы, которые я читаю. Карпати предложил просить модель писать как авиационное руководство. Исследователи Google опубликовали Harness², фреймворк, который улучшает всё вокруг модели, а не саму модель. Инженеры OpenAI рассказали, как с помощью агента за две недели удалили 800 000 строк мёртвого кода. Все три хороши. Все три при этом приходят в виде «добавьте одну магическую строку в промпт», а промпт — именно то, что дрейфует при следующем вызове. Поэтому мы взяли их в наш открытый конфиг github.com/AnastasiyaW/codex-claude-code-config как проверки. Ниже — что оставили, что выбросили и почему.

Авиационное руководство: два правила из девяноста

Стандарт — ASD-STE100, Simplified Technical English. Авиация использует его, чтобы механик читал в каждой инструкции один и тот же смысл. 2 октября Карпати расставил способы сделать вывод модели читаемее: сначала текст в таком стиле, затем диаграмма, потом интерактивная HTML-страница, и наконец собственный видеообъяснитель. Эта лестница полезна сама по себе. Большинству ответов нужна первая ступень, изменению архитектуры — вторая, а сравнению с кучей чисел — третья.

Строка «пиши строго по STE100» слабее, чем кажется. Полный стандарт содержит управляемый словарь примерно из 900 слов и десятки правил. Словарь охраняется авторским правом, и модели его надёжно не знают. Потребуешь строгого соответствия — получишь подражание: обрубленные предложения, а не сам стандарт.

Два правила несут большую часть пользы и не требуют словаря:

• Одно понятие — один термин. Если в проекте написано «worker», каждое предложение говорит «worker». Модели любят синонимы ради разнообразия. Технический читатель тогда должен догадываться, это три разные сущности или одна: «worker», «handler» и «executor».
• Короткие предложения. STE ограничивает инструкции 20 словами, описания — 25.

Мы сделали оба правила механическими. scripts/term_drift_check.py берёт глоссарий проекта и сверяет с ним то, что написал агент. Запись глоссария вроде обработчик* ловит все формы слова, так что проверка работает и по-русски. Существующие линтеры STE этого не делают, потому что сам стандарт написан для английского. Блоки кода, ссылки и комментарии пропускаются. Код выхода 0 — чисто, 1 — есть находки, 2 — проверка не смогла выполниться. Третье состояние нужно потому, что проверка, которая молча ничего не проверила, хуже её отсутствия.

Первая версия страдала именно от этого. Независимый ревьюер, отдельный агент со свежим контекстом, нашёл три способа получить зелёный результат, ничего не проверив: текст в кодировке не UTF-8, незакрытый блок кода и глоссарий без синонимов давали чистый результат. Второй ревьюер нашёл ещё пять. Все исправлены, а самотест теперь включает случаи, которые обязаны упасть, чтобы сломанный детектор не прошёл тихо.

Harness²: метод — да, автоматический патчер — нет

Идея Harness² сильна. Веса модели остаются фиксированными. Агент предлагает правки к своему окружению: системный промпт, память, рекомендации по инструментам, скиллы, скрипты, плагины. Он прогоняет их на задаче, оставляет то, что помогло, и запоминает урок для следующего раза. На трёх бенчмарках профессиональной работы один раунд поднял результаты GLM-5 и Gemini 3.5 Flash максимум на 11,5 пункта.

Мы не стали ставить его как есть. В README его исполнитель работает при открытой сети и с выключенной песочницей Codex, а протокола для отложенных задач там нет. Для агента, который правит собственные правила, это главный риск: он улучшается на задачах, которые видел, и незаметно ломает те, которых не видел.

Поэтому мы взяли метод как небольшой пилот с жёсткими границами:

• замороженный набор из трёх-пяти задач плюс хотя бы одна отложенная задача, на которой изменение не настраивалось;
• одно изменение на кандидата, чтобы причина была очевидна;
• механические квитанции по каждой задаче, а не мнение о результате;
• кандидат побеждает только при строгом улучшении и без регрессий по безопасности и на отложенной задаче;
• живые хуки, права доступа и ограничители не являются целью пилота никогда.

Компаратор читает две квитанции и выносит вердикт. Он не запускает агентов и не трогает живой конфиг. Принятый результат — это доказательство для ревью, а не выкатка.

Мёртвый код: доказательство берётся из продакшена

Цифры OpenAI впечатляют. Больше 1400 влитых PR и больше 800 000 удалённых строк примерно за две недели. Один образ контейнера стал на 48 % меньше, а медианное время CI упало примерно с десяти минут до четырёх с половиной. Промпты здесь не сделали работу. Сработал процесс.

Удаление кода — особый вид изменения. Когда исчезает недостижимый код, ничего не ломается. И ничего не ломается, если вы ошиблись насчёт его недостижимости, — пока не сломается продакшен. Значит, доказательство должно идти из продакшена: телеметрия, состояние флагов в работе, каждый сайт вызова, включая косвенные, владелец. Аудит только читает. Каждое удаление — один небольшой черновой PR с доказательствами и рассуждением в описании. Killswitch-ы и предохранители никогда не удаляются по слову агента.

Мы добавили это как справочник в скилл refactoring-safely. Теперь скилл срабатывает и тогда, когда просят удалить мёртвый код или устаревшие флаги фич.

Комментарии в коде: исследования говорят немного другое

Одновременно я хотела проверить идею, которой мы уже следуем: если агенты пишут и читают код, большинство комментариев лишь тратят контекст. Правило у нас действует с 15 октября, и я поискала под него исследования. Ответ оказался интереснее, чем «комментарии — шум».

• Устаревшие комментарии тянут генерируемый код к старой реализации.
• Модели могут доверять комментарию больше, чем коду, которому он противоречит.
• Отсутствие комментария в найденных мной исследованиях мало что меняло.
• Верный комментарий к неочевидному коду помогал: в одном исследовании кода legacy-мейнфреймов точность выросла примерно с 84 % до 90–96 %.

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

Что теперь в репозитории

• docs/output-legibility.md: лестница читаемости и два правила, со строкой для промпта, которая работает лучше, чем «пиши в STE100»;
• scripts/term_drift_check.py: проверка глоссария, с тестами и самотестом;
• docs/harness-improvement-pilot.md и его компаратор: ограниченный пилот;
• references/dead-code-sweep.md в скилле refactoring-safely;
• обновлённое правило о комментариях в rules/quality-code.md.

Всё вошло в релиз v2026.10.24, полный список изменений — в UPDATES.md. Агент может взять нужное прямо из репозитория: начните с CLAUDE.md и README.md, затем скиллы из skills-lock.json.

Если что-то из этого сэкономило вам день, звезда на GitHub помогает другим найти репозиторий. Если что-то сломалось, откройте issue: большинство наших правил изначально появились именно оттуда.