Vibe coding method that actually works

Source: Dev.to

📍 Engineering’s current situation

You might have heard this already a ton of times: software engineers are going to be replaced with AI systems, agents, and tools.

We won’t comment too much on this particular thing, as no one is clear about it. But a few predictions/things are already happening in the industry:

1️⃣ Small teams are getting really, really effective/productive.
2️⃣ People with agency and intent are being preferred over people who are merely skilled or smart.
3️⃣ Companies will move even faster than before.
4️⃣ Software is building itself.

😳 Examples

• Claude Code is being built using Claude.
• Traycer is being built using Traycer AI.

There is one common thing in every organisation that it is not about:

❓ Should you use AI or not?
It is about how you should use AI.

A lot of people don’t know if they are doing vibe coding or AI‑assisted coding. Yep, there is a huge difference between Vibe Coding & AI‑Assisted Coding.

📍 Usual way of vibe coding

Vibe‑coding workflow generally looks like this:

• You have an agentic IDE (e.g., Cursor, Windsurf) or CLI agents like Claude Code, Gemini CLI.
• You put a prompt in the chat window.
• Your agent reads the prompt, plans, and then starts generating code.

This method works on very small features or when you are starting from scratch because:

• Starting with a fresh context/instance of the agent works for a while.
• As you keep generating code, the agent starts drifting from the actual intent you gave it.
• Small & simple features can be implemented by most LLM models like Claude, Grok, etc.

📍 When things actually break?

As soon as someone starts working on larger codebases, complex features, or end‑to‑end products, agents struggle because:

• They drift away from the human‑given prompt or intent.
• Their performance degrades as the context window fills up.
• Hallucinations appear with confidence and no verification loops.

👉 Because of this, users generate thousands of lines of code only to realise nothing works. Refactoring that codebase becomes a very tedious task, leading to many iterations.

This struggle creates a pseudo‑productivity boost, many iterations, and headaches.

So how should we vibe code then?

No, the picture above doesn’t refer to how you should code 🤪

Coding is still a fundamental problem‑solving method where structure wins, even after many code‑generation LLMs. Using first principles, the process is:

1. Write a PRD (product/feature requirement doc).
2. Divide the PRD into specs.
3. Create tech docs and then sub‑tasks.
4. Assign sub‑tasks to your team so they can finally code.
5. Verify the implementations.

This is where the inner loop solves your problem: code generation.

But have you noticed which part is missing?

Yes, exactly – the outer loop.

📍 The Outer Loop

Missing pieces that keep LLMs from being fully capable of coding are:

1️⃣ Writing a PRD.
2️⃣ Dividing a PRD into specs.
3️⃣ Making tech docs and then sub‑tasks.
⚠️ Assigning sub‑tasks to your team (using the inner loop or LLMs).
4️⃣ Verifying the implementations.

This is where a new field shines – Spec‑Driven Development.

Many products are trying to solve spec‑driven development, which generates PRDs, plans well, verifies each agent’s code step, and prevents agents from drifting away from the user’s intent. Products in this space include Traycer, Kiro, Spec‑kit.

My friends are obsessed with Traycer because of features like EPIC mode, which is highly intuitive.

Traycer solves problems no one else can yet

• Capturing human intent from a normal simple prompt.
• Preventing agents from deviating from the intent.
• Consuming fewer tokens and preventing context bloating.
• Verifying each change so you don’t ship hallucinations with confidence.

Here is a sneak peek of how Traycer AI EPIC mode looks

Traycer AI is my partner nowadays because it acts like my senior engineer instead of just an agent. Highlighting a few features:

• It starts with a simple prompt.
• Then it interviews you around problem statem

Overview

• High‑level questions – product vision, target audience, market fit, tech stack, edge cases, and other strategic considerations.

• Generated deliverables – PRDs, specs, tech flow diagrams, wireframes, sequence diagrams, and user‑flow diagrams.

• Ticket breakdown – the plan is split into smaller tickets that can be handed off to any AI agent (e.g., Claude, Grok, Cursor IDE, etc.).

• Verification – each change is verified to keep agents from drifting or deviating in the wrong direction.

📍 Recently we shipped products like:

• Building your own Redis.
• Building my own WhatsApp that supports semantic search across messages.
• And many more projects we’re building and loving the EPIC mode ❤️