ИИ-агенты и рефакторинг, которого никогда не происходит

Эссе за сентябрь 2026 года на rosenfeld.page о решении, которое, по наблюдениям автора, команды больше не принимают. Претензия не в том, что coding-агенты пишут плохой код. Дело в том, что опытные инженеры перестали говорить: "это стало неуправляемым, нам нужно провести рефакторинг, прежде чем двигаться дальше" ai-agents-refactoring-never-happens.

Триггером было ощущение, что ты запутался

Рассуждение начинается с того, зачем вообще программному обеспечению модульность. Модульность, инкапсуляция и разделение на слои представлены как уступка объёму рабочей памяти человека: систему делят на части до тех пор, пока каждая часть не станет помещаться в голове одного человека. Только так можно безопасно внести изменение или провести код-ревью чужих правок.

Код теряет эту форму из-за обычной текучки требований. Понятное правило обрастает ветвлением под новый случай, затем исключением, потом частным случаем поверх исключения - пока в коде не останутся одни лишь исключения, а от самого правила ничего не останется. Каждый опытный разработчик знает, какой момент наступает следом: ты занимаешься отладкой, идёшь по коду и теряешь нить. Суть мысли автора в том, что раньше это чувство служило сигналом. Запутавшийся сеньор-инженер останавливался и переписывал этот фрагмент, чтобы он и все после него снова могли рассуждать о коде. Этот рефлекс срабатывал из-за человеческих ограничений и был одной из главных сил, поддерживавших долгоживущие системы в пригодном для поддержки состоянии.

Автор аккуратен и не возлагает вину за эту слабость на агентов. Дедлайны, roadmap'ы и менеджеры с вопросами "зачем ты переписываешь то, что работает?" и раньше задвигали рефакторинг в конец списка, а сеньор-инженеры уже перестали сопротивляться этому столь же упорно. Агенты убрали последний внутренний триггер, который всё ещё срабатывал вопреки всему.

Агент никогда не теряет нить

Агент способен прочитать запутанную функцию, отследить каждое место вызова и корректно добавить следующее ветвление, а затем ещё одно - прямо в коде, который в команде уже никто не понимает. Поэтому сигнал так и не появляется. Если только harness, промпт или критерии код-ревью не требуют ставить структуру под сомнение, агент будет поддерживать этот бардак бесконечно, ведь для него этот бардак не представляет проблемы.

Сбой, который беспокоит автора, происходит на стороне людей. Никто в команде не может полноценно рассуждать о ключевых частях системы, код-ревью превращается в формальную отмашку, потому что проверяющий не может уследить за изменением, и команда больше доверяет агенту ровно потому, что хуже понимает код - что автор считает полностью вывернутой наизнанку логикой. Потеря происходит без какого-либо отдельного тревожного момента, потому что момент, который раньше вызывал тревогу, просто убрали из процесса.

Чистый код обходится дешевле и для агента

Затем эссе отходит от принципиальных соображений к аргументу о стоимости, который актуален даже для тех, кто рад переложить на агентов вообще всю работу. Запутанный код означает больше файлов для чтения и больше ветвлений для отслеживания при каждой правке, а значит - больше токенов на каждое изменение. Когда нужная логика не помещается в ограниченный фрагмент, агенты также с большей вероятностью ошибочно предположат, что ветка делает то, чего она не делает, или пропустят исключение, запрятанное на три уровня вглубь. Те же самые границы, которые удерживают модуль в голове человека, удерживают изменение в рамках того, о чём агент может надёжно рассуждать. Это аргумент из clean-code-coding-agents, к которому подошли со стороны рефакторинга, а benchmarking-opus-5-slopcodebench - одно из измерений того, как написанный агентом код разрастается по сложности, если этому ничто не противостоит.

Возвращение точки контроля

Рецепт в том, чтобы намеренно задавать вопросы, которых не задаст агент: понимаю ли я всё ещё эту часть или позволил агенту понимать её за меня; сможет ли человек отладить её без агента; не превратился ли код в сплошные исключения без единого правила; не настало ли время приостановить добавление возможностей и заняться рефакторингом. Кое-что из этого можно заложить в harness, дав агентам указание помечать модули, разросшиеся сверх разумного размера или сложности ветвления, и предлагать рефакторинг, а не только расширение. Автор отмечает: это помогает, но не снимает ответственности, так как способность понимать систему теряют именно люди. Его финальное разграничение: формулировка "агент всё ещё может в этом разобраться" описывает возможности агента, тогда как "система в порядке" описывает наши собственные.

Место в базе знаний

В эссе мало доказательств: это наблюдение одного практика за тенденцией, без указания конкретных команд, цифр или инцидентов. Его ценность - в сформулированном механизме. peril-of-laziness-lost приводит соседний аргумент о том, что у агентов нет ограничения по времени, подталкивающего их к простоте; это эссе добавляет, что у них также нет предела понимания, который раньше останавливал людей. Человеческая часть проблемы - это ironies-of-automation и skill-atrophy-supervision-paradox: как только машина берёт на себя типовой случай, человек теряет навык, позволявший ему заметить неладное, а формальное одобрение на ревью - это проблема бдительности в форме код-ревью (см. code-review-throughput-limits).

Противовесом выступает not-understanding-your-codebase. Goedecke утверждает, что частичное понимание - нормальное состояние любой крупной системы. Это согласуется с данным эссе только при условии, что код по-прежнему позволяет рассуждать локально, а отсутствующий рефакторинг как раз разрушает эту возможность. owning-ai-written-code формулирует ту же мысль с точки зрения отдельного разработчика, а не команды: написание кода раньше вынуждало в нём разбираться, а когда код пишут агенты, понимание превращается в отдельную статью расходов, которую кто-то должен сознательно решить оплатить. back-to-coding-by-hand и building-syntaqlite-ai - свидетельства от первого лица о том, как выглядит этот дрейф, когда его наконец замечают.