Comments 18
200к строк это небольшой проект, это излишество, он целиком влезает в контекст опуса
а для более крупных надо просто заранее продумывать архитектуру
Та же проблема в проекте ~150К строк. Bounded contexts + контракты помогают, но AI всё равно не видит сайд-эффекты на стыках модулей. Как решаете?
150к строк полностью влезает в контекст нейронки
Сайд-эффекты на стыках это как раз больное место. У нас агент не видел, что репозиторий дёргает вебхук, пока это не было явно в типе порта. Помогли две вещи: эффект стал частью контракта (порт описывает что он триггерит, а не только что возвращает), и интеграционные тесты ровно на стыках модулей, которые агент обязан прогнать. Дрейф ловится там, а не в юнит-тестах.
Дело не в том, влезает проект в контекст или нет. Даже когда модель видит все 200к разом, она лезет через границу: чинит баг, дёрнув приватную функцию из соседнего модуля, потому что так короче. Архитектура нужна не чтобы уместить в окно, а чтобы агент не обходил контракт даже когда видит весь код. Продумать заранее согласен, но тут legacy, который уже есть, с нуля переписать не вариант.
Согласен, пришел к похожим идеям. Контроль должен быть на физическом уровне - т.е. тупо не должно быть возможности обойти публичные контракты.
Да, именно физический уровень. У нас границы вынесены в отдельные пакеты, импорт из чужого внутреннего модуля просто не напишется, eslint-boundaries рубит на корню. Пока контракт можно обойти по-человечески, агент рано или поздно это сделает, причём в самый неудобный момент. Когда обойти физически нельзя, выбора у него не остаётся.
С конкретными правилами, цифрами до и после, и честным разделом про то, где Clean Architecture начинает мешать самому же агенту.
У вас кусок промта протёк в статью. Заберите свой нейрослоп обратно.
Может стоит чуть-чуть вчитаться в то, что там написано?
Это статья про то, как я перестроил TypeScript-проект на 200 тысяч строк, чтобы Claude Code приносил поддерживаемый код, а не работающий бетон. С конкретными правилами, цифрами до и после, и честным разделом про то, где Clean Architecture начинает мешать самому же агенту.
Перечитайте полный фрагмент.
Понравились советы, как сделать чтобы агент не ломал архитектуру.
И что, в проекте нигде нет lazy loading?
index.ts же тащит в сборщик всё сразу
Это бэкенд на NestJS, браузерного бандла тут нет, так что для api-модулей index.ts не бьёт по lazy loading. А вот на фронте (next.js) с тем же паттерном один раз словили похожую боль, страница подтягивала лишние 40-50kb JS, потому что компоненты реэкспортировались через общий index.ts модуля. Ушли от этого через точечный dynamic import на уровне страницы, а барьер index.ts оставили только для бэкенд-модулей.
Полгода назад я завис над функцией, в которую не мог внести правку.
Так если это аи-функция - то пусть правку и вносит тот кто её создавал (аи). Просто словами описать правку.
Нужно относится к аи-коду - как к write-only, и даже не пытаться вникать (ну если она самодостаточная, чистая).. главное чтоб у говно-аи-кода была граница, а то что там внутри говно-код - не так уже и страшно.. сам же аи и разберётся)
Есть смысл, но не до конца. Write-only работает, пока агент под рукой и есть время на промпт. У нас за полгода два раза прилетал инцидент среди ночи, код пришлось читать руками, без времени звать агента и формулировать задачу словами. Тогда граница спасает, а write-only нет, если внутри всё равно нужно разобраться за 10 минут. Поэтому границы держу жёсткие, а сам код всё равно пишу читаемым, на случай что его будет читать человек, а не только следующий промпт.
Тут везде надо разделять и властвовать :)
Тесты - это отдельная задача, связанная только с техническим заданием (я про тестирование API, например)
Код - это отдельная задача, связанная только с техническим заданием.
В этот момент наглядно видно, что все пошли в разные стороны или, наоборот - в одну.
Еще пришел к тому, что путь с раздуванием контекста модели бесконечно - тупиковый. Очевидно, что каким бы большим проект не был, для отдельно взятой задачи нужен только кусок проекта. То есть нужен внятный контекст самого проекта. Если пишется модуль/плагин/компонента/библиотека и т.п. - не нужно полное техническое задание. Но чаще всего мы даем доступ ко всему проекту потому, что все там обмазано друг с другом.
Всякий раз есть желание отдать агенту изолированный во всех смыслах кусок работы, который бы он вылизывал сколько нужно, обмазывал тестами, сделал описание интерфейса взаимодействия. Но архитектура проектов, чаще всего это не позволяет :(
То, что агент шарится по отдельно взятым файлам работает только на небольших проектах. На больших тоже работает, но из виду все равно многое упускается.
На мой взгляд должен сложиться более удобный подход для агентного кодинга в новых проектах хотя бы потому, что сейчас уже есть более удобные и менее удобные архитектуры. Кто-то, возможно, уже нашел для себя, я вот в поиске и экспериментах :)
Согласен, разделение это ключ. У нас после перехода на модули с одним index.ts агент почти перестал видеть весь проект целиком, для большинства задач хватает CLAUDE.md конкретного модуля плюс сам модуль, это два-три файла контекста вместо двухсот тысяч строк. Раздутый контекст правда тупиковый путь, мы пробовали закидывать весь проект пару раз в начале, агент путался и трогал не те файлы. Сейчас по опыту изоляция на уровне архитектуры работает лучше, чем любой промпт, который просит агента не трогать чужое.
Clean Architecture и AI: как я перестроил проект на 200К строк, чтобы агенты не ломали код