Когда создатель Redis Сальваторе Санфилиппо заявил, что код стал дешёвым сырьем и пора перестать читать его построчно (подробный разбор этого парадокса здесь), многие восприняли это с восторгом: «Отлично, теперь просто генерируем код агентами, гоняем тесты и не смотрим внутрь!».

Но как только вы начинаете применять этот подход на практике в реальных проектах, вы неизбежно сталкиваетесь со странным феноменом.

Пока вы просите ИИ написать парсер, сделать красивую анимацию для лендинга или сгенерировать скрипт миграции — всё выглядит как магия. Модель кажется умнее половины сеньоров с зарплатой в $10k.

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

Почему это происходит? Ответ кроется в базовой природе языковых моделей: ИИ — это локально-жадный оптимизатор. Он обожает прямые дороги.

Забор Честертона и машинная логика

В философии есть знаменитый парадокс, известный как «Забор Честертона»:

Справка: Забор Честертона (Chesterton’s fence)
Мыслитель Гилберт Кит Честертон в 1929 году описал простой принцип: если вы идете по полю и видите забор, который кажется вам совершенно бесполезным и только мешает пройти прямо, вы не имеете права сносить его до тех пор, пока точно не выясните, почему и зачем его здесь поставили. Тот, кто поставил забор, имел на это причину, даже если она неочевидна на первый взгляд.

ИИ-агенты ведут себя ровно противоположным образом. Они видят цель Точка А → Точка Б и сносят все «заборы» на своем пути, потому что так путь короче.

Представьте реальный production-слой в корпоративной CRM/ERP-системе:

[HTTP Controller] 
       ↓ 
 [Input DTO / Zod Validation] 
       ↓ 
  [Application Service] 
       ↓ 
[Domain Repository Interface] 
       ↓ 
[PostgreSQL Database with Transaction / Audit Logging]

Вы просите агента: «Добавь возможность быстро выгружать статус заказа в сторонний сервис доставки».

Что делает человек-архитектор? Он создает событие OrderExportRequested, кладет его в очередь (RabbitMQ/Redis Stream), вешает обработчик, оборачивает вызов в политику повторов (retry with exponential backoff) и пишет запись в лог аудита. Сложно? Да. Много кода? Да.

Что делает ИИ? Он смотрит на контроллер и думает: «Зачем эти четыре слоя абстракции? Я могу прямо из контроллера дернуть fetch('https://api.delivery.com') и сразу вернуть ответ клиенту. Задача решена, 50 строк лишнего кода сэкономлено, юнит-тест контроллера проходит за 2 миллисекунды!»

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

Но этот «забор» из абстракций стоял не для красоты. Он защищал систему от:

  • Блокировки веб-воркера при сетевом тайм-ауте стороннего API.
  • Утечки персональных данных в сырой лог запроса.
  • Рассогласования состояния, если внешний сервис ответит ошибкой 500, а в локальной базе статус уже изменился.

ИИ сократил путь. Он убрал код. И тем самым нанес удар по устойчивости всей системы.

Случайная сложность против Необходимой

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

В классической статье 1986 года «No Silver Bullet» («Серебряной пули нет») классик компьютерных наук Фред Брукс разделил сложность создания систем на два типа:

Кто такой Фред Брукс (Fred Brooks)?
Легендарный архитектор операционной системы IBM System/360, лауреат премии Тьюринга и автор главной книги по управлению IT-проектами «Мифический человеко-месяц» (The Mythical Man-Month). Именно Брукс сформулировал фундаментальный закон: «Если проект опаздывает, добавление рабочей силы лишь затянет его еще сильнее».

  1. Accidental Complexity (Случайная сложность): рутина, особенности синтаксиса, бойлерплейт, маппинг полей, настройка вебпака. Это то, от чего разработчик страдал годами.
  2. Essential Complexity (Необходимая сложность): сама суть предметной области — финансовые расчеты, конкурентный доступ к общему балансу, сохранение инвариантов при сбоях сети.

ИИ гениально уничтожает случайную сложность. Он генерирует DTO, валидаторы, рутинные хэндлеры и моки быстрее, чем вы успеете налить кофе.

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

В моей практике был показательный кейс: сложный флоу синхронизации сущностей через механизм LISTEN/NOTIFY в PostgreSQL с фоновым пулом воркеров. Агент при «оптимизации» предложил заменить всё это на простой интервальный setInterval с прямым SELECT * FROM table WHERE updated_at > ....

Для агента это выглядело логично: «Смотри, я выкинул 200 строк сложной шины событий, код стал чище!». То, что такой опрос уложит мастер-базу на 5 000 клиентах, в контекстное окно модели просто не поместилось.

Что говорят цифры: Данные GitClear за 2024–2026 годы

Это не просто субъективное ворчание сеньоров. Аналитическая компания GitClear провела масштабное исследование, проанализировав свыше 200 миллионов строк кода в open-source и коммерческих репозиториях за последние годы.

Результаты оказались обескураживающими:

  1. Взрывной рост Code Churn (кода-однодневки):

    • В 2021 году (до массового внедрения ИИ-ассистентов) базовый показатель churn (код, который переписывается или удаляется менее чем через две недели после коммита) составлял 3.3%.
    • К 2025–2026 годам этот показатель подскочил до 7.1% – 8.2%.
      Код пишется в разы быстрее, но выживает в кодовой базе в два раза хуже.

  2. Четырехкратный рост дублирования (Code Clones):

    • ИИ практически перестал делать качественный рефакторинг с выносом общих абстракций (move / update).
    • Вместо этого модели в 4 раза чаще генерируют изолированные копии чужой логики с минимальными изменениями, грубо нарушая принцип DRY (Don’t Repeat Yourself).

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

Архитектурная деградация при зеленых тестах

Самое коварное свойство ИИ-кода — он выглядит аккуратно.

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

ИИ пишет код с идеальными отступами, строгой типизацией на TypeScript, красивыми комментариями в JSDoc и набором зеленых юнит-тестов. Но при этом архитектура может деградировать до состояния монолитного спагетти.

                    ┌─ workaround (AI-fix 1)
                    ├─ direct fetch bypassing queue (AI-fix 2)
[ЧИСТАЯ СИСТЕМА] ───┼─ duplicated helper (AI-fix 3)
                    ├─ inline sql query (AI-fix 4)
                    └─ special case flag (AI-fix 5)

Каждое отдельное изменение в изоляции выглядит разумным. Каждое проходит ревью по чек-листу. Но совокупность этих решений образует так называемый «AI-хвост» (AI Technical Debt).

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

Промежуточный вывод

ИИ не глуп. Он просто работает как совершенный математический оптимизатор локальной функции потерь. Если вы ставите ему задачу «сделай фичу Х», он оптимизирует путь к фиче Х, игнорируя всё, что находится за пределами этой задачи.

Инженер старой школы пытался решить эту проблему, читая каждую строчку чужого кода. Но как мы уже выяснили в первой части — в эпоху генерации 5 000 строк в день этот подход мертв.

Значит, нам нужен другой инструмент контроля. Нам нужен способ заставить агента двигаться только по тем дорогам, которые безопасны для архитектуры.

О том, как построить надежную работу без микроменеджмента кода, я подробно расскажу в заключительном материале серии:
👉 «Архитектор будущего: от построчного ревью к Design Review» (выйдет уже 16 сентября).

Мы рассмотрим паттерн Skeleton + Pluggable Modules, формат артефакта DESIGN.md от Сальваторе Санфилиппо и практический свод правил: что можно отдавать ИИ целиком, а к чему его нельзя подпускать на пушечный выстрел.

Читайте также: Код стал дешёвым. Инженерное мышление — нет | Архитектура кода под ИИ: 5 фундаментальных правил