Про линтер и вайбкодинг - как не размазать архитектуру во время сборки проекта

Про линтер и вайбкодинг - как не размазать архитектуру во время сборки проекта.

С недавнего времени наконец-то послушал советы более опытных коллег и решил расширить влияние линтера на рабочий процесс.

Первое, что сделал, вырезал из правил агента что-то типа "следуй архитектуре, пиши не более 500 строк на файл, используй лучшие практики и тд".

Наконец-то принял строгое правило, что если начинаешь проект с нейронкой, то после подготовки спецификаций и плана, я прошу настроить мне линтер так, чтобы проект нельзя было архитектурно разнести.

Потому что нейронка может писать быстро. Но если ей не поставить заборы, она так же быстро начнёт тащить файлы не оттуда, смешивать всё со всем и делать «ну зато работает».

Обычный линтер проверяет пробелы, запятые и неиспользуемые переменные, но для AI-разработки этого мало.

Нам нужен архитектурный линтер, который говорит:

- приложение не лезет во внутренности модулей;

- один модуль не копается в кишках другого;

- общая техническая папка не знает про бизнес-логику;

- бизнес-правила не зависят от страниц, кнопок и API;

- фичи общаются только через понятные публичные входы;

- никаких utils, helpers, common, куда потом сваливается половина проекта;

- никаких круговых зависимостей, когда файл А зависит от Б, Б от В, а В опять от А;

- у всех модулей одинаковая структура папок;

- схема базы лежит в одном главном месте, а не размазана по проекту.

И самое важное: это должно не просто быть написано в документации. Это должно падать командой типа:

pnpm lint:architecture

А перед сдачей:

pnpm verify:release

Вот тогда вайбкодинг становится намного спокойнее. Нейронка всё ещё может ошибаться, но она уже не может тихо развалить архитектуру. Её сразу тормозит проверка.

Хороший запрос к нейронке на старте проекта (когда спецификации и архитектура уже утверждены):

Настрой архитектурный линтер для проекта.

Мне нужно, чтобы он автоматически запрещал:

1. Импорты приложений во внутренние папки модулей.

2. Прямые импорты между модулями, кроме публичных входов.

3. Импорты бизнес-логики в общую техническую папку.

4. Зависимость бизнес-правил от интерфейса, API и фоновых задач.

5. Прямые импорты между соседними фичами.

6. Папки-свалки вроде utils, helpers, common, misc.

7. Циклические зависимости.

8. Отсутствие обязательных папок в модуле.

9. Разные источники правды для схемы базы.

Добавь команды:

- lint

- lint:architecture

- lint:architecture:imports

- lint:architecture:filesystem

- verify:release

И подключи это к CI, чтобы проверки запускались на каждый pull request.

Ну и затем просим нейронку добавить самой себе в AGENTS.md или прочие правила агента, правило: чтобы перед окончанием выполнения запроса она запускала эти проверки линтером.

Итог следующий: сначала ставим нейронке рельсы, потом просим ехать быстро.