Vibe coding creates security debt; verification engineering becomes the real skill

The thesis. Vercel CEO Guillermo Rauch argues that the era of AI agents demands a new discipline he calls verification engineering: defining the tradeoffs, axioms, and guardrails that guide agents instead of letting them ship unfiltered output. He positions this as the real bottleneck for teams adopting AI today.

The workflow. Rauch describes his personal agent setup built around FX, a 6 MB CLI that boots as fast as a shell. He uses it for research, project creation, and 'agentic inquiry'—having agents explore code or infrastructure and report findings. His key design principle is minimalism and speed, rejecting the bloat that accumulates in larger agent harnesses.

The security warning. The biggest risk, he argues, is the 'immeasurable latent vulnerability' in human-written code, now exploitable by cheap AI agents. He points to the libhif CVE and a hypothetical attack through Artifactory as examples. His advice: move to memory-safe languages like Rust, run development in sandboxes, and proactively audit with tools like DeepSeek.

The velocity distinction. Rauch distinguishes iteration speed from iteration velocity: speed without direction leads to slop. He warns that many teams are token-maxing and PR-counting without asking whether they're moving toward a meaningful goal. The real metric should be end-to-end error-free sessions and user impact.

What teams miss. Most discussions about AI coding fixate on model capability or prompt tricks. Rauch instead emphasizes understanding the underlying stack—latency numbers, caching tiers, file systems—so you can push agents harder. He coins 'agentic inquiry' as the practice of using AI to deepen your own understanding rather than bypass it.

The trade-offs. There is tension between shipping fast (vibe coding) and maintaining security and quality. Rauch argues that technical debt is healthy in product-critical areas, but security and core infrastructure demand opposite rigor. He also notes that obsession with unit tests often gives false confidence, and suggests investing in broader verification (e.g., type systems, proofs).