У нас отдельная группа скиллов работает именно с графом. Есть скилл intake, который разбирает обращение и определяет - это бага или новая фича. На основе данных графа. Дальше есть скилл fix, который первым делом определяет, что нужно поправить в графе (если нужно). И вносит в план наряду с кодом. Ну и скилл feature - он вносит обновления в граф в соответствии с требованиями фичи, потом уже скилл plan планирует технические задачи на разработку.
Можно. Отправьте скиллу задачу из серии "напиши промпт, работая по которому агент будет задавать пользователю вопросы. Его цель - выяснить.... Он уже должен знать .....". После этого, отправив получившийся промпт первым сообщением, получите необходимый режим вопросов.
Да, Вы правы! Внятный образ результата - это больше половины решённой задачи. Но у меня не всегда бывают только такие. Например, когда я брался за придумывание программы для детей в лагере, то у меня не было точного образа. Я мог сказать, что хочу, чего не хочу, какие будут условия - по сути, задать контекст, но не образ результата. И задачей ИИ было как раз предложить 3 разнообразные программы. Без промпта, который мне выдал скилл, у меня не получалось ничего внятного. Промпт со скилом - и я кайфанул от двух вариантов из трёх!
"Правильно" - это понятие субъективное. Мне важно, чтобы когда я прошу "оригинальную идею", то идея была бы действительно оригинальной. Мой скилл позволяет этого добиться быстрее, чем без него :)
Я с Вами полностью согласен, если речь идёт о разработке. Собственно, весь наш фреймворк ровно на это и работает. Но в статье речь идёт о промтах, которые не связаны с разработкой. Или длительными процессами как таковыми.
"Придумай сценарий игры для детей 10-13 лет на острове", "напиши метафорический сценарий для рилс на тему бытовухи", "придумай небанальное поздравление на 50-летний юбилей свадьбы", "напиши промпт для генерации изображения вот в таком-то стиле" - если делать такие промпты "в лоб", получается банальная фигня. Наш скилл как раз добавляет контекста, словесной обвязки и задаёт "правила качественного ответа". И результат получается на порядок лучше.
Промпт "в лоб"
Изготовление промпта
Поздравление на основе промпта, составленного скилом
На мой взгляд, гораздо качественнее. А если дать ещё больше контектса, будет ещё интереснее.
Что может быть Harness для таких промптов, кроме самого промпта?
Интересно, спасибо! Мы не пробовали в claude.md класть такие штуки, стараемся его держать очень кратким, давать в нём много ссылок. Но у нас вся спека - в графе. Поэтому у нас там, скорее, именно инструкции, как что делать по методологии.
По нашим опытам "положительное подкрепление" работает ощутимо лучше, чем "отрицательный пример". Мне кажется (непроверенная гипотеза :) ), что тут срабатывает ассоциативность. LLM проще находить близконаправленные вектора, чем "отталкиваясь от запрета предлжить вариант". Всё как в жизни - запрет создаёт дырку, а не повышает вариативность
Поэтому мы не учим, а просто собрали скилл, который всё это сам делает :)
А с другой стороны, возьмите любую тему и посмотрите, сколько на неё всего и вся. Начиная от того, "как выровнять div по высоте" и заканчивая "как управлять проектами". Это наша реальность, которая меняется с такой скоростью, что приходится постоянно искать новые, более оптимальные подходы. Не готов сказать, что мне это очень нравится. Я, честно говоря, подустал постоянно учиться. Но другого шанса не пополнить ряды "винтажных парогенераторов" я не вижу.
:) Нет, "гаечки" - это валюта лагеря. Дети, помогая взрослым, зарабатывают гаечки и в предпоследний день на аукционе можно купить за них всяких ништяков, типа "посидеть со взрослыми у костра после отбоя" или "катание на плечах самого высокого папы" :)
Мне было важно, чтобы в игре у детей тоже был шанс заработать гаечки
По нашим экспериментам, Claude больше смотрит вглубь, а Codex больше смотрит вширь. То есть один и тот же инцидент Claude разбирает в стиле: «Вот смотри, вот здесь на этой строке произошла ошибка, поэтому кейс твой не сработал». А Codex разбирает в стиле: «Вот смотри, здесь слишком мало источников, поэтому ты ничего не видишь». Примерно такая разница.
При конфликтующих ревью мы сталкиваем агентов лбами. Происходит это так: одному агенту пишем сообщение: «Вот посмотри, другой эксперт сделал такой вывод про этот баг. Сравни со своим анализом, напиши, с чем ты согласен, а с чем не согласен. Добавь аргументацию». Эту аргументацию перекидываем агенту, который ранее проводил ревью. Таким образом приходим обычно или к консенсусу, или же остается какое-то разногласие, которое нам приходится решать уже человеческим мозгом. Но оно 100% лежит не на уровне кода — это скорее разногласие в понимании, а значит, повод поработать с требованиями и постановками.
Лекарства с недоказанной эффективностью - это когда публикуют только успешные результаты и прячут провалы. У меня заход 2 - опубликованный провал: миллион токенов, 22 агента, ложное одобрение кода с реальным багом. Фарма такое прячет, а я с этого начинаю аргументацию.
Про сигмы. Правило красивое, но оно работает для повторяемого процесса с нормальным распределением - диаметр детали на конвейере, толщина стенки. Баг в реальном проекте - это не деталь на конвейере. Каждое изменение в своём контексте, каждый баг уникален. Требовать 2-3 сигма на обнаружение бага - это примерно как требовать от хирурга гауссову гарантию на каждую операцию, когда тело каждый раз другое.
Что реально можно измерить, я измерил: точность на размеченной истине (заход 1, заранее заложенные баги и ловушки), поведение на боевом коде (заходы 2 и 3), стоимость в токенах и во времени, сравнение с контрольным методом - одиночным агентом на тех же файлах. ROI из статьи конкретный: workflow в 15 раз дороже и при этом пропускает баги, которые ловит один агент с доступом к проекту. Я не продаю чудо-таблетку, я опубликовал результаты реальных исследований и причин, к ним приводящим.
Но вот что было бы правда интересно: как вы предлагаете мерить эффективность код-ревью в сигмах? У меня не получается натянуть нормальное распределение на "нашёл баг / не нашёл" при уникальном коде каждый раз. В "доИИшные времена" мы у себя измеряли процент трудозатрат, который разработчик тратит на исправление ошибок относительно трудозатрат, которые тратит на создание фичи. При высоком проценте можно было говорить, что качественно делает или нет. С ИИ этот показатель, в целом, бесполезен. Можно токенами мерить, конечно. Но за счёт обвязки в контексте это будет сложно сравнимая вещь.
Если у Вас есть рабочий подход про измерение качества кода в сигмах - поделитесь, пожалуйста. Ибо это тема для отдельной статьи. Без шуток.
Ну, здравствуй, брат-динозавр, который тоже запускал C++ в Chrome! :)) Не обижайтесь на фривольный тон - я с гугловским NaCl повозился в своё время, пощупал, почесал репу и ушёл обратно в asm.js, потому что идея красивая, а тулчейн больной. Да и потом пришёл WebAssembly и уже закрыл тему для всех.
А с названием у нас другая история. У нас компания называется "ITSalt", и когда придумывали имя для фреймворка, пошли от химии: NaCl - это формула поваренной соли, то есть буквально то, из чего наша соль состоит. У NaCl кристаллическая решётка - жёсткая, регулярная структура, которая держит форму. Фреймворк ровно это и делает - задаёт решётку, по которой агенты работают, а не импровизируют. Без решётки получается аморфная каша, что мы, собственно, и показали на заходе 2, когда workflow без правильных ограничений одобрил код с багом. :)
Так что совпадение с гугловским NaCl случайное, но ироничное - оба проекта про то, как заставить код работать в песочнице с ограничениями. Только Гугл стюардессу таки закопал, а наша всё хорошеет и хорошеет :)
CodeRabbit как внешний взгляд - да, рабочая штука, грех не подключить, если бесплатно. Единственное, что я бы проверил: насколько его находки пересекаются с тем, что ловит ваш основной процесс. Если 80% дублей - это красивый отчёт поверх того же самого. А вот если он стабильно цепляет класс проблем, который ваш агент пропускает - тогда это уже реальное усиление, а не утешительный второй взгляд.
Второй момент. По нашему опыту, все-таки лучше использовать двух разных агентов, причем с разными моделями. Они действительно по-разному смотрят. Мы сейчас в основной пайплайн включаем обязательное ревью Codex кода, написанного через Claude Code, и наоборот.
Про самосогласование - Вы одним словом назвали то, что у нас в статье занимает целый раздел. На втором заходе один из 22 агентов нашёл реальный баг, поднял его как блокер, а верификатор полез искать подтверждение, не нашёл в своём куцем наборе файлов и тихо закрыл. Никакого спора не было - была коллективная вежливость, которая привела к ложному одобрению.
Мы это чинили не столько человеческим гейтом (он у нас в NaCl и так стоит на принципиальных решениях), сколько переворотом логики верификации - и именно переворот сработал! Раньше скептик работал по принципу "не нашёл подтверждения - отклоняю находку". Мы заставили его доказывать, что находка ложная, а если доказать не может - находка живёт. На неполном контексте разница колоссальная, потому что "не вижу подтверждения" при куцем наборе файлов не значит вообще ничего.
Соотношение шума 3:1 на TS-миграции похоже на наш первый сырой прогон (26 находок, две трети мусор). Мы сузили фокус ревьюеров и добавили дедупликацию по корневым причинам вместо симптомов - стало терпимо, хотя до идеала далеко.
А какой размер миграции был? И скептик у вас отдельным агентом работал или был встроен в логику второго?
Мне нравится ваш эксперимент, я бы его даже усилил. Дайте эту гипотезу из трёх предложений gemini pro, а потом спросите: "какой результат я получу, если проведу этот эксперимент?" Модель уверенно выдаст красивый прогноз и промахнётся. У неё же нет данных, только слова. Это мой заход 2 в миниатюре - 22 агента уверенно одобрили код с багом, потому что в их контексте не лежал файл с доказательством.
При этом то, что вы называете "непреодолимый потолок", мы видели буквально, руками. Агент-верификатор поймал правильную находку, полез искать подтверждение, не нашёл в своём куцем наборе файлов - и выкинул её. Я на заходе 3 дал тому же workflow весь проект, он нашёл гонку данных, которую одиночный агент пропустил. Тот же код, те же промпты. Другой контекст - другой результат.
Потолок есть, кто ж спорит. Но мне кажется, он не там, где вы его рисуете. Мы суём модели выжимку и удивляемся, что на выходе тоже выжимка. У меня главный вынос из всех трёх заходов: модели не надо "думать глубже", ей надо видеть конкретную строку в конкретном файле. Сравнить "тут processing, а тут running, они не совпадают" она может прекрасно. Угадать, что в невидимом файле написано processing вместо running - нет. Это не потолок мышления, это отсутствие входных данных.
Расскажете, что за гипотеза из трёх предложений? Интересно разобрать на ней: в какой формулировке модель сломается, а в какой вытянет. Подозреваю, граница пройдёт ровно по количеству конкретных фактов в этих предложениях.
Критерии LLM прописывает сам во время конструирования промпта. Если у меня есть требования, как проверить, то пишу их в первичной постановке.
Спасибо!
Про универсальный формат - если честно, ни разу не пробовал, так как прошу под Claude или GPT. Добавлял, скорее, для универсализации.
У нас отдельная группа скиллов работает именно с графом. Есть скилл intake, который разбирает обращение и определяет - это бага или новая фича. На основе данных графа. Дальше есть скилл fix, который первым делом определяет, что нужно поправить в графе (если нужно). И вносит в план наряду с кодом. Ну и скилл feature - он вносит обновления в граф в соответствии с требованиями фичи, потом уже скилл plan планирует технические задачи на разработку.
Можно. Отправьте скиллу задачу из серии "напиши промпт, работая по которому агент будет задавать пользователю вопросы. Его цель - выяснить.... Он уже должен знать .....". После этого, отправив получившийся промпт первым сообщением, получите необходимый режим вопросов.
Используем Neo4j и собственную методологию. https://github.com/ITSalt/NaCl/blob/main/docs/methodology/overview.ru.md - по ссылке подробное описание
Да, Вы правы! Внятный образ результата - это больше половины решённой задачи. Но у меня не всегда бывают только такие. Например, когда я брался за придумывание программы для детей в лагере, то у меня не было точного образа. Я мог сказать, что хочу, чего не хочу, какие будут условия - по сути, задать контекст, но не образ результата. И задачей ИИ было как раз предложить 3 разнообразные программы. Без промпта, который мне выдал скилл, у меня не получалось ничего внятного. Промпт со скилом - и я кайфанул от двух вариантов из трёх!
Как узнать, что ты чему-то научился? Если поменял на что-то точку зрения или стал делать по-другому - значит, научился :)
"Правильно" - это понятие субъективное. Мне важно, чтобы когда я прошу "оригинальную идею", то идея была бы действительно оригинальной. Мой скилл позволяет этого добиться быстрее, чем без него :)
Я с Вами полностью согласен, если речь идёт о разработке. Собственно, весь наш фреймворк ровно на это и работает. Но в статье речь идёт о промтах, которые не связаны с разработкой. Или длительными процессами как таковыми.
"Придумай сценарий игры для детей 10-13 лет на острове", "напиши метафорический сценарий для рилс на тему бытовухи", "придумай небанальное поздравление на 50-летний юбилей свадьбы", "напиши промпт для генерации изображения вот в таком-то стиле" - если делать такие промпты "в лоб", получается банальная фигня. Наш скилл как раз добавляет контекста, словесной обвязки и задаёт "правила качественного ответа". И результат получается на порядок лучше.
На мой взгляд, гораздо качественнее. А если дать ещё больше контектса, будет ещё интереснее.
Что может быть Harness для таких промптов, кроме самого промпта?
Интересно, спасибо! Мы не пробовали в claude.md класть такие штуки, стараемся его держать очень кратким, давать в нём много ссылок. Но у нас вся спека - в графе. Поэтому у нас там, скорее, именно инструкции, как что делать по методологии.
По нашим опытам "положительное подкрепление" работает ощутимо лучше, чем "отрицательный пример". Мне кажется (непроверенная гипотеза :) ), что тут срабатывает ассоциативность. LLM проще находить близконаправленные вектора, чем "отталкиваясь от запрета предлжить вариант". Всё как в жизни - запрет создаёт дырку, а не повышает вариативность
А к чему порекомендуете прийти?
Поэтому мы не учим, а просто собрали скилл, который всё это сам делает :)
А с другой стороны, возьмите любую тему и посмотрите, сколько на неё всего и вся. Начиная от того, "как выровнять div по высоте" и заканчивая "как управлять проектами". Это наша реальность, которая меняется с такой скоростью, что приходится постоянно искать новые, более оптимальные подходы. Не готов сказать, что мне это очень нравится. Я, честно говоря, подустал постоянно учиться. Но другого шанса не пополнить ряды "винтажных парогенераторов" я не вижу.
:) Нет, "гаечки" - это валюта лагеря. Дети, помогая взрослым, зарабатывают гаечки и в предпоследний день на аукционе можно купить за них всяких ништяков, типа "посидеть со взрослыми у костра после отбоя" или "катание на плечах самого высокого папы" :)
Мне было важно, чтобы в игре у детей тоже был шанс заработать гаечки
По нашим экспериментам, Claude больше смотрит вглубь, а Codex больше смотрит вширь. То есть один и тот же инцидент Claude разбирает в стиле: «Вот смотри, вот здесь на этой строке произошла ошибка, поэтому кейс твой не сработал». А Codex разбирает в стиле: «Вот смотри, здесь слишком мало источников, поэтому ты ничего не видишь». Примерно такая разница.
При конфликтующих ревью мы сталкиваем агентов лбами. Происходит это так: одному агенту пишем сообщение: «Вот посмотри, другой эксперт сделал такой вывод про этот баг. Сравни со своим анализом, напиши, с чем ты согласен, а с чем не согласен. Добавь аргументацию». Эту аргументацию перекидываем агенту, который ранее проводил ревью. Таким образом приходим обычно или к консенсусу, или же остается какое-то разногласие, которое нам приходится решать уже человеческим мозгом. Но оно 100% лежит не на уровне кода — это скорее разногласие в понимании, а значит, повод поработать с требованиями и постановками.
Спасибо большое! Поправил. К сожалению, пока у нас во фреймворке нет скилла, позволяющего публиковать статьи на автомате. Но мы работаем над этим :)
Лекарства с недоказанной эффективностью - это когда публикуют только успешные результаты и прячут провалы. У меня заход 2 - опубликованный провал: миллион токенов, 22 агента, ложное одобрение кода с реальным багом. Фарма такое прячет, а я с этого начинаю аргументацию.
Про сигмы. Правило красивое, но оно работает для повторяемого процесса с нормальным распределением - диаметр детали на конвейере, толщина стенки. Баг в реальном проекте - это не деталь на конвейере. Каждое изменение в своём контексте, каждый баг уникален. Требовать 2-3 сигма на обнаружение бага - это примерно как требовать от хирурга гауссову гарантию на каждую операцию, когда тело каждый раз другое.
Что реально можно измерить, я измерил: точность на размеченной истине (заход 1, заранее заложенные баги и ловушки), поведение на боевом коде (заходы 2 и 3), стоимость в токенах и во времени, сравнение с контрольным методом - одиночным агентом на тех же файлах. ROI из статьи конкретный: workflow в 15 раз дороже и при этом пропускает баги, которые ловит один агент с доступом к проекту. Я не продаю чудо-таблетку, я опубликовал результаты реальных исследований и причин, к ним приводящим.
Но вот что было бы правда интересно: как вы предлагаете мерить эффективность код-ревью в сигмах? У меня не получается натянуть нормальное распределение на "нашёл баг / не нашёл" при уникальном коде каждый раз. В "доИИшные времена" мы у себя измеряли процент трудозатрат, который разработчик тратит на исправление ошибок относительно трудозатрат, которые тратит на создание фичи. При высоком проценте можно было говорить, что качественно делает или нет. С ИИ этот показатель, в целом, бесполезен. Можно токенами мерить, конечно. Но за счёт обвязки в контексте это будет сложно сравнимая вещь.
Если у Вас есть рабочий подход про измерение качества кода в сигмах - поделитесь, пожалуйста. Ибо это тема для отдельной статьи. Без шуток.
Ну, здравствуй, брат-динозавр, который тоже запускал C++ в Chrome! :)) Не обижайтесь на фривольный тон - я с гугловским NaCl повозился в своё время, пощупал, почесал репу и ушёл обратно в asm.js, потому что идея красивая, а тулчейн больной. Да и потом пришёл WebAssembly и уже закрыл тему для всех.
А с названием у нас другая история. У нас компания называется "ITSalt", и когда придумывали имя для фреймворка, пошли от химии: NaCl - это формула поваренной соли, то есть буквально то, из чего наша соль состоит. У NaCl кристаллическая решётка - жёсткая, регулярная структура, которая держит форму. Фреймворк ровно это и делает - задаёт решётку, по которой агенты работают, а не импровизируют. Без решётки получается аморфная каша, что мы, собственно, и показали на заходе 2, когда workflow без правильных ограничений одобрил код с багом. :)
Так что совпадение с гугловским NaCl случайное, но ироничное - оба проекта про то, как заставить код работать в песочнице с ограничениями. Только Гугл стюардессу таки закопал, а наша всё хорошеет и хорошеет :)
Два момента хочу отметить.
CodeRabbit как внешний взгляд - да, рабочая штука, грех не подключить, если бесплатно. Единственное, что я бы проверил: насколько его находки пересекаются с тем, что ловит ваш основной процесс. Если 80% дублей - это красивый отчёт поверх того же самого. А вот если он стабильно цепляет класс проблем, который ваш агент пропускает - тогда это уже реальное усиление, а не утешительный второй взгляд.
Второй момент. По нашему опыту, все-таки лучше использовать двух разных агентов, причем с разными моделями. Они действительно по-разному смотрят. Мы сейчас в основной пайплайн включаем обязательное ревью Codex кода, написанного через Claude Code, и наоборот.
Про самосогласование - Вы одним словом назвали то, что у нас в статье занимает целый раздел. На втором заходе один из 22 агентов нашёл реальный баг, поднял его как блокер, а верификатор полез искать подтверждение, не нашёл в своём куцем наборе файлов и тихо закрыл. Никакого спора не было - была коллективная вежливость, которая привела к ложному одобрению.
Мы это чинили не столько человеческим гейтом (он у нас в NaCl и так стоит на принципиальных решениях), сколько переворотом логики верификации - и именно переворот сработал! Раньше скептик работал по принципу "не нашёл подтверждения - отклоняю находку". Мы заставили его доказывать, что находка ложная, а если доказать не может - находка живёт. На неполном контексте разница колоссальная, потому что "не вижу подтверждения" при куцем наборе файлов не значит вообще ничего.
Соотношение шума 3:1 на TS-миграции похоже на наш первый сырой прогон (26 находок, две трети мусор). Мы сузили фокус ревьюеров и добавили дедупликацию по корневым причинам вместо симптомов - стало терпимо, хотя до идеала далеко.
А какой размер миграции был? И скептик у вас отдельным агентом работал или был встроен в логику второго?
Мне нравится ваш эксперимент, я бы его даже усилил. Дайте эту гипотезу из трёх предложений gemini pro, а потом спросите: "какой результат я получу, если проведу этот эксперимент?" Модель уверенно выдаст красивый прогноз и промахнётся. У неё же нет данных, только слова. Это мой заход 2 в миниатюре - 22 агента уверенно одобрили код с багом, потому что в их контексте не лежал файл с доказательством.
При этом то, что вы называете "непреодолимый потолок", мы видели буквально, руками. Агент-верификатор поймал правильную находку, полез искать подтверждение, не нашёл в своём куцем наборе файлов - и выкинул её. Я на заходе 3 дал тому же workflow весь проект, он нашёл гонку данных, которую одиночный агент пропустил. Тот же код, те же промпты. Другой контекст - другой результат.
Потолок есть, кто ж спорит. Но мне кажется, он не там, где вы его рисуете. Мы суём модели выжимку и удивляемся, что на выходе тоже выжимка. У меня главный вынос из всех трёх заходов: модели не надо "думать глубже", ей надо видеть конкретную строку в конкретном файле. Сравнить "тут processing, а тут running, они не совпадают" она может прекрасно. Угадать, что в невидимом файле написано processing вместо running - нет. Это не потолок мышления, это отсутствие входных данных.
Расскажете, что за гипотеза из трёх предложений? Интересно разобрать на ней: в какой формулировке модель сломается, а в какой вытянет. Подозреваю, граница пройдёт ровно по количеству конкретных фактов в этих предложениях.