Comments 50
Поймал себя на мысли: "Как необычно видеть длинную статью без нейрослопа!" Спасибо, было приятно читать. Хотя для себя я выбрал правило начинать новую сессию при 50% заполнении контекстного окна.
Интересно, что у меня главным пожирателем контекста оказался не CLAUDE.md, а вывод команд. Один прогон тестов с -v — это 30–50 тыс. символов, почти все строки PASSED, а агент гоняет тесты по кругу и каждый раз добавляет ещё одну такую простыню. Заметил и неприятную вещь: если команда падает, Claude Code обрезает вывод примерно до 10 тыс. символов и выкидывает конец, а именно там pytest печатает ошибки. В итоге агент идёт перезапускать тесты с grep. Сейчас пропускаю длинные выводы через фильтр, который оставляет ошибки и итог, а полный текст кладёт в файл. Про Haiku: гонял её на задаче «почини баги по упавшим тестам», она чинила всё и по числу шагов была почти как Sonnet.
Видимо у вас cli утилита ломает вывод, если он слишком объемный. В десктопном приложении такого нет. Мне ближе именно командная строка и на десктоп я долго не переходил, но неожиданно для меня оно оказалось очень удобным
Странно что разработчики cli до сих пор не сделали нормальный флаг для хвостовой обрезки
Как-то странно такое слышать, у меня вообще никогда Клод не запустит команду с потенциально большим выбором без tail или grep
Вывод команд это беда. Подумываю использовать mpecan/tokf или edouard-claude/snip в качестве более системного решения, но пока тоже ограничился фильтрами. Justfile во всех проектах для всех частных команд и там уже зашиты все нужные фильтры.
Мой лайфхак: инструкция для суб-агента - передавать главному основному агенту ТОЛЬКО результат его работы. А если субагент результат сохраняет в файл, то передавать только краткий статус (задача выполнена/не выполнена), чтобы не забивать контекст главного агента.
Блин, я думал, я один такой же этого додумался =) Я ему ещё пишу, чтоб экономил контекст. Пусть другие делают, его задача - контроль процесса =)
Когда я изучал суб-агентов, то выполнил ряд тестов - с ними и без них для тестовой задачи, скажем независимая обработка 10 файлов. И вижу, что с суб-агентами контекст главного агента почему-то такой же раздутый - экономии нет. Вначале понять не мог, зачем тогда субагенты. Потом догадался проверить что субагенты передавали главному потоку и понял, как доработать задачу.
А код который агенты сгененрили кто читать будет?
Если хотя бы просто читать и поверхностно понимать что там агенты наделали то подписки за 100 долларов хватает с головой.
На мелких задачах сотни баксов действительно хватает за глаза
Чтение кода убивает большую часть смысла агентов, надо находить способы его не читать. Даже Боб Мартин уже к этому пришёл.
И получить махровое легаси которое никто не понимает как работает и как починить с первого дня.
Классный план. Что же может пойти не так?
Ну тут либо шашечки, либо ехать. Если хотите ускорения, то надо отказываться от чтения кода неизбежно, хотя ты частично отказываться. Если не отказываться, то это чтение становится узким местом очень быстро.
В первую очередь надо чтобы софт работал. А сбои было понятно как исправлять.
У моего софта есть пользователи. Под ним есть деньги. Много денег. Ускорение это конечно хорошо, но если никто не знает как поправить сбой то никакое ускорение нафиг не нужно.
Ну так с тем, чтобы работал проблем нет. Проблемы у всех с поддержкой. Да и то, непонятно ещё насколько.
Работал это работал. Не в моменте, а и через год и через три года. После неизвестных доработок и неизвестного изменения окружения.
Проблемы огромные. Кто перестал читать код тот уже получил гору легаси с которой непонятно что делать. И факапы, факапы. Которые непонятно как чинить.
Не только не доказано, но и не может быть. Не прошёл год с тех пор как появились последние модели. Т.е. это просто ощущения.
Я уже видел такой проект. Его умудрились превратить в легаси за полгода. Не, ну он работает. Но что делать никто уже не понимает. Риск уже реализовался, теперь дело только за дятлом который его развалит.
У меня буквально прошлая статья об этом: Мы все обречены поддерживать легаси код, когда‑то сгенерированный ИИ
Даже Боб Мартин уже к этому пришёл.
А, ну раз сам Боб Мартин, то тогда, конечно, надо не читать...
Даже Боб Мартин уже к этому пришёл.
Вы так написали, как будто он долгое время был за чтение кода, написанного агентами, а потом поменял свое мнение. Но это же не так.
Он экспериментирует. Код не читает, потому что обложил свои агенты кучей правил, ограничений, тестов и т.д. — он считает, что этого достаточно для верификации. Но это же лишь гипотеза.
И что же он советовал?
Видимо, ничего. Так как код тестами на покрывается полностью почти никогда. Остаётся только некоторый нулевой уровень рисков. Иногда приемлемый.
Я первое время тоже искал подходы к агентской разработке, когда код бы совсем не пришлось читать. В итоге это привело к тому, что через несколько месяцев пришлось проходить буквально функцию за функцией у всего пайплайна обработки. При том специфика моего сервиса не супер какая сложная - это on-call для админов/девопсов (расписания дежурств, политики, эскалации, звонки на мобилу).
К сожалению, спустя полгода я уже на 100% уверен, что хотя бы даже без беглого чтения кода что-то серьезное сделать не получится. Увы, нейронки отличные исполнители, но видения продукта у них нет. Они не горят идеей, не держат в голове концепции, не понимают как пройти по границам архитектуры, не свалившись в оверинженеринг. Но код они генерируют (не пишут!) отлично, этого не отнять. Что потом с ним делать вообще непонятно. Я только на днях потратил несколько млн токенов на выкидывание мусорных комментов.
В качестве компромисса я сейчас уделяю максимум внимания аналитике с агентом. Что-то в духе "а как ты будешь реализовывать эту задачу?" или "а для этой фичи как изменится нагрузка на БД и её схема?". После такого диалога уже становится понятно куда он пойдет и тут имеет смысл задать ему жесткие границы, иначе потом офигеете.
Я ещё в самом начале добавил инструкцию про комменты, может раз или два её обновлял, в итоге проблем с ними никаких. Может ещё кодовая база такая.
В остальном в проекте, в котором до 20к строк на питоне, можно уверенно не читать почти ничего. Более крупные стоит пытаться разбивать и читать как можно меньше.
Про 20К согласен, но у меня уже 200К+ и это без учета комментов и это только бэк. По личному опыту начинать читать точно придется уже с 80К, но лучше конечно начать заранее, потому что из будущих условных 100К треть может оказаться ненужным мусором. Потом ужасно обидно тратить кучу времени на вычитывание такого объема и вообще на понимание того как твой запрос "сделай хорошо, пожалуйста, а плохо не делай" превратился в такой ад
Ребята переписывают по полмиллиона строк на раст автоматом, и ничего в продакшен. Так что может просто недостаточно мы умеем управлять агентами со своими 20к. И ещё неизвестно, кто больше ошибок сделает и пропустит человек или ИИ, просто это будут разные ошибки. Ну и ПО никогда не выигрывало рынок качеством кода.
Еще с Opus 4.5 я использовал подход классической agile‑команды субагентов с разными промптами. Выглядело это следующим образом: аналитик разбирает задачу и передает в разработку, программист пишет код, ревьювер и QA принимают у него задачу с разных сторон.
Такой подход увеличивает потребление токенов во много раз. У меня было увеличение потребления примерно в 7 раз, в итоге отказался от такого подхода. В теории это звучит хорошо, но на практике разбивается об реальность, и заметно замедляет разработку. Такой подход хорошо работает на маленьких моделях типа Qwen3.8-27b, которые склоны к галюцинациям и заметно повышает качество кода. На больших моделях, практически бесполезен - повышает потребление токенов и замедляет скорость разработки.
Спасибо за наводку. Только что удалил 5740 блоков ненужных комментариев .
Вот утилка для мультиагентной разработки, умеет в перезапуск сессии на определенном пороге и многое другое
https://github.com/raul-cortez/claude-swarm
Когда делаю долгую задачу (на много часов вычислений и т п), прошу клода писать прогресс и eta раз в 30 минут. Соответственно, и мне приятно это видеть, и токены не уходят из кеша.
Дополнительный бонус: если какие-то аномалии (странные промежуточные результаты, необьяснимое замедление/ускорение и т п), то Клод имеет шанс это заметить сразу и починить, а не после многих часов вычислений. Плюс если eta внезапно превысил разумные пределы, то Клод пойдет оптимизировать, а не будет висеть днями.
В целом имеет смысл правило, что если ИИ запускает что-то, что может работать дольше получаса, то в это что-то должна быть встроена в какой-то форме краткая индикация прогресса и состояния, а агент должен поставить себе таймер (лучше всего через sleep, cron task глючат) и регулярно смотреть и писать свои наблюдения в чат.
Работы субагентов это тоже касается, обычно главный пишет что-то типа "измененных файлов нет, субагент ещё читает код", "субагент изменил 20 файлов, работа в самом разгаре" (при этом он не читает ни транскрипт субагента, ни содержимое файлов, так что контекст не жрется слишком быстро). В принципе можно попросить и в промт субагентов встраивать уведомления (они же могут слать друг другу сообщения).
не пробовал выносить прогон тестов в отдельный скрипт с отдачей короткого статуса?
Весь набор тестов я вообще запретил гонять без моего апрува, прошу запустить сам параллельно ручной приемке фич с верхнеуровневым агентом. Но в целом ваш подход очень выигрышный. Для повторяющихся задач очень полезно писать скрипты. У меня такой скрипт есть для аналитики использования токенов в сессии - дает отчет сколько субагентов было запущено, сколько токенов и на какие задачи сожгли, какие именно модельки запускались, плюс считает сколько бы за это пришлось отдать в баксах при использовании через API. Субагент на такой подсчет тратил около 200-300к токенов, а сейчас это для него один tool call
При аналогичной проблеме пошел по пути создания скилов и ранбуков, на каждую отдельную задачу нейронка пишет ранбук, который может воспроизвести человек, в формате MD и складывает в мой Obsidian, сам их просматриваю и правлю, вырезая лишнее. Если задача повторяется многократно - делается скилл, на все используемые мной инструменты есть скилы, на все проекты и используемые там решения тоже. Каждая новая задача начинается с новой сессии, туда через скилы притягиваются ранбуки необходимые только для этой задачи, нейронке не обязательно знать о всем проекте целиком, если задача, условно, подвинуть кнопку на одной форме. Так же все скилы и ранбуки заправлены в synthing и синхронизированы между несколькими рабочими местами. Итого мне все равно какую модель использовать в данный момент, кончились токены на клоде, используем GPT, нет денег на личной и предстоит сложная архитектурная задача, запускаем на корповой Fable. Если до этого я мог пожечь 5 часовой лимит просто в 1 запрос из-за подгрузки огромных контекстов, то теперь я не добираюсь и до половины недельных лимитов и 5 часовые почти всегда с запасом. Минусы тоже есть - требует ручного контроля и нельзя дать одному оркестратору задачу сделай все хорошо, иногда в первом запросе надо перечислить какие скилы использовать и какие ранбуки конкретно смотреть, но это окупается огромной экономией контекста, возможностями переноса и контролем понимания, что вообще делалось в рамках конкретной сессии. Ну и общая проблема захламления комментариями кода решается, все лежит в отдельных ранбуках с привязкой к задаче в жире или коммиту в гите.
Что вы там все пишете такое, венду свою что ли реализуете, что вам подписки даже за 200 баксов может не хватить? И что с этим объемом нагенеренного кода делаете, тупо ревью другой сеткой и в прод? Самому ж смотреть и вникать целый жизни на такие объемы не хватит.
Это сильно вредит будущим субагентам, потому что они вдруг почему‑то начинают считать информацию в комментариях более приоритетной. Абсурд, но такова реальность. Иногда доходило до смешного: формулировка очередной задачи строилась на основе разбора комментариев, но не кода, а в процессе работы нужно было подстраиваться уже на ходу под «внезапно» обнаруженную иную реализацию.
Я на это наткнулся в своей работе по исследованию инъекций в пулл‑реквестах, про которую написал статью https://habr.com/ru/articles/1086966/
Как оказалось, модели больше верят словам на человеческом языке, чем коду. Главный канал инъекций — не зловредный код, а текстовое описание. Зловредную правку в коде, добавляющую бэкедор, отклоняли почти все модели, делающие ревью, кроме ну самых слабых. А вот описание того же самого в тексте описания, особенно в виде строгого требования, пропускал даже Opus, не говоря уж о более слабых.
Поэтому да, при работе с ИИ текстовый канал важнее кодового, и следить за ним надо тщательнее.
У меня вышло наоборот: чем больше окно, тем больше я туда сваливаю, а после авто-компакта агент бодро спрашивает то, что мы уже решили час назад — как коллега после отпуска. Так что понимаю ваш выбор :)
Интересно, а какой оптимум для локального Квена 3.8 (28В параметров который) на своем компьютере? 48К нормально или нет.
Русский язык съедает в 3 раза больше контекста. Пиши на русском, читай на английском. А лучше сразу все на английском.
Субагента кеш так же прогревается на час. Там всё по умолчанию час. И вроде бы есть разница между 5 минутами и 60 минутами. В случае с 5 минутами ещё дешевле. В крайнем случае, субагентов, если они стоят на 5 минут, можно так же перевести на 60 минут
Давно поставил правило - при запуске субагента таймер на 50 минут обязательно. Потом перезаписать таймер, если субарь не завершил ещё работу. Сразу вся проблема с прогревом уходит.
Дополнительно как совет - ставь в каждый второй твой промпт напоминание через хуки о том, что данные нужно проверять.
Код кривой пишут не только лишь все.
Очень странно заявлять, что клод пишет с ошибками, и поэтому его такого тупого надо проверять руками и с гпт. С тем же успехом мог бы сразу писать с гпт. Но мы ж понимаем прекрасно, почему мы не пишем с гпт код, правда?)
Почему я вернулся на контекстное окно в 200К у Клода