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