Jediah Katz про harness: что остаётся после новой модели (Рубрика #AI4SDLC)
Jediah Katz, инженер из Cursor, теперь в SpaceXAI, в 18-минутном докладе разбирает занятный процесс: команда улучшает harness, а следующая модель позволяет удалить часть этой работы. Запись вышла 19 октября на AI Engineer под названием «Smarter Models Killed the Harness. Here's What's Left».
По словам Каца, в Cursor раньше приходилось отдельно объяснять модели, как исследовать репозиторий и проверять результат, а для применения правок использовать вспомогательную модель. Постепенно модели освоили эти действия. Его объяснение: обвязка делает более сложные задачи доступными, появляются полезные траектории работы, на них учатся модели — и часть прошлих подпорок становится лишней. Это взгляд инженера изнутри продукта, а не независимое доказательство того, что сложная обвязка больше нигде не нужна.
У этого процесса есть продолжение. В Grokbot, где постоянный агент-координатор распределяет работу между исполнителями, команда снова добавляет инструкции и вмешательства. Теперь нужно осваивать сайты, вовремя сообщать о ходе работы, понимать, когда действовать, а когда уточнять, и запоминать предпочтения человека. На новом классе задач модель опять нуждается в помощи, но это уже похоже на мета-харнесс:)
Отдельно Кац выделяет следующие устойчивые части обзвизки: - Исполнение: где живёт агент, как сохраняется состояние и продолжается работа после сбоя. - Полномочия: к каким данным и действиям у него есть доступ, где заканчивается бюджет. - Эффективность: сколько стоят контекст, повторные вызовы и выбор моделей. Одинаковый балл на бенчмарке ещё не означает одинаковую цену задачи.
А самая вкусная деталь — учёт временных подпорок, которые команда называет shims. Например, агенту приходится напоминать, что пользователь ждёт ответа. По словам Каца, такие вмешательства учитываются централизованно, срабатывания логируются, а бот предлагает PR на удаление тех, которые перестали срабатывать.
Здесь доклад очень рифмуется с тем, что я рассказывал 16 октября на Giga Conf: после новой модели стоит пересматривать накопленные инструкции. Иначе обвязка постепенно становится музеем ограничений предыдущих поколений. В Research Insights #38 я разбирал, как проверять вклад отдельных компонентов: какой сбой исправляет план, управление контекстом или инструмент? А в лонгриде об эволюции harness предложил реестр предположений: зачем добавили компонент, при какой модели он помогал, какое есть доказательство и когда его перепроверить.
Кац показывает, как к такому реестру прикрутить наблюдение за реальной работой. Но «перестало срабатывать» — только повод для эксперимента. Могли исчезнуть нужные задачи, сломаться логирование или просто давно не повторялся редкий сбой. Я бы проверял удаление так:
- Сохранить эпизоды, ради которых появилась подпорка, и добавить характерные текущие задачи. - На одной версии модели и при одинаковом бюджете сравнить полную обвязку с вариантом без этого компонента (это исследования через абляции). Повторить запуски - Заранее определить допустимое ухудшение. Смотреть на качество, стоимость, время и вмешательства человека; если данных мало, оставить вопрос открытым. - Приложить результаты к PR и сохранить возможность вернуть компонент при регрессии.
И отдельно — границы полномочий. Запрет на удаление чужих данных нельзя отменять потому, что агент давно его не нарушал. Рост способностей модели сам по себе не расширяет её права. А в следующем PR, который добавляет агенту ещё одно правило, я бы сразу попросил записать: при каком результате проверки мы сможем это правило убрать?
#AI4SDLC #Agents #Engineering #Architecture #Evals