Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 20
В мире жЫвотных.
Наблюдать интересно, а пользы никакой.
Ещё музыка на заставке передачи красивая :)
А что для Вас было бы пользой?
ROI
Устойчивое развитие ©
Что-то хоть немного отличающееся от магии. Вероятность найти ошибку 2-3 сигма
Проще говоря, вы занимаетесь онан созданием лекарств с недоказанной эффективностью
Лекарства с недоказанной эффективностью - это когда публикуют только успешные результаты и прячут провалы. У меня заход 2 - опубликованный провал: миллион токенов, 22 агента, ложное одобрение кода с реальным багом. Фарма такое прячет, а я с этого начинаю аргументацию.
Про сигмы. Правило красивое, но оно работает для повторяемого процесса с нормальным распределением - диаметр детали на конвейере, толщина стенки. Баг в реальном проекте - это не деталь на конвейере. Каждое изменение в своём контексте, каждый баг уникален. Требовать 2-3 сигма на обнаружение бага - это примерно как требовать от хирурга гауссову гарантию на каждую операцию, когда тело каждый раз другое.
Что реально можно измерить, я измерил: точность на размеченной истине (заход 1, заранее заложенные баги и ловушки), поведение на боевом коде (заходы 2 и 3), стоимость в токенах и во времени, сравнение с контрольным методом - одиночным агентом на тех же файлах. ROI из статьи конкретный: workflow в 15 раз дороже и при этом пропускает баги, которые ловит один агент с доступом к проекту. Я не продаю чудо-таблетку, я опубликовал результаты реальных исследований и причин, к ним приводящим.
Но вот что было бы правда интересно: как вы предлагаете мерить эффективность код-ревью в сигмах? У меня не получается натянуть нормальное распределение на "нашёл баг / не нашёл" при уникальном коде каждый раз. В "доИИшные времена" мы у себя измеряли процент трудозатрат, который разработчик тратит на исправление ошибок относительно трудозатрат, которые тратит на создание фичи. При высоком проценте можно было говорить, что качественно делает или нет. С ИИ этот показатель, в целом, бесполезен. Можно токенами мерить, конечно. Но за счёт обвязки в контексте это будет сложно сравнимая вещь.
Если у Вас есть рабочий подход про измерение качества кода в сигмах - поделитесь, пожалуйста. Ибо это тема для отдельной статьи. Без шуток.
Многоагентный workflow имеет смысл, если цена ошибки выше цены токенов.
Многоагентный workflow имеет смысл, если задача выражена в строго понятных для конкретного агента шагах, с запасом умещающихся в контекст. Cемантичекое мышление - это брутфорс, жёсткий, пока что непреодолимый потолок ллмок на сегодня. Попробуйте сформировать гипотезу из, не знаю, трёх предложений, и заставьте модные ллм, какой-нибудь gemini pro формально размышлять об этом. Они скатываются в бред уровня chatgpt 2.
Мне нравится ваш эксперимент, я бы его даже усилил. Дайте эту гипотезу из трёх предложений gemini pro, а потом спросите: "какой результат я получу, если проведу этот эксперимент?" Модель уверенно выдаст красивый прогноз и промахнётся. У неё же нет данных, только слова. Это мой заход 2 в миниатюре - 22 агента уверенно одобрили код с багом, потому что в их контексте не лежал файл с доказательством.
При этом то, что вы называете "непреодолимый потолок", мы видели буквально, руками. Агент-верификатор поймал правильную находку, полез искать подтверждение, не нашёл в своём куцем наборе файлов - и выкинул её. Я на заходе 3 дал тому же workflow весь проект, он нашёл гонку данных, которую одиночный агент пропустил. Тот же код, те же промпты. Другой контекст - другой результат.
Потолок есть, кто ж спорит. Но мне кажется, он не там, где вы его рисуете. Мы суём модели выжимку и удивляемся, что на выходе тоже выжимка. У меня главный вынос из всех трёх заходов: модели не надо "думать глубже", ей надо видеть конкретную строку в конкретном файле. Сравнить "тут processing, а тут running, они не совпадают" она может прекрасно. Угадать, что в невидимом файле написано processing вместо running - нет. Это не потолок мышления, это отсутствие входных данных.
Расскажете, что за гипотеза из трёх предложений? Интересно разобрать на ней: в какой формулировке модель сломается, а в какой вытянет. Подозреваю, граница пройдёт ровно по количеству конкретных фактов в этих предложениях.
Ваши ответы в комментариях выглядят как ответы ллм. Ладно уж, поговорю с ботом: уже не могу поделиться гипотезой, потому что она стала теоремой вчера. Чуть ли не бегал от счастья.
Если не понимаете теорию, то просто проведите эксперимент: возьмите какую угодно непопулярную гипотезу и попробуйте формально доказать с ллм. Они просто не могут логически рассуждать, очевидно же
Мы пробовали двухагентный ревью на TS-миграции: один пишет, второй проверяет допущения. Нашёл пару незаметных edge cases, но шума было раза в три больше реальных проблем. Вывод про «цена ошибки > цена токенов» точный, у нас примерно так и работало. Один момент который добавил: без human gate workflow уходит в самосогласование, агенты начинают закрывать находки друг друга. Нужен явный скептик.
условный кодеребит отлично даже на фри тарифе проверяет кстати, можно использовать как дополнительный источник идей и советов при ревью когда. сам агент его в терминале может запускать.
Два момента хочу отметить.
CodeRabbit как внешний взгляд - да, рабочая штука, грех не подключить, если бесплатно. Единственное, что я бы проверил: насколько его находки пересекаются с тем, что ловит ваш основной процесс. Если 80% дублей - это красивый отчёт поверх того же самого. А вот если он стабильно цепляет класс проблем, который ваш агент пропускает - тогда это уже реальное усиление, а не утешительный второй взгляд.
Второй момент. По нашему опыту, все-таки лучше использовать двух разных агентов, причем с разными моделями. Они действительно по-разному смотрят. Мы сейчас в основной пайплайн включаем обязательное ревью Codex кода, написанного через Claude Code, и наоборот.
Про пересечение замечаний точно, это и есть правильный критерий. Если 80% дублей, второй взгляд не усиливает, только замедляет. Codex на Claude Code не пробовал, но идея понятна: разные базы обучения, разные слепые пятна. Один вопрос: при конфликтующих ревью кто побеждает, или это повод задать вопрос автору?
По нашим экспериментам, Claude больше смотрит вглубь, а Codex больше смотрит вширь. То есть один и тот же инцидент Claude разбирает в стиле: «Вот смотри, вот здесь на этой строке произошла ошибка, поэтому кейс твой не сработал». А Codex разбирает в стиле: «Вот смотри, здесь слишком мало источников, поэтому ты ничего не видишь». Примерно такая разница.
При конфликтующих ревью мы сталкиваем агентов лбами. Происходит это так: одному агенту пишем сообщение: «Вот посмотри, другой эксперт сделал такой вывод про этот баг. Сравни со своим анализом, напиши, с чем ты согласен, а с чем не согласен. Добавь аргументацию». Эту аргументацию перекидываем агенту, который ранее проводил ревью. Таким образом приходим обычно или к консенсусу, или же остается какое-то разногласие, которое нам приходится решать уже человеческим мозгом. Но оно 100% лежит не на уровне кода — это скорее разногласие в понимании, а значит, повод поработать с требованиями и постановками.
У нас та же картина с Claude и GPT-4: Claude находит «вот здесь строка упадёт при null», GPT-4 говорит «вот здесь слабое место по архитектуре». Приём со столкновением агентов возьму в работу, у нас пока второй взгляд это ручной второй чат. Вопрос: финальное решение при разногласии всегда человеческое или бывает что вес аргументации одной стороны явно перевешивает?
Пробовал CodeRabbit на нескольких проектах. Основная проблема: он не знает ваш контекст, нашу архитектуру, наши паттерны, почему именно так написали. Комментирует по общим правилам и часто то что уже обсуждено и принято намеренно. Как первый взгляд со стороны полезно, но 60-70% его замечаний у нас были шум.
Про самосогласование - Вы одним словом назвали то, что у нас в статье занимает целый раздел. На втором заходе один из 22 агентов нашёл реальный баг, поднял его как блокер, а верификатор полез искать подтверждение, не нашёл в своём куцем наборе файлов и тихо закрыл. Никакого спора не было - была коллективная вежливость, которая привела к ложному одобрению.
Мы это чинили не столько человеческим гейтом (он у нас в NaCl и так стоит на принципиальных решениях), сколько переворотом логики верификации - и именно переворот сработал! Раньше скептик работал по принципу "не нашёл подтверждения - отклоняю находку". Мы заставили его доказывать, что находка ложная, а если доказать не может - находка живёт. На неполном контексте разница колоссальная, потому что "не вижу подтверждения" при куцем наборе файлов не значит вообще ничего.
Соотношение шума 3:1 на TS-миграции похоже на наш первый сырой прогон (26 находок, две трети мусор). Мы сузили фокус ревьюеров и добавили дедупликацию по корневым причинам вместо симптомов - стало терпимо, хотя до идеала далеко.
А какой размер миграции был? И скептик у вас отдельным агентом работал или был встроен в логику второго?
Нейминг, конечно, так себе, для вашего фреймворка. NaCl, хоть и задеприкейченная технология из мира Хрома, но всё-таки, достаточно известная.
Ну, здравствуй, брат-динозавр, который тоже запускал C++ в Chrome! :)) Не обижайтесь на фривольный тон - я с гугловским NaCl повозился в своё время, пощупал, почесал репу и ушёл обратно в asm.js, потому что идея красивая, а тулчейн больной. Да и потом пришёл WebAssembly и уже закрыл тему для всех.
А с названием у нас другая история. У нас компания называется "ITSalt", и когда придумывали имя для фреймворка, пошли от химии: NaCl - это формула поваренной соли, то есть буквально то, из чего наша соль состоит. У NaCl кристаллическая решётка - жёсткая, регулярная структура, которая держит форму. Фреймворк ровно это и делает - задаёт решётку, по которой агенты работают, а не импровизируют. Без решётки получается аморфная каша, что мы, собственно, и показали на заходе 2, когда workflow без правильных ограничений одобрил код с багом. :)
Так что совпадение с гугловским NaCl случайное, но ироничное - оба проекта про то, как заставить код работать в песочнице с ограничениями. Только Гугл стюардессу таки закопал, а наша всё хорошеет и хорошеет :)
Family Cinema - https://claude.ai/chat/TODO_ССЫЛКА_FAMILY_CINEMA
Предлагаю добавить в ваш воркфлоу новый скилл который будет валидировать публикации, особенно ссылки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мы попробовали в реальном проекте Dynamic Workflows от Claude Code. Рассказываю, что сработало, а что нет