Looks clean, crashes hard. Why you shouldn’t vibe-code a Windows Kernel Driver

My colleagues tried building a prototype EDR driver (intercepting file I/O, process creation, and registry changes) entirely with AI tools.
The surprise: AI generated amazingly clean, 8-module, maintainable architecture with dynamic IOCTL handling and ring-buffer diagnostics.
The reality check: It also accidentally introduced major security flaws and BSOD triggers:
Open Device Access: Unprotected control device allowing unprivileged IOCTL execution.

Missing I/O Paths: Completely missed memory-mapped writes and Transactional NTFS.

BSOD Traps: Name queries on paging paths causing deadlocks, plus missing re-entry guards (recursive callback loops).

Context Naivety: Hardcoded trust for PID 4 and threadless IRPs.

Lesson learned: AI can generate gorgeous facade code, but kernel drivers require deep domain knowledge about race conditions, memory paths, and threat models that AI currently misses.
Let me know in the comments if you want a follow-up post with more details!