01Instructions
CLAUDE.md и AGENTS.md, правила, карта репозитория и блок red lines: пронумерованные запреты со ссылкой на инцидент, из которого правило родилось.
без неёагент блуждает и каждый раз изобретает свой порядок работы
Frontier-модели пишут код нормально. Ломается всё вокруг них: правила, доступы, среда, память, приёмка. Разбираем, из чего состоит эта обвязка и почему именно она определяет разброс результата.
«Модель можно купить, а контур - нельзя. Это навык.» принцип методологии харнеса
Харнес - это всё вокруг модели, кроме её весов: инструкции, инструменты, окружение, состояние, проверки. Модель - фиксированный актив, одинаковый у вас и у конкурента. Дисперсию задаёт окружение. Если агент сделал не то, чинят не промпт, а конкретный кусок харнеса.
схема прокручивается вбок
Инструмент раздали, скорость выросла, поток PR вырос в 5 и более раз. Предел осознания кода человеком остался прежним - порядка 3000 строк за один заход. Разница между «сгенерировано» и «реально понято» копится и превращается в когнитивный долг: в метриках скорости его не видно, он всплывает на ревью, на инциденте и на передаче проекта другому человеку.
Второй симптом того же порядка: процесс перестаёт быть детерминированным. Один и тот же запрос на той же кодовой базе даёт разный результат от сессии к сессии. Это не каприз модели - это недостающая инструкция в харнесе.
Ответ не в том, чтобы читать быстрее. Понимание переносится в артефакты: каждая работа агента оставляет след - требования, принятое решение, доказательства, отвергнутые варианты. Сумма следов становится базой знаний проекта, по которой можно ходить срезами, а не читать целиком. Роль человека смещается из «искать и писать» в «валидировать на точках передачи».
Рабочая рамка простая: вы тимлид команды джунов и мидлов, которая стоит порядка $250 в месяц, не устаёт и не помнит вчерашний день. Всё, что вы дали бы такой команде - правила, доступы, среда, память, приёмка - и есть харнес.
Диагностика начинается с вопроса «какая подсистема сломана», а не «какой промпт переписать». Пять зон покрывают почти все случаи, когда агент сделал не то. Потеря любой даёт каскадную деградацию.
CLAUDE.md и AGENTS.md, правила, карта репозитория и блок red lines: пронумерованные запреты со ссылкой на инцидент, из которого правило родилось.
Shell, файловые операции, тесты, MCP - типизированные, с явными контрактами. Каждый вывод инструмента заканчивается одним маркером следующего шага, чтобы агент не угадывал.
Зависимости, песочница, воспроизводимая сборка из git. Отдельно проектируются owned и forbidden зоны: где агенту можно писать, а где нельзя.
Git, память по временным слоям, handoff между сессиями. Ядро контекста загружается каждый ход, остальное поднимается по запросу, микро-решения живут с TTL.
Валидация, линтер, тесты, smoke, скоринг артефактов. Наибольший эффект при наименьшем пороге входа - и почти всегда строятся последними, потому что вместо них бесконечно тюнят инструкции.
Текстовые токены и компоненты, к которым агент обязан обращаться, плюс визуальный гейт до мерджа: снапшоты, сверка состояний, цветов и отступов.
Шесть принципов, которые сразу меняют процесс в команде разработки.
Самооценка систематически завышена: студент не проверяет свой экзамен. Generator и verifier разделяются на каждой стадии - проверка отдельным агентом в чистой сессии, по внешнему ground truth: git diff, реальный запуск, скриншот. Пустой diff при зелёных тестах - блокер, а не успех.
В пайплайне появляется роль ревьюера, которая физически не может писать код. Отчёт «done, тесты зелёные» перестаёт быть основанием для мерджа.
Всё, что настроено локально у одного человека, не существует для остальных и для агентов. Гейт должен стоять там, где через него проходят все коммиты, включая агентские.
Ревью успевает за генерацией не потому, что люди читают быстрее, а потому что до человека доходит только то, что прошло машинные гейты.
Информация, которой нет в репо, для агента не существует. Не «должна быть» - именно не существует. Markdown в git первичен, любые базы и индексы - производный кэш, перестраиваемый одной командой.
Знание из вики, тредов и голов тимлидов переезжает в репозиторий рядом с кодом. Побочный эффект: документация начинает обновляться, потому что от неё зависит результат агента.
Правило из документа нарушали 32 раза за полгода. Правило либо зашито в компилятор, хук, гейт или denylist, либо это фольклор. Нарушено дважды - переезжает из текста в enforcement.
Стандарт разработки перестаёт быть документом, который никто не читает, и становится набором проверок, которые невозможно обойти.
Надёжность решения считается как минимум по доказательствам, а не как среднее: среднее статистически отмывает слабое свидетельство. Доказательства оцениваются по формальности, гранулярности и надёжности источника в вашем контексте.
Whitepaper вендора не перевешивает собственный замер на своём проде. Выбор стека и инструментов перестаёт быть спором вкусов.
У каждого замера есть срок годности, у каждого решения - условия пересмотра: дата, событие или метрика, которые срабатывают сами. Решение без условий пересмотра - памятник, а не рабочий артефакт. Отсюда и следующий шаг: ошибка агента разбирается до конкретного куска харнеса - правило, проверка, память или инструмент.
Ретро после задачи заканчивается правкой конкретного файла в репозитории, а не переписыванием промпта. Доверие к процессу растёт от количества пройденных циклов, а не от смены модели.
Перевод методологии в то, что видно руководителю ИТ через месяц после запуска контура.
Команды сидят на Claude, Cursor, Codex и своих обвязках - и это нормально. Стандарт задают артефакты в репозитории и гейты в сборке, а не выбор редактора. Вопрос методологии, а не молотка: пересаживать всех на один инструмент не требуется.
До человека доходит diff, уже прошедший машинные проверки и ревью отдельным агентом в чистой сессии. Человек тратит внимание на границы: контракты, инварианты, необратимые решения - а не на вычитку тысяч строк.
Тот же запрос завтра даёт тот же результат, потому что решения, отвергнутые варианты и условия их пересмотра лежат в репозитории. Проект переживает уход человека: контекст не в голове, а в артефактах.
Новый разработчик или аналитик заходит в проект, где правила, карта репозитория и точки эскалации уже описаны для агента - значит, описаны и для человека. Карта слоёв строится детальная: роуты, бизнес-логика, скрипты, конфиги, документация.
Песочница, owned и forbidden зоны, denylist инструментов по ролям, точки обязательной остановки. Это ложится на требования ИБ напрямую: видно, что уходит наружу, что остаётся во внутреннем контуре и где агент не имеет прав.
Не каждой задаче нужны артефакты. Правка в один файл с откатом за час - просто коммит. Полный конвейер включается там, где решение необратимо или задевает несколько команд. Записи «на всякий случай» хуже отсутствия записей.
Три шага. Сроки не называются до аудита: они зависят от того, что найдётся в текущем контуре.
Берут команду, которая собрала больше всего грабель. Смотрят, что уже есть по пяти подсистемам, где рвётся, какие проверки существуют и где они живут, как выглядит ревью агентского кода сейчас. На выходе - карта пробелов: что есть, что частично, чего нет.
Маленькая разнородная группа и настоящий продукт, а не учебный. Разработка в нормальном понимании: с девопсом, CI/CD и требованиями ИБ. Харнес собирается по ходу задач - инструкции, гейты в сборке, ревью отдельным агентом, артефакты решений - и каждая ошибка агента разбирается как баг харнеса.
То, что выжило в пилоте, оформляется в переносимый контур: шаблоны артефактов, гейты, роли агентов, протокол онбординга. Дальше команды подключаются к общему стандарту, оставаясь на своих инструментах.
схема прокручивается вбок
Пять шагов, каждый из которых делается за один вечер и уже меняет поведение агента. Порядок неслучайный: сначала то, что даёт обратную связь, потом то, что накапливает знание.
Поставьте хотя бы одну проверку в CI. Линтер, юнит-тесты или smoke - что угодно, лишь бы коммит не проходил без зелёного и лишь бы это работало у всех, а не в настройках одного ноутбука.
Напишите CLAUDE.md или AGENTS.md с картой репозитория и блоком red lines. Пронумерованные запреты со ссылкой на инцидент, из которого правило родилось. Остальное - явно помечено как рекомендации, чтобы агент видел разницу.
Разведите того, кто делает, и того, кто проверяет. Ревью артефакта или диффа - новой чистой сессией с задачей найти минимум три проблемы. В той же сессии модель защищает свой ответ и не находит ничего.
Заведите docs/decisions/ и запишите первое решение.
Контекст, варианты, доказательства, выбор, отвергнутое и условия пересмотра. Двести-четыреста слов. Пропускают обычно последний пункт - он и отличает живое решение от памятника.
Проведите ретро одной задачи, где агент ошибся. Найдите, какая подсистема дала сбой - правило, проверка, память или инструмент - и почините её. Правка конкретного файла, а не промпта. Нарушено дважды - переносите из текста в гейт.
Харнес нельзя купить готовым: он растёт из инцидентов конкретной команды и конкретной кодовой базы. Но собирать его с нуля каждый раз тоже не нужно - есть отработанные шаблоны артефактов, ролей и гейтов.
Разбираем это в программе AI Masters для ИТ-команд: пять подсистем на своём репозитории, гейты в своём CI, разбор ошибок агента как багов харнеса. Обсудить формат под вашу команду - в личных сообщениях.