AI-агенты и архитектура: почему CTO нельзя делегировать оркестрацию

Что именно произошло: взгляд изнутри

В недавнем обсуждении Сергей Алешин отметил, что даже при наличии современных AI‑агентов он не может полностью избавиться от роли CPO/CTO. По его словам, если он не проектирует подсистему управления ошибками и оркестрацию, логирование событий и сбоев, механизм формирования и восстановления бэкапов, систему документации и бэклога, а также процессы рефакторинга монолитов, контейнеризацию Docker‑Compose, версионирование и тестирование, проект сразу начинает «дрейфовать в хаос».

Источник: t.me

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

В ответ на это он привёл личный опыт: более 40 лет назад, будучи инженером‑электронщиком, он полностью погрузился в создание сложных систем, как на работе, так и дома. Позднее, осознав, что «вода в ступе» не даёт пользы, он освободился от этой привязанности, передав оборудование другу‑журналисту. По его мнению, подобное «освобождение» – нормальная реакция на переизбыток контроля.

Почему это меняет стоимость, время и риск проекта

1. Непрерывный микроменеджмент. Если AI‑агент не способен самостоятельно поддерживать оркестрацию, логирование и бэкапы, каждый сбой требует вмешательства человека. Это удлиняет время реакции и увеличивает нагрузку на технический руководитель.
2. Рост расходов на персонал. Непрерывный контроль со стороны CTO/​CPO подразумевает, что в команде нужен человек, способный «видеть» всю архитектуру. При попытке делегировать это AI‑решениям, компании часто вынуждены нанимать дополнительных специалистов для проверки результатов AI, что удваивает затраты.
3. Увеличение операционного риска. Ошибки в автоматическом рефакторинге или в восстановлении бэкапа могут привести к потере данных или к длительным простоям. Без человеческой верификации такие риски трудно оценить заранее.
4. Снижение гибкости. Проекты, построенные как «конвейер», не учитывают ежедневные изменения бизнес‑требований. Когда AI‑агент «соскальзывает», команда теряет возможность быстро адаптироваться, что отражается на сроках поставки и удовлетворённости клиентов.

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

Что компании следует проверить перед реакцией

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

Где находятся границы и какие риски остаются

1. Неоднозначность бизнес‑правил. AI‑агент опирается на формализованные правила. Когда в проекте появляются новые бизнес‑требования, которые ещё не описаны в правилах, агент может принимать неверные решения.
2. Сложные зависимости между микросервисами. В реальном проекте часто возникают скрытые зависимости, которые трудно полностью описать в модели. Ошибки в оркестрации могут привести к каскадным сбоям.
3. Ограничения в понимании контекста. Как отметил Алешин, «проект это не конвейер задач». Ежедневные изменения в концепциях и ошибках в предыдущих решениях требуют гибкой оценки, которой текущие AI‑агенты пока не обладают.
4. Человеческая привязанность к контролю. Даже если агент технически способен, руководитель может испытывать «привязанность» к процессу, что приводит к избыточному микроменеджменту и снижает эффективность.
5. Регуляторные и юридические ограничения. Автоматическое изменение кода, бэкапов или документации может нарушать внутренние политики и требования регуляторов, если не зафиксированы соответствующие аудиты.

Эти риски требуют от CTO не только технической, но и управленческой готовности к постоянному мониторингу и корректировке.

Что сделать уже на этой неделе: практический чек‑лист

1. Составьте карту текущих процессов – оркестрация, логирование, бэкапы, документация, рефакторинг. Отметьте, какие из них уже автоматизированы, а какие требуют ручного вмешательства.
2. Определите «точки отказа» – места, где ошибка может привести к потере данных или простоям. Проверьте, есть ли у вашего AI‑агента механизмы отката и уведомления.
3. Запросите у поставщика AI‑решения доказательства (case studies, SLA) по каждому из перечисленных процессов. Сравните их с вашими требованиями.
4. Проведите небольшое пилотное тестирование: выберите один из менее критичных процессов (например, автоматическое обновление документации) и запустите агент на ограниченной среде. Зафиксируйте результаты и время, затраченное на проверку.
5. Оцените затраты – посчитайте, сколько человеко‑часов экономится и сколько добавляется на контроль результатов. Сравните с текущими расходами на штатный контроль.

Выполнение этих шагов даст вам объективную картину, где AI‑агент действительно может облегчить работу, а где всё ещё нужен ваш личный контроль.

Источники

• Исходный пост

Что почитать дальше

• AI-шлюз для агентов: контроль расходов и безопасности данных
• Биоинформатика: когда данных больше, чем может обработать команда
• Claude Code Starter v6.3.0: оркестрация AI-агентов без хаоса
• Grok 4.5 для бизнеса в РФ: чек-лист проверки и оценки рисков
• Где есть бензин в Иркутске: 4 сервиса для проверки АЗС перед выездом