Обновить

Комментарии 17

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

Аналогия рабочая, но с одним отличием - у водителя отзывают права за конкретные нарушения, а тут пока непонятно кто вообще “за рулём”. Amazon говорит что виноват инженер который выдал права, FT говорит что агент сам выбрал деструктивное решение. Если переводить на автомобили - это как если бы автопилот снёс забор, а производитель сказал “водитель не должен был включать автопилот на этой дороге”. Вроде и правда, но проблема-то в том что автопилот вообще позволяет себе ехать в забор без торможения.

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

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

Допилят конечно, вопрос когда. Claude Code уже сейчас умеет спрашивать перед опасными командами, у него есть permissions в settings.json. А Kiro почему-то запустили без этого. Ну то есть технология для guardrails существует, просто Amazon решил что 80% adoption rate важнее чем “давайте сначала допилим safety”. Классика - сначала деплой, потом postmortem, потом guardrails. А KPI на использование инструмента без KPI на quality of that usage это вообще отдельный жанр менеджмента)

Я даже более глубокую структуру имел ввиду - типа общекорпоративные полититики что можно, а что нельзя, а потом уже сам разработчик права даёт на что можно, а что нельзя. А так да - вскрытие покажет и бесполезные(вообще вопрос, а могут ли они быть полезными?) KPI классика...

Двухуровневая система - да, примерно так Claude Code и работает. Есть глобальные permissions в settings.json от команды/компании, а есть CLAUDE.md в проекте где разработчик описывает что можно а что нельзя. У Kiro видимо ничего такого не было, просто operator-level доступ на весь scope. Про бесполезные KPI - ну 80% weekly usage как OKR для менеджеров это прям учебник по Goodhart’s Law, когда метрика становится целью она перестаёт быть метрикой

Вообще так подумал надо это не как KPI рассматривать - это в данном случае карательный инструмент в руках ленивого менеджмента. Люди инертны и имеют подсознательное сопротивление новому, даже в ИТ и иногда чтоб подсадить людей нужно целую спецоперацию устраивать (ну например у тебя нет полномочий чтоб как раз внедрить в приказном порядке). Не навязывать, устроить "спектакль" - показать на своем примере что это круто работает. Потом невзначай предложить, напомнить. Муторное дело...

Ну да, если инструмент реально хороший - люди сами подтянутся. Когда Claude Code появился, никто не заставлял его использовать, просто кто-то попробовал и рассказал коллегам. А тут 1500 человек прямо говорят “мы уже нашли что работает лучше” и им в ответ KPI. Это даже не ленивый менеджмент, это менеджмент который активно игнорирует фидбек от собственных инженеров. Ну и результат соответствующий

Если у тебя на кону будут стоять опционы топменеджмента ты за 5 минут найдешь все преимущества собственного решения)

Ну да, классика NIH синдрома. Только тут масштаб другой - обычно NIH это когда переписывают библиотеку потому что “мы знаем лучше”, а Amazon заставил 80% инженеров использовать свой инструмент вместо того который те сами выбрали. И потом удивились что что-то пошло не так

Ну вот смотри, с тросиком понятно - он рвётся, машина не едет. Детерминированная система. А агент может на один и тот же баг предложить патч, а может решить пересоздать окружение. Ты не знаешь заранее что он выберет, в отличие от педали. Поэтому мне кажется тут ответственность не только на “водителе” а ещё и на том кто дал агенту возможность делать необратимые вещи без подтверждения. Ну то есть если бы Kiro перед delete спросил “точно удалить?” - инцидента бы не было. Это не вопрос квалификации инженера, это вопрос отсутствия guardrail в самом инструменте.

он рвётся, машина не едет. Детерминированная система

Если бы. Может порваться или зацепиться в положении "полный газ". А уж про электронный вариант молчу. И там тоже не известно что будет. Я согласен что у агентов в отличии от автомобиля больше вариантов действий и контролировать там сложнее. Но ответственность на агента не повесишь, а если попробовать повесить на создателя агента, то он за него захочет такую цену, что о массовом использовании можно забыть.

Про тросик в положении “полный газ” - ладно, тут ты меня поймал, плохой пример был) Про ответственность на создателя - а ведь так и будет скорее всего. EU AI Act уже классифицирует AI-системы по уровню риска, и для high-risk обязывает делать human oversight. Цена вырастет, но не факт что критично - тот же mandatory peer review для AI-изменений у Amazon это по сути бесплатный guardrail, просто раньше не додумались включить.

Может порваться или зацепиться в положении "полный газ".

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

Сюда же относятся пневматические тормоза грузовиков, работающие на разжатие колодок. То есть если пневматика повреждена, машину нельзя снять с тормозов.

Позиция Amazon: это «user access control issue» - инженеры выдали агенту слишком широкие права, виноват не AI, а настройка. «A coincidence that AI tools were involved.»

Позиция FT (четыре источника): агент действовал автономно и выбрал деструктивное решение как оптимальное.

Лично я вижу тут 2 ошибки: агенту дали много прав, после чего агент выбрал деструктивное действие для решения проблемы. Так что верны обе версии.

Ага, я к тому же выводу прихожу в статье - обе версии не взаимоисключающие. Просто Amazon пытается свести к “user access control issue” и снять вопрос, а FT акцентирует автономность агента. На практике это два слоя одной проблемы - и оба надо фиксить. Права ограничить И checkpoint перед деструктивными действиями добавить

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации