Понял логику: изолируешь то что можно формально проверить, делаешь автоматически, остальное принимаешь как человеческое решение. Сам к этому пришёл, только через 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, но без формализации.
Мы пробовали двухагентный ревью на TS-миграции: один пишет, второй проверяет допущения. Нашёл пару незаметных edge cases, но шума было раза в три больше реальных проблем. Вывод про «цена ошибки > цена токенов» точный, у нас примерно так и работало. Один момент который добавил: без human gate workflow уходит в самосогласование, агенты начинают закрывать находки друг друга. Нужен явный скептик.
У нас схожий опыт на TypeScript/Node.js. DDD + Clean Architecture позволили описать проект в 20 строк CLAUDE.md. Без архитектурных границ пришлось бы писать 200, контекст всё равно был бы размытым. Про разбивку файла согласен, упёрлись в монолит на 8000 токенов и перешли на скиллы. Orleans с акторами сам по себе задаёт хорошие границы агрегатов, Claude этот паттерн понимает точно.
Похожая идея, только снаружи а не через hooks. Внешний скрипт даёт больше контроля: промпт можно менять между итерациями, модели переключать. У нас был похожий loop на локальных LLM для рутины, остановились на трёх итерациях максимум иначе уходит в занос. Как решаете задачи где нет формальных тестов, там критерий готовности всегда субъективный?
YOLO Classifier узнал случайно когда смотрел source для дебага. Правило на обычном английском которое позволяет деструктивные операции на staging, это мощно. У нас в CLAUDE.md это было через workaround, а оказывается есть нативный механизм. Про hooks и stdout тоже не знал, беру в копилку.
Пробовал похожий подход с hooks ещё до того как Ralph стал мемом. Работает именно там где описано: тесты зелёные, линтер чист, сборка прошла. Сломался на задачах где “готово” субъективно. Агент уходил в цикл переписывания одного и того же куска по-разному. Главный вывод: completion promise должен быть машиночитаемым. “Выглядит хорошо” не работает. “Все тесты прошли” работает.
Согласен. Я имел в виду не процент, а сам факт что граничные случаи теперь описаны и проверены, пусть и несовершенно. До этого их не было вообще. Процент сам по себе не метрика.
Знакомо. У нас тоже поначалу называли это “ненужными проверками”. Переломный момент был когда именно простой граничный случай сломал прод. После этого разговор стал другим.
Именно. Мы раньше тоже срезали на граничниках, “потом допишем”. Потом превращалось в никогда. Сейчас описываю кейсы словами, Claude пишет тесты за минуту. Уровень покрытия вырос, и это не заслуга дисциплины, просто стоимость написать тест упала до нуля.
Вот именно. Особенно когда спрашиваешь мнение, а в ответ прилетает текст из пяти пунктов про смежные вещи. Может человек и потратил два часа на промпт, но результат не прочёл. По формату всегда видно.
Да, название не самоочевидное. ts-clean-arch-create было бы понятнее при первом взгляде. Выбрал archkit намеренно. Планирую 3-4 шаблона внутри, не только library-clean, и не хотел зашивать стек в имя. Но без статьи это загадка, согласен.
Согласен. У нас тесты на бизнес-логику были, а вот граничные случаи, null, undefined, пустая строка, не везде. Именно там и поймали. Теперь это первое что проверяю перед тем как запускать миграцию.
С фабриками и динамическими импортами боль понятна. У нас таких мест в проекте хватало, и там я работал руками. Просто не доверял агенту когда зависимость не прямая. Это пока нерешённый класс проблем, у меня во всяком случае.
Понял логику: изолируешь то что можно формально проверить, делаешь автоматически, остальное принимаешь как человеческое решение. Сам к этому пришёл, только через 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, но без формализации.
Мы пробовали двухагентный ревью на TS-миграции: один пишет, второй проверяет допущения. Нашёл пару незаметных edge cases, но шума было раза в три больше реальных проблем. Вывод про «цена ошибки > цена токенов» точный, у нас примерно так и работало. Один момент который добавил: без human gate workflow уходит в самосогласование, агенты начинают закрывать находки друг друга. Нужен явный скептик.
У нас схожий опыт на TypeScript/Node.js. DDD + Clean Architecture позволили описать проект в 20 строк CLAUDE.md. Без архитектурных границ пришлось бы писать 200, контекст всё равно был бы размытым. Про разбивку файла согласен, упёрлись в монолит на 8000 токенов и перешли на скиллы. Orleans с акторами сам по себе задаёт хорошие границы агрегатов, Claude этот паттерн понимает точно.
Похожая идея, только снаружи а не через hooks. Внешний скрипт даёт больше контроля: промпт можно менять между итерациями, модели переключать. У нас был похожий loop на локальных LLM для рутины, остановились на трёх итерациях максимум иначе уходит в занос. Как решаете задачи где нет формальных тестов, там критерий готовности всегда субъективный?
YOLO Classifier узнал случайно когда смотрел source для дебага. Правило на обычном английском которое позволяет деструктивные операции на staging, это мощно. У нас в CLAUDE.md это было через workaround, а оказывается есть нативный механизм. Про hooks и stdout тоже не знал, беру в копилку.
Пробовал похожий подход с hooks ещё до того как Ralph стал мемом. Работает именно там где описано: тесты зелёные, линтер чист, сборка прошла. Сломался на задачах где “готово” субъективно. Агент уходил в цикл переписывания одного и того же куска по-разному. Главный вывод: completion promise должен быть машиночитаемым. “Выглядит хорошо” не работает. “Все тесты прошли” работает.
Согласен. Я имел в виду не процент, а сам факт что граничные случаи теперь описаны и проверены, пусть и несовершенно. До этого их не было вообще. Процент сам по себе не метрика.
Знакомо. У нас тоже поначалу называли это “ненужными проверками”. Переломный момент был когда именно простой граничный случай сломал прод. После этого разговор стал другим.
Именно. Мы раньше тоже срезали на граничниках, “потом допишем”. Потом превращалось в никогда. Сейчас описываю кейсы словами, Claude пишет тесты за минуту. Уровень покрытия вырос, и это не заслуга дисциплины, просто стоимость написать тест упала до нуля.
Вот именно. Особенно когда спрашиваешь мнение, а в ответ прилетает текст из пяти пунктов про смежные вещи. Может человек и потратил два часа на промпт, но результат не прочёл. По формату всегда видно.
Да, название не самоочевидное. ts-clean-arch-create было бы понятнее при первом взгляде. Выбрал archkit намеренно. Планирую 3-4 шаблона внутри, не только library-clean, и не хотел зашивать стек в имя. Но без статьи это загадка, согласен.
Согласен. У нас тесты на бизнес-логику были, а вот граничные случаи, null, undefined, пустая строка, не везде. Именно там и поймали. Теперь это первое что проверяю перед тем как запускать миграцию.
С фабриками и динамическими импортами боль понятна. У нас таких мест в проекте хватало, и там я работал руками. Просто не доверял агенту когда зависимость не прямая. Это пока нерешённый класс проблем, у меня во всяком случае.