Субпрайм-кризис кода. Долгосрочная цена ИИ-ассистентов

Ключевые вопросы

Где в разработке origination, securitization и foreclosure?

Почему rating agencies (метрики) врут?

Кто платит по счетам, когда субпрайм срабатывает?

Как провести стресс-тест архитектуры до того, как придёт foreclosure?

Почему «у нас всё под контролем» — это красный флаг, а не успокоение?

2.1. Origination: промпт как выдача кредита без проверки дохода

В 2007 году кредит выдавали так: заёмщик приходил, говорил «у меня есть доход», ему верили. Никаких документов. Никакой проверки. Кредит выдан. Дом куплен.

В разработке origination выглядит так. Разработчик открывает чат с ИИ, пишет: «Сделай мне модуль биллинга с поддержкой скидок». Модель генерирует 800 строк. Разработчик смотрит: «Выглядит нормально». Мержит. Никто не спросил: куда это встраивается? Какие ограничения? Кто owner? Какие критерии приёмки? Промпт выдан — кредит выдан.

Проблема не в том, что промпт плохой. Проблема в том, что никто не проверил заёмщика. Заёмщик в данном случае — код. Проверка — это спецификация, архитектурный review, понимание ограничений. Если их нет — вы выдаёте кредит без проверки дохода.

Бывает хуже. Промпт пишется не разработчиком, а продактом. Или тимлидом в спешке. Или джуном, который не знает контекста. Модель не задаёт вопросов. Она генерирует. А тот, кто мержит, часто не тот, кто понимает.

Origination без проверки — это не ошибка одного разработчика. Это системная практика, которая выглядит как скорость. Пока не наступает reset.

2.2. Securitization: merge-пачки как CDO

В ипотечном кризисе банки не держали кредиты у себя. Они упаковывали их в CDO (collateralized debt obligations) и продавали. Чем больше кредитов — тем больше CDO. Чем быстрее продали — тем меньше риска.

В разработке securitization выглядит так. Разработчик генерирует 10 PR за день. Ревьюер смотрит каждый по 5 минут. Мержит. К вечеру в main — 3000 строк нового кода. Никто не держит этот код «у себя» — он уже в main. Риск передан дальше.

Чем больше PR — тем меньше времени на каждый. Чем меньше времени — тем выше вероятность, что что-то пропустили. Это не халатность. Это математика: если у вас 10 PR и 8 часов, у вас 48 минут на PR. Включая чтение, понимание, проверку тестов, обсуждение.

Вот как это выглядит в жизни. Пятница, 18:40. Ревьюер открывает четырнадцатый PR за день. 600 строк. Он листает. Функции выглядят знакомо. Тесты зелёные. Он пишет «LGTM» и закрывает ноутбук. В понедельник он не вспомнит этот PR. В следующем квартале — тем более. А код останется.

Securitization — это не злой умысел. Это следствие скорости генерации. ИИ генерирует быстрее, чем команда способна ревьюить. Merge-пачки — это способ не остановить поток. Но именно они превращают отдельные кредиты в CDO.

Вы не помните, что мержили вчера. Вы не помните, что мержили утром. Вы помните только, что «закрыли 15 задач». Это и есть securitization.

2.3. Leverage: техдолг как кредитное плечо

Команда взяла техдолг, чтобы успеть к релизу. Через полгода техдолг взял команду. Вот это leverage.

Кредитное плечо — это когда вы используете заёмные деньги, чтобы увеличить доходность. Работает, пока рынок растёт. Когда падает — вы теряете больше, чем вложили.

Техдолг — это то же самое. Вы берёте «кредит» в виде быстрых решений: генерируете код без тестов, без документации, без понимания. Это позволяет быстрее доставлять фичи. Пока фичи нужны — плечо работает. Когда приходит инцидент или требование изменить логику — плечо срабатывает против вас.

Виды техдолга, которые создаёт ИИ-код:

Тип долга Как возникает Когда срабатывает

Когнитивный Никто не понимает замысел При первом изменении

Архитектурный Локальные оптимумы, дублирование При масштабировании

Операционный Нет тестов, нет логирования При инциденте

Организационный Нет owner-а При уходе автора

Безопасностный Секреты в коде, уязвимые зависимости При аудите или атаке

Каждый тип — это плечо. Чем больше плечо, тем выше доходность в хорошие времена и тем глубже яма в плохие.

Какое у вас плечо? Если вы не можете ответить — вы в зоне субпрайма. Если можете, но число растёт — вы в зоне субпрайма, просто пока этого не видно.

2.4. Rating agencies: velocity, LOC, «скорость доставки»

CTO смотрит на дашборд. Velocity — зелёная. Инциденты — красные. Он смотрит на velocity. Потому что её видно. Инциденты он увидит через полгода. Вот это rating agencies.

В 2008 году рейтинговые агентства ставили AAA на CDO, которые через год становились мусором. Почему? Потому что модель оценки не учитывала риск. Она учитывала только доходность.

В разработке рейтинговые агентства — это ваши метрики. Velocity, LOC, story points, «скорость доставки». Они показывают рост. Они не показывают риск.

Что измеряет velocity:

сколько задач закрыто;

сколько PR смержено;

сколько story points сожжено.

Что она не измеряет:

сколько кода никто не понимает;

сколько инцидентов будет через 6 месяцев;

сколько времени уйдёт на отладку;

сколько будет стоить rewrite;

сколько инженеров уволится.

ИИ усиливает этот эффект: генерация растёт, velocity растёт, рейтинг AAA. Пока не наступает reset.

Если в вашем дашборде есть velocity, но нет cost of ownership — вы смотрите на rating agencies. Если в отчёте для руководства есть «скорость доставки», но нет «частоты инцидентов» — вы смотрите на rating agencies. Если в ретроспективе обсуждают «как ускориться», а не «как снизить риск» — вы смотрите на rating agencies.

2.5. Foreclosure: outage, rewrite, потеря команды

Сначала алерт. Потом on-call не понимает код. Потом звонит автору. Автор уволен. Потом rewrite. Потом уход команды. Это не три сценария. Это один.

Первый алерт — в пятницу, 21:14. Биллинг считает скидки дважды. On-call открывает модуль. 800 строк. Сгенерировано ИИ восемь месяцев назад. Автор промпта уволен в рамках оптимизации. Комментариев нет. Тестов нет. On-call пишет в чат: «Кто-нибудь знает, что делает этот модуль?» Тишина.

В субботу он всё ещё не понимает. В воскресенье CTO открывает Slack и пишет: «Кто-нибудь понимает, что делает модуль биллинга?» Тишина. В понедельник CTO увольняется.

Через месяц команда решает: переписать. Переписывание стоит дороже, чем всё, что сэкономили на генерации. Плюс время. Плюс нервы. Плюс уход людей, которые устали чинить то, что не понимают.

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

Foreclosure не приходит внезапно. Он зреет месяцами. Сначала — «ещё один патч». Потом — «разберёмся позже». Потом — «почему это не работает?». Потом — «кто это писал?». Потом — «никто не знает».

Foreclosure — это не событие. Это процесс. И он уже начался, если вы не можете ответить на вопрос «кто владеет этим кодом?».

2.6. Кто платит: следующая команда, следующая компания, следующий инженер

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

В разработке платят тоже не те, кто генерировал.

Платят клиенты, которые ушли после третьего outage. Платят инженеры, которые уволились, потому что устали тушить пожары. Платят те, кто остался: они работают за троих и не могут найти замену, потому что рынок знает репутацию компании.

Платят следующая команда — те, кто придёт поддерживать код. Платят следующая компания — если проект продан или передан. Платят следующий инженер — тот, кто откроет файл и скажет «что это вообще?». Платят бизнес — через outage, потерю клиентов, репутацию. Платят следующий CTO — который будет объяснять, почему rewrite стоит миллионы.

Тот, кто генерировал код, часто уже не платит. Он ушёл. Он получил оффер. Он в другой компании, где всё «по-другому». А долг остался.

Вопрос не в том, кто виноват. Виноватых не будет. Вопрос в том, кто платит. Если ответ «следующая команда» — вы в зоне субпрайма. Если ответ «мы» — вы уже платите. Если ответ «не знаю» — foreclosure уже в процессе.

Практика: что сделать завтра

Проведите стресс-тест архитектуры. Что будет, если завтра уйдёт вся команда, писавшая ИИ-код? Кто сможет поддерживать систему? Сколько времени уйдёт на восстановление контекста?

Посчитайте bus factor для критичных модулей. Сколько людей понимают этот код? Если один — bus factor = 1. Это риск. Если ноль — foreclosure уже близко.

Проверьте, есть ли в вашем дашборде cost of ownership. Если нет — добавьте. Если есть — посмотрите динамику за 6 месяцев.

Проведите аудит merge-пачек. Сколько PR мержится в день? Сколько времени уходит на ревью каждого? Если меньше 30 минут на PR — вы в зоне securitization.

Задайте вопрос: «Кто платит за этот код?» Если ответ «следующая команда» — начните с ownership.

Введите метрику debt interest. Команда тратит 40% времени на поддержку кода, который никто не понимает? Это и есть проценты по субпрайму.

Метрики

Метрика Формула Что показывает

Orphan code ratio Код без owner-а / всего кода Риск владения

Bus factor Мин. число людей, знающих модуль Хрупкость команды

Debt interest Время на поддержку / общее время Проценты по субпрайму

Merge latency Время от PR до merge Скорость securitization

Review depth Время на ревью / LOC Качество проверки

Формула debt interest (оценка):

text

Debt Interest = (Время на поддержку ИИ-кода / Общее время команды) × 100%

Если debt interest> 30% — вы платите больше, чем зарабатываете. Если> 50% — foreclosure близко.

Кейс из trenches

Собирательный кейс. Детали изменены.

Аутсорс-компания, 40 разработчиков, fixed-price контракт с крупным заказчиком. Стек: Java + Spring + Oracle. Проект — система документооборота для банка. Сроки — 9 месяцев. Бюджет — фиксированный.

Чтобы уложиться, команда активно использовала ИИ-ассистента. К концу срока сгенерировали ~70% кода. Сдали проект. Заказчик принял. Аутсорс получил оплату. Все довольны.

Через год заказчик пришёл с требованием: «Нужно изменить логику согласования». Команда аутсорса к тому времени распалась — проект закончен, люди ушли на другие. Новые разработчики открыли код. 500 000 строк. Без документации. Без тестов. Без owner-а.

Новый разработчик открыл DocumentApprovalService. java. 12 000 строк. Ни одного комментария. Ни одного теста. В git log — один коммит: «initial commit from AI assistant». Он закрыл файл. Открыл резюме.

Через месяц попыток изменить логику — каскад ошибок. Сгенерированный код использовал неочевидные side effects, которые никто не задокументировал. Три месяца попыток. Два rewrite. Заказчик подал в суд. Аутсорс потерял контракт и репутацию.

Стоимость поддержки за год превысила стоимость разработки в 2,5 раза (оценка). Кто заплатил? Аутсорс — деньгами и репутацией. Заказчик — временем и нервами. Следующая команда — тем, что вошла в проект, который «уже работает».

Красные флаги

«У нас всё под контролем.»

«Мы потом отрефакторим.»

«Это ИИ сгенерировал, но работает же.»

«Кто это писал? Не помню.»

«У нас velocity выросла, значит, всё хорошо.»

«Зачем нам owner? Оно же работает.»

«Следующая команда разберётся.»

Антипаттерн

Как делать НЕ надо:

Мержить PR пачками без глубокого ревью.

Считать velocity единственной метрикой.

Не считать debt interest.

Не вводить bus factor как метрику риска.

Верить, что «работает» = «можно поддерживать».

Оставлять код без owner-а после ухода автора.

Делать rewrite, не разобравшись, почему первый вариант сломался.

Чеклист

□ Проведён стресс-тест: что будет, если команда уйдёт завтра?

□ Посчитан bus factor для критичных модулей.

□ Введена метрика debt interest.

□ Проверен merge latency: не слишком ли быстро мержим?

□ Есть owner для каждого критичного модуля.

□ Orphan code ratio известен и отслеживается.

□ Есть план на случай foreclosure.

□ Руководство знает, кто платит за субпрайм.

□ Merge-пачки не заменяют review.

□ Rewrite не начинается без анализа причин.

Что запомнить

Foreclosure уже начался. Вы просто ещё не получили уведомление.

Что почитать

«The Big Short» (Michael Lewis) — как финансовые модели могут быть формально верными и катастрофически ошибочными. Прямая аналогия с вашими метриками.

«Release It!» (Michael Nygard) — про production-мины и стоимость отказов.

«Team Topologies» (Skelton, Pais) — про ownership и границы команд.

DORA State of DevOps Report — метрики, которые реально предсказывают риск.

«Working Effectively with Legacy Code» (Michael Feathers) — как разбирать код без автора.

Глава 3. Голоса с передовой: DOU, Reddit, HN

«ИИ сгенерировал 500 строк. Я сгенерировал резюме.»

— из треда на Reddit про review-усталость

Тезис

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

Ключевые вопросы

Что реально пишут инженеры, а не маркетинг?

Какие паттерны повторяются в сотнях команд?

Где хайп расходится с реальностью?

Что говорят не только жертвы, но и выжившие?

Как провести диагностику своей команды по этим паттернам?

3.1. Как читать форумы и не утонуть в anecdotes

Пятница, 23:40. Вы листаете Reddit. Тред «AI assistants ruined my codebase». 400 комментариев. Половина — «same here». Половина — «skill issue». Вы закрываете ноутбук и не понимаете, что делать.

Это не диагностика. Это шум. Один комментарий — это человек, у которого болит. Десять одинаковых в разных тредах — это система, которая болит. Верьте системе.

Как отличить сигнал от шума:

Что видите Что это значит Что делать

Один комментарий Anecdote Игнорировать

5—10 похожих в одном треде Локальный паттерн Запомнить

10+ в разных тредах за месяц Системный паттерн Проверить у себя

Паттерн + кейс с деталями Сигнал Включить в диагностику

Паттерн + цифры + повтор Диагноз Действовать

Если паттерн всплывает на DOU, Reddit и HN одновременно — это не хейт. Это реальность, которую кто-то не хочет замечать.

3.2. Паттерн 1: review-усталость

Среда, 17:20. Ревьюер открывает двенадцатый PR за день. 700 строк. Сгенерировано ИИ. Он листает. Функции выглядят знакомо. Тесты зелёные. Он пишет «LGTM» и идёт домой. В понедельник он не вспомнит этот PR. Через месяц — тем более.

Это не лень. У ревьюера 32 минуты на PR. Включая чтение. Включая понимание. Включая обсуждение. 32 минуты. Дальше — арифметика: если PR 700 строк, вы не ревьюите. Вы имитируете ревью.

В треде на DOU один тимлид написал: «Я больше не читаю PR. Я их просматриваю». Через два комментария другой добавил: «Раньше ревью занимало 20 минут. Теперь — 5, потому что иначе не успеваю». Третий ответил: «Мне кажется, я пропускаю баги, но у меня нет времени их искать». Это не три истории. Это одна система.

Что происходит дальше: баги уходят в прод. Инциденты растут. Команда удивляется: «Как мы это пропустили?» Пропустили, потому что не читали.

3.3. Паттерн 2: галлюцинированные зависимости

Разработчик пишет промпт: «Добавь библиотеку для парсинга PDF». ИИ генерирует код. Импорт: from pdf_magic_parser import PDFWizard. Разработчик мержит. CI падает. Библиотеки не существует. Модель её выдумала.

На Hacker News был тред, где инженер описал, как нашёл в проекте зависимость, которая существовала только в галлюцинациях модели. Документация выглядела правдоподобно. API — логично. Пакета не было. Он написал: «Теперь мы проверяем каждый импорт вручную». Второй добавил: «ИИ уверенно использует API, которого нет. И документация выглядит правдоподобно».

Галлюцинированные зависимости — это не баг. Это свойство модели. Она генерирует правдоподобный код, а не работающий. Разница — как между «выглядит как самолёт» и «летает».

Опасность не в том, что CI упадёт. Если CI упал — вы уже выиграли. Вы узнали о проблеме до прода. Настоящая опасность — если галлюцинированная зависимость существует, но делает не то, что вы думаете. Тогда CI зелёный. Прод красный. И никто не понимает, откуда инцидент.

3.4. Паттерн 3: код, который никто не понимает

Понедельник, 10:15. Архитектор открывает модуль, который нужно изменить. 1200 строк. Сгенерировано полгода назад. Автор промпта ушёл. git blame показывает: «AI assistant, initial commit». Архитектор читает функцию за функцией. Понимает процентов на тридцать. Остальное — «работает, но непонятно как».

Он спросил автора — тот ещё отвечал на сообщения в Telegram. «Почему здесь два индекса?» Автор ответил: «ИИ так предложил». Архитектор кивнул. Через месяц автор удалил аккаунт. Архитектор остался с двумя индексами и без ответа.

На Reddit это называют «археологией». Каждый рефакторинг — раскопки. Один разработчик написал: «Я боюсь его трогать. Он работает. Пока я не трогаю». Другой добавил: «У нас есть код, который никто не может объяснить. Но он в проде». Третий — самое честное: «Код работает. Но никто не знает, почему. И это страшнее, чем баг».

Код без замысла — это чёрный ящик. Он может работать годами. А потом одно изменение — и он рассыпается, потому что никто не знал, на чём он держится. Это не технический долг. Это когнитивный долг. Вы платите не за то, что код плохой. Вы платите за то, что никто не понимает, почему он хороший.

3.5. Паттерн 4: «ИИ сгенерировал — ИИ и чини»

Вторник, 14:30. Прод упал. Разработчик открывает чат с ИИ. Копирует ошибку. Пишет: «Почини». ИИ генерирует патч. Разработчик мержит. Через час — новый инцидент. Он снова копирует ошибку. Снова патч. Снова мерж.

Это как лечить перелом пластырем. Пластырь держится. Пока не надо бегать. Через месяц вы бежите. И узнаёте, что кость срослась неправильно.

На DOU один разработчик описал это так: «Мы чиним сгенерированный код сгенерированными патчами. Это рекурсия». Другой добавил: «ИИ сгенерировал баг, ИИ сгенерировал фикс, ИИ сгенерировал новый баг». Третий — самое точное: «Я чувствую себя оператором, а не инженером».

Патч поверх патча — это не отладка. Это имитация. Вы не лечите причину. Вы закрашиваете симптом. Через месяц у вас десять патчей, которые взаимодействуют непредсказуемо. Опасность в том, что это работает. До поры. Пока не перестанет.

3.6. Паттерн 5: сокращения и потеря экспертизы

Пятница, 16:00. CTO объявляет: «ИИ справляется. Мы сокращаем четырёх из пяти разработчиков». Оставшийся кивает. Через месяц он дежурит 24/7. Через два — увольняется. Через три — компания ищет замену. Найти не может: репутация уже известна.

На Reddit был тред от разработчика, который остался один. Он написал: «Нас было пятеро. Остался один. Я не справляюсь». Через месяц он добавил: «Уволили тех, кто понимал систему. Оставили тех, кто генерирует». Ещё через месяц: «Через полгода никто не помнит, как это работает».

Сокращения под ИИ — это не экономия. Это ставка. Ставка на то, что генерация заменит экспертизу. Экспертиза — это не написание кода. Это понимание, почему он такой. Генерация этого не даёт.

Что происходит через год: команда меньше, инцидентов больше, контекста нет, нанять некого. Экономия на зарплатах — минус. Стоимость восстановления — плюс. Чистый результат — минус. И никто не считал.

3.7. Что говорят не только жертвы, но и выжившие

Форумы — это не только истории провалов. Есть команды, которые прошли через это и остались. Что они делают иначе.

Одна команда в Берлине ввела правило: «Если PR больше 300 строк — он автоматически отправляется на второй review». Через месяц defect escape rate упал на 40% (оценка). Никто не уволился. Velocity упала на 15%. Это оказалось выгодно.

Другая команда, распределённая, ввела «owner дня»: каждый день один человек отвечает за все ИИ-PR. Он не ревьюит всё, но он — точка входа. Если что-то непонятно — идут к нему. Через два месяца review latency выросла, но rework rate упал в три раза (оценка).

Третья команда, в enterprise, ввела «AI Usage Policy»: ИИ разрешён для прототипов, тестов и boilerplate. Запрещён для критичной логики, безопасности и архитектуры. Через полгода — ни одного инцидента, связанного с ИИ-кодом.

Что говорят эти команды:

«ИИ — усилитель. Но усилитель чего? Если у вас хаос, ИИ усилит хаос.»

«Мы не запрещаем ИИ. Мы запрещаем мержить без понимания.»

«Мы перестали мерить velocity. Начали мерить defect escape rate.»

«Мы не сократили никого. Мы изменили роли.»

«ИИ не заменил инженеров. Он заменил рутину.»

Эти голоса тише. Их меньше. Но они есть. И они дают модель, а не только диагноз.

Практика: что сделать завтра

Проведите анонимный опрос в команде. «Что тебя пугает в ИИ-коде?» «Что ты не сможешь починить?» «Сколько времени у тебя на ревью?» Ответы — карта рисков.

Проверьте долю PR, которые никто не может объяснить. Возьмите 10 случайных PR за последний месяц. Спросите авторов: «Что делает этот код?» Если двое не могут ответить — у вас 20%. Если пятеро — 50%. Это unexplained PR ratio.

Посчитайте review latency. Сколько минут уходит на PR? Если меньше 30 — вы в зоне review-усталости.

Проверьте зависимости. Запустите npm audit или pip check. Если найдёте пакеты, которых нет в реестре, — это галлюцинации. Считайте долю.

Проверьте git log критичных модулей. Если там цепочка «fix», «hotfix», «fix again», «revert fix» — это patch-over-patch. Считайте долю.