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

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

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

Когда AI заменяет понимание

Представим команду, которая решила создать новый продукт на Rust и MongoDB. При этом глубокого опыта работы с этими технологиями у разработчиков нет. План выглядит современно: подробно описать требования, использовать spec-driven development и поручить значительную часть реализации AI-агентам.

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

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

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

Проблема не в MongoDB или Rust. Любая технология может оказаться удачным выбором. Важно, чтобы архитектурное решение основывалось на реальных требованиях, а не только на интересе к новому инструменту и уверенности в возможностях AI.

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

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

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

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

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

AI снижает стоимость создания технической сложности, но не гарантирует снижения стоимости её дальнейшей эксплуатации.

Почему хорошая спецификация не спасает от плохой архитектуры

Spec-driven development помогает точно описать поведение системы и критерии готовности. Чем подробнее требования, тем меньше приходится угадывать AI-агенту.

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

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

В результате получится система, которая соответствует спецификации, но содержит неоправданную сложность.

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

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

Один из популярных подходов — поручать разным AI-агентам разработку и проверку результата.

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

Такая проверка может быть полезной. Независимый анализ способен обнаружить ошибки и пропущенные сценарии.

Однако несколько положительных заключений AI не доказывают, что команда понимает собственную систему.

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

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

Но даже качественное AI-ревью не заменяет инженерную компетенцию.

Что такое долг компетенций

Технический долг обычно связан с недостатками реализации: дублированием кода, временными решениями, отсутствием тестов или сложной архитектурой.

Долг компетенций — другое явление. Это ситуация, когда команда экономит время на изучении решений, но постепенно теряет способность самостоятельно изменять, диагностировать и восстанавливать систему.

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

Такой долг проявляется на двух уровнях.

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

Второй — потеря понимания конкретного продукта: его истории, бизнес-ограничений и причин ранее принятых решений.

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

Риск заключается в том, что AI способен выполнить практически весь цикл работы: исследовать проблему, предложить гипотезу, изменить код, запустить тесты и проверить результат.

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

Похожий эффект автоматизации описывала Лизанна Бейнбридж ещё в 1983 году в статье «Ирония автоматизации». Автоматизация берёт на себя регулярные операции, оставляя человеку редкие и сложные ситуации, когда требуется вмешательство.

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

Почему ошибки техлидов особенно опасны

Часто обсуждают, как AI влияет на обучение начинающих разработчиков. Но риски существуют и для опытных инженеров.

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

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

Например, компания много лет использует PostgreSQL. У неё уже есть мониторинг, резервное копирование, документация и специалисты, умеющие устранять проблемы.

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

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

Продакшен начинается после запуска

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

Со временем увеличивается объём данных, меняется нагрузка, появляются новые конкурентные операции. Запросы начинают выполняться медленнее, возникают тайм-ауты, отстают реплики, перестают подходить ранее созданные индексы.

AI может помогать анализировать логи, метрики, трассировки и конфигурации. Иногда он способен быстрее человека обнаружить причину проблемы.

Однако принципиально различаются две ситуации: когда AI помогает инженеру разобраться в понятной ему системе и когда AI остаётся единственным доступным способом понять её устройство.

Во втором случае зависимость от агента становится особенно опасной при нестандартных инцидентах.

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

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

Как использовать AI без потери компетенций

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

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

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

Разница заключается в подходе.

В первом случае инженер использует AI, чтобы не разбираться в технологии. Во втором — чтобы разобраться в ней быстрее.

Оба варианта могут привести к работающему продукту. Однако уровень понимания у команды будет разным.

Перед внедрением нового архитектурного решения техлиду стоит убедиться, что команда способна объяснить:

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

Важно не просто получить ответы от агента, а действительно понимать их.

Главный вывод

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

Но вместе с этим снижается естественное сопротивление ненужной архитектурной сложности.

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

Главный вопрос уже не в том, способен ли AI собрать систему на выбранном стеке. Важно, сможет ли команда через несколько лет самостоятельно объяснить её устройство, поддерживать работу и восстановить после серьёзного сбоя.

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