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