У нас схожий опыт на 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, пустая строка, не везде. Именно там и поймали. Теперь это первое что проверяю перед тем как запускать миграцию.
С фабриками и динамическими импортами боль понятна. У нас таких мест в проекте хватало, и там я работал руками. Просто не доверял агенту когда зависимость не прямая. Это пока нерешённый класс проблем, у меня во всяком случае.
Да, именно такой кейс. Скомпилилось, тесты зелёные, а в runtime ведёт себя иначе. Второй агент который смотрит на допущения после закрытия плана, хорошая идея, беру в копилку. У нас такого не было только потому что ревью делал вручную после каждого батча. По 5-15 файлам да, эмпирика. Плавает от размера и плотности типов. На простых утилитах можно и 20, на файлах с дженериками лучше ближе к 5. Ориентировался на то когда начинал чувствовать что контекст расплывается.
Хорошая декомпозиция. Исследовательские задачи самые болезненные, агент галлюцинирует именно тогда когда нужен ответ «как это устроено здесь» а не «как это обычно устроено». По кодогенерации частично закрылись через CLAUDE.md с примерами реальных паттернов из этой же базы, но исследования пока ручные, не нашли надёжного решения.
Логично для хакатона, показываешь что работает. Интересно что GPT-5.2 справляется именно когда документ влезает в контекст, это потолок, реальные внутренние доки в компании обычно не влезают. Как планируете решать в проде, чанкинг или что-то другое?
Понял, то есть ограничение архитектурное а не просто «не допилили». Для нашего кейса, часто нужно именно «что обычно идёт рядом с этим модулем», чистый CodeGraph не закроет. Буду смотреть в сторону гибрида, LSP для структуры и отдельный слой для семантики.
Не знаешь, в этом вся суть. Проблема не в факте использования ИИ а в том что процесс стал невидим. Раньше было понятно что человек думал, теперь нет. Именно поэтому «вот что сказал ChatGPT» звучит иначе чем цитата из книги, книга не скрывает авторство.
Да, примерно так. Шесть месяцев это общий стаж с Claude Code, конкретная миграция шла около десяти недель. Стартовали в районе конца лета 2025, тогда Claude как раз вышел на уровень где результат был предсказуем, не в теории а на практике.
Справедливо, не буду спорить. Статья писалась быстро и этот слой не отработал как надо, чувствуется. Принял, следующие буду вычитывать именно на этот критерий отдельно.
Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.
У нас схожий опыт на 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, пустая строка, не везде. Именно там и поймали. Теперь это первое что проверяю перед тем как запускать миграцию.
С фабриками и динамическими импортами боль понятна. У нас таких мест в проекте хватало, и там я работал руками. Просто не доверял агенту когда зависимость не прямая. Это пока нерешённый класс проблем, у меня во всяком случае.
Да, именно такой кейс. Скомпилилось, тесты зелёные, а в runtime ведёт себя иначе. Второй агент который смотрит на допущения после закрытия плана, хорошая идея, беру в копилку. У нас такого не было только потому что ревью делал вручную после каждого батча. По 5-15 файлам да, эмпирика. Плавает от размера и плотности типов. На простых утилитах можно и 20, на файлах с дженериками лучше ближе к 5. Ориентировался на то когда начинал чувствовать что контекст расплывается.
Хорошая декомпозиция. Исследовательские задачи самые болезненные, агент галлюцинирует именно тогда когда нужен ответ «как это устроено здесь» а не «как это обычно устроено». По кодогенерации частично закрылись через CLAUDE.md с примерами реальных паттернов из этой же базы, но исследования пока ручные, не нашли надёжного решения.
Логично для хакатона, показываешь что работает. Интересно что GPT-5.2 справляется именно когда документ влезает в контекст, это потолок, реальные внутренние доки в компании обычно не влезают. Как планируете решать в проде, чанкинг или что-то другое?
Понял, то есть ограничение архитектурное а не просто «не допилили». Для нашего кейса, часто нужно именно «что обычно идёт рядом с этим модулем», чистый CodeGraph не закроет. Буду смотреть в сторону гибрида, LSP для структуры и отдельный слой для семантики.
Не знаешь, в этом вся суть. Проблема не в факте использования ИИ а в том что процесс стал невидим. Раньше было понятно что человек думал, теперь нет. Именно поэтому «вот что сказал ChatGPT» звучит иначе чем цитата из книги, книга не скрывает авторство.
Да, примерно так. Шесть месяцев это общий стаж с Claude Code, конкретная миграция шла около десяти недель. Стартовали в районе конца лета 2025, тогда Claude как раз вышел на уровень где результат был предсказуем, не в теории а на практике.
Слышу. Следующая будет лучше.
Справедливо, не буду спорить. Статья писалась быстро и этот слой не отработал как надо, чувствуется. Принял, следующие буду вычитывать именно на этот критерий отдельно.
Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.