Год практики с LLM-ассистентами выявил устойчивую закономерность: на небольших проектах модель работает предсказуемо, но по мере роста кодовой базы всё больше времени уходит не на новые функции, а на исправление того, что ИИ сломал в соседних модулях. Автор материала на Habr описывает собственный опыт поиска выхода из этого круга.
Попытки решить проблему через правила, встроенные комментарии и скиллы приводили к одному результату — бесконтрольному росту контекстного окна. Это системное ограничение LLM: в отличие от разработчика, который постепенно строит карту системы в голове, языковая модель каждый раз начинает запрос заново, без накопленного контекста. Когда проект достигает определённого размера, модель начинает делать предсказуемые ошибки: ломает соседние модули, предлагает ненужные рефакторинги, меняет контракты функций и создаёт каскадные зависимости.
Вывод, к которому пришёл автор, звучит контринтуитивно: проблема не в качестве модели, а в архитектуре. Классические практики разработки — абстракции, наследование, dependency injection, универсальные интерфейсы — появились в эпоху, когда код писал человек. Они оптимизированы под когнитивные возможности разработчика, а не под то, как работает LLM.
На этой основе автор сформулировал несколько принципов. Первый — «прибитые гвоздями» интерфейсы: после создания контракт не изменяется никогда. Если требования меняются, создаётся новый блок, даже если это выглядит избыточно. Стоимость нового блока при генерации ИИ близка к нулю, тогда как стоимость связности остаётся высокой. Второй принцип — древовидная структура вместо графа: каждый уровень импортирует только родительские, соседние ветки изолированы. Архитектура получается менее элегантной, зато предсказуемой для модели. Третий принцип — отказ от рефакторинга в пользу полного переписывания: плохую реализацию не исправляют, а удаляют и пишут заново.
Эти идеи прямо противоречат устоявшимся практикам. Переиспользование кода и рефакторинг десятилетиями считались признаком профессионализма именно потому, что написание кода было дорогим. Когда эту стоимость берёт на себя LLM, экономика меняется: дорогой становится связность, а не написание нового модуля. Схожую логику можно увидеть в дискуссиях вокруг микросервисов — там изоляция тоже достигается ценой дублирования, и это считается оправданным компромиссом.
Автор оговаривается, что это гипотеза, а не универсальный рецепт, и подход явно не подходит для всех проектов. Тем не менее он запустил открытый проект вокруг этой идеи и продолжает эксперимент. Для отрасли это сигнал более широкого сдвига: если основным автором кода становится ИИ, то ценность разработчика смещается от знания API и ручного рефакторинга к декомпозиции, проектированию интерфейсов и пониманию предметной области.
