Про связь vibe coding и архитектуры Будем исходить из определения, что vibe coding - это подход к разработке, при котором программист описывает задачи на естественном языке, а искусственный интеллект генерирует код. Все описанные ниже потенциальные проблемы касаются крупных и сложных систем, которые нужно поддерживать. Итак, к чему быть готовыми: ▪️Накопление техдолга / непоследовательная и нелогичная архитектура При «кодинге» без четких ограничений и требований создается неструктурированный код с непоследовательными стилями. Как говорил еще Фред Брукс: Я считаю, что концептуальная целостность — главный принцип в проектировании систем. Лучше сделать систему чуть проще - без некоторых спорных, выбивающихся из общего замысла функций и улучшений, но выдержанную в единой логике и стиле, чем систему, в которой собрано много хороших идей, но каждая сама по себе и никак не связана с другими. Сгенерированный ИИ код часто бывает хрупким и плохо организованным. Кстати, мы снова начали слышать про dead code, о котром уже успели позабыть. В отчетах стали появляться куски кода, которые никогда не исполняются, хотя раньше это казалось нонсенсом. Это неизбежно, если явно не указывать как код (ответственность) должен распределяться по модулям и слоям и не контролировать этот процесс, учитывая, что ИИ генерит очень много рабочего кода. И не забываем, что ИИ может потерять часть контекста проекта, что часто приводит к неожиданному регрессу. ▪️Сложностью отладки Отладку кода, сгенерированного ИИ, часто описывают как «чрезвычайно сложную». Разработчики не до конца понимают логику кода, написанного ИИ и, вместо поиска причин ошибок, нередко прибегают к повторной генерации кода, пока тот не заработает. Это решает поверхностные, чаще синтаксические проблемы, но не работает против сложных архитектурных багов на уровне бизнес-логики или взаимодействия компонентов. ▪️Безопасность Отдельный пласт проблем порождают проблемы безопасности. ИИ может непреднамеренно создавать уязвимости, например: использовать устаревшие библиотеки, небезопасные настройки по-умолчанию. Иногда бывают совсем интересные случаи, когда сгенерированный код с запросами к базе данных часть параметров экранировал, а часть – нет. И нужно было ему очень настойчиво описывать подход с экранированием параметров, чтобы в итоге он написал безопасный код. ▪️Over-engineering ИИшки могут предлагать сложные решения для простых задач, если им не хватает контекста и эти решения помимо того, что ведут к проблемам, описанным выше, так еще и могут вызывать проблемы с производительностью и масштабируемостью. Не указали, что у сервиса есть ограничение сверху на потребление памяти? Ну и получите сложный алгоритм и бесконечный рост потребления ресурсов 🙂 Как с этим жить? Выше упомянул Фреда Брукса. Увы, той самой пули не существует, но что можно сделать прямо сейчас (широкими мазками): ▪️Человек проектирует жесткие контракты, интерфейсы, структуру модулей. ИИ наполняет. Запрет на делегирование ИИ архитектурных решений (по крайней мере на текущем витке развития). То есть… человек - архитектор, ИИ - строитель 🙂 ▪️Очень жесткие quality gates. Строгие линтеры, SAST’ы, DAST’ы, проверки зависимостей, ArchUnit-тесты. И все это в CI/CD и блокировать сборку при малейшем отклонении. ▪️Договориться о правиле «не понимаешь - не мержишь». В Google (читал пост от какой-то команды) есть практика code review: если ревьюер не понял код за первые секунды - reject. Нужна определенная инженерная культура, чтобы это не приводило к межличностым конфликтам, но с ИИ проще - он не обижается. Однако, теперь важно не просто реджектнуть, но и явно просить модель провести рефакторинг с объяснением, что именно непонятно, иначе можно застрять в цикле генерации мусора. ▪️Зашивать в системный промпт лимиты по памяти, список запрещенных библиотек, требования к сложности алгоритмов (O-нотация) и принципы KISS/SOLID. ИИ должен знать о своих ограничениях до того, как напишет первую строчку. То есть… требования к квалификации разработчиков, использующих ИИ-агентов, должны вырасти?