Вместо вступления
За последний год я заметил странную закономерность. Когда кодовая база была небольшая, все было хорошо, но чем больше кода писал ИИ, тем меньше времени уходило на добавление фичей и больше — на исправление текущего кода. Это сильно раздражало.
Я как будто ходил по кругу:
Сначала мне казалось: сейчас заставлю ИИ самому для себя писать правила. Кол‑во правил росло, сложность росла. Сначала в них переставал ориентироваться я, потом ИИ.
Следующий шаг был: «а что, если вписывать комментарии прямо в код, тогда при чтении ИИ сразу будет понимать контекст». В результате контекстное окно стало нереально большим — коллапс.
Следующий шаг — использовать скиллы. Получился очередной бесконтрольный рост контекста.
Продолжать можно какое‑то время. Мне стало понятно, что любой подход ограничивался бесконтрольным ростом контекстного окна.
Я подумал, что, вероятно, проблема тут системная и связана с тем, что само написание кода было ориентировано на человека, а не на ИИ.
Почему AI тонет в больших кодовых базах
Современная разработка строится вокруг идеи гибкости.
Мы любим:
абстракции
наследование
переиспользование
dependency injection
универсальные интерфейсы
рефакторинг
Для человека это нормально. Человек способен постепенно строить и удерживать в голове карту системы. LLM — нет. Другими словами, разработчик постепенно строит контекст, у ИИ такой возможности так, для LLM каждый запрос. Как первый раз.
Когда проект становится достаточно большим, ИИ начинает делать предсказуемые ошибки:
ломает соседние модули
предлагает ненужные рефакторинги
меняет контракты функций
создает каскадные зависимости
чинит одно место и ломает три других
После нескольких месяцев работы я пришел к неожиданному выводам:
Проблема не в AI;
Проблема в архитектуре.
Если бы код изначально проектировался для AI
Что если принять новую аксиому:
Основным автором кода является AI, а человек является проектировщиком системы.
Тогда многие привычные практики перестают выглядеть разумными:
Почему интерфейсы должны постоянно меняться?
Почему рефакторинг считается нормой?
Почему мы так боимся дублирования кода?
Как каждый модуль узнает о существовании десятков других модулей?
Концепция «прибитого гвоздями интерфейса»
Вместо гибких интерфейсов я начал использовать жесткие контракты. После создания интерфейс больше не изменяется.
Никогда.
Если требования изменились не меняем интерфейс, а создаем новый блок, даже если это выглядит избыточно. Цена нового блока стала практически нулевой. ИИ напишет его за секунды. Есть и минусы: цена связности становится высокой.
Дерево вместо графа
Большинство проектов постепенно превращаются в граф. Каждый модуль знает о многих других. Я начал экспериментировать со строго древовидной структурой. Каждый уровень может импортировать только родительские уровни. Соседние ветки не знают друг о друге. Получается не самая элегантная архитектура. Но зато она предсказуема для ИИ.
Отказ от рефакторинга
Самая спорная идея.
Если реализация плохая:
не исправлять.
удалить.
переписать целиком.
Если нужен новый сценарий:
не расширять.
создать новый блок.
Если нужен новый контракт:
не модифицировать.
создать новый интерфейс.
Звучит радикально. Но когда код пишет ИИ, стоимость переписывания становится нулевой. Если раньше разработчик старался максимально переиспользовать существующий код, то теперь ИИ способен написать новый модуль за секунды. Зато цена связности никуда не исчезла.
Что остается человеку
Если ИИ пишет код, то ценность смещается.
Менее важными становятся:
знание API наизусть
ручной рефакторинг
работа с огромными графами зависимостей
Более важными становятся:
декомпозиция
проектирование интерфейсов
архитектурные ограничения
понимание предметной области
Человек становится оператором фабрики, а не токарем у станка.
Это гипотеза, а не религия
Я не утверждаю, что это заменит существующие подходы.
Я не утверждаю, что это подойдет для всех проектов.
Но я все чаще замечаю, что все практики классической разработки появились в эпоху, когда код писал человек, а это 40–50 лет.
Если код начинает писать ИИ, возможно, некоторые из этих практик стоит пересмотреть или создать новые.
Именно вокруг этой идеи я начал собирать открытый проект.
А позже она привела меня к созданию второго проекта.
Интересно посмотреть, насколько далеко можно зайти, если проектировать системы не для программиста, а для модели.
Комментарии (32)
Dhwtj
17.06.2026 16:00Открыл чистую архитектору штоле?
Low coupling high cohesion, слои, ACL, ща до домена дойдешь
Бггг
Lerozo Автор
17.06.2026 16:00Не совсем, вероятно, я плохо выразил основную мысль.
Моя гипотеза не в том, что рефакторинг плох сам по себе или что нужно бездумно плодить дублирование.
Идея была в другом.
Когда проект становится достаточно большим, ИИ начинает ломать его из-за связности. Наследование, графы импортов, неявные зависимости и постоянно меняющиеся контракты требуют удерживать в контексте слишком большой объём системы одновременно.
Человек постепенно строит ментальную модель проекта. ИИ каждый раз вынужден восстанавливать её заново из ограниченного контекста.
Поэтому моя гипотеза звучит скорее так:
Если убрать большую часть связности и собирать систему из независимых блоков с наглухо прибитыми интерфейсами, то ИИ сможет работать с существенно большими системами.
В такой модели реализация блока становится расходным материалом. Если блок работает неправильно, мы не трогаем соседние части системы. Мы просто переписываем реализацию внутри того же контракта.
Стоимость такой операции для ИИ становится близкой к нулю, потому что переписывается не система целиком, а изолированный блок с заранее известным интерфейсом.
Возможно, это тупиковая идея. Возможно, это просто переоткрытие старых архитектурных принципов под новым углом. Но мне кажется интересным посмотреть, как изменятся оптимальные архитектурные решения, если исходить из предположения, что основной автор кода — не человек, а модель.
netricks
17.06.2026 16:00Да. Всё верно. Программирование с агентом требует регулярного переписывания. Переписывание снижает связность и улучшает код. Это, кстати, одна из причин, почему вчитываться в код нейронки бесполезно. Что его толку читать, если уже послезавтра вы его перепишите...
netricks
17.06.2026 16:00Стоит поаккуратней обходиться с терминологией "Отказ от рефакторинга". То что вы предлагаете - это и есть рефакторинг. Ре фактор. Переделение, деление по другому. Это оно и есть
Lerozo Автор
17.06.2026 16:00Справедливое замечание.
Возможно, термин «отказ от рефакторинга» действительно оказался слишком провокационным.
Я скорее имел в виду отказ от постоянного изменения уже существующих контрактов и постепенного усложнения старых модулей.
Если смотреть формально, то полная замена реализации при сохранении интерфейса действительно тоже может считаться разновидностью рефакторинга.
Наверное, точнее будет сказать так:
Не «не рефакторить», а «предпочитать замену изолированного блока изменению связанной системы».
В статье меня интересовала именно эта разница.
olegl84
17.06.2026 16:00У меня ничего не ломается, просто им должен обязательно писать тесты. С помощью ИИ можно сделать близкое к 100 процентам покрытие тестами и этим надо пользоваться. Ну и грамотная архитектура. Я когда и сам писал, всегда использовал дерево а не граф как организацию кода, ибо сложность графа растет экспоненциально а дерева линейно
Lerozo Автор
17.06.2026 16:00Согласен, но
Golden Armada поднимает уровень разработки с уровня кода и архитектуры на уровень описания функциональности, понятной даже человеку без технического бэкграунда.
Пользователь описывает не реализацию, а поведение системы — то, что он ожидает увидеть в результате.
При этом тесты и трейсинги остаются критически важной частью процесса. Они не заменяются и не обесцениваются — наоборот, становятся встроенной частью системы наблюдаемости и проверки корректности.
Просто их роль меняется: это уже не внешний инструмент контроля над кодом, а часть самой архитектуры, обеспечивающая прозрачность и воспроизводимость поведения системы.
amaksr
17.06.2026 16:00У меня тоже мысли в том же направлении идут. Все что мы считаем аксиомой в разработке (OOP, DRY, KISS, Clean code, рефакторинг, и т.п.) имеет целью помочь человеку управляться со сложностью с учетом ментальных ограничений человека:
мы лучше понимаем объекты когда это черный ящик с парой методов,
мы забываем обновить все копии кода если что-то надо поменять, поэтому нужны функции, наследование и прочие приемы повторного использования кода,
нам проще читать чем писать, поэтому упор всегда на читаемость и дедупликацию
нам нужно делать рефакторинг потому что в какой-то момент мы запутались и не можем разобраться в сложности.
и т.д.
У ИИ все по другому:
ИИ проще сгенерировать несколько кусков похожего кода, чем прочитать функцию, реконструировать взаимосвязи и понять что она делает;
от ИИ не надо прятать внутреннюю реализацию объекта, и вообще объект для ИИ может быть не нужен или даже вредить
ИИ легко преобразует код из одного языка или синтаксиса в другой, сохраняя эквивалентность, так что традиционные тесты делаются ненужными
Сейчас код является основным артефактом, определяющим систему. Для ИИ таким артефактом тоже скорее всего будет код, но язык был бы заточен для описания архитектуры, спецификаций, графа зависимостей, движка политик и ограничений и системы формальных контрактов. А сгенерированный код не традиционном ЯП делается вторичен.
И было бы интересно увидеть как будет выглядеть что-то сложное на таком языке. Человеку все равно надо это как-то понимать...
U3DSBVRGE
17.06.2026 16:00если архитектура изначально построена правильно (послойная, с чёткими границами, инкапсуляцией и модульностью), то ИИ отлично с ней справляется.
Значит, проблема автора статьи не в том, что «все архитектуры плохи для ИИ», а в том, что он либо не умеет строить правильную послойную архитектуру, либо его проект был изначально «кашей», и он пытается вылечить её радикальным методом, который справедливо называется костылём.
-
Автор, судя по описанию, допустил ошибки:
Возможно, у него были циклические зависимости или «божественные» классы, которые тянули всё на себе.
Интерфейсы были размытыми или часто менялись.
Отсутствовала строгая иерархия, и модули знали друг о друге слишком много.
Когда он поручал ИИ рефакторинг, тот не мог удержать в голове все неявные связи, потому что их не было видно из кода (например, через глобальные переменные, синглтоны или косвенные вызовы).
В такой ситуации даже человеку трудно рефакторить без ошибок, а ИИ — тем более. Автор решил проблему не исправлением архитектуры (что было бы правильнее), а запретом на рефакторинг и плодя новых сущностей — это действительно выглядит как «я не умею строить нормальную архитектуру, поэтому буду дублировать».
какой размер кодо базы, когда начались проблемы, и какой размер средний одного файла кода?
Lerozo Автор
17.06.2026 16:00И да, и нет.
Я не утверждаю, что послойная архитектура, модульность или инкапсуляция перестали работать. Наоборот, моя гипотеза выросла именно из попыток строить системы с понятными границами.
Проблема, которую я наблюдал, была немного другой.
Человек постепенно строит ментальную модель системы. Если он два часа назад изменил интерфейс или переименовал метод, то обычно помнит об этом и учитывает последствия.
Для LLM каждая новая итерация в каком-то смысле начинается заново. Модель не обладает долговременным пониманием проекта и каждый раз восстанавливает картину из доступного контекста.
Поэтому возникает ситуация, когда изменение в одном месте исправляется, а в другом месте начинает проявляться старая версия представления о системе. Отсюда и эффект «починили здесь — сломали там».
Моя гипотеза не в том, что существующие архитектуры плохие.
Скорее в том, что если проектировать систему исходя из ограничений LLM — минимизировать связность, фиксировать контракты и делать блоки максимально независимыми, — то масштаб, с которым ИИ способен работать без ошибок, может оказаться существенно больше.
Собственно, статью я и написал как попытку проверить эту гипотезу, а не как утверждение, что нашёл универсальную замену существующим подходам.
p.s. Ответ на вопрос: я не знаю. Я не считал строки и в базу не заглядывал.
Hoksmur
17.06.2026 16:00Соглашусь с вами в том, что грамотная архитектура уменьшает и ментальную нагрузку. А вот ИНС как правило не способен создать хорошую архитектуру. Автор в свою очередь прав в том, что сложно для нас - то просто для ИНС и наоборот. Поэтому в проекте с нейросетями надо учитывать этот момент.
-
xna123
17.06.2026 16:00Но когда код пишет ИИ, стоимость переписывания становится нулевой.
Ну нет же. Этот новый код может содержать баги и их придётся исправлять.
Lerozo Автор
17.06.2026 16:00Согласен, баги никуда не исчезают.
Наверное, я неудачно сформулировал мысль.
Я не имел в виду, что переписанный ИИ код автоматически будет правильным. Разумеется, новая реализация тоже может содержать ошибки.
Скорее я говорю о стоимости изменения.
Если блок имеет жёсткий интерфейс и не влияет на остальную систему, то его можно переписывать много раз практически без риска для соседних частей проекта.
А вот стоимость ошибки в связанной системе обычно выше. Изменение общего базового класса, контракта или поведения может затронуть множество зависимых компонентов сразу.
Моя гипотеза состоит не в том, что ИИ пишет без багов, а в том, что для ИИ дешевле многократно регенерировать небольшую изолированную реализацию, чем безопасно изменять сильно связанную систему, сохраняя все существующие зависимости.
Именно поэтому в статье основной акцент был не на качестве генерации, а на уменьшении связности и фиксированных контрактах.
musk
17.06.2026 16:00Но когда код пишет ИИ, стоимость переписывания становится нулевой.
На работе недавно СТО решил «переписать» систему чата с помощью ИИ и crm к ней за несколько выходных, чтобы не платить SaaS. Ну решил удружить бизнесу. Радостно покликал это с фронтом и выкатил это в прод. Итог? XSS, уведенный аккаунт оператора, да еще и последующий ddos сообщениями огромного размера. Вот такая нулевая цена переписывания.
У недобросовестного клиента, в итоге, ничего не получилось, так как я в свое время со скрипом продавил идею принудительного использования впн с авторизацией через ldap и добавлением механизма, который бы вдруг становился очень придирчивым к ip пользователя, если вдруг на входе в апи появлялся бы запрос от пользователя с правами сотрудника. Но код в том числе и crm системы заботливо лежал рядом с кодом чата (километровые портянки js кода), чем пытливый клиент тут же и воспольвался.
А вам удачи.
Lerozo Автор
17.06.2026 16:00Согласен с примером — это как раз иллюстрация обратного случая: когда границы системы не были зафиксированы, и переписывание затронуло слишком большой радиус изменений.
И на самом деле это хорошо подтверждает мою гипотезу, а не опровергает её.
Проблема возникает не из-за самого факта переписывания, а из-за отсутствия изоляции и стабильных контрактов между частями системы.
В моей модели ключевая идея как раз в том, что:
переписывание допустимо и даже желательно, но только внутри строго ограниченного блока с неизменяемым интерфейсом
То есть система должна быть устроена так, чтобы:
изменение не могло “расползаться” по зависимостям
влияние каждого блока было формально ограничено контрактом
любая замена была локальной и проверяемой
В этом смысле описанный кейс — это не контраргумент, а пример системы, где эти ограничения отсутствовали.
И именно это отсутствие границ и приводит к тем самым катастрофическим эффектам при AI-генерации или массовом переписывании.
musk
17.06.2026 16:00Да в общем я со скрипом понял ваш тезис, наверное, становлюсь, как СТО. Однако ничего нового вы, собственно, на мой взгляд, не сказали. Что нарушение и пересмотр контрактов ведет к возможной деградации? Ну, это было известно еще до эпохи ИИ, даже OCP пытался с этим бороться.
roudakov
17.06.2026 16:00А на основании чего вы будете уверены, что код ИИ делает именно то, что ему поручено? Тестами все не покроешь. Контракты дают только формальные границы. Если код - черный ящик, то рано или поздно он сделает то, что не должен делать.
И ладно если цена ошибки несколько часов простоя. А если несколько миллионов в деньгах? Или чья-то жизнь?
Опять же, если вы не читаете и не правите код, не убираете дублирование, неэффективные данные и код… то вы получаете тормозное раздутое приложение.
Сколько с ИИ экспериментирую, все больше убеждаюсь, что он прекрасно делает видимость того что ты хочешь, но стоит копнуть поглубже - логика там совсем не та, что ты закладывал.
Ну а читать ИИ код намного сложнее, чем код человека. Даже если код полностью покрыт комментариями. А если оставить на волю ИИ и архитектуру, это будет код: write only.
Branefuck и то читабельнее.
Lerozo Автор
17.06.2026 16:00Согласен почти со всеми рисками, которые вы описали.
Если цена ошибки — миллионы рублей или человеческая жизнь, то никакая архитектурная идея не отменяет необходимость верификации, аудита, тестирования и ответственности человека.
Но моя гипотеза была немного о другом.
Я не предлагаю доверять ИИ без проверки и не предлагаю превращать систему в набор чёрных ящиков, которые никто не понимает.
Я пытаюсь решить более узкую проблему: как уменьшить вероятность того, что ИИ сломает уже работающую систему при внесении изменений.
Контракты в моей модели нужны не для доказательства корректности логики. Они нужны для ограничения радиуса изменений.
Другими словами, контракт отвечает на вопрос:
"Что этот блок может сломать вокруг себя?"
а не на вопрос:
"Гарантированно ли этот блок реализован без ошибок?"
Это разные задачи.
Что касается качества реализации, тут я скорее придерживаюсь классической инженерной позиции: тесты, ревью, мониторинг, верификация и человек в контуре никуда не исчезают.
Более того, именно потому что ИИ часто пишет неоптимальный или странный код, мне и хочется максимально изолировать такие реализации друг от друга.
Если блок оказался плохим, я хочу иметь возможность заменить только его, не рискуя затронуть десятки зависимых модулей.
Поэтому статья не про отказ от контроля качества. Она скорее про попытку уменьшить связность системы в мире, где значительную часть кода начинает писать модель.
roudakov
17.06.2026 16:00Писать максимально изолированные модули - подход не новый. Он правильный, но в реальных проектах не всегда возможный.
Ограничить область изменений вносимых ИИ - это логично. Отдельный изолированный блок легче проверить, прочитать, понять логику. Он будет меньше контекста отъедать. Опять же, легче локализовать проблему при ошибка.
Но это не "подстраивать архитектуру под ИИ" (а меня именно эта фраза насторожила). Такой подход и для программистов людей хорошо работает.
Я бы сказал, что это небольшая смена парадигмы. Не исправлять плохой код, а писать заново, так как стоимость написания меньше стоимости исправления. Это не отказ от рефакторинга, это рефакторинг и есть. Просто на другом уровне.
В случае ИИ - такой подход может и сработать. Это вполне логичный способ использования ИИ. Генерируем несколько вариантов кода, выбираем тот что больше подходит и доводим до ума вручную. Если модуль достаточно небольшой или типовой - ИИ может даже с первого раза родить что-то вменяемое.
Lerozo Автор
17.06.2026 16:00Ты немного смещаешь фокус на “качество модулей”, но моя мысль вообще не про это.
В классической модели, когда тимлид говорит “почини модуль”, разработчик почти никогда не ограничивается этим модулем. Он вынужден:
понять соседние зависимости
восстановить контекст системы
и по сути сделать мини-рефакторинг всей зоны влияния
Цена изменения высокая — поэтому включается глубокое понимание системы как целого.
С LLM ситуация другая.
LLM действительно может “починить модуль” за 10–20 секунд.
Но это уже не тот же процесс.
Потому что стоимость изменения резко падает, а радиус воздействия изменения резко растёт
И проблема не в том, что “код плохой” или “модули слабые”.
Проблема в том, что система больше не ограничивает последствия изменений через стоимость и время человеческого понимания.
В результате локально всё выглядит правильно, но глобально возникают побочные эффекты в других частях системы и они проявляются не сразу
И отсюда мой тезис:
Если стоимость переписывания кода стремится к нулю, то главным становится не “как писать модули”, а как ограничивать влияние автоматических изменений на остальную систему
И именно поэтому я говорю про усиление изоляции и “утяжеление границ” модулей — не как стиль кода, а как способ контролировать распространение изменений в системе, где цена изменений почти исчезла.
roudakov
17.06.2026 16:00Два нюанса: то о чем вы пишите, об уменьшении влияния модулей, ни как не привязано к ИИ. Это прекрасно работает и на программистах людях и рекомендуется ни один десяток лет. Только это очень сложно реализовать на многих задачах. А так да, идея снизить зависимости, - прекрасна.
Второй нюанс: если вы замените один плохой модуль на другой плохой модуль, чем это поможет? Дешевизна ИИ-шного кода иллюзорна. Вы просто перекладываете стоимость с разработки на тестирование и поддержку.
Да, вы не пишите код неделю. Вы его месяц отлаживаете и переписываете. Причем, уже после того как код вышел в продуктив. Потому что ИИ прекрасно проходит синтетические тесты, на которых он создавался. А в реальной работе всплывают артефакты и человеческий фактор.
Lerozo Автор
17.06.2026 16:00Верно, полностью согласен. Я бы даже сказал, если код пишет ии, а ревьюит человек, то стоимость ии-шного кода нулевая. Скорость не возрастает, Mr быстрее не апрувятся. Это абсолютно точно. Я к этому и веду, что если код пишет ии, то у человека должны быть другие механизмы верификации, другие метрики и подходы к разработке. Какие? Я не знаю. Поэтому я и хотел попробовать начать эту дискуссию.
art3012
17.06.2026 16:00Что если принять новую аксиому: Основным автором кода является AI, а человек является проектировщиком системы.
«А вы, друзья, как ни садитесь, всё в музыканты не годитесь» И. А. Крылов, «Квартет» ИИ-агентов
Lerozo Автор
17.06.2026 16:00Ты немного упрощаешь идею до “AI пишет код, человек проектирует систему”, но это не то, о чём речь.
Если бы всё сводилось к роли “автор vs проектировщик”, это уже давно бы решалось архитектурой и автоматизацией.
Проблема в другом.
Когда стоимость генерации кода становится почти нулевой, меняется не роль человека, а поведение системы:
код начинает меняться слишком быстро
локальные изменения становятся дешёвыми
но их влияние на систему становится непредсказуемым
И в этот момент классическая модель “архитектор → разработчик → код” перестаёт объяснять происходящее.
Дело не в том, кто “пишет код”.
Дело в том, что:
мы больше не успеваем осмыслять последствия изменений на уровне всей системы, потому что скорость модификации превышает скорость человеческого контекстного восприятия
Поэтому вопрос не в том, что AI “заменяет разработчика” или что человек становится “проектировщиком системы”.
Вопрос в другом:
как оценивать поведение системы, если изменения стали настолько быстрыми, что человеческая модель причинно-следственных связей больше не успевает за ними?
И именно здесь появляется идея вроде Golden Armada — не как “новый способ писать код”, а как попытка восстановить наблюдаемость системы на уровне её эволюции, а не отдельных решений.
AlexeyChijov
17.06.2026 16:00Интересные мысли (хотя и очень спорные) о том, каким должен быть код проекта, когда переходим на агентную разработку.
BobovorTheCommentBeast
У меня не получилось забивать винты молотком, поэтому, я заменил их на гвозди, клинья и заклепки.