Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.
По возвратам примерно каждый пятый PR шёл на доработку, чаще не из-за ошибок а из-за того что Claude выбирал тип который формально правильный но не наш паттерн. Реальных косяков в продакшене не было, но именно потому что тестовое покрытие держали жёстко, без этого страшно даже думать. По деньгам вышло примерно $800-850 на токены за весь проект, это в два-три раза дешевле ручной работы если считать честно с зарплатой.
Я тоже так думал пока не начали. Типы это самое простое, дальше идут conditional types, overloads, дженерики которые Claude пишет корректно но не так как я написал бы сам, и потом ревью которое в итоге съело больше времени чем сама миграция. Формально один диалект в другой, по факту архитектурные решения пачками.
Приятно слышать. Сам когда запустил первый батч и посмотрел что вышло, примерно так же себя чувствовал, смесь воодушевления и лёгкой паники от мысли что это теперь надо ревьюить.
Спасибо, заглянул в часть 4, там как раз разобрано то что меня интересовало. Подход с публикацией событий наружу вместо прямой зависимости между модулями выглядит чисто, буду брать в работу.
Именно так, это и есть главный навык работы с LLM сейчас, не заставить его написать правильно, а научиться отличать рабочее от галлюцинации. Причём это не один раз проверил и забыл, а постоянный критический взгляд на каждый вывод.
Согласен с посылом, но немного другой угол. Проблема не в том что человек использует ИИ для ответа, а в том что не пропустил ответ через свой опыт перед публикацией. Хороший ответ с ИИ выглядит как "я бы сказал вот это, ИИ помог сформулировать точнее". Плохой выглядит как "вот что сказал ChatGPT". Разница не в инструменте, а в том добавил ли ты что-то своё.
Точно та же история с CLAUDE.md. Полтора года назад писал в него подробные инструкции с объяснением логики, сейчас оставил только ограничения и правила вывода. Verbose CoT в промпте это действительно был workaround для моделей без внутреннего рассуждения, сейчас он мешает. Единственное что у меня по-прежнему работает из старого арсенала это явные примеры формата вывода, Claude уважает независимо от уровня thinking. А вот role-play действительно умер, согласен.
На монорепо в 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. Интересно как вы решаете проблему агрегации данных из нескольких доменов, это всегда самое больное место.
Практически всё совпадает с тем что видели у нас. Когда пытались просто заменить отдельные шаги в существующем процессе агентом, получили +10-15% скорости. Когда перепроектировали процесс целиком под агентный подход, получили совсем другие цифры. Ключевой момент про институциональную экспертизу точный, у нас именно те люди которые могут правильно настроить контекст агента, это те же кто глубоко знает предметную область. Без этих людей агент генерирует быстро но генерирует неправильно.
Про "don't know? -> google it" огонь, беру. Сам больше думал про структуру а не про токен-экономию на уровне синтаксиса, попробую переписать несколько правил в телеграфном стиле и посмотрю изменится ли поведение. Статья про контекстную гигиену кстати была бы очень в тему, про это реально мало написано.
Хороший нюанс, не думал об этом в таком разрезе. Получается три уровня: в CLAUDE.md то что нужно в каждой сессии, в скиллах то что нужно часто но не всегда, и агенты для одноразовых задач где важно не засорять основной контекст. Попробую для длинных рутинных операций, у нас как раз есть несколько таких задач которые сейчас идут в основном контексте и действительно его раздувают.
Про лимит не знал точных цифр, спасибо. Это ещё один аргумент за то что CLAUDE.md должен быть компактным, а тяжёлые инструкции уходят в скиллы или slash-команды которые подгружаются только по запросу. По ощущениям именно так и оптимально, маленький корневой файл с принципами и отдельные команды под конкретные задачи, в итоге на каждый запрос тратишь только нужный контекст.
Точно, разрыв между "накопленный опыт в тикетах за 10 лет" и "всё описано рядом с кодом" это реально разные задачи. У нас проект относительно молодой и CLAUDE.md закрывает текущие решения, но уже чувствуем что когда история решений накапливается, плоский файл начинает трещать. Интересно как у вас выглядит точка где RAG начинает выигрывать, по объёму контекста или по типу задач, и есть ли смысл гибридного подхода когда CLAUDE.md покрывает "сейчас", а RAG достаёт "почему было принято решение год назад".
Согласен, у нас это решалось через правило в CLAUDE.md что перед изменением публичных интерфейсов надо выписать план и дождаться ок. Не идеально, иногда пропускал, но лучше чем ничего. Хочется чтобы это было встроено в модель, а не костыль через промпт.
По возвратам примерно каждый пятый PR шёл на доработку, чаще не из-за ошибок а из-за того что Claude выбирал тип который формально правильный но не наш паттерн. Реальных косяков в продакшене не было, но именно потому что тестовое покрытие держали жёстко, без этого страшно даже думать. По деньгам вышло примерно $800-850 на токены за весь проект, это в два-три раза дешевле ручной работы если считать честно с зарплатой.
Я тоже так думал пока не начали. Типы это самое простое, дальше идут conditional types, overloads, дженерики которые Claude пишет корректно но не так как я написал бы сам, и потом ревью которое в итоге съело больше времени чем сама миграция. Формально один диалект в другой, по факту архитектурные решения пачками.
Приятно слышать. Сам когда запустил первый батч и посмотрел что вышло, примерно так же себя чувствовал, смесь воодушевления и лёгкой паники от мысли что это теперь надо ревьюить.
Спасибо, заглянул в часть 4, там как раз разобрано то что меня интересовало. Подход с публикацией событий наружу вместо прямой зависимости между модулями выглядит чисто, буду брать в работу.
Именно так, это и есть главный навык работы с LLM сейчас, не заставить его написать правильно, а научиться отличать рабочее от галлюцинации. Причём это не один раз проверил и забыл, а постоянный критический взгляд на каждый вывод.
Согласен с посылом, но немного другой угол. Проблема не в том что человек использует ИИ для ответа, а в том что не пропустил ответ через свой опыт перед публикацией. Хороший ответ с ИИ выглядит как "я бы сказал вот это, ИИ помог сформулировать точнее". Плохой выглядит как "вот что сказал ChatGPT". Разница не в инструменте, а в том добавил ли ты что-то своё.
Точно та же история с CLAUDE.md. Полтора года назад писал в него подробные инструкции с объяснением логики, сейчас оставил только ограничения и правила вывода. Verbose CoT в промпте это действительно был workaround для моделей без внутреннего рассуждения, сейчас он мешает. Единственное что у меня по-прежнему работает из старого арсенала это явные примеры формата вывода, Claude уважает независимо от уровня thinking. А вот role-play действительно умер, согласен.
На монорепо в 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. Интересно как вы решаете проблему агрегации данных из нескольких доменов, это всегда самое больное место.
Практически всё совпадает с тем что видели у нас. Когда пытались просто заменить отдельные шаги в существующем процессе агентом, получили +10-15% скорости. Когда перепроектировали процесс целиком под агентный подход, получили совсем другие цифры. Ключевой момент про институциональную экспертизу точный, у нас именно те люди которые могут правильно настроить контекст агента, это те же кто глубоко знает предметную область. Без этих людей агент генерирует быстро но генерирует неправильно.
Про "don't know? -> google it" огонь, беру. Сам больше думал про структуру а не про токен-экономию на уровне синтаксиса, попробую переписать несколько правил в телеграфном стиле и посмотрю изменится ли поведение. Статья про контекстную гигиену кстати была бы очень в тему, про это реально мало написано.
Хороший нюанс, не думал об этом в таком разрезе. Получается три уровня: в CLAUDE.md то что нужно в каждой сессии, в скиллах то что нужно часто но не всегда, и агенты для одноразовых задач где важно не засорять основной контекст. Попробую для длинных рутинных операций, у нас как раз есть несколько таких задач которые сейчас идут в основном контексте и действительно его раздувают.
Про лимит не знал точных цифр, спасибо. Это ещё один аргумент за то что CLAUDE.md должен быть компактным, а тяжёлые инструкции уходят в скиллы или slash-команды которые подгружаются только по запросу. По ощущениям именно так и оптимально, маленький корневой файл с принципами и отдельные команды под конкретные задачи, в итоге на каждый запрос тратишь только нужный контекст.
Точно, разрыв между "накопленный опыт в тикетах за 10 лет" и "всё описано рядом с кодом" это реально разные задачи. У нас проект относительно молодой и CLAUDE.md закрывает текущие решения, но уже чувствуем что когда история решений накапливается, плоский файл начинает трещать. Интересно как у вас выглядит точка где RAG начинает выигрывать, по объёму контекста или по типу задач, и есть ли смысл гибридного подхода когда CLAUDE.md покрывает "сейчас", а RAG достаёт "почему было принято решение год назад".