Согласен, разделение это ключ. У нас после перехода на модули с одним index.ts агент почти перестал видеть весь проект целиком, для большинства задач хватает CLAUDE.md конкретного модуля плюс сам модуль, это два-три файла контекста вместо двухсот тысяч строк. Раздутый контекст правда тупиковый путь, мы пробовали закидывать весь проект пару раз в начале, агент путался и трогал не те файлы. Сейчас по опыту изоляция на уровне архитектуры работает лучше, чем любой промпт, который просит агента не трогать чужое.
Есть смысл, но не до конца. Write-only работает, пока агент под рукой и есть время на промпт. У нас за полгода два раза прилетал инцидент среди ночи, код пришлось читать руками, без времени звать агента и формулировать задачу словами. Тогда граница спасает, а write-only нет, если внутри всё равно нужно разобраться за 10 минут. Поэтому границы держу жёсткие, а сам код всё равно пишу читаемым, на случай что его будет читать человек, а не только следующий промпт.
Это бэкенд на NestJS, браузерного бандла тут нет, так что для api-модулей index.ts не бьёт по lazy loading. А вот на фронте (next.js) с тем же паттерном один раз словили похожую боль, страница подтягивала лишние 40-50kb JS, потому что компоненты реэкспортировались через общий index.ts модуля. Ушли от этого через точечный dynamic import на уровне страницы, а барьер index.ts оставили только для бэкенд-модулей.
Да, именно физический уровень. У нас границы вынесены в отдельные пакеты, импорт из чужого внутреннего модуля просто не напишется, eslint-boundaries рубит на корню. Пока контракт можно обойти по-человечески, агент рано или поздно это сделает, причём в самый неудобный момент. Когда обойти физически нельзя, выбора у него не остаётся.
Дело не в том, влезает проект в контекст или нет. Даже когда модель видит все 200к разом, она лезет через границу: чинит баг, дёрнув приватную функцию из соседнего модуля, потому что так короче. Архитектура нужна не чтобы уместить в окно, а чтобы агент не обходил контракт даже когда видит весь код. Продумать заранее согласен, но тут legacy, который уже есть, с нуля переписать не вариант.
Сайд-эффекты на стыках это как раз больное место. У нас агент не видел, что репозиторий дёргает вебхук, пока это не было явно в типе порта. Помогли две вещи: эффект стал частью контракта (порт описывает что он триггерит, а не только что возвращает), и интеграционные тесты ровно на стыках модулей, которые агент обязан прогнать. Дрейф ловится там, а не в юнит-тестах.
Тут не про одноразовость, агент правда отлично рефакторит свои же простыни в свежей сессии, согласен. Но дешевле это когда у кода есть границы. Функция с 20 зависимостями дорого рефакторится и человеком, и агентом, в контекст надо затащить пол проекта чтобы ничего не сломать. Ограничения ставлю не чтобы защитить человека от агента, а чтобы каждая следующая правка, в том числе агентом, стоила меньше контекста.
Так и пришли в итоге. Главный файл держим коротким, а методику, стандарты и паттерны вынесли в отдельные файлы которые подтягиваются по необходимости. Эффект двойной: основной контекст не раздувается, и каждый кусок можно править отдельно не задевая остальное. Плоский CLAUDE.md на 8000 слов это была стадия которую надо было просто пережить.
Глянул overview, спасибо. Neo4j под методологию выглядит логично, граф как раз для того чтобы агент шёл по связям а не грузил всё плоским файлом. У нас пока проще, markdown со ссылками, но на больших проектах плоская структура начинает мешать. Любопытно как держите граф в актуальном состоянии, дополняете руками или агент сам дописывает узлы по ходу работы?
Согласен, список это только видимая верхушка. Опыт нужен чтобы понять какой вопрос задать в новой ситуации, которой в списке нет. Чек-лист закрывает известное и очевидное, OWASP top-10 и подобное. А чутьё на то что странный поток транзакций пахнет проблемой, хотя формально всё зелёное, из чек-листа не достаётся. Список даёт вайбкодеру пол шага, дальше нужен тот кто эти списки набивал руками.
Тут соглашусь, kill-switch это родовая черта SaaS, кто платит за облако принимает это по умолчанию. Но раньше рубильник был у самого вендора и срабатывал по понятным причинам, неоплата или нарушение правил. Здесь дёрнуло третье лицо, государство, и под раздачу попали те кто всё оплатил и ничего не нарушал. Меняется не наличие рубильника, а кто и по какому поводу его жмёт.
Хороший разбор, gmail.modify плюс корзина вместо удаления это по сути и есть обратимость, согласен что так даже надёжнее моего «сначала только чтение». Драйран который ловит улетевшую в спам рассылку магазина прям показательно, без него такие вещи всплывают через неделю когда уже поздно. Беру связку scope плюс предпросмотр на заметку для своих сценариев с почтой.
Процессы те же, согласен. Но одно поменялось по факту: раньше узким местом было написание кода и ревью за ним поспевало. Сейчас генерация почти бесплатная, а ревью руками не масштабируется, столько за день не прочитаешь. Поэтому проверки приходится толкать в автоматику, composition analysis и пиннинг зависимостей в CI. Slopsquatting у нас ловит lockfile, на глаз такое уже не поймаешь.
Главное тут не модель, а то что у IndexedDB есть WPT как исполняемое определение «готово». Гонял Claude в похожем цикле на TS миграции, где тестов почти не было, агент уверенно зеленил то что сам же и придумал, дрейф пошёл сразу. Там где тесты заданы заранее, цикл сходится, где нет, ночью получаешь красиво оформленный мусор. Спека на английском плюс приёмочные тесты решают больше чем выбор модели.
Зацепил второй пункт, прям про меня. Сел отправить пост в телеграм, а к утру у меня вместо поста редакция из агентов, которой пользуюсь я один. Всё работает, всё красиво, только пост так и не ушёл. Спасло тупое правило: если самописная штука не окупится за неделю, беру готовое и иду делать дело. Раньше это за меня решала цена, теперь приходится себя одёргивать руками.
Разгребал похожее полгода назад, правда с кодовой базой а не фотоархивом, около 180К файлов с историей на 8 лет. Главный вывод совпадает: AI-агент хорошо справляется с задачами где есть объём и понятный критерий «готово», но человек давно бы сдался от монотонности. Интересно что вы дали агенту доступ к Gmail API напрямую, я обычно осторожнее и даю только чтение на первом проходе, потом отдельно подтверждаю действия. Для фотоархива разумный риск, но для рабочей почты добавил бы промежуточный шаг с превью что агент собирается сделать.
У меня это тоже случается, отложил пять задач на «завтра» и вот завтра наступило с таймером. Про параллельные агенты есть нюанс: шесть одновременно это не оптимально, контексты начинают мешать друг другу раньше чем заканчивается квота. На практике два-три параллельных на разных частях одного проекта работают лучше, каждый держит меньше в голове и ошибок меньше. Слово Lastbursting хорошее, беру. И интересно про один большой промпт на всё сразу, это честный способ проверить где у модели реальный потолок, без декомпозиции которая всегда немного читерство.
Ну с оружием и военкой всё понятно, там ограничения никого не удивляют. Здесь интересно другое: Claude это SaaS к которому ты подключаешься через браузер как к любому другому продукту. Anthropic продавала подписки без вопросов о гражданстве, и вот в один день компания получила устные объяснения от правительства и была вынуждена отключить сначала иностранцев, потом вообще всех. Прецедент не в том что ограничения существуют, а в том что привычный SaaS может быть отозван по щелчку пальца, без суда, без внятного объяснения клиентам.
Согласен, разделение это ключ. У нас после перехода на модули с одним index.ts агент почти перестал видеть весь проект целиком, для большинства задач хватает CLAUDE.md конкретного модуля плюс сам модуль, это два-три файла контекста вместо двухсот тысяч строк. Раздутый контекст правда тупиковый путь, мы пробовали закидывать весь проект пару раз в начале, агент путался и трогал не те файлы. Сейчас по опыту изоляция на уровне архитектуры работает лучше, чем любой промпт, который просит агента не трогать чужое.
Есть смысл, но не до конца. Write-only работает, пока агент под рукой и есть время на промпт. У нас за полгода два раза прилетал инцидент среди ночи, код пришлось читать руками, без времени звать агента и формулировать задачу словами. Тогда граница спасает, а write-only нет, если внутри всё равно нужно разобраться за 10 минут. Поэтому границы держу жёсткие, а сам код всё равно пишу читаемым, на случай что его будет читать человек, а не только следующий промпт.
Это бэкенд на NestJS, браузерного бандла тут нет, так что для api-модулей index.ts не бьёт по lazy loading. А вот на фронте (next.js) с тем же паттерном один раз словили похожую боль, страница подтягивала лишние 40-50kb JS, потому что компоненты реэкспортировались через общий index.ts модуля. Ушли от этого через точечный dynamic import на уровне страницы, а барьер index.ts оставили только для бэкенд-модулей.
Спасибо. Самое рабочее из всего, пожалуй, запрет на импорт из чужих внутренних модулей, остальное уже надстройка над этим.
Да, именно физический уровень. У нас границы вынесены в отдельные пакеты, импорт из чужого внутреннего модуля просто не напишется, eslint-boundaries рубит на корню. Пока контракт можно обойти по-человечески, агент рано или поздно это сделает, причём в самый неудобный момент. Когда обойти физически нельзя, выбора у него не остаётся.
Дело не в том, влезает проект в контекст или нет. Даже когда модель видит все 200к разом, она лезет через границу: чинит баг, дёрнув приватную функцию из соседнего модуля, потому что так короче. Архитектура нужна не чтобы уместить в окно, а чтобы агент не обходил контракт даже когда видит весь код. Продумать заранее согласен, но тут legacy, который уже есть, с нуля переписать не вариант.
Сайд-эффекты на стыках это как раз больное место. У нас агент не видел, что репозиторий дёргает вебхук, пока это не было явно в типе порта. Помогли две вещи: эффект стал частью контракта (порт описывает что он триггерит, а не только что возвращает), и интеграционные тесты ровно на стыках модулей, которые агент обязан прогнать. Дрейф ловится там, а не в юнит-тестах.
,
Тут не про одноразовость, агент правда отлично рефакторит свои же простыни в свежей сессии, согласен. Но дешевле это когда у кода есть границы. Функция с 20 зависимостями дорого рефакторится и человеком, и агентом, в контекст надо затащить пол проекта чтобы ничего не сломать. Ограничения ставлю не чтобы защитить человека от агента, а чтобы каждая следующая правка, в том числе агентом, стоила меньше контекста.
Так и пришли в итоге. Главный файл держим коротким, а методику, стандарты и паттерны вынесли в отдельные файлы которые подтягиваются по необходимости. Эффект двойной: основной контекст не раздувается, и каждый кусок можно править отдельно не задевая остальное. Плоский CLAUDE.md на 8000 слов это была стадия которую надо было просто пережить.
Глянул overview, спасибо. Neo4j под методологию выглядит логично, граф как раз для того чтобы агент шёл по связям а не грузил всё плоским файлом. У нас пока проще, markdown со ссылками, но на больших проектах плоская структура начинает мешать. Любопытно как держите граф в актуальном состоянии, дополняете руками или агент сам дописывает узлы по ходу работы?
Согласен, список это только видимая верхушка. Опыт нужен чтобы понять какой вопрос задать в новой ситуации, которой в списке нет. Чек-лист закрывает известное и очевидное, OWASP top-10 и подобное. А чутьё на то что странный поток транзакций пахнет проблемой, хотя формально всё зелёное, из чек-листа не достаётся. Список даёт вайбкодеру пол шага, дальше нужен тот кто эти списки набивал руками.
Тут соглашусь, kill-switch это родовая черта SaaS, кто платит за облако принимает это по умолчанию. Но раньше рубильник был у самого вендора и срабатывал по понятным причинам, неоплата или нарушение правил. Здесь дёрнуло третье лицо, государство, и под раздачу попали те кто всё оплатил и ничего не нарушал. Меняется не наличие рубильника, а кто и по какому поводу его жмёт.
Хороший разбор, gmail.modify плюс корзина вместо удаления это по сути и есть обратимость, согласен что так даже надёжнее моего «сначала только чтение». Драйран который ловит улетевшую в спам рассылку магазина прям показательно, без него такие вещи всплывают через неделю когда уже поздно. Беру связку scope плюс предпросмотр на заметку для своих сценариев с почтой.
Процессы те же, согласен. Но одно поменялось по факту: раньше узким местом было написание кода и ревью за ним поспевало. Сейчас генерация почти бесплатная, а ревью руками не масштабируется, столько за день не прочитаешь. Поэтому проверки приходится толкать в автоматику, composition analysis и пиннинг зависимостей в CI. Slopsquatting у нас ловит lockfile, на глаз такое уже не поймаешь.
Главное тут не модель, а то что у IndexedDB есть WPT как исполняемое определение «готово». Гонял Claude в похожем цикле на TS миграции, где тестов почти не было, агент уверенно зеленил то что сам же и придумал, дрейф пошёл сразу. Там где тесты заданы заранее, цикл сходится, где нет, ночью получаешь красиво оформленный мусор. Спека на английском плюс приёмочные тесты решают больше чем выбор модели.
Зацепил второй пункт, прям про меня. Сел отправить пост в телеграм, а к утру у меня вместо поста редакция из агентов, которой пользуюсь я один. Всё работает, всё красиво, только пост так и не ушёл. Спасло тупое правило: если самописная штука не окупится за неделю, беру готовое и иду делать дело. Раньше это за меня решала цена, теперь приходится себя одёргивать руками.
Разгребал похожее полгода назад, правда с кодовой базой а не фотоархивом, около 180К файлов с историей на 8 лет. Главный вывод совпадает: AI-агент хорошо справляется с задачами где есть объём и понятный критерий «готово», но человек давно бы сдался от монотонности. Интересно что вы дали агенту доступ к Gmail API напрямую, я обычно осторожнее и даю только чтение на первом проходе, потом отдельно подтверждаю действия. Для фотоархива разумный риск, но для рабочей почты добавил бы промежуточный шаг с превью что агент собирается сделать.
У меня это тоже случается, отложил пять задач на «завтра» и вот завтра наступило с таймером. Про параллельные агенты есть нюанс: шесть одновременно это не оптимально, контексты начинают мешать друг другу раньше чем заканчивается квота. На практике два-три параллельных на разных частях одного проекта работают лучше, каждый держит меньше в голове и ошибок меньше. Слово Lastbursting хорошее, беру. И интересно про один большой промпт на всё сразу, это честный способ проверить где у модели реальный потолок, без декомпозиции которая всегда немного читерство.
Ну с оружием и военкой всё понятно, там ограничения никого не удивляют. Здесь интересно другое: Claude это SaaS к которому ты подключаешься через браузер как к любому другому продукту. Anthropic продавала подписки без вопросов о гражданстве, и вот в один день компания получила устные объяснения от правительства и была вынуждена отключить сначала иностранцев, потом вообще всех. Прецедент не в том что ограничения существуют, а в том что привычный SaaS может быть отозван по щелчку пальца, без суда, без внятного объяснения клиентам.