Субпрайм-кризис кода. Долгосрочная цена ИИ-ассистентов
- -
- 100%
- +
© Андрей Ладыгин, 2026
ISBN 978-5-0071-4411-7
Создано в интеллектуальной издательской системе Ridero
Введение
«Мы купили скорость. Счёт придёт позже.»
— из разговора с CTO, который пережил rewrite
Зачем эта книга
В 2023—2024 годах индустрия пережила первую волну массового внедрения ИИ-ассистентов. Компании увидели рост velocity, сократили штат, отчитались о «повышении эффективности». Через 6—18 месяцев начали приходить сигналы: инциденты, которые не чинятся «ещё одним патчем», миграции, которые ломают всё, уход инженеров — единственных носителей контекста, rewrites, которые стоят дороже, чем вся сэкономленная зарплата.
Это не история про «ИИ — плохо». Это история про асимметрию: ИИ снизил стоимость написания кода, но не снизил стоимость владения им. Разница между этими двумя величинами накапливается, как проценты по кредиту. Мы называем это субпрайм-ипотекой на архитектуру.
Книга — попытка посчитать этот долг и дать инструменты, чтобы его не брать.
Что произошло на самом деле
Три года назад считалось, что главная проблема разработки — скорость написания кода. Медленно пишем, медленно доставляем, медленно реагируем. ИИ решил эту проблему. Сегодня разработчик с ассистентом генерирует в 3—5 раз больше кода, чем без него (оценка, зависит от контекста и языка).
Но скорость написания — не единственное узкое место. Есть ещё:
Понимание. Код, который никто не понимает, невозможно эволюционировать.
Review. 500 строк сгенерированного кода нужно прочитать, проверить, протестировать.
Ownership. Кто-то должен дежурить, чинить, отвечать.
Организационная память. Контекст решений живёт в головах, а не в модели.
Ответственность. За outage отвечает CTO, а не нейросеть.
ИИ ускорил только первую часть уравнения. Остальные остались прежними — или выросли. Это как если бы вы ускорили выдачу кредитов, но не изменили систему проверки заёмщиков. Больше кредитов — больше плохих кредитов. Больше кода — больше скрытого долга.
Ключевая метафора
Субпрайм-ипотека 2007—2008 работала так:
Кредит выдавали без проверки дохода.
Первые 2—3 года — низкая ставка (teaser rate).
Потом ставка росла.
Заёмщик не мог платить.
Фореклоужер.
С ИИ-кодом то же самое:
Этап Ипотека ИИ-код
Origination Кредит без проверки Промпт без спецификации
Teaser rate Низкий платёж 2—3 года Быстрая генерация, «работает»
Securitization CDO Merge пачками в main
Rating agencies AAA-рейтинги Velocity, LOC, «скорость доставки»
Reset Ставка выросла Инциденты, отладка, миграции
Foreclosure Дом забрали Outage, rewrite, потеря команды
Первые месяцы всё выглядит отлично. Метрики растут, руководство довольно. Потом наступает reset. И foreclosure.
Эта книга — не про то, как запретить ИИ. Она про то, как не купить дешёвый код и не получить дорогую архитектуру.
Для кого эта книга
CTO, VP Engineering, Head of Development — тем, кто принимает решения о внедрении ИИ и сокращениях.
Tech lead, staff/principal engineer, архитекторы — тем, кто отвечает за архитектуру и review.
DevOps/SRE — тем, кто дежурит и чинит последствия.
Security engineers — тем, кто ищет мины в сгенерированном коде.
Senior-разработчикам — тем, кто ревьюит ИИ-код и чувствует review-усталость.
Продуктовым лидерам — тем, кто верит, что «один с ИИ заменит пятерых».
Книга не для тех, кто ищет подтверждение, что «ИИ всё сломает». И не для тех, кто ищет подтверждение, что «ИИ всё починит». Она для тех, кто хочет посчитать реальную цену и выстроить систему, которая выдерживает скорость генерации.
Что вы найдёте внутри
Книга состоит из пяти частей:
Часть I. Диагноз: почему ИИ-код — это субпрайм. Что такое стоимость владения, как она накапливается, где именно возникает долг. Пять слоёв скрытого долга: когнитивный, архитектурный, операционный, организационный, безопасностный.
Часть II. Механика отказа: как именно ИИ ломает инженерную систему. Чёрные ящики, парадокс review, ownership-вакуум, архитектурная эрозия, production-мины, организационная слепота. Как отказ выглядит на практике.
Часть III. Принципы антихрупкости. ИИ как усилитель, а не заменитель ответственности. Контракт до генерации. Владение важнее авторства. Архитектура как бюджет. Review нового поколения. Безопасность по умолчанию. Прозрачность и provenance.
Часть IV. Практики и ритуалы для команд. AI-aware review, верификация, ритуалы (ADR/RFC, debt review, postmortem), on-call, метрики здоровья, политика внедрения, роли и оргдизайн, обучение и культура.
Часть V. Экономика и стратегия. TCO ИИ-кода, где ИИ реально экономит, сценарии для стартапа/enterprise/аутсорса/regulated, дорожная карта на 90/180/365 дней, будущее агентов и автономных PR, манифест антихрупкой команды.
В конце — приложения: чеклисты, шаблоны, метрики, кейсы, глоссарий.
Как читать эту книгу
Если вы CTO или VP Engineering — начните с части I и части V. Часть I даст диагноз, часть V — экономику и дорожную карту.
Если вы tech lead или архитектор — читайте последовательно. Части II и III — ваши. Часть IV — практика на каждый день.
Если вы SRE или security — начните с глав 10, 17, 22. Это про мины и инциденты.
Если вы разработчик — начните с глав 6, 7, 8. Это про чёрные ящики, review и ownership.
Если вы продуктовый лидер — начните с глав 1, 11, 27. Это про экономику и сокращения.
Книгу можно читать по главам — каждая самодостаточна. Но связи между главами есть: мы ссылаемся на номера, чтобы вы могли вернуться.
Что эта книга не делает
Не обещает серебряных пуль. Нет «одного правильного способа внедрить ИИ». Есть набор практик, которые работают в разных контекстах.
Не запрещает ИИ. ИИ — усилитель. Вопрос в том, что именно он усиливает: вашу инженерную систему или ваш технический долг.
Не морализирует. Мы не говорим, что «ИИ — это плохо» или «ИИ — это хорошо». Мы показываем механику и даём инструменты.
Не выдумывает исследования. Если ссылаемся — только на общеизвестные практики (DORA, SBOM, ADR, RFC, mutation testing). Кейсы — собирательные, помечены. Числа — с пометкой «оценка», где нет источника.
Главная мысль
ИИ-ассистенты — это кредитное плечо. Плечо может ускорить рост, а может уничтожить компанию. Вопрос не в том, использовать ли ИИ, а в том, есть ли у вас инженерная система, которая выдерживает скорость генерации.
Если нет — вы берёте субпрайм-ипотеку на архитектуру. И однажды придёт фореклоужер: outage, rewrite, потеря команды и рынка.
Книга даёт не страх, а инструменты: review, ownership, архитектурный контроль, метрики и экономику. Тогда ИИ станет усилителем, а не долговой пирамидой.
Как пользоваться книгой
Каждая глава построена одинаково:
Эпиграф — задаёт тон.
Тезис — что доказываем.
Ключевые вопросы — на что отвечает глава.
Основной текст — разделы по подглавам.
Практика — что сделать завтра.
Метрики — что мерить.
Кейс из trenches — история, которую легко узнать.
Красные флаги — цитаты, которые вы слышали.
Антипаттерн — как делать не надо.
Чеклист — 5—10 пунктов.
Что запомнить — что унести.
Что почитать — 5 источников.
Вы можете читать главы последовательно или выборочно. Но если вы CTO — рекомендую последовательно: логика книги выстроена как диагностика, потом лечение.
От автора
Я пишу эту книгу как инженер, который видел и хорошие, и плохие внедрения ИИ. Я не против ассистентов — я против слепой веры в них. Я не против скорости — я против скорости без ответственности.
Если после прочтения вы:
посчитаете стоимость владения кодом в своей команде;
введёте owner-а для каждого PR;
начнёте мерить не только velocity, но и defect escape rate;
перестанете сокращать команду на основе роста генерации;
введёте review для ИИ-кода;
— книга сделала своё дело.
Начинаем.
Часть I. Диагноз: почему ИИ-код — это субпрайм
Глава 1. Дешёвый код, дорогое владение
«Код — как ребёнок. Сделать легко. Воспитывать — всю жизнь.»
— из разговора двух тимлидов после трёхдневного инцидента
Тезис
ИИ снизил стоимость написания кода, но не стоимость владения им. Разница между этими двумя величинами — и есть субпрайм-ипотека на архитектуру. Владение = понимание + эксплуатация + эволюция. Пока эти три компонента не учтены, экономия от ИИ — это отсроченный платёж с процентами.
Ключевые вопросы
Почему «код работает» не равно «код готов к эксплуатации»?
Что такое владение кодом и почему ИИ его не отменяет?
Где именно возникает скрытая цена ИИ-кода?
Почему генерация ускорилась, а ответственность — нет?
Как посчитать реальную стоимость одной строки кода?
1.1. Код как обязательство, а не актив
В бухгалтерии код иногда записывают в активы. В инженерии — это обязательство. Каждая строка, попавшая в main, требует: понимания, сопровождения, тестирования, обновления зависимостей, миграций, обработки инцидентов. Пока код жив — он генерирует работу. Чем больше кода — тем больше работы.
Код — как кот. Пока жив — жрёт, гадит и требует внимания. Только кот хотя бы мурлычет. Код не мурлычет никогда.
ИИ ускорил создание обязательств. Раньше разработчик писал 50—100 строк в день и помнил каждую. Теперь он генерирует 1500 строк до обеда и не помнит ни одной. Прогресс? Смотря для кого. Для его резюме — да. Для on-call-а через полгода — нет.
Вы взяли кредит, чтобы купить квартиру. Квартира — актив. Кредит — обязательство. Если вы берёте кредиты быстрее, чем растёт стоимость квартиры, вы не богатеете — вы тоните. С кодом то же самое: если вы генерируете код быстрее, чем команда способна его освоить, вы не ускоряетесь — вы берёте субпрайм-ипотеку.
Код — это не то, что вы создали. Это то, что вы обязаны поддерживать. Пока не посчитана стоимость поддержки — стоимость создания бессмысленна.
1.2. Что такое владение: три ночи из жизни on-call-а
Есть три сцены, которые объясняют владение лучше любого определения.
Сцена первая: понимание.
3:47 ночи. Звонит алерт. On-call открывает модуль биллинга. 800 строк. Сгенерированы ИИ восемь месяцев назад. Автор промпта уволен в рамках оптимизации. Комментариев нет. Тестов нет. Есть только код, который «работал». On-call смотрит на функцию calculate_discount () и не понимает, почему скидка применяется дважды. Он не может починить то, что не понимает.
Это отсутствие понимания. Без него владения нет.
Сцена вторая: эксплуатация.
Та же ночь. Через четыре часа. Инцидент не закрыт. On-call пишет в чат: «Кто-нибудь знает, что делает этот модуль?» Тишина. Он дежурит, но не владеет. Он отвечает за код, который никогда не писал и не понимает.
Это отсутствие эксплуатации в руках того, кто отвечает. Владение — это не только «понимаю», но и «готов чинить в 4 утра».
Сцена третья: эволюция.
Через месяц приходит требование: изменить логику скидок. Архитектор открывает модуль. Понимает с трудом. Начинает рефакторить — и ломает три соседних сервиса, потому что сгенерированный код использовал неочевидные side effects. Никто не знал, что они там есть.
Это отсутствие эволюции. Код, который нельзя безопасно изменить, — это не актив. Это мина с часовым механизмом.
Владение = понимание + эксплуатация + эволюция. Уберите любой компонент — и вы получите субпрайм. Платёж вносится, но дом вам не принадлежит.
ИИ не закрывает ни один из трёх компонентов. Модель не объясняет замысел. Модель не дежурит. Модель не знает, почему вчера было решено именно так. Она даёт результат — и уходит. Владение остаётся на команде. Или не остаётся ни на ком.
1.3. Три стоимости: где именно прячется долг
Компания посчитала: фича стоила два часа генерации. Дёшево. Через год та же фича стоила 60 часов инцидентов, отладки и миграций. Разница — это Own. Складываем — получаем настоящую цену.
Стоимость кода не одна. Их три.
Стоимость Что входит Кто платит Когда платит
Написание (Write) Промпт, генерация, правки, merge Разработчик Сейчас
Review Чтение, проверка, тесты, обсуждение Ревьюер, команда Сейчас
Владение (Own) Понимание, отладка, миграции, инциденты, удаление Команда, on-call, будущие инженеры Через 3—24 месяца
ИИ резко снизил Write. Review остался прежним или вырос: ревьюить 500 строк сложнее, чем 100. Own — вырос кратно, потому что сгенерированный код часто не имеет автора, который понимает замысел.
text
Total Cost of Code = Write + Review + Own
Own включает:
время на отладку (debug time);
время на инциденты (incident time × cost of downtime);
время на миграции и рефакторинг;
стоимость rewrites;
стоимость потери контекста при уходе инженера.
Числовой пример (оценка):
1000 строк сгенерированного кода.
Write: 2 часа.
Review: 4 часа.
Own (за 12 месяцев): 20—60 часов на отладку, инциденты, миграции.
Итого: 26—66 часов.
Для сравнения: 1000 строк, написанных человеком с пониманием: Write 20 часов, Review 4 часа, Own 10—30 часов. Итого: 34—54 часа.
Разница не в пользу ИИ, если код не понят командой. Если понят — ИИ выигрывает. Если нет — проигрывает. Третьего нет. Ключевое слово — «понят». Это и есть владение.
1.4. Почему генерация ускорилась, а ответственность — нет
Генерация — это функция от промпта. Ответственность — это функция от понимания, ownership и организационной структуры. ИИ ускорил первую. Вторую он не трогал.
Вот что не изменилось.
Понимание. Чтобы отвечать за код, его нужно понимать. ИИ не даёт понимания. Он даёт результат. Разница — как между «я знаю, что это работает» и «я знаю, почему это работает». Первое ломается при первом изменении. Второе — живёт.
Ownership. Кто-то должен дежурить, чинить, отвечать. ИИ не дежурит. Модель не просыпается в 3:47. Модель не пишет постмортем. Модель не объясняет бизнесу, почему упал биллинг.
Организационная память. Контекст решений живёт в головах. ИИ не помнит, почему вы выбрали именно это решение. Он не был на том созвоне, где вы спорили два часа и выбрали вариант B. Через год вариант B станет «странным кодом, который никто не понимает».
Ответственность перед бизнесом. За outage отвечает CTO, а не модель. За потерянные деньги отвечает компания, а не API-провайдер. За увольнение команды отвечает руководитель, а не нейросеть.
ИИ ускорил только одну часть уравнения. Это как если бы вы ускорили подачу заявок на кредиты, но не изменили систему проверки заёмщиков. Больше заявок — больше плохих кредитов. Больше кода — больше скрытого долга.
Скорость генерации — не узкое место. Узкое место — способность команды осваивать и владеть кодом. ИИ это узкое место не расширяет. Он его маскирует.
1.5. Почему метрики velocity это скрывают
Velocity измеряет, сколько команда выдала. Она не измеряет, сколько команда сможет поддерживать. Это как измерять качество кредита по количеству выданных кредитов. Пока рынок растёт — всё хорошо. Когда рынок падает — выясняется, что половина кредитов — мусор.
Что измеряет velocity:
количество закрытых задач;
количество PR;
story points;
время до merge.
Что она не измеряет:
стоимость владения;
частоту инцидентов;
rework rate;
orphan code ratio;
время до первого фикса;
стоимость outage.
ИИ усиливает этот эффект: генерация растёт, velocity растёт, а скрытые метрики — нет. Компания принимает решения по метрикам, которые не видят риска.
Метрика без стоимости владения — это рейтинговое агентство субпрайма. Оно показывает рост, пока не наступает фореклоужер.
Практика: что сделать завтра
Посчитайте стоимость одной строки кода. Возьмите 1000 строк сгенерированного кода. Оцените Write, Review, Own за 6 и 12 месяцев. Сравните с кодом, написанным человеком.
Введите метрику «cost of ownership» в дашборд. Она не обязана быть точной. Она должна быть видимой.
Проведите аудит: сколько кода в main не имеет owner-а? Используйте CODEOWNERS или git blame. Если git blame показывает «автор — ИИ, owner — NULL» — это orphan code.
Задайте вопрос команде: «Что ты не сможешь починить, если автор уйдёт?» Ответы — это карта рисков.
Введите правило: «нет owner-а — нет merge». Даже для ИИ-кода.
Проверьте три компонента владения для критичных модулей. Есть ли понимание? Есть ли эксплуатация? Есть ли план эволюции? Если хотя бы одного нет — модуль в зоне риска.
Метрики
Метрика Формула Что показывает
Cost per line (write) Время на написание / LOC Стоимость генерации
Cost per line (own) Время на владение / LOC Скрытая стоимость
Rework rate Переписанные строки / всего строк Доля кода, который не работает
Defect escape rate Баги в проде / всего багов Качество review
Orphan code ratio Код без owner-а / всего кода Риск владения
Формула субпрайм-процента (оценка):
text
Subprime Rate = (Own — Write) / Write × 100%
Если Own больше Write — вы платите проценты. Если Own в 5 раз больше Write — foreclosure не за горами.
Кейс из trenches
Собирательный кейс. Детали изменены.
Стартап, 12 разработчиков, B2B SaaS, стек: Python + React + PostgreSQL. Внедрили ИИ-ассистента в январе. К марту генерировали в 3 раза больше фич. Руководство довольно, velocity выросла на 180%.
В апреле сократили 4 разработчиков: «ИИ справляется».
В июне, в 2:47 ночи, on-call получил алерт от биллинга. Он открыл сгенерированный модуль. 800 строк. Ни комментариев, ни тестов, ни автора. Промпт писал уволенный разработчик. Через 4 дня он всё ещё не понимал, почему скидка считалась дважды. Через 5 дней уволился.
Потеряли $40—80 тыс. (оценка) на инциденте и ещё больше — на найме замены.
В августе — второй инцидент: утечка секретов через сгенерированный конфиг. В сентябре — третий: миграция БД, сгенерированная ИИ, удалила часть данных. Восстановление — 2 недели.
К декабрю: velocity упала на 60%, команда — 6 человек (из 12), CTO уволен, проект переписывают. Стоимость rewrite — $200—400 тыс. (оценка). Экономия на зарплатах — $150—200 тыс. (оценка). Чистый убыток — $250—500 тыс.
Что сделали не так: не считали стоимость владения, не вводили ownership, не проверяли числа.
Красные флаги
«Мы просто генерируем и мержим, review потом.»
«ИИ справляется, зачем нам 5 разработчиков?»
«У нас velocity выросла в 2 раза.»
«Это ИИ сгенерировал, я не знаю, как оно работает.»
«Разберёмся, когда сломается.»
«У нас всё под контролем.»
«Мы потом отрефакторим.»
Антипаттерн
Как делать НЕ надо:
Мержить ИИ-код без owner-а.
Считать velocity единственной метрикой здоровья.
Сокращать команду на основе роста генерации.
Не считать стоимость владения.
Не вводить review для ИИ-кода.
Хранить контекст только в головах уволенных.
Верить, что «ещё один патч» решит проблему.
Чеклист
□ Посчитана стоимость Write, Review, Own для 1000 строк кода.
□ Введена метрика cost of ownership.
□ Проведён аудит orphan code.
□ Каждый PR имеет owner-а.
□ Команда знает, что не сможет починить без автора.
□ Velocity не единственная метрика.
□ Review ИИ-кода не формальность.
□ Сокращения не основаны на росте генерации.
□ Есть план на случай ухода ключевых инженеров.
□ Стоимость владения видна руководству.
Что запомнить
Скорость генерации — не метрика здоровья. Метрика — стоимость владения. Пока она не посчитана, вы не экономите — вы берёте кредит под высокий процент.
Что почитать
DORA State of DevOps Report — метрики доставки и их ограничения.
«Accelerate» (Forsgren, Humble, Kim) — про то, какие метрики реально предсказывают здоровье команды.
«Working Effectively with Legacy Code» (Michael Feathers) — про владение кодом без автора.
Google SRE Book, глава про postmortem — как разбирать инциденты без поиска виноватых.
«The Mythical Man-Month» (Fred Brooks) — про цену отсрочки и иллюзию скорости.
Глава 2. Анатомия субпрайм-ипотеки на архитектуру
«Мы не брали кредит. Мы просто генерировали код. Разница — как между „не брал“ и „не помню, как брал“.»
— из разбора инцидента в аутсорс-компании
Тезис
Финансовая аналогия работает не как метафора, а как точная модель: origination → securitization → leverage → rating → foreclosure. Каждый этап можно найти в вашем репозитории. Если вы не видите этап — вы просто стоите в его середине. Foreclosure всегда приходит. Вопрос — к кому.