Дешёвый ИИ-код оставляет компании дорогую обязанность: поддерживать всё, что она уже продала клиентам. Аналитическая компания GitClear, изучив 211 млн изменённых строк за 2020–2024 годы, обнаружила рост доли копирования примерно на 48%. Доля переносимых строк, связанных с переработкой существующих решений, с 2021 года сократилась более чем на 60%. Разработчики размножают фрагменты, обслуживание которых позднее потребует отдельных решений и проверок.

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

При этом внимание команд уходит от уже работающего продукта. В отчёте GitClear за 2026 год доля изменений кода, к которому не прикасались более 12 месяцев, сократилась с 1,7% в 2023 году до 0,46%. Новые функции нарастают вокруг старых, причины прежних ограничений забываются. Когда требуется изменить общую бизнес-логику, инженеру приходится сначала восстанавливать знание о программе. Количество доступных генераций эту работу не измеряет.

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

Этот выбор уже отражается в опросе Checkmarx за 2026 год. Среди компаний, где ИИ создаёт 81–100% кода, о выпуске ПО с известными уязвимостями сообщили 47%. При доле ИИ-кода 1–20% таких было 14%. Опрос связывает массовую генерацию с трудностями контроля, хотя сам по себе не устанавливает причину каждого дефекта. Отложенное исправление переносит расходы на действующий продукт: нужно проверять сохранность данных и обслуживать обращения клиентов одновременно с ремонтом.

Экономию легко признать раньше, чем проявятся эти затраты. В эксперименте исследовательской организации METR с инструментами начала 2025 года опытные разработчики потратили на задачи на 19% больше времени и всё равно считали, что ускорились примерно на 20%. Это конкретный исторический результат: в феврале 2026 года METR сообщила о вероятном улучшении скорости и трудностях её надёжного измерения. Ошибка самооценки остаётся предупреждением для бюджета. Удовлетворённость помощником не подтверждает снижение стоимости эксплуатации.

Полная генерация приложения заново также не освобождает от обязательств. Клиенты продолжают пользоваться сохранёнными данными и согласованными интеграциями. Перед заменой нужно доказать, что новая версия правильно воспроизводит нужное поведение, включая исключения, о которых составитель задания мог забыть. Удалить старый исходный текст проще, чем безопасно перевести работающий бизнес на другой.

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

@ex_trakt