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

Вот бы писать код быстрее – тогда я бы наконец сделал нормальный рефактор, идеальную архитектуру, всё “как надо”

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

Автоматизация + ИИ = бомба замедленного действия

Используя ИИ, разработчик пишет код быстрее, чем когда-либо. Фичи собираются легко. Разработчик меньше уделяет внимание ^[2] рутине, а компоненты выглядят аккуратно и «правильно».

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

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

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

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

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

Проблема – не в коде

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

• забыли проверку;

• не учли крайний случай;

• сделали неверное допущение в коде.

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

И это действительно работает. Но самая большая боль ^[4] закладывается — в моменте, когда:

• принят компромисс “под дедлайн”;

• ограничение упростили (нужно MVP и быстрее);

Эти решения не выглядят опасными. в этом случае долгосрочные последствия отложили “на потом”. CI остаётся зелёным. Все проверки проходят хорошо.

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

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

Как ИИ смещает точки отказа

ИИ не создаёт новые типы ошибок.

Как я написал ранне время рассуждения над задачей стало меньше и нужно было писать бойлерплейт, исследовать альтернативы, “посидеть с задачей”. В процессе возникали вопросы.

ИИ исключает этот шаг

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

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

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

Где ИИ встраивают неправильно

Я собрал несколько примеров не правильного использования ИИ.

ИИ встраивают туда, где решения ещё должны обсуждаться, но после его результата обсуждение переходит в исполнение.

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

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

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

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

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

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

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

Автоматизация без ответственности

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

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

• Ревью становится поверхностным;

• Обсуждении вокруг кода ИИ не происходит;

• Ответственного на стыке ИИ и разработчика найти становиться сложно.

А когда ответственность нельзя локализовать, способность команды к системному обучению ^[6] становится невозможной

Чем ИИ действительно должен помогать

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

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

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

От качества кода – к качеству решений

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

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

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