Модель это коммодити. Ров это харнесс

Недавно попалась статья Eyad Khrais (@eyad_khrais) про harness engineering. Хорошее объяснение. Модель это мозг агента. Харнесс это тело. Мозг вызываешь через API. Тело придётся строить самому.

Всё так. Но «тело» это ещё не вся картина. Само по себе тело ничего не делает. Ценность в инструментах, которыми оно владеет. Это руки, которые берут нужный инструмент и делают работу правильно.

За последний год я прочувствовал это на своём проекте. И вывод у меня жёстче, чем «постройте телу руки».

Модель у всех одна

Один и тот же API вызывают все. Ваше преимущество не в модели. Оно в контексте и инструментах вокруг неё. Вот это и есть ров.

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

У нас это правило прямо в манифесте проекта. Делаешь что-то второй раз руками ИИ, вынеси это в CLI.

Промпт стал тонким

Отсюда неудобный вывод. Промпт-инжиниринг оказался самой короткой профессией в айти.

Не потому что промпт не важен. Рычаг сместился. У сдвига даже есть имя. Летом 2025 Tobi Lütke и Андрей Карпаты закрепили термин «context engineering». Gartner сказал прямо: context engineering in, prompt engineering out.

Аналогия Карпаты простая. Модель это процессор. Контекстное окно это оперативка. Вся работа в том, что вы туда грузите. Раньше умение было в том, чтобы хитро сформулировать запрос. Теперь промпт тонкий. Толстыми должны быть контекст и харнесс под проект.

Зная контекст, модель сама берёт нужную CLI-команду. И получает предсказуемый результат. Без контекста она импровизирует. Тут и начинается рандом.

У себя я промпт почти не трогаю. Вся работа ушла в контекст и инструменты.

Контекст не толстый, а выверенный

Тут ловушка. «Толстый контекст» не значит, что нужно грузить все подряд.

Chroma прогнала 18 моделей на длинном вводе. Качество падает по мере роста контекста. Задолго до того, как окно заполнится. Они назвали это «context rot». Окно на 200k может поплыть уже на 50k.

Значит работа харнесса не «дай модели всё». А «дай ровно нужное на этом шаге». Иногда это просто список того, что есть. Модель сама выберет нужное под ситуацию. Обработали вывод, выбрали следующий шаг.

Детерминизм против галлюцинаций

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

Модель выдаёт неверный вызов с той же уверенностью, что и верный. Для неё это просто текст. И даже получив верный результат, ты не знаешь, верить ли ему. Перепроверка может дать новое число.

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

Ресёрч говорит то же самое, только сухо. Ограничение в промпте остаётся вероятностным. «Постарайся не повторяться» модель нарушит. Ограничение в коде определённо. if id in used не обойти. Поэтому счёт, сортировку, проверку правил выносят из модели в код. LLM проваливает даже простую арифметику в длинной задаче. Вывод простой. Чем меньше модель считает сама, тем меньше у неё шансов соврать.

CLI это и есть перенос работы из головы модели в код. Правильный запрос зашит один раз. Модель не пересобирает логику на ходу. Она оркестрирует проверенные инструменты.

Это стоит трети проекта

Даром не даётся. В моём проекте харнесс занял около трети всей сложности. Треть, которую модель не написала за меня.

Окупается ли. Не просто окупается. Харнесс поднимает общую точность системы. Детерминированную работу забирают проверенные инструменты. Модель меньше опирается на своё рассуждение там, где ошибка дорогая.

А есть области, где ошибка дорогая по-настоящему. Финансы. Медицина. Право. Там нельзя катить в продакшен «модель вроде посчитала верно». Вы бы доверили этому свои деньги? Я нет. Полный харнесс под проект там не роскошь. Это условие, чтобы вообще запускаться.

Когда делать инструмент, а когда нет

Как понять, что пора. Простое правило. Третий раз делаешь руками ИИ, значит это команда.

Хороший инструмент похож не на API для разработчика. А на инструмент для агента. Я пришёл к этим правилам сам, набивая шишки. Потом увидел, что Anthropic описала ровно то же:

• Узкий. Одна задача. Понятные входы и выходы.

• Детерминированный. Одинаковый вход даёт одинаковый выход.

• Понятный модели. Чёткое имя, описание, пример. Ответ не забивает контекст (в Claude Code ответ тула режут до 25k токенов).

• Сгруппированный. Общие префиксы (db_get, db_write), чтобы модель не путалась среди похожих.

• С проверкой. Валидация до выполнения. Лимиты, права. Опасное отдаём человеку.

У них хорошая формула. Сколько сил вы вкладываете в интерфейс для человека, столько же вложите в интерфейс для агента. И главная строчка: агент настолько хорош, насколько хороши его инструменты.

И обратное. Не всё, что шевелится, достойно CLI. Разовая задача не окупит инструмент. Иначе утонете в командах, которые никто не вызовет. Периодически я провожу чистку и убираю лишнее. Тут ИИ помогает сам. Он отлично скажет, что редко используется и что можно улучшить.

А не съедят ли это модели поумнее

Честный вопрос. И есть сильное возражение. Ричард Саттон, «The Bitter Lesson»: рукотворную структуру всегда в итоге смывает масштаб. Модель умнеет и сама делает то, что вы зашивали руками. Логично предположить, что и харнесс однажды не понадобится.

Возражение серьёзное, и я его не отметаю. Manus переписывал свою обвязку четыре раза, пока модели росли. Часть работы и правда обесценивается со временем.

Но не вся. Координация, состояние, восстановление после ошибки, права доступа. Это не задачи рассуждения, которые модель «додумает». Это инфраструктура. Её кто-то должен держать, и это харнесс.

Плюс модели неровные. Экономист Joshua Gans назвал это «рваным интеллектом». На одном запросе отличный результат, на соседнем уверенно неверно. Масштаб это не лечит. А значит в дорогих доменах вы всё равно обкладываете модель проверками и инструментами. Бенчмарку нельзя верить, когда на кону деньги.

Так что да. Часть харнесса будет таять с ростом моделей. А детерминизм, состояние и проектный контекст останутся. Это не костыль под слабую модель. Это то, как вообще делают надёжные системы.

И ещё один плюс, чисто практический. Харнесс это автоматизация. Собрать данные, обработать, подать модели готовыми. Это экономит токены и ускоряет работу. Да, модель сделает это и сама. Но зачем ждать и платить больше, если автоматизация почти бесплатная.

Что оставить модели, а что отдать харнессу

Простое разделение, которым я пользуюсь.

Модель: язык, суждение, неоднозначность, план из размытой задачи.

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

Модель предлагает. Харнесс проверяет и исполняет. Если что-то обязано быть верным, оно не должно проходить через свободное рассуждение модели.

Куда это идёт

Модели становятся взаимозаменяемыми. Свапнуть одну на другую посреди задачи уже реально. А раз модель сменная, преимущество утекает в то, что вокруг неё. В тело. В руки. В инструменты. В память и контекст.

Роль «prompt engineer» уходит. Остаётся тот, кто строит проектный харнесс, память и контекст. И чем важнее точность, тем большую часть проекта займёт именно эта работа.

Я на это ставлю. И вкладываюсь в руки, а не в погоню за идеальной моделью.

Мозг можно арендовать у кого угодно. Руки придётся сделать самому.