Agent First Repository

Одно ограничение, из которого выводится остальное

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

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

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

Знание репозитория как система записи

Первый провал был предсказуемым: один большой файл инструкций. Подход «вся правда в AGENTS.md» не сработал по четырём причинам, и каждая самостоятельна:

• Контекст — дефицитный ресурс. Гигантский файл инструкций вытесняет из окна саму задачу, код и нужную документацию: агент либо теряет ограничения, либо начинает оптимизировать не то.
• Слишком много указаний перестаёт быть указаниями. Когда важно всё, не важно ничто, и агент начинает подражать локально вместо того, чтобы двигаться осмысленно.
• Файл протухает мгновенно. Монолитная инструкция превращается в кладбище устаревших правил: агент не отличает ещё верное от уже неверного, люди перестают её поддерживать, и она тихо становится ловушкой.
• Его нечем проверить. Единый ком не поддаётся механическим проверкам — покрытия, свежести, владения, перекрёстных ссылок, — и расхождение неизбежно.

Решение — сменить жанр файла: не энциклопедия, а оглавление. Короткий AGENTS.md порядка сотни строк подаётся в контекст и служит картой с указателями, а система записи живёт в структурированном каталоге docs/: планы активные и завершённые, реестр технического долга, генерируемые артефакты вроде схемы базы, спецификации продукта со своим индексом, справочники, документы по проектированию и архитектуре.

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

Маршрутизация как отдельный слой

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

Agent Harnesses оформляет этот инвариант конкретной файловой конвенцией: краткий HARNESS.md ведёт к routing-файлам веток, а .harnessleaf и .leaf-detectors останавливают обход перед внутренностями skill, скриптами или большим хранилищем. Вложенный HARNESS.md начинает новое независимое дерево и оправдан только для самодостаточной подсистемы — плагина или vendored package, — а не как ещё один уровень обычной группировки.

Имена файлов здесь вторичны. AGENTS.md, CLAUDE.md, индекс документации или инструмент структурного поиска могут реализовать тот же протокол. Важно, чтобы клиент соблюдал маршрут и границы, а не просто видел лежащие на диске указатели: файл без загрузчика или metaskill остаётся рекомендацией, которую модель может не прочитать. Как измерять фактический маршрут, а не наличие карты, — Agent Navigation Observability.

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

У такого плана есть проверяемая форма, и она узнаваемо не похожа на постановку задачи для человека. Наблюдаемая структура спецификации на одно изменение: фронтматтер с идентификатором задачи, репозиторием, оценкой объёма и затронутой поверхностью; дальше продуктовая половина и техническая. Существенны в ней четыре раздела, каждый из которых закрывает свой способ разойтись с реальностью:

• пронумерованные инварианты с точки зрения потребителя, а не описание намерения: «восстановление разговора с таким-то значением показывает такую-то строку до следующего запроса, и отсутствие значения показывает «недоступно», а не ноль». Такой пункт проверяем буквально, и по нему же потом пишется тест;
• альтернативы по каждой развилке, где разумных вариантов больше одного, с выбранным и причиной выбора. Без этого следующий читатель — человек или агент — переоткрывает решение и часто выбирает иначе;
• закрытые вопросы: то, что при написании было неизвестно, и чем именно оно разрешилось. Вопрос, превращённый в решение с обоснованием, перестаёт всплывать заново;
• критерии проверки и радиус поражения: чем подтверждается, что сделано, и что ломается, если сделано неверно.

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

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

Спецификация живёт в двух состояниях, иначе она становится кладбищем

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

Разрешается это тем, что состояний держат два одновременно:

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

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

Регламент, что через инкремент не проводится, обязателен. Без него накладные расходы съедают выигрыш и дисциплина ломается за месяц. Граница проводится по смыслу: цвет кнопки спецификацию не меняет; баг, где спецификация права, а реализация ошиблась, тоже — исправляется реализация. Отдельный случай — технический инкремент: рефакторинг меняет поведение, но не смысл, поэтому у него есть намерение, разбор и план, но нет спецификации.

Коммит, подписанный намерением

Привязка документа к ревизии из раздела выше отвечает на вопрос «верно ли описание на этот коммит». Обратное направление — от строки кода к причине её появления — закрывается тем, что каждый коммит несёт идентификатор инкремента, и это проверяется на приёме.

Ценность именно машинная. Агент приходит в незнакомый код, видит, что часть задуманного уже реализована, и вместо того чтобы переизобрести или сломать, находит по подписи спецификацию и узнаёт, в рамках какого намерения это писалось. Дальше он расширяет существующее решение, а не строит второе рядом. У человека тот же ход делается через blame, но человек его обычно не делает, а агент делает всегда.

Слабое место известно заранее: подписывать забывают, особенно на технических коммитах, а мультирепозиторий делает сбор подписей ручной работой. Чинится это не призывом, а проверкой в конвейере — то есть третьей ступенью ратчета из раздела ниже.

Граница применимости у всего этого узкая, и её называют сами практики. Спецификация впереди кода окупается, когда известно, чего хочешь. Когда не известно — стартап, продуктовая гипотеза, незнакомая предметная область, — она даёт обратный эффект: долгое планирование, добросовестная реализация и вывод «мне нужно было не это». Там дешевле собрать выбрасываемый прототип, покликать его и вывести модель данных из того, что получилось. Промежуточный ход, снимающий часть этого риска, — начинать не со спецификации, а с онтологии проекта: заставить агента собрать понятийный аппарат по коду и текстам, найти места, где одно понятие называется по-разному на разных слоях, и записать результат в репозиторий. Это дёшево, полезно и не требует знать заранее, что именно будет построено.

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

Форма проверки у архитектурного документа своя: привязка к ревизии. Проверка свежести умеет сказать, что файл недавно менялся, — утверждение слабое. Сильное даёт другая конструкция: описание системы несёт пути к файлам и диапазоны строк, а сам документ — адрес репозитория и полную сорокасимвольную ревизию. Проверка ходит в git, убеждается, что путь существует на этой ревизии и что строка не выходит за пределы файла, и только тогда собирает постоянную ссылку. Документ перестаёт утверждать «верно вообще» и начинает утверждать «верно на коммит X»; когда файл уезжает, проверка падает вместо того, чтобы промолчать. Ход тот же, что дата сверки у утверждения и диапазон версий у правила структурного поиска.

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

Тот же приём для умений, а не только для документации

Постепенное раскрытие выше применено к знанию о проекте. Ровно так же оно применяется к умениям — специализированным инструкциям вида «наши соглашения по аутентификации», «как у нас устроены миграции».

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

Устройство, которое решает это тем же ходом:

• имя и одна строка описания каждого умения живут в промпте всегда — это дёшево;
• полный текст лежит файлом на диске и грузится отдельным инструментом только тогда, когда агент решил, что умение нужно;
• разрешение конфликтов по имени: первый каталог выигрывает — так проектные умения перекрывают глобальные, не удаляя их;
• к загруженному тексту применяются те же потолки, что к любому выводу инструмента (Bounded Tool Output), иначе одно большое умение съедает окно.

Плотность раздела в промпте — одна строка на умение. Больше означает вернуться к исходной задаче в меньшем масштабе.

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

Конструкция, которая это закрывает, — объявленная специализация вместо замены:

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

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

Умение, которое ни разу не сработало, — дефект описания, а не лишний файл. Выбор умения делается по одной строке описания, и ошибка выбора бесшумна: сработает не то, выдаст правдоподобный результат, и по итогу не видно, что нужное умение лежало рядом непрочитанным. Отсюда две разные проверки, и нужны обе:

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

Родственное — Tool Retrieval: там тот же отбор по описанию делается для инструментов, и цена ошибки та же.

У умения есть жизненный цикл, и он такой же, как у правила

Постепенное раскрытие снимает цену умения в контексте, но не снимает цену его существования: сто умений с короткими описаниями снова съедают окно, и выбор между похожими снова становится ненадёжным. Значит, у набора умений нужны те же три операции, что у файла инструкций, — заведение по порогу, снятие по неиспользованию и слияние.

• Порог заведения называется числом. Наблюдаемая форма: задача, потребовавшая больше пяти вызовов инструментов, — кандидат в умение. Число здесь важнее своего значения: без порога умения заводятся «на всякий случай», а такое умение не срабатывает никогда и при этом занимает строку в промпте.
• Снятие идёт по факту использования, а не по мнению. Ступенчато: не использовалось месяц — умение деактивируется, то есть его описание перестаёт подкладываться в каждый запрос (или подкладывается урезанным), но само умение остаётся; не использовалось квартал — уходит в архив. Ступень нужна, чтобы редкое, но нужное умение не исчезало от одного тихого месяца.
• Слияние идёт по расписанию. Периодический проход ищет мелкие умения, которые можно объединить попарно в более крупное. Без него набор растёт монотонно и приходит ровно к той задаче, ради которой заводилось постепенное раскрытие, только в меньшем масштабе.

Устройство узнаваемое: это ратчет из раздела ниже, применённый к умениям вместо правил, — с той разницей, что здесь у снятия есть объективный сигнал, которого у правил нет. Правило нечем измерить, кроме чтения подряд; умение либо срабатывало, либо нет, и это видно из журналов.

Умение без контроля не считается написанным

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

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

Тот же контроль объясняет, почему инструкция, написанная по самоотчёту специалиста, работает плохо: человек рассказывает не то, что делает. Рабочий способ вывести умение — провести агента руками по трудным местам задачи, поправить его на каждом, и только потом попросить записать методичку для следующего. Материалом методички становится наблюдавшийся ход, а не воспоминание о нём.

Опыт не переписывает live-умение напрямую

Fresh-agent контроль отвечает, полезен ли новый текст, но не отвечает, кто имеет право его выпустить и к какой версии относилось решение. Если агент учится по собственным трассам, между разбором и live SKILL.md нужен отдельный proposal: evidence, target, ownership, base hash, полный diff, RED/GREEN и способ отката. Изменившийся base делает proposal устаревшим; разрешение на прежнюю ревизию не переносится на новую.

Неизвестный, пользовательский и импортированный skill по умолчанию считаются user-owned. Автоматическое применение допустимо только в явно machine-owned пространстве; для остальных агент предлагает изменение. Уже запущенная сессия продолжает с загруженным снимком skill, поэтому новую версию проверяет свежая сессия. Полный протокол — Skill Change Control.

Умение или основной файл: критерий размещения

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

Отсюда разделение по признаку «всегда или иногда»:

• то, что должно действовать на каждом действии — «изменение сопровождается тестами», «ошибки логируются так-то», — живёт в основном файле инструкций. Умением это становиться не должно: цена в контексте невелика, а пропуск фатален;
• отдельный рабочий процесс, включающийся осознанно и целиком, — разбор производительности, работа с многоязычностью, анализ выдачи, миграция — это и есть умение. Признак узнаваемый: человек в такой момент говорит себе «сейчас я делаю не фичу, а вот это конкретное».

Метаумение, вызывающее другие умения по порядку, задачу решает частично и добавляет свою точку отказа: не сработало метаумение — не сработало ничего.

У ратчета обязан быть обратный ход

Ратчет описан выше только вперёд: провал превращается в правило, правило остаётся навсегда. В такой формулировке он через год даёт файл, который сам стал проблемой, — и отказ приходит не оттого, что правил много, а оттого, что их никто не снимает.

Правило уходит, когда его начала принуждать проверка. Строка «всегда прогоняй тесты после правки» осмысленна ровно до того дня, когда прогон тестов встроен в цикл; после этого она занимает контекст, ничего не добавляя, и конкурирует за внимание с правилами, которые ещё работают. Разгрузка — не уборка, а часть механизма: ступень надёжности выросла, значит запись на нижней ступени лишняя (Harness Optimization).

Каждая строка датируется. Недатированное правило нечем пересмотреть: непонятно, отвечает ли оно на провал прошлой недели или на устройство, которого в проекте уже нет. Файл инструкций из двух сотен недатированных строк — это не обвязка, а технический долг, притворившийся ею.

Несогласованность обнаруживается только при чтении подряд. Характерный отказ: правило «всегда добавляй обработку ошибок» и правило «функции короче двадцати строк» написаны разными людьми с разницей в месяцы, а вместе невыполнимы. Агент подчинится тому, которое прочитал последним, и это будет выглядеть как своеволие.

Скорость роста файла — метрика, и здоровое её направление убывающее. В начале правила добавляются часто, потому что открываются частые классы провала; по мере их закрытия темп падает. Зрелая обвязка добавляет правило в неделю, а не пять в день. Метрика удобна тем, что считается на производной: сам размер файла не говорит ни о чём, а его ускорение говорит, что провалы пошли новым классом.

Когда правило пора превращать в проверку

Триггер называется числом, а не ощущением: один и тот же комментарий ревьюера в третий раз обязан перестать быть комментарием. Прогрессия при этом ступенчатая, и каждая ступень отвечает на свой вопрос:

Четвёртого раза быть не должно. Условия перевода на ступень проверки формулируются заранее: требование проверяемо без субъективного суждения, нарушение стоит переделки или прод-риска, и проверка умеет объяснить, как чинить.

Архитектура как принуждаемый инвариант

Документации мало: она не удерживает связность кодовой базы, целиком написанной агентом. Работает другое — принуждать инварианты, а не управлять реализациями.

Пример границы: от агента требуют разбирать входные данные на границе системы, но не предписывают библиотеку. Требование — свойство результата, а не способ его получить.

Устройство, на котором это стоит: каждая предметная область разделена на фиксированный набор слоёв со строго проверяемыми направлениями зависимостей и ограниченным списком допустимых рёбер. Порядок — Types → Config → Repo → Service → Runtime → UI, зависеть можно только «вперёд». Сквозные заботы — аутентификация, коннекторы, телеметрия, флаги функциональности — входят через единственный явный интерфейс (Providers). Всё остальное запрещено и проверяется механически.

Наблюдение, ради которого этот раздел стоит читать: это архитектура, которую обычно откладывают до сотни инженеров, а с агентами она становится ранним предусловием. Ограничения — то, что позволяет держать скорость без распада. В процессе с людьми такие правила выглядят педантизмом; с агентами они становятся множителем, потому что, будучи записаны один раз, применяются везде сразу.

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

Отчуждаемые куски: код, который дешевле переписать, чем читать

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

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

Экономика здесь другая, чем у обычного модуля. Модуль выделяют, чтобы его было проще понять; отчуждаемый кусок выделяют, чтобы его не приходилось понимать вообще. Условие ровно одно и проверяется механически: поверхность взаимодействия должна быть настолько узкой, чтобы переписывание не могло затронуть ничего снаружи.

Раньше такое деление держалось на дисциплине и потому не держалось. Теперь у него появился измеримый смысл: доля кода, которую можно не рецензировать, прямо снижает нагрузку на самое узкое место процесса (Parallel Agent Dispatch).

Легибельность приложения: узкое место переезжает на человека

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

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

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

Размер изменения как гейт, а не как пожелание

Сделать приложение читаемым для агента — половина ответа на переезд узкого места. Вторая половина — ограничить объём, который вообще доходит до человека, и делать это не просьбой, а проверкой, валящей сборку.

Основание известно задолго до агентов: у человека предел внимательного чтения диффа — порядка двух-четырёх сотен строк, дальше качество ревью падает нелинейно. Агентная разработка не меняет этот предел, а только увеличивает поток, который в него упирается. Наблюдаемая форма — жёсткий потолок в пятьсот строк на изменение, без исключений; исключение здесь опаснее отсутствия правила, потому что делает потолок предметом переговоров.

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

Побочный эффект оказался сильнее основного. Ограничение размера само отсекает сгенерированный мусор, и вот почему: агент, работающий без вмешательства, не перерабатывает существующий интерфейс под новую возможность, а надстраивает её сверху. Такие изменения выходят объёмными по построению — и не проходят потолок, не доходя ни до машинного ревью, ни до человеческого. Правило, введённое ради внимания читателя, оказалось фильтром по способу работы.

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

Пропускная способность меняет процесс

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

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

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

Энтропия: агент воспроизводит и плохое тоже

Полная автономия приносит новую проблему: агент воспроизводит паттерны, которые уже есть в репозитории, включая неровные и неудачные. Со временем это неизбежно даёт дрейф.

Ответ устроен как сборка мусора: фоновые задачи регулярно ищут отклонения, обновляют оценки качества по областям и открывают точечные правки — большинство просматриваются меньше чем за минуту и вливаются автоматически.

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

Числа и как их читать

Как это читать. Числа получены командой о собственной работе с собственным инструментом, на одном продукте и одной кодовой базе; независимой перепроверки нет. Оценка «в десять раз» — оценка, а не замер: контрфактического прогона руками не было и быть не могло.

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

Итоговая формулировка, которая и есть смысл практики: строить софт по-прежнему требует дисциплины, но дисциплина переезжает из кода в оснастку — в инструменты, абстракции и петли обратной связи, которые удерживают кодовую базу связной.

Независимое совпадение с устройством этой базы

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

Что это подтверждает и чего не подтверждает. Подтверждается устройство, а не утверждение о мире: совпадение не доказывает правильность решения, но снижает вероятность, что оно отвечает вкусу автора, а не ограничению. Ограничение при этом называется одинаково с обеих сторон — конечное окно и отсутствие памяти между запусками (Source Independence про то, почему независимость источника весит больше их количества).

Где расхождение — и оно интереснее совпадения:

• Сообщение проверки как носитель исправления. У них текст ошибки линтера вносит в контекст инструкцию, что делать. Здешние скрипты печатают отчёт: check-rules.ts сообщает, что правило не прошло, но не говорит, что писать вместо. Перенимаемо и дёшево.
• Садовник фоновый и правит сам. Здесь vault-audit только диагностирует, а правки идут отдельным проходом после подтверждения. Это осознанное расхождение, а не отставание: у них правка касается кода, у базы — смысла утверждений, и молчаливая автопочинка смысла опаснее пользы.
• Оценки качества по областям. У них области документации получают оценку, отслеживаемую во времени. Балльные рубрики для заметок здесь отклонены — но расхождение мнимое: оценивается покрытие, а отклонялась оценка достоверности, и это разные вещи.

Граница аналогии, без которой раздел был бы самолюбованием. Их docs/ протухает, когда меняется код, который пишет та же система, — потому садовник и привязан к коду. Заметки здесь протухают, когда меняется мир, а внутри репозитория этого не видно ничем: отсюда verified с актором и stale_after вместо сканирования на расхождение с кодом. Механизм свежести у двух баз разный по необходимости, а не по вкусу.

Чего отсюда не следует

Пункт чеклиста не заводится. Всё описанное — про среду, в которой агент пишет код, а не про агентную систему, которую сдают в прод. Чеклист базы проверяет второе.

Практика не переносится по частям. Автономия здесь — следствие всей оснастки сразу: без легибельного приложения агенту нечем проверить свою работу, без принуждаемых инвариантов правки расходятся, без садовника накапливается дрейф. Взять один приём и ждать заявленного эффекта — то же, что взять число из чужого бенчмарка.

Связано с

• Agent Harness — исполнительная обвязка; здесь про среду вокруг неё, а не про её устройство
• Parallel Agent Dispatch — та же среда со стороны человека, ведущего несколько задач сразу
• Convention Over Instruction — приём, работающий против роста файла инструкций: сменить конвенцию вместо того, чтобы её описывать
• Context Compaction — постепенное раскрытие как приём управления контекстом
• Context Layers — слои контекста с разным сроком жизни; docs/ здесь ровно такой слой
• ADLC — релизный процесс, жёсткость гейтов в котором эта практика ставит под вопрос
• Agent Evals — оценочные стенды здесь тоже пишет агент
• Source Independence — почему совпадение с устройством этой базы что-то значит
• ADR — решения как версионируемые артефакты; здесь тот же приём распространён на планы