Недовірений код

У першому коментарі посилання на статтю “MCP Vulnerability Exposes the AI Untrusted Code Crisis”

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