Зелёный CI - не признак качества. Как ИИ ломает инженерное мышление

Эта статья не про инструменты и не про то, «как использовать ИИ». Она про то, почему автоматизация и AI могут снижать качество инженерных решений - даже в зрелых командах. И про то, почему большинство систем ломаются не из-за багов, а из-за решений, которые никогда не выглядели ошибками.
ㅤ

Используя ИИ, разработчик пишет код быстрее, чем когда-либо.

Фичи собираются легко. PR проходят быстро. Компоненты выглядят аккуратно и «правильно».

И именно здесь начинается риск.

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

Проблема не в плохом коде.
Часто код — лучший за всю историю проекта.

Проблема в том, что скорость убирает трение. А вместе с трением исчезают паузы, в которых раньше рождались сомнения и инженерные решения.

А когда код создаётся легко, решения перестают ощущаться решениями. Они становятся значениями по умолчанию.

ㅤ

Когда что-то ломается в проде, мы ищем техническую причину:

Код можно проверить, протестировать, переписать. Мы десятилетиями строили экосистему вокруг повышения качества кода: линтеры, статический анализ, тесты, CI.

И это действительно работает.

Но самые болезненные сбои начинаются раньше — в моменте, когда:

Эти решения не выглядят опасными. CI остаётся зелёным. Все проверки пройдены.

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

Мы отлично умеем ревьюить код.
Но гораздо хуже - ревьюить решения.

ㅤ

ИИ не создаёт новый тип ошибок.
Он меняет форму старых.

Раньше многие решения замедлялись трением: нужно было писать бойлерплейт, исследовать альтернативы, «посидеть с задачей». В этих паузах возникали вопросы.

ИИ убирает это сопротивление.

Код выглядит завершённым раньше, чем разработчик успевает осмыслить проблему. То, что раньше требовало размышлений, теперь ощущается как выполнение.

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

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

ИИ оптимизирует локальную корректность.

ㅤ

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

Решение приходит быстро, выглядит чисто и не встречает сопротивления - значит, оно «готово». Нет точки, где нужно остановиться и задать вопрос. Решение растворяется в коде.

Код проходит ревью. Тесты зелёные. А система постепенно теряет способность объяснять саму себя.

Опасность не в том, что появляется плохой код.
Опасность в коде, который выглядит оправданным по умолчанию.

Со временем временный компромисс становится архитектурой.

И тогда сбой становится неизбежностью.
ㅤ

Использовать ИИ не там - ошибка.
Не использовать его вовсе - ещё большая ошибка.

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

Также частый паттерн - использовать ИИ для финализации решения до того, как понятны ограничения. ИИ не помогает исследовать пространство решений - он преждевременно фиксирует ответ.
ㅤ

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

Другой риск - подключать ИИ после того, как решения уже заморожены. Автоматизация начинает «полировать» существующее, делая систему эффективнее в том, что, возможно, вообще не стоило делать.
ㅤ

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

Самое опасное место - пайплайны без обратной связи. Когда AI-изменения проходят ревью и CI (об этом я писал в этой статье), не создавая новых точек размышления, решения теряют видимость. Есть только вариации допустимых изменений.

Пример: ИИ предлагает переработку сервиса. Код чистый, тесты проходят, CI зелёный - мерж. Обсуждается реализация, а не исходный выбор архитектуры.

Автоматизацию часто "продают" как способ снизить человеческий фактор. На практике она снижает человеческое участие.

Решения принимаются, но их авторство размывается.

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

CI зелёный. А система становится непрозрачной.

И когда ответственность нельзя локализовать, способность команды к системному обучению становится невозможной
ㅤ

Если ИИ ускоряет выполнение, его ценность нельзя мерить скоростью.

Скорость дёшево стоит. Необратимость - нет.

Хорошо используемый ИИ не заменяет суждение. Он создаёт условия для его проверки. Самая ценная роль ИИ - не в генерации решений, а в подсветке пространства вокруг них: допущений, ограничений, отложенных последствий.

Не «реши задачу», а:

ИИ полезен, когда он замедляет в нужных местах.
ㅤ

Качество кода долго было нашим главным прокси инженерного мастерства. И это важно. Но качество кода говорит о том, что написано, а не почему именно так.

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

ИИ усиливает этот разрыв.

Повышать качество кода, не повышая качество решений, - значит просто откладывать проблемы на потом.