https://thenewstack.io/mcp-vulnerability-exposes-the-ai-untrusted-code-crisis/

Непонятно почему это рассматривается как новая проблема. И до появления LLM код получал одобрение не потому, что его написал человек, а после прохождения тестов, сканеров, ревью, ручных проверок QA и всего остального, что удалось «впихнуть» в CI и SDLC. Были исключения для отдельных людей и отдельных проектов, но это были именно исключения.

И то, что действительно изменилось сейчас — это существенно увеличившийся объём кода на одного программиста и визуальная адекватность кода, которая притупляет бдительность. И эти факторы будут только расти: создавать код будет всё проще.

И это то, почему QA как часть процесса разработки становится всё более важным.

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

• Выстраивание чётких процессов одобрения кода: даже если код на первый взгляд выглядит адекватно, он всё равно может содержать любые ошибки
• Улучшение документации: чем больше контекста будет у LLM, тем меньше вероятность ошибок
• Обучение Context Engineering всех разработчиков: чем лучше разработчики будут понимать, как строить контекст для LLM, тем меньше вероятность ошибок
• Объяснение им всех рисков и их ответственности: разработчики должны понимать, что они несут ответственность за код, который они коммитят, вне зависимости от того, кто его написал
• Автоматизация проверок кода старыми методами: тесты всех уровней, линтеры, статические анализаторы, dead-code-сканеры (это прямо беда LLM), поиск заглушек
• Включение QA на ранних этапах SDLC: это даст улучшение спецификаций, возможность построить QA-тесты, доступные разработчикам и так далее
• Использование LLM для проверки кода
• Внедрение Canary Deployment и/или Ring-based Deployment чтобы сократить ожидаемые потери от ошибок
• Внедрение Feature Flag для отключения новых фич для критичных проектов
• Улучшение Observability, мониторинга и алертинга