Хочу начать с того, что наверняка уже случалось с вами.
На прошлой неделе вы смержили пул-реквест. Сгенерированный ИИ код выглядел чисто — читабельный дифф, тесты зелёные, ничего подозрительного. Вы одобрили. А через два дня в продакшне что-то сломалось так, что никто не ожидал.
Если с вами это ещё не произошло — вам просто везло. Потому что я вижу такие ситуации постоянно, и в них есть чёткий паттерн.
ИИ-инструменты действительно изменили скорость, с которой команды производят код. Это реальность. Но они не изменили скорость, с которой кодовая база способна этот код безопасно поглотить. А именно в разрыве между этими двумя вещами и происходят инциденты.
Баг, которого как будто нет
У этого типа отказов уже есть название: иллюзия корректности (illusion of correctness).
Код, сгенерированный ИИ, синтаксически чистый. Он следует паттернам. Компилируется. Проходит тесты. На ревью выглядит так, будто его написал опытный инженер. Проблема скрыта глубже — в допущениях, которые код молча принял и которые не видны при чтении.
Вот четыре типа таких допущений, которые чаще всего ломают продакшн.
Допущения о границах значений. «Это поле всегда присутствует.» Только нет. Один из ваших downstream-сервисов восемь месяцев назад пережил неудачный деплой и с тех пор при определённых условиях это поле не отдаёт. Тесты в стейджинге проходят. Нагрузочное тестирование тоже. А в два часа ночи реальный заказ попадает в реальный граничный случай.
Допущения о конкурентности. «Этот вызов идемпотентен.» Нет. Именно так клиент списывается дважды — в коде, который на ревью выглядел абсолютно правильным. ИИ увидел паттерн повторных попыток, но не знал доменного правила: что происходит, если вызвать этот эндпоинт дважды.
Доменные допущения. «Эти два статуса заказа эквивалентны.» Нет. Команда фулфилмента и команда биллинга всегда трактовали их по-разному. Никто не зафиксировал это как обязательное правило. ИИ не мог знать — этого не было в коде.
Допущения о безопасности. «Запрос приходит из внутреннего сервиса, значит, ему можно доверять.» Внутренняя сеть — не периметр безопасности. Это допущение тихо встраивается в код и проходит через любое ревью, которое доверяет чистому виду выдачи.
Код компилируется. PR выглядит аккуратно. И только продакшн-данные и реальные пользователи обнажают отсутствующие правила.
Самое неприятное в этом — на ревью оно не всплывает. Оно всплывает в инцидентах.
Почему более высокая скорость может вас замедлить
Вот ментальная модель, которую я использую с командами.
У каждой системы есть ёмкость поглощения изменений (change absorption capacity) — объём нового кода, который она способна безопасно принять, прежде чем начнут появляться сбои. Эта ёмкость определяется контрактами, покрытием инвариантных тестов, наблюдаемостью и степенью связанности. Когда темп поступающих изменений начинает обгонять эту ёмкость, система становится нестабильной. Не сразу, но неизбежно.
Что обычно удивляет: если продолжать давить на систему, которая не успевает, реальная скорость доставки нередко падает. Время, сэкономленное на генерации кода, съедается в два-три раза на отладке, откате и переработке.
ИИ поднимает скорость производства изменений. Рефакторинг поднимает скорость их безопасного поглощения. Разрыв между этими двумя числами — ваш реальный уровень риска.
Команды, которые, по моим наблюдениям, по-настоящему выигрывают при разработке с помощью ИИ, используют не более продвинутые модели. Они выстроили инженерную систему, способную поглощать изгенерированные ИИ изменения, не накапливая при этом незаметный технический долг.
Рефакторинг — не уборка. Это множитель.
Большинство команд смотрят на рефакторинг неправильно. Они относятся к нему как к одному из трёх: уборка, выплата технического долга или пункт роадмапа, который переносится каждый квартал.
Ни один из этих фреймингов не помогает, когда нужно двигаться быстро и безопасно.
Правильный фрейминг: рефакторинг — это способ снизить стоимость изменений, чтобы система могла поглощать более частые и объёмные правки без накопления незаметной хрупкости. В среде, где ИИ ускоряет разработку, это превращает рефакторинг в множитель скорости, а не в налог на неё.
Что даёт непрерывный рефакторинг: стабильные границы — изменения распространяются предсказуемо; меньше связанности — ничто не ломается цепной реакцией; чёткое владение — нет неопределённости, кто за что отвечает; тестируемые инварианты — код-ревью перестаёт делать работу, которую должны делать тесты; лучшая наблюдаемость — отклонения обнаруживаются раньше, чем о них сообщат пользователи.
Антипаттерн: разгонять AI-ассистированную разработку поверх нерешённого технического долга. В итоге вы получаете ускоренное накопление несогласованностей, больше регрессий в продакшне и чистую скорость, которая на самом деле идёт назад — переработка поглощает всё.
Четыре страховочных механизма, которые удерживают скорость: CATS
Я применяю фреймворк под названием CATS в своих командах и на конференциях. Он описывает четыре практики, которые в совокупности позволяют двигаться быстро и ничего не ломать.
C — Контракты (Contracts)
Делайте границы явными. API-спецификации, схемы событий, контракты данных, определения владения.
Вот сценарий, который я видел не раз. Три команды используют общий сервис ценообразования. Никакого формального контракта — только общее понимание и документ, который никто не обновляет. Один инженер с помощью ИИ рефакторит форму ответа. Выглядит чисто, тесты проходят, мержится. Два дня спустя две из трёх команд получают пейджер-алерты: поля, на которые они рассчитывали, изменили смысл или исчезли.
Это не проблема ИИ. Это проблема отсутствующего контракта.
Когда контракт есть — версионированная API-спека, схема события со значениями полей и владением — внутренности могут меняться свободно. Контракт — это стабильная поверхность. И ИИ генерирует код по явному контракту значительно надёжнее, чем угадывает неявные соглашения.
Каждый раз, когда в вашей команде говорят «я думал, это поле всегда есть» — это кандидат на контракт. Запишите. Не только форму: смысл, допустимые значения и кого звать, когда что-то сломается.
A — Автоматическая верификация (Automated Verification)
Тесты, которые проверяют доменные инварианты, а не только happy path. Валидация схем в CI. Проверки безопасности в пайплайне.
ИИ хорошо генерирует тестовый код. Он действительно плохо справляется с тем, чтобы знать, какие доменные правила тестировать — потому что эти правила живут в post-mortem’ах инцидентов и в головах людей, а не в кодовой базе.
Распространённый провал: команда генерирует тест-сьют с помощью ИИ, цифры покрытия выглядят убедительно, команда доверяет результату. Но покрытие — по тем случаям, которые ИИ смог вывести из паттернов кода. Случаи, которые ломают продакшн, — те, что никто не записал.
Ваша задача — назвать инварианты. Задача ИИ — их покрыть. Валидация схем в CI ловит дрейф контрактов в момент мержа, а не в продакшне. Автоматические проверки безопасности ловят места, где «это внутреннее, значит безопасное» встраивается без чьего-либо участия.
T — Телеметрия (Telemetry)
Логи, метрики, трейсы — которые говорят вам, что происходит на самом деле, а не то, что вы думаете на основе кода.
Ревью кода говорит вам, что код написан. Телеметрия говорит, что он делает. Это разные вещи. Когда вы мержите больше PR быстрее, разрыв между тем, что код говорит, и тем, что он делает, может расти стремительно.
Реальный пример: команда выкатывает рефакторинг флоу обработки заказов. Ревью прошло, нагрузочные тесты прошли. Но небольшое изменение в обработке null-значений приводит к тому, что определённый тип граничного заказа начинает падать молча — никакой ошибки, просто неверное состояние. Без алерта на переходы состояний заказов они узнают об этом через три дня из тикета в службу поддержки.
С детектированием дрейфа вы поймаете это при 0,3% ошибок. Не на стадии «подождите, почему выручка упала в четверг?»
Помимо поиска проблем: фиче-флаги, пороги для canary-деплоев, чеклист отката, который ваша команда реально может выполнить в 23:00. Если откат требует созыва четырёх человек — вы недостаточно защищены для работы в темпе ИИ.
S — Упрощение (Simplification)
Непрерывное устранение скрытых зависимостей и размытого владения — не как проект, а как привычка, встроенная в работу над фичами.
Если рефакторинг требует разговора о роадмапе, он не произойдёт. Команды, которые реально это делают, встраивают его в работу над фичами. Вы и так в этом файле, никаких затрат на координацию. Зашли, улучшили, пошли дальше.
ИИ здесь тоже полезен — он хорошо замечает дублирование и подсказывает, где должны быть контракты. Но структурные предложения ИИ всё равно нужно проверять на соответствие доменным знаниям. ИИ может увидеть паттерн. Вы знаете, имеет ли предложенная граница смысл именно в вашей системе.
И измеряйте правильное. Не то, насколько чистым выглядит код. Не количество изменённых строк. Стало ли дешевле вносить изменения со временем или дороже? Это и есть сигнал, который говорит, работает ли упрощение на самом деле.
Как это выглядит на практике
Сравним два режима конкретно.
Без CATS: ИИ генерирует сервис. PR выглядит отлично. Формального API-контракта нет. Downstream-команды интегрируются исходя из наблюдений. Три квартала спустя кто-то рефакторит форму ответа. Две команды получают пейджер одновременно в пятницу вечером. Post-mortem констатирует «сбой коммуникации». Реальная причина — отсутствующий контракт.
С CATS: ИИ генерирует тот же сервис. До мержа кто-то пишет контракт — API-спека, смысл полей, владение, версионирование. Валидация схемы встраивается в CI. Когда три квартала спустя происходит рефакторинг, версия контракта поднимается, и потребители узнают об этом через сбой в CI, а не в продакшне.
Второй режим не медленнее. Как только контракт существует, каждое последующее изменение быстрее, потому что радиус поражения ограничен и виден. Инвестиция окупается на каждом следующем PR.
Быстро без CATS: скорость превращается в хрупкость. Быстро с CATS: скорость накапливается.
Двухнедельный спринт для старта (без паузы на фичи)
Не нужно делать из этого большую инициативу. Вот как выглядят два сфокусированных weeks — без разговоров о роадмапе, без заморозки фичей.
Неделя 1: контракты и безопасность
Найдите две-три хрупкие границы. Где чаще всего что-то ломается? Где ваша команда говорила «я думал, это всегда так»? Вот ваши кандидаты на контракты.
Напишите контракты. Не только форму — смысл. Что представляет каждое поле? Каковы допустимые значения? Кто владелец? Кому звонить, когда что-то сломается?
Добавьте валидацию контрактов в CI. Валидация схемы на мерже как блокирующее условие.
Напишите один инвариантный тест. Выберите доменное правило, нарушение которого наносит наибольший ущерб. Один тест-сьют. Не весь бэклог — только один.
Неделя 2: наблюдаемость и упрощение
Добавьте дашборды и алерты для отслеживания дрейфа. Отслеживайте режимы отказов из первой недели. Узнавайте о проблемах при 0,3% ошибок, а не по сообщению клиента.
Устраните одну точку сильной связанности. Общая зависимость, изменения которой дают наибольшую рябь. Выделите её, уточните владение.
Добавьте дефолтные инструменты безопасного выката. Шаблон фиче-флага, пороги canary, чеклист отката, которым команда реально воспользуется без созыва коллег.
Измерьте. Размер PR, инциденты на изменение, накладные расходы на координацию. Зафиксируйте базовую линию. Проверьте на четвёртой неделе.
Это не решит всё. Но за две недели создаст видимое, измеримое снижение рисков — и начнёт формировать привычки, которые делают быструю разработку устойчивой.
Сдвиг, который имеет значение
Сообщество platform engineering годами строило более качественные инструменты — внутренние платформы для разработчиков, golden path’ы, service mesh’и, стандартизированные стеки наблюдаемости. Вся эта инфраструктура предполагает, что команды могут выпускать продукт на высокой скорости, не делая систему постепенно хрупкой.
ИИ резко изменил скоростную составляющую этого уравнения. Составляющая безопасности не успевает.
У организаций, которые справляются с этим хорошо, есть общие черты. Контракты — первоклассные артефакты, а не запоздалая мысль. Тестирование доменных инвариантов — самостоятельная практика, а не метрика покрытия. Наблюдаемость действительно говорит им, что происходит, а не только то, что написано в коде. И рефакторинг непрерывен — встроен в работу над фичами, а не живёт в бэклоге.
Ничего нового здесь нет. Новое — то, что сейчас это несущая конструкция. Без неё ИИ-ускоренная скорость не накапливается. Она колеблется: быстро квартал, потом медленно, когда долг приходит к погашению.
Заключение
Эпоха ИИ поощряет скорость. Но она наказывает за хрупкость быстрее, чем мы привыкли, — потому что хрупкость теперь тоже может накапливаться быстрее.
Вперёд вырвутся не те команды, что сгенерировали больше всего кода. А те, что построили системы, способные безопасно поглощать сгенерированные ИИ изменения — через контракты, автоматическую верификацию, телеметрию и непрерывное упрощение.
Если вы сейчас движетесь быстро, вопрос не в том, добавлять ли страховочные механизмы. Вопрос в том, не накопили ли вы уже достаточно незаметного долга, чтобы ваша скорость начала разворачиваться против вас.
Задача на понедельник: найдите одну хрупкую границу. Напишите её контракт. Добавьте один инвариантный тест.
Вот с чего начинается.