Риск AI-агентов не только в модели

Вокруг coding agents обычно обсуждают одно: какая модель умнее, какой агент лучше пишет код, какой CLI быстрее доведет задачу до diff.

Под coding agents я имею в виду практические инструменты разработки, которые читают repo, работают с файлами, запускают команды, смотрят вывод и приносят изменение или рабочий артефакт, а не просто отвечают в чате.

Но за последние дни мне попался более интересный сигнал.

На Hacker News и GitHub вышли небольшие инструменты не про еще одного универсального агента, а про грязь вокруг его работы:

Сами проекты пока маленькие. Это не рейтинг и не рекомендация ставить весь набор.

Но направление важное.

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

Почему это сильный сигнал

Когда команда впервые подключает AI к разработке, кажется, что главный вопрос такой:

какой агент лучше?

Через несколько недель вопрос часто меняется:

в какой среде этот агент вообще работает?

Потому что агент не висит в пустоте. Он читает документацию, таскает в контекст файлы, смотрит логи, получает доступы, оставляет следы в истории, иногда видит секреты, иногда повторно читает мусор, иногда уверенно опирается на устаревший setup.

Если это не контролировать, проблема выглядит как плохая модель.

На деле это может быть плохое рабочее место.

Документация как интерфейс для агента

Раньше плохая документация раздражала человека.

Человек мог догадаться, спросить коллегу, вспомнить прошлый проект, посмотреть рядом лежащий скрипт и как-то собрать картину.

Агент тоже может угадывать. В этом и риск.

Если документация неполная, агент может не остановиться на границе незнания. Он достраивает недостающее сам и приносит правдоподобный результат.

Поэтому мне нравится сам класс задач вроде dari-docs: дать агентам конкретную задачу и проверить, где документация блокирует выполнение.

Это меняет вопрос.

Не "понятно ли написано".

А "можно ли по этим docs выполнить рабочее действие без угадывания".

Контекст как бюджет и риск

Вторая линия еще практичнее: что вообще попадает агенту в контекст.

Lockfiles, generated artifacts, coverage, старые логи, jsonl-экспорты, огромные instruction files, повторные чтения одних и тех же файлов.

Для человека это мусор на фоне.

Для агента это часть рабочей памяти, бюджета и поверхности ошибок.

Если агент прочитал лишние 200 тысяч tokens, проблема не только в счете за модель. Он мог:

Это уже не промптинг.

Это hygiene работы с AI-инструментами.

Логи как часть review

Третья линия: доступ к логам.

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

Это странный ручной мост.

Если агент участвует в разработке, ему нужен не бесконечный доступ ко всему, а нормальный ограниченный способ смотреть релевантные runtime-сигналы:

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

История чатов как секретное хранилище

Четвертая линия неприятная.

AI-инструменты копят историю. В эту историю легко попадают токены, env, stack traces, внутренние URL, куски config, приватные данные, временные ключи.

Потом это воспринимается как обычный локальный след работы.

Но для команды это уже поверхность безопасности.

Если появились инструменты, которые специально сканируют историю Cursor и Claude на секреты, это не случайность. Это признак, что AI-workflow начал создавать новый тип мусора: не только generated code, но и generated operational residue.

Что из этого следует

Я бы осторожнее относился к формулировке "мы внедряем AI-агентов".

Слишком часто за ней стоит только выбор инструмента.

А надо хотя бы минимально проверить рабочее место:

1. Docs

Может ли агент выполнить типовую задачу по документации без догадок?

2. Context

Какие файлы и artifacts агент вообще видит? Что надо исключить?

3. Logs

Как агент получает runtime-сигналы? Через копипасту человека или через ограниченный рабочий канал?

4. Secrets

Где могут остаться ключи, env, приватные данные и внутренние URL после AI-сессий?

5. Session trail

Можно ли потом понять, что агент читал, какие команды запускал, где зациклился и почему результат появился именно таким?

6. Review

Есть ли у ревьюера не только diff, но и след работы: задача, контекст, логи, ошибки, проверки, ограничения?

Практическое правило

Если агент часто ошибается, не стоит сразу менять модель.

Сначала стоит посмотреть на рабочее место:

Иногда "агент плохо справился" означает не то, что агент слабый.

Иногда это значит, что команда дала ему плохую среду.

Ограничения

По свежим маленьким проектам нельзя делать большой вывод о зрелости рынка.

У некоторых мало stars. У некоторых ранняя стадия. У некоторых может не быть production-grade гарантий. Часть инструментов завтра поменяет интерфейс или исчезнет.

Но как сигналы они полезны.

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

Для меня это более взрослая стадия AI-assisted development.

Не магический агент.

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

Источники для проверки:

Если у вас уже всплывали такие поломки вокруг AI-инструментов: docs, context, логи, секреты, session history, generated artifacts, напишите в комментариях.

Я хочу собрать из этого отдельную карту маленькой AI-workbench hygiene. Рабочие заметки по таким разборам веду в Telegram: https://t.me/goalrail