Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.
По возвратам примерно каждый пятый PR шёл на доработку, чаще не из-за ошибок а из-за того что Claude выбирал тип который формально правильный но не наш паттерн. Реальных косяков в продакшене не было, но именно потому что тестовое покрытие держали жёстко, без этого страшно даже думать. По деньгам вышло примерно $800-850 на токены за весь проект, это в два-три раза дешевле ручной работы если считать честно с зарплатой.
Я тоже так думал пока не начали. Типы это самое простое, дальше идут conditional types, overloads, дженерики которые Claude пишет корректно но не так как я написал бы сам, и потом ревью которое в итоге съело больше времени чем сама миграция. Формально один диалект в другой, по факту архитектурные решения пачками.
Приятно слышать. Сам когда запустил первый батч и посмотрел что вышло, примерно так же себя чувствовал, смесь воодушевления и лёгкой паники от мысли что это теперь надо ревьюить.
Спасибо, заглянул в часть 4, там как раз разобрано то что меня интересовало. Подход с публикацией событий наружу вместо прямой зависимости между модулями выглядит чисто, буду брать в работу.
Именно так, это и есть главный навык работы с LLM сейчас, не заставить его написать правильно, а научиться отличать рабочее от галлюцинации. Причём это не один раз проверил и забыл, а постоянный критический взгляд на каждый вывод.
Согласен с посылом, но немного другой угол. Проблема не в том что человек использует ИИ для ответа, а в том что не пропустил ответ через свой опыт перед публикацией. Хороший ответ с ИИ выглядит как "я бы сказал вот это, ИИ помог сформулировать точнее". Плохой выглядит как "вот что сказал ChatGPT". Разница не в инструменте, а в том добавил ли ты что-то своё.
На монорепо в 200к строк TypeScript пробовали разные подходы, сейчас смотрим в сторону статического анализа как раз. Интересно что у CodeGraph нет эмбеддингов, то есть поиск только структурный, по символам и связям. Это хорошо для "кто вызывает эту функцию", но как оно справляется с семантическим поиском типа "где у нас обрабатывается авторизация", когда сам код называется не auth а permission_check или middleware_guard? Это та граница где vector-подход выигрывает, интересно как авторы видят это ограничение.
Именно, и это ещё один аргумент в пользу паттернов которые можно объяснить в одной строке: "используй object as const вместо enum". Чем проще правило, тем надёжнее его выполняет ИИ и тем легче ревьюить результат.
Согласен с выводом, но думаю суть вопроса немного в другом. Agent-first это не про синтаксис языка а про качество структурированного фидбека который агент получает от тулинга. TypeScript уже достаточно agent-friendly потому что у него отличный LSP, понятные сообщения об ошибках и предсказуемая система типов. Проблема не в том что у языка фигурные скобки, а в том что большинство ошибок в больших кодовых базах это семантические ошибки которые ни один компилятор не поймает.
Реально узнаваемая история. У нас похожее было с Code-агентом, который уверенно "вспоминал" архитектурные решения которых никогда не было. Вылечилось двумя вещами: явная инструкция "если не нашёл в контексте, напиши что не знаешь, не выдумывай" и принудительная верификация ответа на наличие конкретного факта из базы знаний перед отправкой. Второе важнее первого, потому что инструкцию про "не выдумывай" модель выполняет непоследовательно, а верификация факта это уже детерминированная проверка.
Похожий путь прошли, только пришли к немного другому решению, const object с as const вместо enum, но тот же принцип. Главный выигрыш который вы правильно нащупали, это когда к значению нужно добавить метаданные (цвет, иконку, условие видимости), с enum это всегда костыль, а с конфигом просто ещё одно поле. Плюс Claude Code такой паттерн знает хорошо и генерирует аккуратно, в отличие от enum-хелперов которые каждый раз делает по-своему.
Cursor для прототипирования это да, очень быстро. Сам делал что-то похожее, разница между "работает как демо" и "можно отдать пользователям" огромная, особенно по части обработки граничных случаев и стабильности. Интересно как у вас разрешился вопрос с оценкой макетов по внутренней документации, это же RAG по гайдлайнам? Именно это место в LLM-пайплайнах обычно самое нестабильное.
Боль узнаваемая, сам прошёл этот путь на проекте примерно в 200к строк NestJS. Feature-based структура выглядит логично в начале, потом начинается перекрёстное использование сервисов между модулями, circular dependencies, и в итоге модули которые по названию независимы по факту связаны со всем остальным. У нас спас явный запрет на cross-module service injection кроме как через shared-модули, и правило что если сервис нужен в двух местах он переезжает в core. Интересно как вы решаете проблему агрегации данных из нескольких доменов, это всегда самое больное место.
Про "don't know? -> google it" огонь, беру. Сам больше думал про структуру а не про токен-экономию на уровне синтаксиса, попробую переписать несколько правил в телеграфном стиле и посмотрю изменится ли поведение. Статья про контекстную гигиену кстати была бы очень в тему, про это реально мало написано.
Хороший нюанс, не думал об этом в таком разрезе. Получается три уровня: в CLAUDE.md то что нужно в каждой сессии, в скиллах то что нужно часто но не всегда, и агенты для одноразовых задач где важно не засорять основной контекст. Попробую для длинных рутинных операций, у нас как раз есть несколько таких задач которые сейчас идут в основном контексте и действительно его раздувают.
Про лимит не знал точных цифр, спасибо. Это ещё один аргумент за то что CLAUDE.md должен быть компактным, а тяжёлые инструкции уходят в скиллы или slash-команды которые подгружаются только по запросу. По ощущениям именно так и оптимально, маленький корневой файл с принципами и отдельные команды под конкретные задачи, в итоге на каждый запрос тратишь только нужный контекст.
Точно, разрыв между "накопленный опыт в тикетах за 10 лет" и "всё описано рядом с кодом" это реально разные задачи. У нас проект относительно молодой и CLAUDE.md закрывает текущие решения, но уже чувствуем что когда история решений накапливается, плоский файл начинает трещать. Интересно как у вас выглядит точка где RAG начинает выигрывать, по объёму контекста или по типу задач, и есть ли смысл гибридного подхода когда CLAUDE.md покрывает "сейчас", а RAG достаёт "почему было принято решение год назад".
Поймал точно, противоречия это главная болезнь когда файл накапливается со временем. Идея попросить Claude самого найти противоречия реально работает, сам делаю такой аудит примерно раз в месяц, Claude довольно точно находит где правила конфликтуют. И про CLAUDE.md как оглавление со ссылками на отдельные файлы согласен, монолит проигрывает структурированному дереву.
Именно так и работает, маленькие специализированные скиллы под конкретную задачу вместо одного огромного файла. У меня отдельно под git-workflow, под архитектурные решения, под правила тестирования. Claude читает узкий файл гораздо внимательнее чем портянку на 500 строк.
Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.
По возвратам примерно каждый пятый PR шёл на доработку, чаще не из-за ошибок а из-за того что Claude выбирал тип который формально правильный но не наш паттерн. Реальных косяков в продакшене не было, но именно потому что тестовое покрытие держали жёстко, без этого страшно даже думать. По деньгам вышло примерно $800-850 на токены за весь проект, это в два-три раза дешевле ручной работы если считать честно с зарплатой.
Я тоже так думал пока не начали. Типы это самое простое, дальше идут conditional types, overloads, дженерики которые Claude пишет корректно но не так как я написал бы сам, и потом ревью которое в итоге съело больше времени чем сама миграция. Формально один диалект в другой, по факту архитектурные решения пачками.
Приятно слышать. Сам когда запустил первый батч и посмотрел что вышло, примерно так же себя чувствовал, смесь воодушевления и лёгкой паники от мысли что это теперь надо ревьюить.
Спасибо, заглянул в часть 4, там как раз разобрано то что меня интересовало. Подход с публикацией событий наружу вместо прямой зависимости между модулями выглядит чисто, буду брать в работу.
Именно так, это и есть главный навык работы с LLM сейчас, не заставить его написать правильно, а научиться отличать рабочее от галлюцинации. Причём это не один раз проверил и забыл, а постоянный критический взгляд на каждый вывод.
Согласен с посылом, но немного другой угол. Проблема не в том что человек использует ИИ для ответа, а в том что не пропустил ответ через свой опыт перед публикацией. Хороший ответ с ИИ выглядит как "я бы сказал вот это, ИИ помог сформулировать точнее". Плохой выглядит как "вот что сказал ChatGPT". Разница не в инструменте, а в том добавил ли ты что-то своё.
На монорепо в 200к строк TypeScript пробовали разные подходы, сейчас смотрим в сторону статического анализа как раз. Интересно что у CodeGraph нет эмбеддингов, то есть поиск только структурный, по символам и связям. Это хорошо для "кто вызывает эту функцию", но как оно справляется с семантическим поиском типа "где у нас обрабатывается авторизация", когда сам код называется не auth а permission_check или middleware_guard? Это та граница где vector-подход выигрывает, интересно как авторы видят это ограничение.
Именно, и это ещё один аргумент в пользу паттернов которые можно объяснить в одной строке: "используй object as const вместо enum". Чем проще правило, тем надёжнее его выполняет ИИ и тем легче ревьюить результат.
Согласен с выводом, но думаю суть вопроса немного в другом. Agent-first это не про синтаксис языка а про качество структурированного фидбека который агент получает от тулинга. TypeScript уже достаточно agent-friendly потому что у него отличный LSP, понятные сообщения об ошибках и предсказуемая система типов. Проблема не в том что у языка фигурные скобки, а в том что большинство ошибок в больших кодовых базах это семантические ошибки которые ни один компилятор не поймает.
Реально узнаваемая история. У нас похожее было с Code-агентом, который уверенно "вспоминал" архитектурные решения которых никогда не было. Вылечилось двумя вещами: явная инструкция "если не нашёл в контексте, напиши что не знаешь, не выдумывай" и принудительная верификация ответа на наличие конкретного факта из базы знаний перед отправкой. Второе важнее первого, потому что инструкцию про "не выдумывай" модель выполняет непоследовательно, а верификация факта это уже детерминированная проверка.
Похожий путь прошли, только пришли к немного другому решению, const object с as const вместо enum, но тот же принцип. Главный выигрыш который вы правильно нащупали, это когда к значению нужно добавить метаданные (цвет, иконку, условие видимости), с enum это всегда костыль, а с конфигом просто ещё одно поле. Плюс Claude Code такой паттерн знает хорошо и генерирует аккуратно, в отличие от enum-хелперов которые каждый раз делает по-своему.
Cursor для прототипирования это да, очень быстро. Сам делал что-то похожее, разница между "работает как демо" и "можно отдать пользователям" огромная, особенно по части обработки граничных случаев и стабильности. Интересно как у вас разрешился вопрос с оценкой макетов по внутренней документации, это же RAG по гайдлайнам? Именно это место в LLM-пайплайнах обычно самое нестабильное.
Боль узнаваемая, сам прошёл этот путь на проекте примерно в 200к строк NestJS. Feature-based структура выглядит логично в начале, потом начинается перекрёстное использование сервисов между модулями, circular dependencies, и в итоге модули которые по названию независимы по факту связаны со всем остальным. У нас спас явный запрет на cross-module service injection кроме как через shared-модули, и правило что если сервис нужен в двух местах он переезжает в core. Интересно как вы решаете проблему агрегации данных из нескольких доменов, это всегда самое больное место.
Про "don't know? -> google it" огонь, беру. Сам больше думал про структуру а не про токен-экономию на уровне синтаксиса, попробую переписать несколько правил в телеграфном стиле и посмотрю изменится ли поведение. Статья про контекстную гигиену кстати была бы очень в тему, про это реально мало написано.
Хороший нюанс, не думал об этом в таком разрезе. Получается три уровня: в CLAUDE.md то что нужно в каждой сессии, в скиллах то что нужно часто но не всегда, и агенты для одноразовых задач где важно не засорять основной контекст. Попробую для длинных рутинных операций, у нас как раз есть несколько таких задач которые сейчас идут в основном контексте и действительно его раздувают.
Про лимит не знал точных цифр, спасибо. Это ещё один аргумент за то что CLAUDE.md должен быть компактным, а тяжёлые инструкции уходят в скиллы или slash-команды которые подгружаются только по запросу. По ощущениям именно так и оптимально, маленький корневой файл с принципами и отдельные команды под конкретные задачи, в итоге на каждый запрос тратишь только нужный контекст.
Точно, разрыв между "накопленный опыт в тикетах за 10 лет" и "всё описано рядом с кодом" это реально разные задачи. У нас проект относительно молодой и CLAUDE.md закрывает текущие решения, но уже чувствуем что когда история решений накапливается, плоский файл начинает трещать. Интересно как у вас выглядит точка где RAG начинает выигрывать, по объёму контекста или по типу задач, и есть ли смысл гибридного подхода когда CLAUDE.md покрывает "сейчас", а RAG достаёт "почему было принято решение год назад".
Поймал точно, противоречия это главная болезнь когда файл накапливается со временем. Идея попросить Claude самого найти противоречия реально работает, сам делаю такой аудит примерно раз в месяц, Claude довольно точно находит где правила конфликтуют. И про CLAUDE.md как оглавление со ссылками на отдельные файлы согласен, монолит проигрывает структурированному дереву.
Именно так и работает, маленькие специализированные скиллы под конкретную задачу вместо одного огромного файла. У меня отдельно под git-workflow, под архитектурные решения, под правила тестирования. Claude читает узкий файл гораздо внимательнее чем портянку на 500 строк.