+1 Да, это хорошая формулировка. Я бы добавил только, что ключевой момент не в замене рефакторинга как практики, а в контроле радиуса изменений через неизменяемые контракты.
Согласен с примером — это как раз иллюстрация обратного случая: когда границы системы не были зафиксированы, и переписывание затронуло слишком большой радиус изменений.
И на самом деле это хорошо подтверждает мою гипотезу, а не опровергает её.
Проблема возникает не из-за самого факта переписывания, а из-за отсутствия изоляции и стабильных контрактов между частями системы.
В моей модели ключевая идея как раз в том, что:
переписывание допустимо и даже желательно, но только внутри строго ограниченного блока с неизменяемым интерфейсом
То есть система должна быть устроена так, чтобы:
изменение не могло “расползаться” по зависимостям
влияние каждого блока было формально ограничено контрактом
любая замена была локальной и проверяемой
В этом смысле описанный кейс — это не контраргумент, а пример системы, где эти ограничения отсутствовали.
И именно это отсутствие границ и приводит к тем самым катастрофическим эффектам при AI-генерации или массовом переписывании.
Я не имел в виду, что переписанный ИИ код автоматически будет правильным. Разумеется, новая реализация тоже может содержать ошибки.
Скорее я говорю о стоимости изменения.
Если блок имеет жёсткий интерфейс и не влияет на остальную систему, то его можно переписывать много раз практически без риска для соседних частей проекта.
А вот стоимость ошибки в связанной системе обычно выше. Изменение общего базового класса, контракта или поведения может затронуть множество зависимых компонентов сразу.
Моя гипотеза состоит не в том, что ИИ пишет без багов, а в том, что для ИИ дешевле многократно регенерировать небольшую изолированную реализацию, чем безопасно изменять сильно связанную систему, сохраняя все существующие зависимости.
Именно поэтому в статье основной акцент был не на качестве генерации, а на уменьшении связности и фиксированных контрактах.
Я не утверждаю, что послойная архитектура, модульность или инкапсуляция перестали работать. Наоборот, моя гипотеза выросла именно из попыток строить системы с понятными границами.
Проблема, которую я наблюдал, была немного другой.
Человек постепенно строит ментальную модель системы. Если он два часа назад изменил интерфейс или переименовал метод, то обычно помнит об этом и учитывает последствия.
Для LLM каждая новая итерация в каком-то смысле начинается заново. Модель не обладает долговременным пониманием проекта и каждый раз восстанавливает картину из доступного контекста.
Поэтому возникает ситуация, когда изменение в одном месте исправляется, а в другом месте начинает проявляться старая версия представления о системе. Отсюда и эффект «починили здесь — сломали там».
Моя гипотеза не в том, что существующие архитектуры плохие.
Скорее в том, что если проектировать систему исходя из ограничений LLM — минимизировать связность, фиксировать контракты и делать блоки максимально независимыми, — то масштаб, с которым ИИ способен работать без ошибок, может оказаться существенно больше.
Собственно, статью я и написал как попытку проверить эту гипотезу, а не как утверждение, что нашёл универсальную замену существующим подходам.
p.s. Ответ на вопрос: я не знаю. Я не считал строки и в базу не заглядывал.
Не совсем, вероятно, я плохо выразил основную мысль.
Моя гипотеза не в том, что рефакторинг плох сам по себе или что нужно бездумно плодить дублирование.
Идея была в другом.
Когда проект становится достаточно большим, ИИ начинает ломать его из-за связности. Наследование, графы импортов, неявные зависимости и постоянно меняющиеся контракты требуют удерживать в контексте слишком большой объём системы одновременно.
Человек постепенно строит ментальную модель проекта. ИИ каждый раз вынужден восстанавливать её заново из ограниченного контекста.
Поэтому моя гипотеза звучит скорее так:
Если убрать большую часть связности и собирать систему из независимых блоков с наглухо прибитыми интерфейсами, то ИИ сможет работать с существенно большими системами.
В такой модели реализация блока становится расходным материалом. Если блок работает неправильно, мы не трогаем соседние части системы. Мы просто переписываем реализацию внутри того же контракта.
Стоимость такой операции для ИИ становится близкой к нулю, потому что переписывается не система целиком, а изолированный блок с заранее известным интерфейсом.
Возможно, это тупиковая идея. Возможно, это просто переоткрытие старых архитектурных принципов под новым углом. Но мне кажется интересным посмотреть, как изменятся оптимальные архитектурные решения, если исходить из предположения, что основной автор кода — не человек, а модель.
+1 Да, это хорошая формулировка. Я бы добавил только, что ключевой момент не в замене рефакторинга как практики, а в контроле радиуса изменений через неизменяемые контракты.
Согласен с примером — это как раз иллюстрация обратного случая: когда границы системы не были зафиксированы, и переписывание затронуло слишком большой радиус изменений.
И на самом деле это хорошо подтверждает мою гипотезу, а не опровергает её.
Проблема возникает не из-за самого факта переписывания, а из-за отсутствия изоляции и стабильных контрактов между частями системы.
В моей модели ключевая идея как раз в том, что:
То есть система должна быть устроена так, чтобы:
изменение не могло “расползаться” по зависимостям
влияние каждого блока было формально ограничено контрактом
любая замена была локальной и проверяемой
В этом смысле описанный кейс — это не контраргумент, а пример системы, где эти ограничения отсутствовали.
И именно это отсутствие границ и приводит к тем самым катастрофическим эффектам при AI-генерации или массовом переписывании.
Справедливое замечание.
Возможно, термин «отказ от рефакторинга» действительно оказался слишком провокационным.
Я скорее имел в виду отказ от постоянного изменения уже существующих контрактов и постепенного усложнения старых модулей.
Если смотреть формально, то полная замена реализации при сохранении интерфейса действительно тоже может считаться разновидностью рефакторинга.
Наверное, точнее будет сказать так:
Не «не рефакторить», а «предпочитать замену изолированного блока изменению связанной системы».
В статье меня интересовала именно эта разница.
Согласен, баги никуда не исчезают.
Наверное, я неудачно сформулировал мысль.
Я не имел в виду, что переписанный ИИ код автоматически будет правильным. Разумеется, новая реализация тоже может содержать ошибки.
Скорее я говорю о стоимости изменения.
Если блок имеет жёсткий интерфейс и не влияет на остальную систему, то его можно переписывать много раз практически без риска для соседних частей проекта.
А вот стоимость ошибки в связанной системе обычно выше. Изменение общего базового класса, контракта или поведения может затронуть множество зависимых компонентов сразу.
Моя гипотеза состоит не в том, что ИИ пишет без багов, а в том, что для ИИ дешевле многократно регенерировать небольшую изолированную реализацию, чем безопасно изменять сильно связанную систему, сохраняя все существующие зависимости.
Именно поэтому в статье основной акцент был не на качестве генерации, а на уменьшении связности и фиксированных контрактах.
И да, и нет.
Я не утверждаю, что послойная архитектура, модульность или инкапсуляция перестали работать. Наоборот, моя гипотеза выросла именно из попыток строить системы с понятными границами.
Проблема, которую я наблюдал, была немного другой.
Человек постепенно строит ментальную модель системы. Если он два часа назад изменил интерфейс или переименовал метод, то обычно помнит об этом и учитывает последствия.
Для LLM каждая новая итерация в каком-то смысле начинается заново. Модель не обладает долговременным пониманием проекта и каждый раз восстанавливает картину из доступного контекста.
Поэтому возникает ситуация, когда изменение в одном месте исправляется, а в другом месте начинает проявляться старая версия представления о системе. Отсюда и эффект «починили здесь — сломали там».
Моя гипотеза не в том, что существующие архитектуры плохие.
Скорее в том, что если проектировать систему исходя из ограничений LLM — минимизировать связность, фиксировать контракты и делать блоки максимально независимыми, — то масштаб, с которым ИИ способен работать без ошибок, может оказаться существенно больше.
Собственно, статью я и написал как попытку проверить эту гипотезу, а не как утверждение, что нашёл универсальную замену существующим подходам.
p.s. Ответ на вопрос: я не знаю. Я не считал строки и в базу не заглядывал.
Если это намек на vibe codding, то это правда.
При стабильном интерфейсе и отсутствии зависимостей, стоимость переписывания будет околонулевой.
Не совсем, вероятно, я плохо выразил основную мысль.
Моя гипотеза не в том, что рефакторинг плох сам по себе или что нужно бездумно плодить дублирование.
Идея была в другом.
Когда проект становится достаточно большим, ИИ начинает ломать его из-за связности. Наследование, графы импортов, неявные зависимости и постоянно меняющиеся контракты требуют удерживать в контексте слишком большой объём системы одновременно.
Человек постепенно строит ментальную модель проекта. ИИ каждый раз вынужден восстанавливать её заново из ограниченного контекста.
Поэтому моя гипотеза звучит скорее так:
В такой модели реализация блока становится расходным материалом. Если блок работает неправильно, мы не трогаем соседние части системы. Мы просто переписываем реализацию внутри того же контракта.
Стоимость такой операции для ИИ становится близкой к нулю, потому что переписывается не система целиком, а изолированный блок с заранее известным интерфейсом.
Возможно, это тупиковая идея. Возможно, это просто переоткрытие старых архитектурных принципов под новым углом. Но мне кажется интересным посмотреть, как изменятся оптимальные архитектурные решения, если исходить из предположения, что основной автор кода — не человек, а модель.