Vibe Coding's Hidden Trap: When "It Works" Actually Doesn't

We've all been there. You describe your vision to an AI coding assistant, watch it assemble your app piece by piece, see the tests turn green, and ship it with a satisfied grin. This is vibe coding at its finest — fast, magical, almost effortless.

Until something goes catastrophically wrong at 3 AM.

Maybe your app dies with an OOM killer message. Maybe it exhausts every available file descriptor and stops responding. Or maybe it handles your demo data perfectly but chokes the moment real users arrive. The code worked. It solved exactly what you asked it to solve. The problem is that nobody told it there were limits.

The Invisible Box Nobody Mentioned

Here's what conference talks conveniently skip: when you write code yourself, constraints live in your head automatically. You know your laptop has 16 gigs of RAM. You know production limits file handles. You know that 400-gigabyte CSV can't just get loaded wholesale into memory.

AI doesn't carry any of that. When you ask it to sort a file, it thinks: load everything, sort it, done. It works flawlessly because your test file weighs 50 kilobytes. The real file weighs 50 gigabytes.

Traditional code reviews won't save you either. Those lines of code look perfectly reasonable. Nobody flags them for logic errors because the logic is fine. The actual problem is invisible: the code was designed to operate inside a box nobody ever described.

What If Your Compiler Actually Cared About Resources?

This is where things get genuinely interesting. A developer named Nicolas Grislain has been exploring something bold: what if resource limits were part of your code's type signature, not afterthoughts in comments?

Instead of hoping AI-generated code respects memory ceilings, imagine the compiler simply refusing to compile anything that violated them. Picture a world where statements like "this function never keeps more than 100 records in memory" or "this program never opens more than 3 files at once" were verified facts instead of optimistic comments.

This isn't abstract theory. The experiment uses Lean 4 — yes, the same Lean gaining traction in formal mathematics — to bake resource budgets directly into function types. The compiler becomes a resource watchdog, confirming your code stays within limits before execution even begins.

The Mechanics: Resources as Types

The approach is surprisingly elegant. Resource counts get threaded through the type system as phantom parameters that must balance at compile time.

Open a file? Your type signature changes: you enter with N files open, exit with N+1. Close it? Back to N. The compiler tracks every operation. You literally cannot compile code that opens files without closing them, or opens more than your defined ceiling.

Memory handling follows similar logic but with a clever twist. Records don't float around freely — they live in a bounded pool with a fixed number of slots. You don't hold a raw object; you hold a reference into that pool. Types track how many live references exist, and allocation requires proof of available space.

The crucial part: every program must start with zero resources and end with zero. No leaked handles. No exceeded caps. The compiler simply won't allow it.

What This Changes for Vibe Coding

This fundamentally reshapes how you'd prompt AI assistants. Today you might write something vague like "be memory-efficient" or "close all file handles" — wishful thinking, really. With resource-aware types, you state constraints formally, and the implementation must restructure itself to satisfy them.

The flow looks like this: AI gets the unconstrained version, tests pass, then you enable limits. The compiler rejects the implementation. The AI must find a different approach — maybe streaming chunks instead of loading everything, or using connection pools instead of direct file operations.

The result isn't code that accidentally works; it's code proven to work within specified bounds.

The Real-World Situation

Let's be honest: this isn't ready for most teams right now. The Lean 4 setup requires real investment, and thinking in indexed types adds cognitive overhead. But the core insight matters regardless of implementation details.

When vibe coding, you're handing off not just typing but your entire mental model of system constraints. Your AI assistant has no idea your container gets 512MB of RAM. It doesn't know your Linux kernel limits file descriptors to 1024. It doesn't know anything about your actual environment.

Until tooling catches up, you're not helpless:

1. State explicit bounds in prompts — "Input may reach 10 million rows" beats "handle large files efficiently" every time
2. Test with production-scale data — Tiny training data means no intuition about resource behavior
3. Choose bounded architectures — Connection pools, streaming patterns, and bounded queues resist misuse by design
4. Watch the tooling space — The industry is waking up to constraint problems in AI-generated code

The Core Insight

Vibe coding's real issue isn't buggy code. It's code that's correct inside an invisible constraint box — a box that happens to include your laptop, your test server, maybe your first thousand users. It categorically does not include "production under real load."

Resource-aware type systems like this Lean 4 experiment suggest a future where "correct" means more than logically sound. It means provably constrained within actual, existing limits.

That's worth pursuing. Until the tooling matures, keep your test data realistic, and consider adding an explicit note about file descriptor limits in your next prompt.

Your on-call future self will appreciate it.