Код написал AI, другой AI его проверил. Проект собирается, тесты проходят, архитектурная схема выглядит убедительно. А кто теперь понимает систему?

Недавно я разговаривал с приятелем. Его команда начала новый проект на Rust + MongoDB, и первым делом я спросил про БД. Не потому, что это плохая база, а потому, что мне стало интересно: почему выбрали именно её? На этом месте разговор начал буксовать. Глубокого опыта ни с Rust, ни с MongoDB в команде нет. План примерно такой: хорошо описать требования, использовать spec-driven development, подключить AI-агентов и посмотреть, как пойдёт. Речь не о pet-проекте: на этом стеке собираются делать реальный продукт, а решение принимает техлид.

При этом разработчиков не ограничивала инфраструктурная команда. Наоборот, среди участников были коллеги из инфраструктуры, которым самим хотелось ради опыта развернуть что-то новое. Это нормальное желание: инженеры растут, когда пробуют незнакомые инструменты. Интерес команды к технологии и реальная потребность продукта в ней не всегда совпадают. Не всегда работает и фраза «отдадим это пopus, он всё объяснит и развернёт»: агент может подготовить конфигурацию и команды запуска, но дежурить, разбирать инциденты и отвечать за восстановление системы всё равно придётся людям.

Проблема ещё и в том, что выгода и цена такого эксперимента распределяются неравномерно. Разработчик получает опыт с Rust, коллега из инфраструктуры — с MongoDB, техлид внедряет агентские подходы, и эта польза видна сразу. Стоимость поддержки проявится позже и ляжет уже на всю компанию: дежурным придётся разбирать инциденты, новым сотрудникам — осваивать ещё один стек, а бизнесу придется оплачивать эксплуатацию системы. Это не значит, что участники действуют безответственно, но из-за такого перекоса личную пользу эксперимента легко принять за достаточное обоснование архитектурного решения.

Меня зацепила уже не MongoDB, а сам подход. Ещё несколько лет назад предложение взять в продакшен технологию, которую никто в команде толком не знает, породило бы пачку неудобных вопросов. Почему текущий стек не подходит? Какие сценарии отказа появятся? Кто будет обновлять и мониторить систему? Что произойдёт, если человек, который её внедрил, уйдёт? Теперь на часть этих вопросов всё чаще находится удобный ответ: AI поможет разобраться по ходу дела.

Сразу подчеркну: это не исследование рынка, а моё мнение, основанное на личных наблюдениях и разговорах с людьми из других компаний. К счастью, в Big Tech подобный выбор вряд ли прокатит без дополнительных вопросов: там обычно есть архитектурные ревью, платформенные стандарты, требования безопасности и проверка готовности системы к эксплуатации. В компаниях с менее формальным процессом интереса к новому стеку и уверенности в AI иногда оказывается достаточно, чтобы эксперимент быстро стал частью продакшена.

Дело не в MongoDB

MongoDB поддерживает транзакции над несколькими документами в replica set и шардированных кластерах, поэтому тезис «в Mongo нет транзакций» давно устарел. Но само наличие транзакций не означает, что привычную модель работы с реляционной базой можно бездумно перенести на документную. До запуска нужно понять, подходит ли документная модель под данные, где достаточно атомарности одного документа, а где появятся операции над несколькими документами. Вопрос тут даже не в названии технологии, а в том, способен ли человек, принимающий решение, объяснить, зачем она появилась в системе и какие компромиссы команда приняла вместе с ней. Из услышанного я так и не понял, почему задачу нельзя решить на обычной реляционной базе. Поэтому главный вопрос остался прежним: какую проблему мы решаем добавлением MongoDB?

Незнание раньше было полезным тормозом

Представим, что несколько лет назад кто-то предлагал добавить Cassandra. Первый вопрос звучал просто: кто-нибудь с ней работал? Если нет, решение сразу становилось дорогим. Нужно было читать документацию, разбираться с моделью данных, согласованностью, эксплуатацией кластера и мониторингом, а иногда искать людей, которые уже поддерживали Cassandra в продакшене. Через несколько дней исследования вполне могло выясниться, что она вообще не нужна. Команда тратила несколько дней, зато не получала несколько лет дополнительной инфраструктурной сложности.

Высокий порог входа был не только недостатком, но и естественным фильтром. Чтобы принести новую технологию в продакшен, чаще приходилось заранее разобраться в её ограничениях. Конечно, технологические зоопарки существовали и до AI: были микросервисы ради микросервисов, Kafka там, где хватило бы таблицы, Kubernetes для пары контейнеров и event sourcing после одного интересного доклада. AI эту проблему не придумал, но заметно уменьшил сопротивление на входе.

Код появляется быстрее, чем понимание

Сегодня можно попросить агента сделать сервис на Rust + MongoDB, а уже в проекте добавить слой репозитория, индексы, транзакции, ретраи, метрики, тесты и т.д. Через короткое время может появиться проект, который выглядит вполне прилично: он компилируется, тесты проходят, есть README, CI и линтер. Если попросить, агент напишет ещё и ADR, объясняющий, почему MongoDB была хорошим выбором. Правда, сам такой запрос уже подталкивает модель искать доводы в пользу принятого решения, а не проверять, нужно ли оно вообще.

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

AI позволяет добавить техническую сложность раньше, чем команда успеет её понять. Можно написать сервис на языке, которого не знаешь, подключить незнакомую БД и как-то настроить брокер сообщений, причём всё это действительно может работать. Поэтому проблема не обязательно заключается в плохом коде. Чем лучше становится AI, тем сложнее её заметить: что делать, если код хороший, архитектура выглядит убедительно, тесты проходят и агент для ревью тоже говорит, что всё в порядке?

Спецификация не отвечает на вопрос «зачем»

Мне нравится spec-driven development. С развитием AI хорошие спецификации будут становиться только важнее: чем меньше агенту приходится угадывать, тем лучше. Но функциональная спецификация обычно отвечает на вопрос «что должна делать система» и сама по себе не объясняет, почему для этого нужны именно MongoDB, Kafka и несколько сервисов.

Можно подробно описать создание заказа, публикацию события, обработку ошибок, состояния и критерии приёмки. После этого AI добавит MongoDB, Kafka, Redis, и подключить это сервисам. Всё будет соответствовать требованиям, хотя бизнесу, возможно, хватило бы трёх таблиц в PostgreSQL и одной фоновой задачи. Spec-driven development помогает контролировать реализацию, но не защищает от лишней архитектурной сложности: в спецификации можно очень подробно описать поведение системы, которую вообще не стоило строить.

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

Архитектура зависит от возможностей команды

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

Архитектура отвечает не только на вопрос «может ли технология выполнить задачу?». Не менее важно, сможет ли именно эта команда нормально жить с ней следующие несколько лет. Компетенция команды — тоже часть инфраструктуры, и интерес коллег из инфраструктуры к новому инструменту эту компетенцию ещё не создаёт. AI может написать конфигурацию, объяснить параметры и помочь с диагностикой, но его ответы не превращаются автоматически в опыт работы с системой под реальной нагрузкой. Поэтому эксперимент полезен для обучения, но сам по себе ещё не доказывает, что команда готова эксплуатировать технологию в продакшене.

Первый AI написал, второй проверил

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

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

Человек, который плохо знает технологию, не может качественно проверить результат и поэтому превращается в прокси между агентами. Уверенности чуть больше становится(если доверяем агенту и скиллам), хотя собственное понимание почти не изменилось. Получается замкнутая петля: я не могу проверить AI, потому что плохо знаю технологию, поэтому попрошу AI проверить AI, а затем буду считать решение проверенным. Но откуда в этой цепочке взялась компетенция?

Так появляется долг компетенций

О техническом долге говорят давно, и его часто можно увидеть: вот костыль, вот дублирование, вот участок без тестов. С долгом компетенций сложнее. Я бы назвал так ситуацию, в которой команда экономит время на понимании решения, но постепенно теряет способность самостоятельно менять, диагностировать и восстанавливать систему. Код при этом может быть относительно хорошим, тесты — проходить, документация — оставаться подробной, а CI — зелёным.

У такого долга есть два уровня. На первом команда плохо знает саму технологию: как MongoDB ведёт себя при сбое, что означают её гарантии и где искать причину деградации. На втором люди перестают понимать конкретную систему, её историю и бизнес-ограничения. Первый пробел иногда можно закрыть наймом специалиста или консультацией, а второй восстановить намного сложнее, потому что часть контекста нигде не записана.

Раньше разработчик мог несколько часов разбираться, почему транзакция ведёт себя определённым образом: читать документацию, ставить эксперименты, ловить конфликт, менять настройки и снова проверять. Задача занимала полдня, зато после неё оставалось понимание. Теперь ошибку можно отдать агенту, который предложит исправление, изменит код, прогонит тесты и остановится, когда всё заработает. Для бизнеса хорошо, что задача закрыта быстрее, но обучение человека при этом не гарантировано.

Риск технической деградации появляется не тогда, когда разработчик забывает синтаксис цикла. Он появляется, когда агент забирает ту часть работы, во время которой человек строил собственную модель системы. Документация и ответы со Stack Overflow тоже позволяли сэкономить время, но их всё равно приходилось адаптировать. Агент способен самостоятельно пройти почти весь цикл «проблема → исследование → гипотеза → проверка → решение», и если человек наблюдает только готовый результат, ему сложнее накопить опыт.

Эта проблема появилась задолго до LLM. В 1983 году Лизанна Бейнбридж описала похожий парадокс в статье «Ирония автоматизации»: автоматизация забирает регулярную работу, но оставляет человеку редкие и самые сложные ситуации, в которых он должен вмешаться. Позже это назвали проблемой выпадения из контура управления (out-of-the-loop performance problem): чем меньше человек участвует в обычной работе системы, тем сложнее ему восстановить понимание и взять управление на себя после сбоя. В агентной разработке механизм похож: AI закрывает типовые задачи, а инженер встречается с системой уже тогда, когда готового решения не существует.

Цена ошибки senior и tech lead выше

Обычно в этом контексте обсуждают junior-разработчиков: если новичок с первого дня отдаёт агенту каждую задачу, как он научится программировать? Этот риск никуда не исчезает. Но ошибка senior-разработчика или техлида обходится дороже, потому что принятое ими решение может определить архитектуру системы на несколько лет.

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

Для таких выводов мало знать набор архитектурных паттернов. Нужна накопленная модель того, как системы ломаются. Запрос сначала прекрасно работает на миллионе строк, а потом начинает деградировать. Миграция блокирует таблицу, consumer отстаёт на несколько миллионов сообщений, заканчиваются соединения с БД. Затем приходится восстанавливать данные из резервной копии, которую, как выяснилось, давно никто не проверял.

Не обязательно лично наступать на все грабли. Можно читать postmortem (сам так делал), учиться на чужом опыте, ставить эксперименты и использовать AI. Но если весь путь от проблемы до решения проходит внутри агента, опытному инженеру тоже становится сложнее поддерживать модель того, как система работает и где она может сломаться.

Продакшен начинается после «оно работает»

AI может заметно ускорить путь до состояния «запускается», но продакшен начинается после этого. Данные растут, профиль нагрузки меняется, появляются параллельные операции, которых не было в тестах. Начинаются тайм-ауты, реплика отстаёт, индекс перестаёт подходить под новые запросы, а после обновления драйвера меняется поведение. В документации написано одно, но в конкретной системе происходит другое.

AI может помочь и здесь: ему можно отдать логи, метрики, трейсы, код и конфигурацию, а иногда он действительно найдёт проблему быстрее человека. Но есть большая разница между «AI помогает мне разобраться в системе, которую я понимаю» и «AI разбирается вместо меня, потому что никто в команде уже не понимает, как она работает». Во втором случае долг компетенций проявляется во время нестандартной ситуации, когда готового решения нет и становится понятна его реальная цена.

Технологический зоопарк может стать ещё больше

Никто не знает Rust? Агент напишет. Никто не работал с ClickHouse? AI спроектирует таблицы. Kafka кажется сложной? Сгенерируем конфигурацию. Хочется написать новый сервис на Elixir? Почему бы и нет, ведь AI может писать на нём. Каждое отдельное решение может оказаться нормальным, но через несколько лет проблема проявится на уровне всей организации.

В одном сервисе PostgreSQL, в другом MongoDB, в третьем Cassandra. Здесь Kafka, там NATS, ещё где-то RabbitMQ. Часть сервисов написана на Go, один сервис на Rust, а другой на Elixir. Один агент предложил Temporal, другой построил собственную очередь поверх PostgreSQL. В итоге появляются несколько способов деплоя, разные подходы к наблюдаемости, разные миграции и много связующего кода.

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

AI можно использовать для обучения

Из всего этого не следует, что нужно перестать брать новые технологии или запретить AI. Наоборот, он хорошо подходит для их изучения. Можно взять незнакомую базу, попросить объяснить её модель данных, сравнить с PostgreSQL, разобрать гарантии согласованности, предложить несколько вариантов схемы и найти слабые места каждого. Затем поднять стенд, провести нагрузочный тест, смоделировать падение узла и самостоятельно разобрать результат.

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

Что должен понимать человек, принимающий решение

Я бы не запрещал архитектуру, спроектированную с помощью AI. Пусть агент предлагает варианты, критикует их, сравнивает с более простыми альтернативами, ищет сценарии отказа, моделирует инциденты и предлагает метрики. Но человек, принимающий решение, должен быть способен своими словами ответить на несколько вопросов:

• почему мы выбрали эту технологию;

• почему задачу нельзя решить текущим стеком;

• какие альтернативы рассматривали;

• какие гарантии решение даёт, а какие нет;

• какие новые сценарии отказа появились;

• как наблюдать и восстанавливать систему;

• кто сможет её поддерживать;

• что делать, если исходные предположения окажутся неверными.

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

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

Вывод

История с MongoDB для меня в итоге вообще не про MongoDB. Вместо неё можно подставить Cassandra, Elixir, микросервисы или event sourcing. Высокая стоимость освоения новой технологии иногда раздражала, но одновременно заставляла ответить на простой вопрос: нам действительно это нужно? AI заметно снижает эту стоимость, а вместе с ней — естественное сопротивление появлению новой сложности.

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

Код можно переписать, а конфигурацию сгенерировать заново. Намного сложнее восстановить понимание системы, если внутри компании его больше ни у кого нет.