Обновить

Разделение ответственности между Claude и Codex: как я перестал выбирать одну нейросеть и усилил сразу две

Уровень сложностиСредний
Время на прочтение14 мин
Охват и читатели11K
Всего голосов 8: ↑6 и ↓2+7
Комментарии22

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

Чтобы тратить токенов в 2 раза больше?

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

Каким методом сравнивали? Сколько Аб тестов провели и как ?

Одинаковые кейсы не брал и точно не замерял. Сужу по субъективным наблюдениям во время работы в ходе решения своих задач.

ну так у одного работает, у другого нет, без цифр не понятно

Можете протестировать у себя. Я не настиваю, а подчёркиваю, что это не решает все проблемы.

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

Качество растёт не за счёт бюджета.

Проверяли? Мультиагентная разработка добавляет действий, так что в абсолютных токенах должно быть дороже. Ведь высказывание в цитате не равно "просто за счет бюджета без изменений процесса можно повысить качество."

Если есть возможность, киньте ссылки, пожалуйста, на практики.

Это хорошо для больших задач. План составил, кинул выполнение на нейронку, пришел, проверил и поправил что не так. Либо приходится много участвовать в разработке и всё время грамотно соблюдать контекст, делать /compact, новые чаты для сохранения контекста. Тут нейронка сама делает.
Всё же это еще один инструмент, иногда он просто будет избыточен.

Лично у меня получается перерасход ну на процентов 30 от силы. Зато экономия времени в разы.

Тут же ссылки желательны под конкретные варианты, у меня их, конечно, нет.

А "перерасход ну на процентов 30 от силы " как раз и означает, что качество растёт за счет бюджета, что прямо противоположно Вашему тезису. Рекомендую переформулировать последний.

Процентов 30 в среднем сейчас. Если не забивать на PLAN.md, а редактировать перед запуском, его вовсе может не быть. Поэтому я указал именно такой формулировкой.

С учетом того что вам не нужно самому прописывать каждый однотипный кейс для сторибука, 30 % перерасхода токенов выглядят адекватной ценой)

у меня 5 локальных cli
создал мультиагентую систему, которая запускает ревьюеров, кодеров, дебатеров
при этом и тим лид и его подчиненные юзают rtk, codegraph, профильные скиллы и мсп исходящие из задачи. Оркестрируется все бинарником, харнесс сокращен до минимума. Общая память на всех агентов. И я могу с уверенностью сказать, что тим лид тратит сильно больше. Особенно если тим лид мой любимый кими. Клод справляется малой кровью. Но пока в моих задачах лимитов хватает по подпискам, жаловаться грех. Как доделаю все, выложу в паблик, может и получится общими усилиями сократить расход токенов.
в какой то момент устаешь от написания сенсоров, гейтов, хуков, опускаешь руки и юзаешь as is.

Вы сами-то сколько трудитесь с ними? Или as is означает ещё и доверие к результату?

около 3 месяцев. as is это из разряда, "бог с ним" и так работает)

Интересно. Я бы почитал. Хочется прийти к тому, что приходишь к ИИ как ленивый заказчик: "хочу шоб было зашибись и работало". И всё было зишибись и работало, а я вообще не тратил когнитивных усилий на это.
Но в итоге через пол года всё опять перевернется и надо будет переделывать. =)

Мб для снижения нагрузки на поддержку харнесса перевести агентов на реактивную событийную модель? По идее настройка триггеров строго на конкретные вебхуки от гитлаба при пуше уберет необходимость постоянно писать самописные сенсоры

Все круто, но не ново, так как +- все сейчас так и работают. То есть статья полезная, но не уникальная для тех людей, кто реально (по серьезке) что-то программирует в нейронках. Могу быть свои дополнительные фишки и приблуды, но скелет у тебя правильный.

Интересный подход. Но насколько результат зависит именно от связки Claude + Codex? Возможно, похожий эффект можно получить и с одной моделью, если разделить планирование, реализацию и проверку на отдельные сессии.

пришёл к выводу что клод код отупел. опус 5 сейчас как оркестратор а 5.6sol реально хорошо пишет код и ревью

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

Чтоб агенты не уходили в бесконечный цикл правок жестко лимитируйте глубину контекста в самом скилле. Передача только последнего diff-а и списка упавших тестов спасает от размытия фокуса и прилично экономит память на локальной тачке

Как бы Вы сформулировали лимит для скилла на глубину контекста?

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

Публикации