Согласен с главным тезисом: токены, DAU и сам факт внедрения не доказывают ценность.
Единственное, насчет saved time с агентами в первые месяцы после внедрения я бы был осторожен.
Часто вижу у команд, которые только внедряют ИИ-агентов и не понимают их ограничений: saved time космическая, задача заняла 1 день вместо 2 недель, покрытие тестами 146%, разумеется все зеленые. Ревью прошла. Через месяц оказывается, что была допущена тупая архитектурная ошибка, которая людям даже в голову не могла прийти, из-за которой нужно рефакторить не только эту задачу, но и весь код написанный после.
У Amplified недавно как раз опубликовался кейс с выводом, что эффект возможен за 1.5 секунды внимания, если distinctive brand assets поставлены правильно. То есть не "ускорили баннер и победили", а заранее проверили, что баннер распознается за один взгляд
Когда рекламу смотрят полторы секунды, выигрывает тот, кого успели узнать без чтения :)
Хук я бы чуть поправил. run_bot_tests.py при падении pytest печатает в stderr и делает sys.exit(0). Т.е. PostToolUse делает "увидел ошибку - попробовал починить". Но tool call уже прошел, файл уже изменен.
exit 2 у PostToolUse не откатывает действие, а только скармливает ошибку обратно Клоду. Если нужна именно защита от мусорного результата, ее надо вешать на Stop/TaskCompleted или тащить в pre-commit/CI.
Хорошая статья как ликбез, но я бы немного сместил акценты.
Ключевая проблема не в том, что агенту надо "объяснить" Zero Trust. Агент вообще не должен быть местом, где принимаются security decisions. Его надо считать недоверенным клиентом.
Главная граница - не промпт, а вызов инструмента. Всё опасное происходит в моменте: какой user запустил агента, какой tool вызывается, с какими аргументами, к каким данным/секретам/эндпоинтам он получает доступ, есть ли approval, можно ли сделать это действие в текущем ворклфлоу.
Поэтому allowlist в системном промпте, "будь осторожен" и описания tools - это не контроль, а подсказки для модели. Контроль начинается там, где перед каждым tool call стоит внешний слой авторизации (policy gateway / PEP-PDP / OPA / Cedar / ...). Важно, что решение принимает не модель.
То же самое с runtime и MCP. Контейнер сам по себе не делает агента безопасным, если внутри широкий доступ к фс, сети и секретам. MCP сервер тоже нельзя просто "подключить и доверять": дескрипторы, версии и права должны быть зафиксированы и проверяемы, иначе tool poisoning и silent update превращаются в supply-chain проблему.
Для меня формула такая: агент = untrusted client, тулы = protected backend, policy gateway = enforcement point.
Тогда прмопт-инъекция остается атакой на намерение агента, но не становится прямым доступом к инфраструктуре.
Попытки создавать самообновляемые вики/доки/скиллы по проектам начались еще до эры GPT 3.5. Но через N месяцев независимо от "мозгов" моделей всегда оказывается, что эту самообновляемую вики проще выкинуть, чем рефакторить, и она скорее вредна для агентов, чем полезна. Даже если был обвес из метрик и множества авто-CI-этапов.
Правила = артефакт архитектуры и процессов, влияющий на всю дальнейшую траекторию разработки. На мой взгляд, это не то, что имеет смысл доверять агентам, даже если это какие-то "вторичные" инструкции.
Вот как это организовано у меня (то есть в командах, куда я внедрил разработку на агентах):
Для каждого проекта (сервиса) есть плагины со скиллами. Проектные плагины, доменные, процессные. В одном плагине может быть от одного до несколько десятков скиллов про работу с отдельными независимыми компонентами проекта, внешними API, тулами и т.д.
Плагины в отдельных репо. Перед запуском сессий обертка над агентами проверяет их актуальность и обновляет.
Скиллы аккуратно разбиты на references под тот самый "progressive disclosure".
Потенциальные изменения в "правила" может составлять человек с агентом или без (как угодно). Агент может помогать человеку собирать наблюдения, предлагать изменения.
Ревью и обновление скиллов с "правилами" идет всегда через людей-владельцев процесса. Агент не может сам обновлять main плагинов (откуда их забирают агенты), максимум - создать PR в репо плагинов со скиллами.
Число правил на проекте зависит не от количества строк кода, а от качества архитектуры и количества внешних зависимостей. Качественная архитектура и хорошо написанные доки (доки пишут и ревьювят агенты и люди как код) уменьшают число необходимых правил.
Наиболее жирные правила у меня в командах, работающих над древними legacy, где очень плохая неочевидная архитектура и приходится компенсировать правилами.
Для сравнения:
проект с чистой архитектурой на 440к строк кода = 8кб плагин со всеми проектными правилами и доп.индексами по докам (считая только md, не считая отдельный процессный командный плагин и скиллы по внешним API внутри самого проекта)
legacy на 290к строк кода = 610кб md в скиллах (там альтернативная версия доков по проекту, т.к. старые выкидывать пока не решились)
Чуть-чуть устаревшие данные. Многие штуки уже стали документированными, а какие-то поменяли формат - лучше сверяться с актуальной документацией.
Примеры:
у PreToolUse новый формат, через hookSpecificOutput с hookEventName
результат тула теперь updatedToolOutput, updatedMCPToolOutput оставлен только для MCP
once: true работает только в хуках из frontmatter скилла, в frontmatter самого агента игнорируется
watchPaths ждёт абсолютные пути, а не package.json из текущей папки.
async уже документирован. Я его взял еще в феврале-марте из issues и широко использую а) для логирования б) для сбора метрик использования по командам.
PreToolUse с deny я использую еще с осени прошлого года, а вот про additionalContext не знал, спасибо. В Codex кстати PreToolUse нормально появился только в апреле...
Недокументированные механики могут появиться сегодня и сломаться уже завтра. Лучше использовать их только с целью ресерча, ни в коем случае не в рабочем коде.
Предполагаю, что под проблемой имеется в виду присутствие доступа, а не отсутствие.
Короткий ответ для ОС-изоляции - firewall/nftables/iptables по UID.
Доменные вайтлисты можно делать на уровне egress-proxy, а там уже правила и лимиты. Так проще с плавающими IP у CDN'ов. Для установок на РФ-сервера, egress-proxy еще решает вопрос правильного исходящего IP.
Для npm, pypi итп можно использовать зеркала/кеши, чтобы не нужен был весь интернет для зависимостей.
Могут быть переключаемые "строгий" и "мягкий" режимы. Мягкий = когда нужно дать агенту возможность гуглить, фетчить, ресерчить самостоятельно. У меня есть кастомный cli-тул, который выполняет ресерч (и подобные задачи) в headless-claude в отдельном контейнере и возвращает результаты в голых md, соответственно для этого мне "мягкий" режим не нужен. Но это уже усложнение, тогда можно задуматься и о запуске обычных сессий в контейнерах.
В строгом режиме, агенту разрешены DNS, egress-proxy, относительно доверенные url (напр. опенаи/антропик репо) и нужные внутренние эндпоинты. Всё остальное - deny по умолчанию.
Лимитированные/чувствительные API через прокладки, в которых логи, управление ключами/токенами, лимиты/квоты.
Но, если вы уже на уровне, где нужно строго резать сеть, возможно лучше сразу делать на rootless-контейнерах. Особенно если проектов несколько и для каждого свои правила.
ОС-изоляция скорее вариант для быстрого начала работы, либо когда рисками можно пренебречь.
В плане командной работы с агентами для разработки рынок на самой зачаточной стадии.
Пока адопшн вращается вокруг персонального использования. Компании раздают подписки, но не слишком управляют тем, как они используются. Есть аудит (логи) в корп.подписках = уже хорошо.
Самодельные уровни 2-3 пока существует как "частные" инициативы в крупных компаниях, публично это не анонсируют. Иначе сразу начнутся вопросы по работе с "чувствительными данными", на которые никто лишний раз не хочет отвечать.
В основном, уровни 2-3 - вендорские. Github Coding Agent, Anthropic managed/OpenAI cloud и т.д. Публичных кейсов на весь мир пара десятков, early stage adoption.
Экспериментов с открытыми моделями полно, но если быть честными - реальный код enterprise уровня на них редко пишут. Пока не видел, чтобы кто-то сделал полноценные командные процессы разработки с ними. Наверняка уже есть у китайцев, но я их рынок не ресерчил.
В России же ситуация, я думаю, понятная. Легально работать с передовыми агентами не получится. До решения проблем командного runtime массово никто не дошел, насколько я знаю. Запуск агентов в докерах = да, но это не про командную работу, а про изоляцию.
У меня пока есть 2 кейса с большими российскими корпами, где я внедрял уровни 1-2, но оба = "частные" инициативы в рамках 1 направления, пускай и спущенные сверху. Они даже внутри компании особо не афишируют, на чем и как они работают.
Самые успешные кейсы - небольшие гибкие международные команды, в которых технические лидеры уже давно используют агенты на уровне 0 и сами дошли до узких мест с персональным использованием. С ними и получаются "волшебные" иксы в time-2-market, пока в классических командах до сих пор не уверены, можно ли улучшиться хотя бы на 10%.
Я тоже изобретал этот велосипед с нуля. Ничего вменяемого не нашел, но это нормально, учитывая что почти вся инфра для агентов сейчас вращается вокруг соло-разработки.
С чего оказалось полезно начать: 1. анализа данных из хуков (вызов тулов/компакта/сабагентов) 2. ручного ретро-анализа сессий по факту кривых комитов (в клоде). 3. "когда какие скиллы вызывались, для чего", "когда какие сабагеты вызывались, для чего, сколько токенов сожрали"
Неспецифичные метрики (plan_before_write, tests_after_write, review_after_finish) оказались почти бесполезны.
Полезными оказались структурированные деревья метрик по специфичным скиллам. Например, метрики по кастомному аналогу superpowers - иновукился ли скилл вообще, были ли ревью спеки с x, y, z, были ли проверены выводы ревью-сабагентов перед правками, сколько итераций ревью проведено и сколько блокеров найдено, записаны ли follow-ups, записаны ли issues итд.
Честная рекомендация: начните с ручного анализа сессий. Поймете где болит конкретно у вас в сравнении с воркфлоу, который вы ожидали увидеть. Далее тестируйте метрики на своих и чужих транскриптах, чтобы понять что хорошо, что плохо.
А далее уже метрики -> оценка более умной моделью по чеклисту с подсветкой проблемных мест, дешборды, нотификации себе и самому разрабу и т.д.
"Кто и сколько токенов потратил" позволяет судить только о том, применяет ли человек ИИ вообще, но ничего не говорит об эффективности применения. Человек может успешно сжигать больше всех токенов, но при этом наносить больше всего вреда (или сжигать токены на личные проекты).
"Соц.опросы" - это совсем плохо. Люди врут, додумывают, заблуждаются. Я использую такие штуки для проведения 1-1 и "психотерапии", но никак не для оценки работы с агентами.
Если приходится спрашивать у человека даже какие модели он использовал - у меня плохие новости, это значит что работа с агентами в команде не контролируется и не управляется вообще никак.
Я раделяю метрики на метрики глубины внедрения ИИ в процесс человека, метрики работы человеком по процессу и метрики успеха ИИ и качество архитектуры/кода.
Глубина внедрения = это те самые токены, типы/число взаимодействий и итераций (hooks дергает нужные ручки, собирающие стату и метаданные), объемы диффов, объемы артефактов-документов и т.д. Эти метрики говорят лишь о том, начал ли разраб использовать ИИ, но никак не говорят о том, насколько эффективно и для чего.
Метрики работы человеком по процессу = у меня есть автоматизированное ревью агентских сессий - насколько соблюдались командные правила работы с агентами, как использовались командные плагины, были ли применены/нарушены ключевые паттерны и т.д. В моих командах автоматически это делается у новичков. Ручной запуск одной кнопкой при неудачных PR, ломающих правила и архитектуру (проверки агентами на уровне CI по архитектурным докам и правилам с разных углов + прохождение ревьювером), при инцидентах. Но даже на вроде бы уже "наученнных" людях - при случайной проверке иногда выявляется дичь, от которой волосы дыбом.
Метрики успеха ИИ - не число измененных строк в диффе, а число успехов/неудач в прохождении CI, ревью агентами в CI и людьми, диффы дополнительных ПРАВОК после коммита/PR и т.д.
Мне кажется, главный вопрос не в том, брать ли issue/PR, а в том, как из этого сделать нормальную обучающую траекторию. PR может чинить сразу несколько вещей, issue уже может содержать решение, тесты бывают плохими, патч может проходить CI и всё равно быть нерабочим (классика для тестов, написанных агентами).
В идеале нужно учесть, где модель нашла проблему, какие гипотезы отбросила, какой дифф сделала, чем проверила, и почему альтернативные патчи хуже. Иначе есть риск обучить модель красиво объяснять дифф вместо повышения качества кода
Недавно делали похожую штуку для азиатского маркетплейса.
Какая у вас получилась зависимость эффекта от популярности префикса? У нас на топовых запросах эффект был в разы меньше, чем на редких
Пробовали ли вшивать ранжирующий сигнал в саму модель? Что-то типа reward-weighted preference у OneSug https://ojs.aaai.org/index.php/AAAI/article/view/38497 . Ордера/корзина/клики итд превращаются в списки предпочтений, далее модель дообучается через DPO, чтобы показывать не только самые релевантные подсказки, но и самые конверсионные в целевое действие.
По сути вы описываете почти дефолтный стек claude code с доменными хуками и своим набором инструментов. Те же skill.md, rules, hooks итд.
«Соберет ли бот прямо сейчас» в CI - хороший смоук, но как метрика качества это успех с одной попытки (пасс@1).
А у агентов основная боль не «может ли в принципе», а консистентность: тот же tau-bench честно меряют по пасс@1, и как только начинаешь гонять одну и ту же задачу несколько раз, цифры сыпятся - агент то проходит, то нет на ровном месте, плюс галлюцинации фактов, лишние повторные вызовы инструментов, нарушение собственных инструкций. Один зелёный прогон почти ни о чём не говорит, нужно гонять задачу k раз и смотреть пасс*k — долю, где прошли ВСЕ k.
И второй момент: llm-судья как оценщик сам нестабилен. Даже топовые модели в роли судьи меняют вердикт примерно на 1/4 сложных кейсов, чувствительны к длине ответа и порядку вариантов. судью стоит хотя бы калибровать на размеченном наборе, иначе вы меряете не качество бота, а настроение судьи.
Привет от экс-коллеги :) Эффекты прям жирные. А какие были контрольные группы? Сравнивали с теми, кто перс.предложение не получал? Это именно доп.эффекты, очищенные от того, что и так бы купили?
Диагноз правильный, а вот советы... Какая-то утопия. Тем более, если говорить про РФ.
возобновите набор младших инженеров прямо сейчас. Старшие инженеры 2031 года будут наняты в 2026 году
В РФ половина ИТ-спецов меняет работу каждые 2 года: пруф. Джуны меняют работу за полгода: пруф. В мире постабильнее, но не сильно (если берем запад, а не Китай и Японию). Кому выгодно за свои деньги учить, чтобы через 5 лет хорошо стало кому-то другому? Каков шанс что джун, в которого инвестируют сейчас, останется и будет перфомить Старшим инженером в компании через 5 лет? - очень маленький. Оно того не стоит. Даже FAANG уже перестает так делать.
Остальные советы туда же, чистый идеализм. Так рыночная экономика не работает.
Сегодняшним джунам вижу 2 реалистичных варианта:
Пробиваться в компании через знакомых и растить личный нетворк, чтобы эти знакомые появлялись
Делать полезные пет-проекты и учиться на них, выкладывать в опен сурс, активно участвовать в комьюнити, светить свои проекты, растить упоминаемость себя и своих проектов
Даже если нет знакомых, можно выехать в миддлы за счет пет-проектов. Ведь корпоративный опыт тоже много где начинает значить меньше.
В мире, где ИИ-агенты пишут код, значимость приобретают 3 вещи:
Систем дизайн, нарабатывающийся ТОЛЬКО опытом ошибок и полетов на разных проектах, с реальными пользователями
Софт-скиллы, умение продать себя и выстроить коммуникацию
Я не спорю с тем, что у Cursor есть подписка. Это не опровергает тезис.
Вопрос не "есть ли подписка у Composer", а какая эффективная "цена за задачу."
В статье Composer сравнивают с API-ценой Opus, "$7 за задачу". Реальный кодер на Opus покупает не API, а подписку Anthropic. Тогда та же задача будет стоить не $7, а на порядок (в 20-40 раз) дешевле.
Cursor Pro/Ultra - это не то же самое. Ультра за $200 обычно это $400 в API, а не $5-10k эквивалента в API как у Антропика/ОпенАИ.
Конечно, у Композера в подписке Курсора довольно высокие лимиты, т.к. это собственная модель. Но и сранивать тогда надо Композер в подписке Курсора vs Опус в подписке Антропика, а не Композер (который существует только внутри Курсора) vs публичная цена API Опуса.
Сам Codex тоже написан на Rust, в то время как Claude Code - все еще помойка из ноды и терминального реакта.
За это я давал и буду давать много шансов Codex.
Но к сожалению, они все еще не могут стабилизировать работу сабагентов и многие другие вещи. Моя Issue у них на гитхабе открыта с 24 апреля, продолжает пополняться жалобами, но у них их >4 тысячи открытых...
Если сравнивать честно, то нужно не с ценой API Opus, а с ценой Opus в подписке.
Тогда приведенный пример "задачи на Opus" на тарифе за $200 будет не $7, а дешевле в 20-40 раз, то есть 15-30 центов. И Composer уже не выигрывает. Особенно если учесть, что Cursor CLI отстает от Claude Code по UX очень значительно. У меня кровь из глаз текла при попытке им пользоваться в tmux.
Когда лимиты на подписках Anthropic/OpenAI зарежут, или подписки отменят, может быть другой разговор. Но есть высокий шанс, что в это время какой-нибудь GPT-6-codex тоже будет еще более узко специализирован на коде, и за счет этого станет кратно дешевле обычной версии.
Учитывая, что подписки глубоко убыточны, все будут оптимизировать косты. У моделей Cursor/Composer не очень высокие шансы лидировать в гонке, т.к. у Anysphere пока что на порядок меньше денег, чем у Anthropic/OpenAI.
С самого начала никто не скрывал, что подписки - глубоко субсидируемая маркетинговая история, пока важно показывать улетающую в небо кривую прироста пользователей. Вендоры точно будут:
резать лимиты
повышать стоимость подписок
вводить новые ограничения
строже банить за нарушение правил и автоматизацию
мотивировать переходить на плату за API разными методами
Лучше планировать годовые бюджеты по стоимости API, пока удается сэкономить - радоваться.
Claude на подписках давно отдает в клиент "стоимость" по ценам API. Судя по тому, что я вижу, утыкаясь в лимиты Макса за $200, по факту легко сжигаешь $4-10k.
Информация
В рейтинге
6 049-й
Зарегистрирован
Активность
Специализация
Директор по продукту, Директор по информационным технологиям
Согласен с главным тезисом: токены, DAU и сам факт внедрения не доказывают ценность.
Единственное, насчет saved time с агентами в первые месяцы после внедрения я бы был осторожен.
Часто вижу у команд, которые только внедряют ИИ-агентов и не понимают их ограничений: saved time космическая, задача заняла 1 день вместо 2 недель, покрытие тестами 146%, разумеется все зеленые. Ревью прошла. Через месяц оказывается, что была допущена тупая архитектурная ошибка, которая людям даже в голову не могла прийти, из-за которой нужно рефакторить не только эту задачу, но и весь код написанный после.
У Amplified недавно как раз опубликовался кейс с выводом, что эффект возможен за 1.5 секунды внимания, если distinctive brand assets поставлены правильно. То есть не "ускорили баннер и победили", а заранее проверили, что баннер распознается за один взгляд
Когда рекламу смотрят полторы секунды, выигрывает тот, кого успели узнать без чтения :)
Хук я бы чуть поправил. run_bot_tests.py при падении pytest печатает в stderr и делает
sys.exit(0). Т.е. PostToolUse делает "увидел ошибку - попробовал починить". Но tool call уже прошел, файл уже изменен.exit 2у PostToolUse не откатывает действие, а только скармливает ошибку обратно Клоду. Если нужна именно защита от мусорного результата, ее надо вешать на Stop/TaskCompleted или тащить в pre-commit/CI.Хорошая статья как ликбез, но я бы немного сместил акценты.
Ключевая проблема не в том, что агенту надо "объяснить" Zero Trust. Агент вообще не должен быть местом, где принимаются security decisions. Его надо считать недоверенным клиентом.
Главная граница - не промпт, а вызов инструмента. Всё опасное происходит в моменте: какой user запустил агента, какой tool вызывается, с какими аргументами, к каким данным/секретам/эндпоинтам он получает доступ, есть ли approval, можно ли сделать это действие в текущем ворклфлоу.
Поэтому allowlist в системном промпте, "будь осторожен" и описания tools - это не контроль, а подсказки для модели. Контроль начинается там, где перед каждым tool call стоит внешний слой авторизации (policy gateway / PEP-PDP / OPA / Cedar / ...). Важно, что решение принимает не модель.
То же самое с runtime и MCP. Контейнер сам по себе не делает агента безопасным, если внутри широкий доступ к фс, сети и секретам. MCP сервер тоже нельзя просто "подключить и доверять": дескрипторы, версии и права должны быть зафиксированы и проверяемы, иначе tool poisoning и silent update превращаются в supply-chain проблему.
Для меня формула такая: агент = untrusted client, тулы = protected backend, policy gateway = enforcement point.
Тогда прмопт-инъекция остается атакой на намерение агента, но не становится прямым доступом к инфраструктуре.
Попытки создавать самообновляемые вики/доки/скиллы по проектам начались еще до эры GPT 3.5. Но через N месяцев независимо от "мозгов" моделей всегда оказывается, что эту самообновляемую вики проще выкинуть, чем рефакторить, и она скорее вредна для агентов, чем полезна. Даже если был обвес из метрик и множества авто-CI-этапов.
Правила = артефакт архитектуры и процессов, влияющий на всю дальнейшую траекторию разработки. На мой взгляд, это не то, что имеет смысл доверять агентам, даже если это какие-то "вторичные" инструкции.
Вот как это организовано у меня (то есть в командах, куда я внедрил разработку на агентах):
Для каждого проекта (сервиса) есть плагины со скиллами. Проектные плагины, доменные, процессные. В одном плагине может быть от одного до несколько десятков скиллов про работу с отдельными независимыми компонентами проекта, внешними API, тулами и т.д.
Плагины в отдельных репо. Перед запуском сессий обертка над агентами проверяет их актуальность и обновляет.
Скиллы аккуратно разбиты на references под тот самый "progressive disclosure".
Потенциальные изменения в "правила" может составлять человек с агентом или без (как угодно). Агент может помогать человеку собирать наблюдения, предлагать изменения.
Ревью и обновление скиллов с "правилами" идет всегда через людей-владельцев процесса. Агент не может сам обновлять main плагинов (откуда их забирают агенты), максимум - создать PR в репо плагинов со скиллами.
Число правил на проекте зависит не от количества строк кода, а от качества архитектуры и количества внешних зависимостей. Качественная архитектура и хорошо написанные доки (доки пишут и ревьювят агенты и люди как код) уменьшают число необходимых правил.
Наиболее жирные правила у меня в командах, работающих над древними legacy, где очень плохая неочевидная архитектура и приходится компенсировать правилами.
Для сравнения:
проект с чистой архитектурой на 440к строк кода = 8кб плагин со всеми проектными правилами и доп.индексами по докам (считая только md, не считая отдельный процессный командный плагин и скиллы по внешним API внутри самого проекта)
legacy на 290к строк кода = 610кб md в скиллах (там альтернативная версия доков по проекту, т.к. старые выкидывать пока не решились)
Чуть-чуть устаревшие данные. Многие штуки уже стали документированными, а какие-то поменяли формат - лучше сверяться с актуальной документацией.
Примеры:
у
PreToolUseновый формат, черезhookSpecificOutputсhookEventNameрезультат тула теперь
updatedToolOutput,updatedMCPToolOutputоставлен только для MCPonce: trueработает только в хуках из frontmatter скилла, в frontmatter самого агента игнорируетсяwatchPathsждёт абсолютные пути, а не package.json из текущей папки.asyncуже документирован. Я его взял еще в феврале-марте из issues и широко использую а) для логирования б) для сбора метрик использования по командам.PreToolUseсdenyя использую еще с осени прошлого года, а вот проadditionalContextне знал, спасибо. В Codex кстатиPreToolUseнормально появился только в апреле...Недокументированные механики могут появиться сегодня и сломаться уже завтра.
Лучше использовать их только с целью ресерча, ни в коем случае не в рабочем коде.
Предполагаю, что под проблемой имеется в виду присутствие доступа, а не отсутствие.
Короткий ответ для ОС-изоляции - firewall/nftables/iptables по UID.
Доменные вайтлисты можно делать на уровне egress-proxy, а там уже правила и лимиты. Так проще с плавающими IP у CDN'ов. Для установок на РФ-сервера, egress-proxy еще решает вопрос правильного исходящего IP.
Для npm, pypi итп можно использовать зеркала/кеши, чтобы не нужен был весь интернет для зависимостей.
Могут быть переключаемые "строгий" и "мягкий" режимы. Мягкий = когда нужно дать агенту возможность гуглить, фетчить, ресерчить самостоятельно. У меня есть кастомный cli-тул, который выполняет ресерч (и подобные задачи) в headless-claude в отдельном контейнере и возвращает результаты в голых md, соответственно для этого мне "мягкий" режим не нужен. Но это уже усложнение, тогда можно задуматься и о запуске обычных сессий в контейнерах.
В строгом режиме, агенту разрешены DNS, egress-proxy, относительно доверенные url (напр. опенаи/антропик репо) и нужные внутренние эндпоинты. Всё остальное - deny по умолчанию.
Лимитированные/чувствительные API через прокладки, в которых логи, управление ключами/токенами, лимиты/квоты.
Но, если вы уже на уровне, где нужно строго резать сеть, возможно лучше сразу делать на rootless-контейнерах. Особенно если проектов несколько и для каждого свои правила.
ОС-изоляция скорее вариант для быстрого начала работы, либо когда рисками можно пренебречь.
В плане командной работы с агентами для разработки рынок на самой зачаточной стадии.
Пока адопшн вращается вокруг персонального использования.
Компании раздают подписки, но не слишком управляют тем, как они используются. Есть аудит (логи) в корп.подписках = уже хорошо.
Самодельные уровни 2-3 пока существует как "частные" инициативы в крупных компаниях, публично это не анонсируют. Иначе сразу начнутся вопросы по работе с "чувствительными данными", на которые никто лишний раз не хочет отвечать.
В основном, уровни 2-3 - вендорские. Github Coding Agent, Anthropic managed/OpenAI cloud и т.д. Публичных кейсов на весь мир пара десятков, early stage adoption.
Экспериментов с открытыми моделями полно, но если быть честными - реальный код enterprise уровня на них редко пишут. Пока не видел, чтобы кто-то сделал полноценные командные процессы разработки с ними. Наверняка уже есть у китайцев, но я их рынок не ресерчил.
В России же ситуация, я думаю, понятная. Легально работать с передовыми агентами не получится. До решения проблем командного runtime массово никто не дошел, насколько я знаю. Запуск агентов в докерах = да, но это не про командную работу, а про изоляцию.
У меня пока есть 2 кейса с большими российскими корпами, где я внедрял уровни 1-2, но оба = "частные" инициативы в рамках 1 направления, пускай и спущенные сверху. Они даже внутри компании особо не афишируют, на чем и как они работают.
Самые успешные кейсы - небольшие гибкие международные команды, в которых технические лидеры уже давно используют агенты на уровне 0 и сами дошли до узких мест с персональным использованием. С ними и получаются "волшебные" иксы в time-2-market, пока в классических командах до сих пор не уверены, можно ли улучшиться хотя бы на 10%.
Я тоже изобретал этот велосипед с нуля. Ничего вменяемого не нашел, но это нормально, учитывая что почти вся инфра для агентов сейчас вращается вокруг соло-разработки.
С чего оказалось полезно начать:
1. анализа данных из хуков (вызов тулов/компакта/сабагентов)
2. ручного ретро-анализа сессий по факту кривых комитов (в клоде).
3. "когда какие скиллы вызывались, для чего", "когда какие сабагеты вызывались, для чего, сколько токенов сожрали"
Неспецифичные метрики (plan_before_write, tests_after_write, review_after_finish) оказались почти бесполезны.
Полезными оказались структурированные деревья метрик по специфичным скиллам. Например, метрики по кастомному аналогу superpowers - иновукился ли скилл вообще, были ли ревью спеки с x, y, z, были ли проверены выводы ревью-сабагентов перед правками, сколько итераций ревью проведено и сколько блокеров найдено, записаны ли follow-ups, записаны ли issues итд.
Честная рекомендация: начните с ручного анализа сессий. Поймете где болит конкретно у вас в сравнении с воркфлоу, который вы ожидали увидеть. Далее тестируйте метрики на своих и чужих транскриптах, чтобы понять что хорошо, что плохо.
А далее уже метрики -> оценка более умной моделью по чеклисту с подсветкой проблемных мест, дешборды, нотификации себе и самому разрабу и т.д.
"Кто и сколько токенов потратил" позволяет судить только о том, применяет ли человек ИИ вообще, но ничего не говорит об эффективности применения. Человек может успешно сжигать больше всех токенов, но при этом наносить больше всего вреда (или сжигать токены на личные проекты).
"Соц.опросы" - это совсем плохо. Люди врут, додумывают, заблуждаются. Я использую такие штуки для проведения 1-1 и "психотерапии", но никак не для оценки работы с агентами.
Если приходится спрашивать у человека даже какие модели он использовал - у меня плохие новости, это значит что работа с агентами в команде не контролируется и не управляется вообще никак.
Я раделяю метрики на метрики глубины внедрения ИИ в процесс человека, метрики работы человеком по процессу и метрики успеха ИИ и качество архитектуры/кода.
Глубина внедрения = это те самые токены, типы/число взаимодействий и итераций (hooks дергает нужные ручки, собирающие стату и метаданные), объемы диффов, объемы артефактов-документов и т.д. Эти метрики говорят лишь о том, начал ли разраб использовать ИИ, но никак не говорят о том, насколько эффективно и для чего.
Метрики работы человеком по процессу = у меня есть автоматизированное ревью агентских сессий - насколько соблюдались командные правила работы с агентами, как использовались командные плагины, были ли применены/нарушены ключевые паттерны и т.д. В моих командах автоматически это делается у новичков. Ручной запуск одной кнопкой при неудачных PR, ломающих правила и архитектуру (проверки агентами на уровне CI по архитектурным докам и правилам с разных углов + прохождение ревьювером), при инцидентах. Но даже на вроде бы уже "наученнных" людях - при случайной проверке иногда выявляется дичь, от которой волосы дыбом.
Метрики успеха ИИ - не число измененных строк в диффе, а число успехов/неудач в прохождении CI, ревью агентами в CI и людьми, диффы дополнительных ПРАВОК после коммита/PR и т.д.
Мне кажется, главный вопрос не в том, брать ли issue/PR, а в том, как из этого сделать нормальную обучающую траекторию. PR может чинить сразу несколько вещей, issue уже может содержать решение, тесты бывают плохими, патч может проходить CI и всё равно быть нерабочим (классика для тестов, написанных агентами).
В идеале нужно учесть, где модель нашла проблему, какие гипотезы отбросила, какой дифф сделала, чем проверила, и почему альтернативные патчи хуже. Иначе есть риск обучить модель красиво объяснять дифф вместо повышения качества кода
Недавно делали похожую штуку для азиатского маркетплейса.
Какая у вас получилась зависимость эффекта от популярности префикса? У нас на топовых запросах эффект был в разы меньше, чем на редких
Пробовали ли вшивать ранжирующий сигнал в саму модель? Что-то типа reward-weighted preference у OneSug https://ojs.aaai.org/index.php/AAAI/article/view/38497 . Ордера/корзина/клики итд превращаются в списки предпочтений, далее модель дообучается через DPO, чтобы показывать не только самые релевантные подсказки, но и самые конверсионные в целевое действие.
По сути вы описываете почти дефолтный стек claude code с доменными хуками и своим набором инструментов. Те же skill.md, rules, hooks итд.
«Соберет ли бот прямо сейчас» в CI - хороший смоук, но как метрика качества это успех с одной попытки (пасс@1).
А у агентов основная боль не «может ли в принципе», а консистентность: тот же tau-bench честно меряют по пасс@1, и как только начинаешь гонять одну и ту же задачу несколько раз, цифры сыпятся - агент то проходит, то нет на ровном месте, плюс галлюцинации фактов, лишние повторные вызовы инструментов, нарушение собственных инструкций. Один зелёный прогон почти ни о чём не говорит, нужно гонять задачу k раз и смотреть пасс*k — долю, где прошли ВСЕ k.
И второй момент: llm-судья как оценщик сам нестабилен. Даже топовые модели в роли судьи меняют вердикт примерно на 1/4 сложных кейсов, чувствительны к длине ответа и порядку вариантов. судью стоит хотя бы калибровать на размеченном наборе, иначе вы меряете не качество бота, а настроение судьи.
Привет от экс-коллеги :) Эффекты прям жирные.
А какие были контрольные группы? Сравнивали с теми, кто перс.предложение не получал?
Это именно доп.эффекты, очищенные от того, что и так бы купили?
Диагноз правильный, а вот советы... Какая-то утопия. Тем более, если говорить про РФ.
В РФ половина ИТ-спецов меняет работу каждые 2 года: пруф. Джуны меняют работу за полгода: пруф. В мире постабильнее, но не сильно (если берем запад, а не Китай и Японию). Кому выгодно за свои деньги учить, чтобы через 5 лет хорошо стало кому-то другому? Каков шанс что джун, в которого инвестируют сейчас, останется и будет перфомить Старшим инженером в компании через 5 лет?
- очень маленький. Оно того не стоит. Даже FAANG уже перестает так делать.
Остальные советы туда же, чистый идеализм.
Так рыночная экономика не работает.
Сегодняшним джунам вижу 2 реалистичных варианта:
Пробиваться в компании через знакомых и растить личный нетворк, чтобы эти знакомые появлялись
Делать полезные пет-проекты и учиться на них, выкладывать в опен сурс, активно участвовать в комьюнити, светить свои проекты, растить упоминаемость себя и своих проектов
Даже если нет знакомых, можно выехать в миддлы за счет пет-проектов. Ведь корпоративный опыт тоже много где начинает значить меньше.
В мире, где ИИ-агенты пишут код, значимость приобретают 3 вещи:
Систем дизайн, нарабатывающийся ТОЛЬКО опытом ошибок и полетов на разных проектах, с реальными пользователями
Софт-скиллы, умение продать себя и выстроить коммуникацию
Репутация, присутствие в гугле
Я не спорю с тем, что у Cursor есть подписка. Это не опровергает тезис.
Вопрос не "есть ли подписка у Composer", а какая эффективная "цена за задачу."
В статье Composer сравнивают с API-ценой Opus, "$7 за задачу".
Реальный кодер на Opus покупает не API, а подписку Anthropic. Тогда та же задача будет стоить не $7, а на порядок (в 20-40 раз) дешевле.
Cursor Pro/Ultra - это не то же самое. Ультра за $200 обычно это $400 в API, а не $5-10k эквивалента в API как у Антропика/ОпенАИ.
Конечно, у Композера в подписке Курсора довольно высокие лимиты, т.к. это собственная модель.
Но и сранивать тогда надо Композер в подписке Курсора vs Опус в подписке Антропика, а не Композер (который существует только внутри Курсора) vs публичная цена API Опуса.
Сам Codex тоже написан на Rust, в то время как Claude Code - все еще помойка из ноды и терминального реакта.
За это я давал и буду давать много шансов Codex.
Но к сожалению, они все еще не могут стабилизировать работу сабагентов и многие другие вещи. Моя Issue у них на гитхабе открыта с 24 апреля, продолжает пополняться жалобами, но у них их >4 тысячи открытых...
Если сравнивать честно, то нужно не с ценой API Opus, а с ценой Opus в подписке.
Тогда приведенный пример "задачи на Opus" на тарифе за $200 будет не $7, а дешевле в 20-40 раз, то есть 15-30 центов. И Composer уже не выигрывает.
Особенно если учесть, что Cursor CLI отстает от Claude Code по UX очень значительно. У меня кровь из глаз текла при попытке им пользоваться в tmux.
Когда лимиты на подписках Anthropic/OpenAI зарежут, или подписки отменят, может быть другой разговор. Но есть высокий шанс, что в это время какой-нибудь GPT-6-codex тоже будет еще более узко специализирован на коде, и за счет этого станет кратно дешевле обычной версии.
Учитывая, что подписки глубоко убыточны, все будут оптимизировать косты.
У моделей Cursor/Composer не очень высокие шансы лидировать в гонке, т.к. у Anysphere пока что на порядок меньше денег, чем у Anthropic/OpenAI.
С самого начала никто не скрывал, что подписки - глубоко субсидируемая маркетинговая история, пока важно показывать улетающую в небо кривую прироста пользователей. Вендоры точно будут:
резать лимиты
повышать стоимость подписок
вводить новые ограничения
строже банить за нарушение правил и автоматизацию
мотивировать переходить на плату за API разными методами
Лучше планировать годовые бюджеты по стоимости API, пока удается сэкономить - радоваться.
Claude на подписках давно отдает в клиент "стоимость" по ценам API.
Судя по тому, что я вижу, утыкаясь в лимиты Макса за $200, по факту легко сжигаешь $4-10k.