The Vibe Coding Spectrum: When to Close Your Eyes and When to Look

Two stories landed in the same month.

Story one: Meta's product managers are vibe coding prototype apps and showing them directly to Mark Zuckerberg. They're going from idea to working demo in hours, not weeks. The speed advantage is transforming how one of the world's largest tech companies operates.

Story two: Michael Truell, CEO of Cursor, warned at Fortune's Brainstorm AI conference that vibe coding builds "shaky foundations" that eventually "crumble." He likened it to building a house by putting up four walls and a roof without knowing what's going on under the floorboards.

Both stories are true. Both people are right.

The confusion comes from treating vibe coding as a single thing. It's not. It's a spectrum. And where you are on that spectrum should determine whether you close your eyes or look very carefully at what's being built.

What Truell Actually Said

Let's be precise about the Cursor CEO's warning.

"Vibe coding refers to a method of coding with AI where you kind of close your eyes and you don't look at the code at all and you just ask the AI to go build the thing for you," Truell explained.

He's not saying AI-assisted coding is bad. His entire $29 billion company is built on AI-assisted coding. He's saying there's a difference between using AI as a collaborator and using AI as a replacement for understanding.

"If you close your eyes and you don't look at the code and you have AIs build things with shaky foundations as you add another floor, and another floor, and another floor, and another floor, things start to kind of crumble."

The house metaphor is apt. You can build a garden shed without understanding structural engineering. You cannot build a skyscraper the same way. The approach that works for small, disposable structures fails catastrophically for large, critical ones.

The question isn't whether to use AI for coding. The question is how much to close your eyes, and when.

The Spectrum

Think of vibe coding on a spectrum from "eyes completely closed" to "eyes wide open."

Eyes closed (pure vibe coding):

• You describe what you want in natural language
• AI generates the code
• You run it and see if it works
• You iterate by describing changes, not editing code
• You never look at what's actually been built

Eyes open (AI-assisted coding):

• You work in an integrated development environment
• AI suggests completions, generates functions, explains errors
• You review every line
• You understand the architecture and can modify it directly
• AI accelerates your work but doesn't replace your judgement

Most people operate somewhere between these extremes. The right position depends on what you're building.

When to Close Your Eyes

Pure vibe coding is appropriate when the stakes are low and speed is high.

Prototypes and demos. You're testing whether an idea has merit. You don't need production-quality code. You need something that works well enough to learn from. Meta's PMs vibe coding for Zuckerberg are doing exactly this. The prototype exists to validate a concept, not to ship to users.

Internal tools with limited scope. A simple dashboard for your team. A script that automates a manual process. A form that collects information. Low stakes, limited users, easy to fix if something breaks.

Learning and exploration. You're trying to understand what's possible. You're exploring a new API, a new framework, a new approach. The code is disposable. The learning is the point.

One-off tasks. Generate a report. Convert a file format. Scrape some data. You'll run it once and throw it away. The code doesn't need to be maintainable because you're not going to maintain it.

Hackathons and experiments. Speed matters more than quality. You're racing to prove a concept. Technical debt is irrelevant because you'll rebuild from scratch if the idea succeeds.

In these contexts, closing your eyes is the right choice. Looking at the code would slow you down without adding value. The output is ephemeral. The learning is permanent.

When to Open Your Eyes

The moment stakes increase, eyes need to open.

Anything touching user data. Security vulnerabilities in vibe-coded apps are real and documented. The moment you're handling personal information, authentication, or sensitive data, you need to understand what's actually happening in the code.

Anything going to production. The prototype that impressed leadership is not the system that should serve customers. Production code needs error handling, edge case management, logging, monitoring. Vibe coding rarely produces these.

Anything that will be maintained. If someone else needs to understand this code in six months, it needs to be readable, documented, and architected deliberately. AI-generated code is often functional but obscure.

Anything that scales. What works for 10 users may fail for 10,000. Performance, concurrency, and resource management require deliberate attention. You can't vibe your way to scalable architecture.

Anything with compliance requirements. Healthcare, finance, government. Regulatory requirements exist for reasons. "The AI wrote it" is not an acceptable audit response.

Anything where failure is expensive. The CrowdStrike outage crashed 8.5 million machines and caused $5.4 billion in damages. Speed without deliberation at that scale is catastrophic. Not every system is that critical, but you need to know which ones are.

In these contexts, closing your eyes is negligent. The convenience of speed doesn't justify the risk of failure. You need to understand what's been built, even if AI helped build it.

The Two-Speed Approach

The smartest practitioners operate at both ends of the spectrum, deliberately.

Vibe code to explore. When you're in discovery mode, close your eyes. Generate quickly. Test ideas. Find the shape of the solution. Don't optimise for code quality. Optimise for learning.

Open eyes to build. When you've found something worth building properly, shift modes. Slow down. Understand the architecture. Review the code. Bring in the deliberation that production systems require.

This isn't a contradiction. It's a workflow.

Meta's PMs vibe code prototypes. But if those prototypes become products, engineers rebuild them with eyes wide open. The vibe-coded version proved the concept. The production version is built properly.

The danger isn't vibe coding. The danger is not knowing when to stop vibe coding.

The System 1 / System 2 Connection

This maps directly to the cognitive framework that 49 AI researchers warned about in the SAFE-AI manifesto.

System 1 thinking is fast, intuitive, pattern-matching. It's great for familiar situations and quick decisions. It's how vibe coding works. Describe what you want, let AI pattern-match to a solution, iterate on the output.

System 2 thinking is slow, deliberate, analytical. It's required for novel situations and high-stakes decisions. It's how production systems should be built. Understand the requirements, consider edge cases, anticipate failures, architect deliberately.

The researchers' warning was that AI plus Agile methodology creates pressure for constant System 1 operation. Speed is rewarded. Deliberation is treated as friction. The result is systems built on "shaky foundations."

Truell is saying the same thing in commercial terms. Cursor succeeds because it enables both modes. You can vibe code when appropriate. You can also see the code, understand it, and exercise judgement about whether it's right.

The tool that only enables eyes-closed operation is dangerous. The tool that enables both, and helps users know when to switch, is valuable.

The Skill That Matters Now

Here's what this means for individuals and organisations:

The valuable skill isn't vibe coding or traditional coding. It's knowing which mode to use when.

A PM who can vibe code a prototype in an afternoon is more valuable than one who can only write requirements documents. But a PM who vibe codes a prototype and then pushes it to production is dangerous.

A developer who can accelerate with AI is more productive than one who types everything manually. But a developer who accepts AI output without understanding it is building the shaky foundations Truell warned about.

The skill is judgement. Knowing when speed matters more than rigour. Knowing when rigour matters more than speed. Knowing how to shift between modes as the stakes change.

This is harder than pure vibe coding. It requires understanding enough to evaluate AI output. It requires discipline to slow down when the situation demands it. It requires the wisdom to know which situation you're in.

What Organisations Should Do

If you're leading a team or an organisation, here's how to navigate the spectrum:

Enable vibe coding for exploration. Give people permission to prototype quickly. Provide access to AI tools. Celebrate rapid experimentation. Don't require production-quality code for proofs of concept.

Require deliberation for production. Create clear gates between prototype and production. Mandate code review for anything that ships. Ensure someone with open eyes has verified the foundations before adding floors.

Teach the distinction. Most people don't naturally know when to shift modes. Train your teams on the spectrum. Make the transition from exploration to production explicit. Create language for discussing which mode is appropriate.

Build review capability. You need people who can look at AI-generated code and evaluate whether it's sound. This is the new bottleneck. Not generation, but verification. Invest in this capability.

Accept that speed and safety trade off. Vibe coding is faster. Deliberate coding is safer. You can't have maximum speed and maximum safety simultaneously. The right trade-off depends on the stakes. Make this trade-off consciously, not by default.

The Cursor Lesson

Truell's warning carries weight because his company embodies the alternative.

Cursor isn't anti-AI. It's the most successful AI coding tool on the market. A billion dollars in annual revenue. Nearly 30 billion dollar valuation. It won by being better at AI-assisted coding than anyone else.

But Cursor keeps programmers in the loop. AI suggests, but humans review. AI generates, but humans understand. AI accelerates, but humans maintain judgement.

That's the model that scales. Not eyes closed forever. Not eyes open always. But the wisdom to know when each is appropriate.

Truell could have built a pure vibe coding tool. It would have been easier. The market clearly wants to close its eyes. But he built something more nuanced, because he understands that shaky foundations eventually crumble.

The question for the rest of us is whether we're building on solid ground or setting ourselves up for collapse.

The Practical Framework

Here's a simple decision tree:

Will this code run more than once?

• No → Vibe code freely
• Yes → Continue to next question

Will anyone other than you depend on this code?

• No → Vibe code carefully, review before trusting
• Yes → Continue to next question

Could failure cause harm, cost money, or damage reputation?

• No → Vibe code with review before deployment
• Yes → Open your eyes completely

Are there security, compliance, or regulatory requirements?

• No → AI-assisted with thorough review
• Yes → AI-assisted with expert review and verification

The higher the stakes, the more open your eyes need to be. The lower the stakes, the more you can close them. Most errors come from misjudging which situation you're in.

Both Are Right

Meta's PMs are right to vibe code prototypes. The speed advantage is real. The learning is valuable. The prototypes serve their purpose.

Truell is right to warn about shaky foundations. Production systems built without understanding will crumble. The technical debt will come due. The security vulnerabilities will be exploited.

The mistake is treating vibe coding as all-or-nothing. It's not. It's a spectrum. The skill is navigating it.

Close your eyes when the stakes are low and speed matters. Open them when the stakes are high and quality matters. Know which situation you're in. Shift deliberately.

That's the capability that matters now. Not just prompting. Not just coding. The judgement to know which mode, when.

Build fast. Ship prototypes. Learn quickly. And when something matters, look at what you've built before adding another floor.