Агентная разработка растит технологический зоопарк

В сообществе разработчиков обсуждают новый побочный эффект агентной разработки: команды всё чаще берут в продакшен технологии, которыми не владеют, полагаясь на AI-агентов. Автор поста на «Хабре» описывает случай знакомой команды, которая начала реальный продукт на Rust и MongoDB, не имея глубокого опыта ни с языком, ни с базой данных. План строился на spec-driven development и подключении агентов, а решение принимал техлид.

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

Раньше высокий порог входа работал естественным фильтром: прежде чем тащить Cassandra или Kafka в продакшен, команде приходилось разбираться с моделью данных, согласованностью и мониторингом. Теперь агент может быстро собрать сервис на незнакомом стеке — с индексами, транзакциями, ретраями, метриками, тестами, README и CI. Проект компилируется и проходит проверки, но понимания системы у людей не прибавляется.

Автор отдельно отмечает, что MongoDB давно поддерживает транзакции в replica set и шардированных кластерах, поэтому тезис об их отсутствии устарел. Однако наличие транзакций не означает, что реляционную модель можно механически перенести на документную. Главный вопрос остаётся прежним: какую задачу решает добавление новой технологии и какие компромиссы команда принимает вместе с ней.

Spec-driven development автор считает полезным подходом, но указывает на его ограничение: спецификация описывает, что должна делать система, и не объясняет, почему нужны именно MongoDB, Kafka и несколько сервисов. Если попросить агента написать ADR, он, скорее всего, подберёт аргументы в пользу уже принятого решения, а не проверит его необходимость.

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

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