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, моніторингу та алертингу