«Дрейфующая гранулярность» точное название. Наблюдаем то же самое: код сначала монолит, потом сам вырисовывает границы через боль. У нас сигнал что граница проведена не там, когда CLAUDE.md одного модуля начинает ссылаться на детали соседнего. Про перекладывание разделения на ИИ интересно, пробовали? Мы пару раз просили Claude предложить разбивку, результат неплохой но требует ревью.
У нас та же картина с Claude и GPT-4: Claude находит «вот здесь строка упадёт при null», GPT-4 говорит «вот здесь слабое место по архитектуре». Приём со столкновением агентов возьму в работу, у нас пока второй взгляд это ручной второй чат. Вопрос: финальное решение при разногласии всегда человеческое или бывает что вес аргументации одной стороны явно перевешивает?
BurntToast отличный выбор для Windows. У меня macOS поэтому osascript, но принцип тот же. Про MCP для БД согласен, это уже must-have, не опция. Возможно стоило включить в список, но тогда 10 превратилось бы в 15.
Тема с 152-ФЗ актуальна: именно из-за неё часть кодовых задач у нас не уходит во внешний API. Но перед дообучением пробовали ещё один шаг: хорошо структурированный контекст через CLAUDE.md + примеры из нашей базы. Для задач где у модели достаточно способностей, но не хватает контекста, это дешевле и быстрее дообучения. Вопрос: на каком пороге сложности выбирали дообучение, а не RAG или prompt engineering?
Гранулярность на уровне модулей: именно к этому пришёл сам после 200к строк с AI. Только у нас дополнительный слой: CLAUDE.md описывает границы каждого модуля явно, чтобы агент не «видел» соседей без необходимости. Получился примерно тот же принцип, каждый модуль самодостаточен и не требует контекста других. Интересно, у вас это получилось эволюционно или изначально закладывали?
Концепция «зафиксировать процесс через skill» прямо совпадает с тем, к чему сам пришёл за несколько месяцев. Структура похожая, только для backend: skill на NestJS-модуль, skill на migration, skill на review. После перехода с CLAUDE.md-монолита на skills расход токенов за сессию упал на 30-40%. Вопрос: как решаете версионирование skills? У нас они устаревают после архитектурных изменений, приходится синхронизировать вручную.
BurntToast отличный выбор для Windows. У меня macOS поэтому osascript, но принцип тот же. Про MCP для БД согласен, это уже must-have, не опция. Возможно стоило включить в список, но тогда 10 превратилось бы в 15.
Интересный опыт. Субагенты это следующий уровень, у меня пока skills как промежуточный шаг. Вопрос: скрипты это bash или что-то своё? Как решаете ситуации где нужен контекст предыдущих сессий, скрипт его не хранит.
По тулам дельное замечание, добавлю в settings. По токенам vs символам: сознательно выбрал символы чтобы не зависеть от модели, у разных токенизаторов разное соотношение. Для Claude это примерно 1к токенов = 4к символов латиницы, для кириллицы чуть меньше. Но согласен что в контексте Claude Code правильнее мыслить в токенах.
По settings.json и acceptEdits: это вопрос сколько прерываний по умолчанию. У меня было 15-20 за сессию, стало 2-3. Если изначально меньше, то да, смысла нет. По безопасности согласен, полной гарантии нет, это friction barrier: чуть медленнее случайно ошибиться. Реальная безопасность только через внешнюю песочницу как ты справедливо написал. По skills солидарен, это лучшее из списка.
Согласен что для большинства задач один запрос с явными критериями дешевле и быстрее. Использую multi-model именно там где ставки высокие: структура базы данных, публичный API или ядро системы, что тяжело переделать. Там 20 лишних минут и $2 на токены оправдывают себя даже если выигрыш 10-15% в качестве решения. На рутинных задачах согласен, один промпт с 3 вариантами работает не хуже.
Понял логику: изолируешь то что можно формально проверить, делаешь автоматически, остальное принимаешь как человеческое решение. Сам к этому пришёл, только через 3-4 болезненных кейса когда пытался загнать субъективное в схему и ложных срабатываний было больше реальных. Что имеешь в виду под «не ручками»? Есть какой-то трюк?
Про пересечение замечаний точно, это и есть правильный критерий. Если 80% дублей, второй взгляд не усиливает, только замедляет. Codex на Claude Code не пробовал, но идея понятна: разные базы обучения, разные слепые пятна. Один вопрос: при конфликтующих ревью кто побеждает, или это повод задать вопрос автору?
Пробовал CodeRabbit на нескольких проектах. Основная проблема: он не знает ваш контекст, нашу архитектуру, наши паттерны, почему именно так написали. Комментирует по общим правилам и часто то что уже обсуждено и принято намеренно. Как первый взгляд со стороны полезно, но 60-70% его замечаний у нас были шум.
Хуки стоит попробовать. Начинал с простого: Stop hook после каждой сессии пишет что изменилось и почему в отдельный файл. Думал что overhead. На третьей сессии понял что вхожу в контекст за минуту вместо 10-15, агент не переспрашивает решённые вопросы. Дальше можно усложнять, но уже это работает.
Плотность абстракций лучше описывает проблему чем размер батча. У меня похожая точка разреза: сколько разных файлов нужно держать в голове чтобы принять одно решение. Три и меньше, батч большой. Пять и больше, режу агрессивно. С type inference всё сложнее, там решения каскадируют и часто не видно заранее насколько далеко цепочка тянется.
Провисшие допущения, хороший термин. У нас были такие же случаи, план фиксировал инвариант, критик его не оспаривал, а оспорить надо было. Добавил в процесс шаг: после закрытия плана явно перечисляем каждое допущение и задаём вопрос «что если это неправда». За два месяца поймали так три кейса, один из которых точно ушёл бы в прод без этого.
У нас похожий кейс был с C# проектом с жёстким контрактом. Основной вывод совпадает: работает там где у LLM есть точный контракт и проверяемый результат. Без этого вайб-кодинг превращается в вайб-дебаггинг. Как решили зависимости между модулями, у нас там обычно начинается нагромождение?
Узнал себя в CLAUDE.md на 7000 токенов. Прошли через это. Сломало то что решение описывалось и дублировалось, а не паттерн из которого агент сам вывел правило. Перешли на скиллы: каждый отвечает за один процесс, короткий, конкретный. Агент не держит весь контекст одновременно. Идея с авто-обновлением памяти через outcomes интересная, мы что-то похожее делаем через post-session hooks, но без формализации.
«Дрейфующая гранулярность» точное название. Наблюдаем то же самое: код сначала монолит, потом сам вырисовывает границы через боль. У нас сигнал что граница проведена не там, когда CLAUDE.md одного модуля начинает ссылаться на детали соседнего. Про перекладывание разделения на ИИ интересно, пробовали? Мы пару раз просили Claude предложить разбивку, результат неплохой но требует ревью.
У нас та же картина с Claude и GPT-4: Claude находит «вот здесь строка упадёт при null», GPT-4 говорит «вот здесь слабое место по архитектуре». Приём со столкновением агентов возьму в работу, у нас пока второй взгляд это ручной второй чат. Вопрос: финальное решение при разногласии всегда человеческое или бывает что вес аргументации одной стороны явно перевешивает?
BurntToast отличный выбор для Windows. У меня macOS поэтому osascript, но принцип тот же. Про MCP для БД согласен, это уже must-have, не опция. Возможно стоило включить в список, но тогда 10 превратилось бы в 15.
Тема с 152-ФЗ актуальна: именно из-за неё часть кодовых задач у нас не уходит во внешний API. Но перед дообучением пробовали ещё один шаг: хорошо структурированный контекст через CLAUDE.md + примеры из нашей базы. Для задач где у модели достаточно способностей, но не хватает контекста, это дешевле и быстрее дообучения. Вопрос: на каком пороге сложности выбирали дообучение, а не RAG или prompt engineering?
Гранулярность на уровне модулей: именно к этому пришёл сам после 200к строк с AI. Только у нас дополнительный слой: CLAUDE.md описывает границы каждого модуля явно, чтобы агент не «видел» соседей без необходимости. Получился примерно тот же принцип, каждый модуль самодостаточен и не требует контекста других. Интересно, у вас это получилось эволюционно или изначально закладывали?
Концепция «зафиксировать процесс через skill» прямо совпадает с тем, к чему сам пришёл за несколько месяцев. Структура похожая, только для backend: skill на NestJS-модуль, skill на migration, skill на review. После перехода с CLAUDE.md-монолита на skills расход токенов за сессию упал на 30-40%. Вопрос: как решаете версионирование skills? У нас они устаревают после архитектурных изменений, приходится синхронизировать вручную.
.
BurntToast отличный выбор для Windows. У меня macOS поэтому osascript, но принцип тот же. Про MCP для БД согласен, это уже must-have, не опция. Возможно стоило включить в список, но тогда 10 превратилось бы в 15.
Интересный опыт. Субагенты это следующий уровень, у меня пока skills как промежуточный шаг. Вопрос: скрипты это bash или что-то своё? Как решаете ситуации где нужен контекст предыдущих сессий, скрипт его не хранит.
По тулам дельное замечание, добавлю в settings. По токенам vs символам: сознательно выбрал символы чтобы не зависеть от модели, у разных токенизаторов разное соотношение. Для Claude это примерно 1к токенов = 4к символов латиницы, для кириллицы чуть меньше. Но согласен что в контексте Claude Code правильнее мыслить в токенах.
По settings.json и acceptEdits: это вопрос сколько прерываний по умолчанию. У меня было 15-20 за сессию, стало 2-3. Если изначально меньше, то да, смысла нет. По безопасности согласен, полной гарантии нет, это friction barrier: чуть медленнее случайно ошибиться. Реальная безопасность только через внешнюю песочницу как ты справедливо написал. По skills солидарен, это лучшее из списка.
Согласен что для большинства задач один запрос с явными критериями дешевле и быстрее. Использую multi-model именно там где ставки высокие: структура базы данных, публичный API или ядро системы, что тяжело переделать. Там 20 лишних минут и $2 на токены оправдывают себя даже если выигрыш 10-15% в качестве решения. На рутинных задачах согласен, один промпт с 3 вариантами работает не хуже.
Понял логику: изолируешь то что можно формально проверить, делаешь автоматически, остальное принимаешь как человеческое решение. Сам к этому пришёл, только через 3-4 болезненных кейса когда пытался загнать субъективное в схему и ложных срабатываний было больше реальных. Что имеешь в виду под «не ручками»? Есть какой-то трюк?
Про пересечение замечаний точно, это и есть правильный критерий. Если 80% дублей, второй взгляд не усиливает, только замедляет. Codex на Claude Code не пробовал, но идея понятна: разные базы обучения, разные слепые пятна. Один вопрос: при конфликтующих ревью кто побеждает, или это повод задать вопрос автору?
Пробовал CodeRabbit на нескольких проектах. Основная проблема: он не знает ваш контекст, нашу архитектуру, наши паттерны, почему именно так написали. Комментирует по общим правилам и часто то что уже обсуждено и принято намеренно. Как первый взгляд со стороны полезно, но 60-70% его замечаний у нас были шум.
Хуки стоит попробовать. Начинал с простого: Stop hook после каждой сессии пишет что изменилось и почему в отдельный файл. Думал что overhead. На третьей сессии понял что вхожу в контекст за минуту вместо 10-15, агент не переспрашивает решённые вопросы. Дальше можно усложнять, но уже это работает.
Плотность абстракций лучше описывает проблему чем размер батча. У меня похожая точка разреза: сколько разных файлов нужно держать в голове чтобы принять одно решение. Три и меньше, батч большой. Пять и больше, режу агрессивно. С type inference всё сложнее, там решения каскадируют и часто не видно заранее насколько далеко цепочка тянется.
Провисшие допущения, хороший термин. У нас были такие же случаи, план фиксировал инвариант, критик его не оспаривал, а оспорить надо было. Добавил в процесс шаг: после закрытия плана явно перечисляем каждое допущение и задаём вопрос «что если это неправда». За два месяца поймали так три кейса, один из которых точно ушёл бы в прод без этого.
У нас похожий кейс был с C# проектом с жёстким контрактом. Основной вывод совпадает: работает там где у LLM есть точный контракт и проверяемый результат. Без этого вайб-кодинг превращается в вайб-дебаггинг. Как решили зависимости между модулями, у нас там обычно начинается нагромождение?
Узнал себя в CLAUDE.md на 7000 токенов. Прошли через это. Сломало то что решение описывалось и дублировалось, а не паттерн из которого агент сам вывел правило. Перешли на скиллы: каждый отвечает за один процесс, короткий, конкретный. Агент не держит весь контекст одновременно. Идея с авто-обновлением памяти через outcomes интересная, мы что-то похожее делаем через post-session hooks, но без формализации.