Вместо вступления
За последний год я заметил странную закономерность. Когда кодовая база была небольшая, все было хорошо, но чем больше кода писал ИИ, тем меньше времени уходило на добавление фичей и больше — на исправление текущего кода. Это сильно раздражало.
Я как будто ходил по кругу:
Сначала мне казалось: сейчас заставлю ИИ самому для себя писать правила. Кол‑во правил росло, сложность росла. Сначала в них переставал ориентироваться я, потом ИИ.
Следующий шаг был: «а что, если вписывать комментарии прямо в код, тогда при чтении ИИ сразу будет понимать контекст». В результате контекстное окно стало нереально большим — коллапс.
Следующий шаг — использовать скиллы. Получился очередной бесконтрольный рост контекста.
Продолжать можно какое‑то время. Мне стало понятно, что любой подход ограничивался бесконтрольным ростом контекстного окна.
Я подумал, что, вероятно, проблема тут системная и связана с тем, что само написание кода было ориентировано на человека, а не на ИИ.
Почему AI тонет в больших кодовых базах
Современная разработка строится вокруг идеи гибкости.
Мы любим:
абстракции
наследование
переиспользование
dependency injection
универсальные интерфейсы
рефакторинг
Для человека это нормально. Человек способен постепенно строить и удерживать в голове карту системы. LLM — нет. Другими словами, разработчик постепенно строит контекст, у ИИ такой возможности так, для LLM каждый запрос. Как первый раз.
Когда проект становится достаточно большим, ИИ начинает делать предсказуемые ошибки:
ломает соседние модули
предлагает ненужные рефакторинги
меняет контракты функций
создает каскадные зависимости
чинит одно место и ломает три других
После нескольких месяцев работы я пришел к неожиданному выводам:
Проблема не в AI;
Проблема в архитектуре.
Если бы код изначально проектировался для AI
Что если принять новую аксиому:
Основным автором кода является AI, а человек является проектировщиком системы.
Тогда многие привычные практики перестают выглядеть разумными:
Почему интерфейсы должны постоянно меняться?
Почему рефакторинг считается нормой?
Почему мы так боимся дублирования кода?
Как каждый модуль узнает о существовании десятков других модулей?
Концепция «прибитого гвоздями интерфейса»
Вместо гибких интерфейсов я начал использовать жесткие контракты. После создания интерфейс больше не изменяется.
Никогда.
Если требования изменились не меняем интерфейс, а создаем новый блок, даже если это выглядит избыточно. Цена нового блока стала практически нулевой. ИИ напишет его за секунды. Есть и минусы: цена связности становится высокой.
Дерево вместо графа
Большинство проектов постепенно превращаются в граф. Каждый модуль знает о многих других. Я начал экспериментировать со строго древовидной структурой. Каждый уровень может импортировать только родительские уровни. Соседние ветки не знают друг о друге. Получается не самая элегантная архитектура. Но зато она предсказуема для ИИ.
Отказ от рефакторинга
Самая спорная идея.
Если реализация плохая:
не исправлять.
удалить.
переписать целиком.
Если нужен новый сценарий:
не расширять.
создать новый блок.
Если нужен новый контракт:
не модифицировать.
создать новый интерфейс.
Звучит радикально. Но когда код пишет ИИ, стоимость переписывания становится нулевой. Если раньше разработчик старался максимально переиспользовать существующий код, то теперь ИИ способен написать новый модуль за секунды. Зато цена связности никуда не исчезла.
Что остается человеку
Если ИИ пишет код, то ценность смещается.
Менее важными становятся:
знание API наизусть
ручной рефакторинг
работа с огромными графами зависимостей
Более важными становятся:
декомпозиция
проектирование интерфейсов
архитектурные ограничения
понимание предметной области
Человек становится оператором фабрики, а не токарем у станка.
Это гипотеза, а не религия
Я не утверждаю, что это заменит существующие подходы.
Я не утверждаю, что это подойдет для всех проектов.
Но я все чаще замечаю, что все практики классической разработки появились в эпоху, когда код писал человек, а это 40–50 лет.
Если код начинает писать ИИ, возможно, некоторые из этих практик стоит пересмотреть или создать новые.
Именно вокруг этой идеи я начал собирать открытый проект.
А позже она привела меня к созданию второго проекта.
Интересно посмотреть, насколько далеко можно зайти, если проектировать системы не для программиста, а для модели.