Клод не ваш архитектор

Видел это три раза за последний месяц. Три разные компании, три разных стека технологий, один и тот же паттерн. У кого-то появляется идея. Может, продакт-менеджер, может, тимлид, может, СТО после конференции. Он открывает Клода, или ChatGPT, или Copilot — неважно какой — и спрашивает, что ему построить. ИИ делает то, что всегда делает: с энтузиазмом валидирует идею, предлагает архитектуру и начинает рисовать компоненты. Он красноречив. Он уверен. Он звучит как очень опытный архитектор, который глубоко продумал проблему.

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

Продуктивность выросла в три раза. Но качество решений — вопрос.

Проблема «аттабой»

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

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

Главный навык хорошего архитектора — не проектирование систем. Это понимание того, какие системы не строить. Это противодействие сложности. Это вопрос «почему?» пять раз подряд, пока из aspirational nonsense не проявится реальное требование. Это объяснить СТО, что его идея с конференции — ужасное решение для команды, которая у него есть.

Клод никогда этого не сделает. Его тренировали быть полезным. Быть полезным значит соглашаться. Соглашаться значит получить одобрительный кивок и башню Дженга, которая сойдёт за архитектуру.

ПОТОК РЕШЕНИЙ: ГДЕ ТЕРЯЕТСЯ КОНТЕКСТ
══════════════════════════════════════

   ИДЕЯ                    КЛОД
   ─────                  ─────
     │        спросил       │
     ▼                     │
   [Что                  [Что
    построить?]            предложить?]
     │                     │
     ▼                     ▼
  НЕТ КОНТЕКСТА        НЕТ КОНТЕКСТА
  ─────────────        ─────────────
  • Реальные            • Паттерны
    ограничения           из обучения
  • Возможности         • «Лучшие
    команды                практики»
  • История              • median всех
    компании              решений

        │                     │
        ▼                     ▼
   НИКОГДА НЕ              ВСЕГДА
   СПРОСИТ                  ОТВЕТИТ
   «А ЗАЧЕМ?»            «ВОТ АРХИТЕКТУРА»
        │                     │
        └──────────┬──────────┘
                   ▼
              [УТВЕРЖДЕНО]
              БЕЗ СПОРА

Башня дженга

Вот как выглядит спроектированная ИИ архитектура на практике. Она технически верна. Компоненты имеют смысл по отдельности. Паттерны узнаваемы — event-driven здесь, CQRS там, service mesh, потому что, а почему нет. Она выглядит как-то, что мог бы спроектировать опытный архитектор. Проходит «тест прищура».

Но она не была спроектирована для вашей команды. Не была спроектирована для ваших ограничений. Не была спроектирована для скучной реальности вашего продакшена — VPC lockdown’ы, легаси-интеграции, команда, которая никогда не работала с Kubernetes в продакшене, комплаенс-требования, которые отключают половину управляемых сервисов.

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

Которая, если уж честно, была спроектирована для никого.

Настоящая архитектура полна компромиссов, которые имеют смысл только в контексте. Вы выбираете Postgres вместо DynamoDB, потому что команда знает Postgres и вы хотите запуститься за две недели, а не учить новую модель данных месяц. Вы пропускаете service mesh, потому что у вас четыре сервиса, а не сорок. Вы используете монолит, потому что задача простая, а микросервисы были бы карьерным развитием.

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

У ИИ-агента нет этого контекста. И хуже — он не знает, что у него его нет.

Пайплайн из jira-тикетов

Вот что меня действительно беспокоит. Когда Клод спроектировал архитектуру, те же люди, которые спрашивали его о дизайне, просят его разбить работу на части. Он производит эпики. Истории. Критерии приёмки. Аккуратно отформатированные, хорошо обоснованные, готовые к загрузке в Jira.

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

Подумайте, что произошло. Люди с наибольшим контекстом, наибольшим опытом и наибольшей ответственностью были сведены к исполнителям тикетов. Сущность с наименьшим контекстом, без опыта и без подотчётности принимает архитектурные решения.

Это не просто неэффективно. Это наоборот.

«но кто-то старший одобрил»

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

Сколько противодействия он проявит? В мире, где ответ на «я думаю, это неправильно» — «Клод потратил на это двадцать минут, а ты хочешь всё отбросить?», линия наименьшего сопротивления — одобрить с небольшими комментариями.

Вот настоящая опасность. Не в том, что ИИ производит плохую архитектуру — часто он производит вполне разумную. Опасность в том, что он замыкает обсуждение. Месси, спорный, time-consuming процесс, где трое инженеров не согласны с подходом, где кто-то говорит «а как насчёт…» и все стонут, но потом понимают, что это хорошая мысль, где финальный дизайн лучше, чем всё, что произвёл бы один человек — этот процесс заменяется на «Клод сказал».

Пробел ответственности

Вот вопрос, который никто не задаёт: когда всё пойдёт не так, кто несёт сумку?

Не Клод. У Клода нет сумки. Клода не будят в три часа ночи. Клод не сидит на послемортном разборе, объясняя, почему архитектура не выдержала нагрузку. Клоду не нужно говорить СТО, что платформу нужно переписать, потому что исходные допущения были неверны.

Ваши инженеры — да.

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

Это нечестно. И это неумно.

Что делать вместо этого

Я не говорю — не используйте ИИ-агентов. Я использую Claude Code каждый день. Это трансформировало мою продуктивность.

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

Инженеры проектируют. Агенты реализуют.

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

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

Защищайте спор. Месси-несогласие между инженерами — откуда берётся хорошая архитектура. Если ИИ замыкает этот процесс — если люди defer к Клоду вместо того, чтобы спорить друг с другом — вы потеряли кое-что гораздо более ценное, чем скорость разработки.

Сохраняйте ответственность людей. Если имя человека не стоит под архитектурным решением, никто им не владеет. А если никто не владеет, никто не будет за него бороться, когда это важно. «Клод спроектировал это» — не архитектурный decision record. Это отречение.

ПРАВИЛЬНОЕ ИСПОЛЬЗОВАНИЕ ИИ
════════════════════════════

  ЧЕЛОВЕК                           КЛОД
  ────────                          ─────
  Ставит цели                  Генерирует варианты
  Знает контекст               Ускоряет рутину
  Несёт ответственность        Не принимает решений

     ▲                              ▲
     │                              │
     │                              │
     └────────────┬─────────────────┘
                  ▼
           ┌───────────┐
           │  ДОВЕРИЕ  │
           │  К РЕЗУЛЬ-
           │  ТАТУ     │
           └───────────┘

  Вопрос: «Кто отвечает за башню Дженга,
          когда она развалится?»
  Ответ: Не Клод.

Ремесло всё ещё важно

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

Но ремесло не изменилось.

Понимать проблему. Знать ограничения. Делать компромиссы. Защищать простое решение против захватывающего. Говорить «нет» идее, которая звучит великолепно, но не подходит.

Это архитектура. Ни один агент её не делает.

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

Потому что когда башня Дженга зашатается — а она зашатается — Клода не будет рядом ловить её.

Выводы

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

Ссылки

• Claude Is Not Your Architect. Stop Letting It Pretend — HollandTech — оригинальная статья-источник