У нас та же картина с 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 описывает границы каждого модуля явно, чтобы агент не «видел» соседей без необходимости. Получился примерно тот же принцип, каждый модуль самодостаточен и не требует контекста других. Интересно, у вас это получилось эволюционно или изначально закладывали?
Узнал себя в «агент соглашается, потом пишет по-своему». Наш ответ: не запреты, а антипаттерны с примерами из нашей базы. Вместо «не используй sigmoid», пишем «вот как это решается у нас, вот что нельзя и почему это сломало prod». Код из живого проекта весит больше чем правило из текста. Не панацея, но на 200к строк JS→TS нас спасло именно это.
Концепция «зафиксировать процесс через 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 и 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 описывает границы каждого модуля явно, чтобы агент не «видел» соседей без необходимости. Получился примерно тот же принцип, каждый модуль самодостаточен и не требует контекста других. Интересно, у вас это получилось эволюционно или изначально закладывали?
Узнал себя в «агент соглашается, потом пишет по-своему». Наш ответ: не запреты, а антипаттерны с примерами из нашей базы. Вместо «не используй sigmoid», пишем «вот как это решается у нас, вот что нельзя и почему это сломало prod». Код из живого проекта весит больше чем правило из текста. Не панацея, но на 200к строк JS→TS нас спасло именно это.
Концепция «зафиксировать процесс через 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, но без формализации.