Хабр Курсы для бэкендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 28
Сколько md файлы едят токенов ...
На своём проекте: CLAUDE.md (~28k символов) + правила (~20k) + индекс памяти (~10k) = ~58k символов, порядка 20k токенов на старте сессии
Но это не так много: грузится один раз за сессию, а память целиком не читается, в контекст идёт только индекс, сами файлы подтягиваются по запросу. На фоне окна в 200k это ~10%. Реально контекст едят длинные выводы команд и история диалога, а не инструкции
Видимо Cursor ест по другому.
Cursor устроен немного иначе, на сколько знаю. CLAUDE.md в Claude Code висит в контексте всю сессию целиком. Cursor же индексирует кодовую базу (эмбеддинги + поиск) и подтягивает только релевантные куски под запрос, а правила .cursor/rules могут цепляться условно, а не всегда
Плюс он прячет токены за моделью “по запросам”, поэтому расход не виден. Принцип тот же - persistent-инструкции маленькие, едят контекст retrieved-код и история. Но Cursor в среднем держит меньше постоянного текста, чем всегда-загруженный CLAUDE.md
Вообще мало работал с курсором, может у вас проблема где-то в другом месте?
28к символов? при бутстрапе? как часто, простите, обновляется? почему не делите на docs/subj1.md и через «@docs/subj1.md» не ссылаетесь? obsidian не пробовали прикрутить? я просто везде в своих проектах имею малюсенький claude.md, разбитый на секции, и также obsidian. плюс подпапки, те же домены можно обогатить своими внутренними claude.md
28к потому что у меня пока всё в одном файле. Обновляю по мере новых фичей, раз в пару недель. На старте ~20к токенов, ~10% окна вроде терпимо, но для крупных проектов мб стоит дробить, есть рефы где посмотреть, как у вас, например?
Вложенные claude.md в подпапках доменов заберу посмотреть, спс, вроде подтягиваются когда модель работает в этом куске
Obsidian показался переусложнённым, и он про навигацию для меня, а не про то, что грузит модель. Если у вас взлетело - расскажите
Несколько раз перечитал, думал в прошлое попал) 20к токенов, ~10% окна , может 2% окна? )
Честно говоря времена до 1М контекста вспоминаю как страшный сон, когда этот бутстрап оптимизировал до каждого байта, и то постоянно не хватало.
Сейчас с этим проблем нет, кроме того что конекст постоянно забывает и claude.md и даже свои мемори , и приходится частенько в них тыкать носом снова.
Про проценты: я считал от 200к (стандартное окно Claude) там 20к это ~10%. Если у вас 1М, то да ~2%, всё зависит от модели
А вот "забывает claude.md и даже мемори" это не приятная правда. Окно большое, но в середине длинной сессии инструкции расплываются, и приходится снова тыкать носом
Для меня это и есть главный аргумент за линтеры и тесты: мягкую инструкцию модель забудет, а красный билд - нет. Жёсткие гейты надёжнее любого claude.md!
Если модель поддерживает контекст 1М то это не означает что она может эффективно работать со всем этим контекстом. Для моделей заявляющих 256к деградацию наблюдают уже от 32к-100к, для 1М уже от 100к-200к. Так что если брать окно эффективности, то 20к это 10-20%.
благодарю за ответ, попробую на неделе максимально полно оформить свой воркфлоу, и отпишусь в этой ветке. основная идея, как и написал ранее - разделение + obsidian vault, opus в качестве архитектора / продакта, sonnet в качестве исполнителя, отдает phase dump’ы опусу и реализует до победного, через меня, как прослойку. потом иду смотреть и тыкать
Звучит как интересная схема, но похоже, ты вручную изобретаешь велик. Твой цикл «Sonnet реализует до победного» это случайно не что-то типа Ralph loop (даже официальный плагин Claude Code от Anthropic есть), а «Opus-архитектор раздаёт phase dump’ы ->спека -> задачи» это BMAD-METHOD / Taskmaster / Spec Kit.
Ralph (Anthropic): https://github.com/anthropics/claude-code/tree/main/plugins/ralph-wiggum
BMAD-METHOD: https://github.com/bmad-code-org/BMAD-METHOD
Taskmaster: https://github.com/eyaltoledano/claude-task-master
Может, проще взять готовое за основу, чем городить с нуля. Интересно сравнить с твоим -отпишись, как попробуешь)
честно сказать, я уже это все видел, слышал, наблюдал. в феврале этого года вступил в ИИ клуб от podlodka podcast, и там регулярно проходят демо дни, доклады. пока вижу что мой «велосипед» меня полностью устраивает, а остальное оверинжиниринг. возможно поэтому от ребят слышу, что улетают токены, и все в таком ключе
понял, принял! Интересно будет посмотреть :)
Обещал вернуться - оформил в статью целиком. Но раз обещал - вот выжимка текущего воркфлоу: CLAUDE.md разбит на секции + подпапки с вложенными claude.md по доменам. Было 20KB в одном файле, сейчас ~5KB в корне + справочники в docs/. Принцип простой: если раздел нужен агенту в 8 из 10 задач - остаётся в корне, если в 1 из 10 - выносится.
Obsidian vault через симлинки как долгосрочная память агентов - они пишут туда логи, читают архитектурные заметки, всё видно в реальном времени.
Распределение ролей: Opus в чате как архитектор/продакт/тимлид - пишет промпты для агентов, проверяет диффы по чеклисту, планирует циклы.
Sonnet в Claude Code как исполнитель - реализует по промпту. Я ревьюю и мержу. Pipeline: спек-тикет в Linear - промпт от Opus - реализация Sonnet-агентом - ревью диффа - коммит. Недельные циклы, одна главная ставка + 2-3 побочные задачи.
Ralph/BMAD/Taskmaster осознанно не взял. Мой велосипед проще и закрывает три проекта на разных стеках (Unity+Colyseus, Raspberry Pi+TypeScript+Python, Laravel+Nuxt) без оверхеда фреймворка.
Когда упрусь - пересмотрю, пока не упёрся. В следующих статьях разберу CLAUDE.md подробно с примерами, Obsidian-связку, и конкретные грабли типа когда агент тебе проект в WebP сконвертирует 'для оптимизации', а Unity его не декодит
https://vorozhbit.su/posts/ot-kladbischa-proektov-k-trem-produktam-kak-ai-izmenil-moyu-razrabotku
вместо этой фигни есть /goal. описываешь критерий успеха и говоришь делай по плану, оно само себя пинает
А почти не едят, claude с завидным упорством всё это не читает. Спрашиваешь почему, говорит почитал первый абзац или выборочно заголовки, дальше решил токены мне сэкономить. в автогружаемых скиллах оказалось стабильнее/удобнее это всё держать. т.е. если идёт работа допустим с переводами, автоматически подгружается по контексту скилл, а в нём уже прописано как мы делаем и как не делаем и почему. И так выходит лучше, чем memory.md, claude.md. А сами скиллы едят кратким описанием не много, а внутрь агент лезет уже когда он понадобился т.е. это и так бы в промпт попало, если бы в скилле не было, ведь руками бы контекст описывал.
Аналогия
Когда люди пересели с пеших переходов на лошадей, скорость выросла в десять раз. Но лошадь это не бесплатный мотор. Её надо кормить, ...
Очень хорошая аналогия. Потому что нифига не в 10 раз. Вы пробовали ходить в конный поход? Разиков в 5 у вас вырастет скорость, если есть почтовые станции и перекладные, которых вы можете менять немедленно по запросу. Например, если вы фельдегерь. Если у вас конь с телегой и вам надо не свадьбу на тройке с бубенцами 300 метров по деревне промчать, то скорость у вас вырастет раза в полтора, а в некоторых случаях (конь один, а телега хорошо груженая) средняя за маршрут может и упасть.
Но глядя со стороны, да пока сам не пробовал, думаешь - ага, щас как в 10 раз ускорюсь... А вот все остальное, которое после "надо", никуда не девается, да.
В 10 раз - это, конечно, фигура речи, а не замер с секундомером) Будь то конь, будь то 1.5–5 раз в реальном походе - точный множитель тут не главное. Главное, что вы сами же и подтвердили: скачок есть
А вот мысль, ради которой аналогия и приводилась: конь это не бесплатный мотор. Выигрыш в скорости реальный, но "всё остальное, которое после надо" никуда не девается. Кормить, поить, чистить -и коня, и модель (контекстом, ревью, перепроверкой)
тут вылезает вторая хитрость. Я начинаю кодить вдвое быстрее я сразу хочу, чтобы и код-ревью успевало, и тесты qa шустрее, потому что pull request’ов стало больше. Конь-то разогнался, а дорога, мосты и станции остались прежними и пробка просто переехала на новое место))
Так что мы с вами об одном. Я про то, что сел в седло - и часть сил уходит уже не на дорогу, а на саму лошадь
Не хватает опции 80-90% руками, AI только для рутины, которую можно "читать по диагонали" - вроде "рыбы" для тестов и в качестве источника условно-"альтернативного" взгляда на код.
Ведь всё это "fine and dandy" ровно до тех пор, пока вам не надо подписываться чем-то серьёзным под результатом. А значит вдумчиво разбирать, что же там "ИИ"-агент нафантазировал, нет ли там затейливых "student-style приколов" в реализации, элементарных ошибок на уровне "детский сад" или же gross-overengineering-трэша в ущерб базе, о котором никто "ИИ"-агента не просил.
Так "вдумчиво разбирать, что нагенерил агент" - это не контраргумент, это и есть мой процесс. Никто не подписывается вслепую: для того и правила, линтеры, тесты и двойное ревью. Подпись под результатом ставится не вместо проверки, а после неё
А "80-90% руками, ИИ на рутину" - это уже устаревшая позиция. Крупные компании вроде GitLab и Anthropic давно вынесли ИИ за рамки «рыбы под тесты»: он пишет значительную долю кода и подключён к ревью на уровне платформы, встроенной в процессы компании. Человек владеет результатом и отвечает за него, но не набивает 90% руками
То, что в статье это верхушка айсберга. Под ней уже формируются best practices по внедрению ИИ во всю компанию. Так что вопрос не «fine and dandy или нет», а кто быстрее перестроит процессы под это
Крупные компании вроде GitLab и Anthropic давно вынесли ИИ за рамки «рыбы под тесты»: он пишет значительную долю кода и подключён к ревью на уровне платформы, встроенной в процессы компании. Человек владеет результатом и отвечает за него, но не набивает 90% руками
Крупные компании могут позволить себе многое, в том числе и “локальный AI”, принципиально лучше защищённый от утечек всего и вся и не являющийся при этом “убогим”, из-за ограниченности вычислительных ресурсов. И большое число инженеров, у которых задача не просто решить какую-то системную или прикладную задачу, а разобраться в задаче, потом разобраться в том, что и как сгенерировал AI и сделать так, чтобы AI в следующий раз это делал “лучше”. Где критерии того самого “лучше” могут оказываться самыми неожиданными.
Как это поможет тем, кто платит за токены и отправляет без какой либо гарантии информацию о своих задачах, процессах и датасеты в облачную инфраструктуру “на милость” того самого “AI”, вовсе не очевидно. Особенно, если человеку действительно приходится досконально разбираться с задачей и разбираться “что к чему” в коде, написанном AI, а не имитировать процесс, “срезая углы” в надежде что именно ему “повезёт”.
Риски есть, не спорю. Но их не игнорируют, компании как раз выстраивают вокруг AI нормальные автоматизированные пайплайны: ревью, тесты, линтеры на уровне платформы. Про это уже выходят статьи и выстраиваются бест практисы
Про «по карману только крупным» - да, у больших и ресурсов больше. Но сам базовый воркфлоу (правила + линтеры + тесты + ревью и тд) спокойно крутится и у соло-разработчика: Claude Code + один md-файл + пол бакса за вопрос. Дисциплина масштабируется и вниз, не только вверх
Про утечки вопрос реальный, и тут многое на стороне платформы: zero-retention, enterprise-договоры, локальные модели для секретного. По сути ты выбираешь инструмент под чувствительность данных. Это отдельная история от того, работает ли AI-разработка как подход
del
ИИ дописывает новый код так чтобы старый продолжал работать. Если проблема решается изменением старого кода, ИИ все равно пишет новый, если не сказать что конкретно делать. Назовите какие задачи вы решаете помимо создания примитивных эндпойнтов для удаления пользователя?
Ресёрч - разобраться в незнакомой области/библиотеке/чужом куске системы, собрать варианты решения с плюсами-минусами, прежде чем писать хоть строчку
ADR-ы - формулирую проблему, агент помогает оформить решение и альтернативы так, чтобы через полгода было понятно, почему сделали именно так
Архитектурные решения с контекстом БД - он видит реальную схему репозитория базы (через MCP-подключение к боевой/тестовой БД), поэтому предлагает не «в вакууме», а с учётом существующих таблиц, связей и индексов
Код по конкретной задаче - да, обычная продуктовая разработка, но в рамках моих правил (стайлгайд, архитектурные ограничения, линтеры/тесты как «кнут» — ровно как в статье)
Свои пет-проекты / продукты - отдельные штуки пилю целиком с ним
Управление командой - рутина тимлида: формулировки, разбор, подготовка решений
Разбор прод-алертов - приходит алерт, агент по скрипту лезет в кластер, собирает логи/состояние подов в окне инцидента, классифицирует причину (OOM / упавший upstream / БД / Kafka) и готовит постмортем с конкретными action items.
Заведение задач в Jira - создание и оформление тикетов из обсуждения/контекста
Статьи в Confluence - внутренняя документация, командные страницы.
И помощь со статьями сюда же, на Хабр 🙂
Ключевое не «оно само», а связка: контекст (CLAUDE.md), правила (.claude/rules), доступ к реальной БД и инфре, плюс линтеры/тесты, которые не дают ему накостылить. Тогда это уже не генератор CRUD-а, а рабочий инструмент почти по всему циклу
20+ e2e тестов это опечатка или шутка?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Десять лет в индустрии я писал код руками. Три месяца назад перестал