choong pw

Over the past year, the conversation around AI‑assisted coding has shifted from awe to practicality. We’ve moved past the “wow” phase of generating full‑stack apps from a single prompt and started asking tougher questions — can we maintain this code? Can we extend it? Does it work in production?

From what I’ve seen, the answer depends heavily on one thing: how well we define our specs.

The limits of “Vibe coding”

When LLMs became mainstream for coding, a lot of developers (myself included) started experimenting through what I call vibe coding — typing a quick prompt, watching the AI generate files, tweaking a few lines, and moving on. It’s fun, fast, and feels creative, but it also has a hard limit.

In real‑world software engineering, we have existing systems, chosen stacks, and long‑term maintainability concerns. A single‑shot generation might look impressive, but scaling from a demo to a working product isn’t that simple. The result often becomes a patchwork of files that “work” but don’t fit well together. You spend more time reviewing and repairing than building new value.

What spec‑driven development brings

Spec‑driven development (SDD) isn’t new, I first observed through Kiro. And it’s gaining new relevance now that AI has entered the workflow. Instead of rushing into code, SDD encourages you to start from the specification: document what you want, define architecture, choose tech stacks, and break things into stepwise tasks.

On paper, this sounds slower — but in practice, it makes AI collaboration smoother. Once your spec is well‑articulated, the model can help generate, refine, and integrate components faster and more accurately. This process feels more like development than rackless vibe coding and hoping for miracle.

I could rebuild apps multiple times and still move forward

During my recent hackathons, this mindset completely changed how I worked. It wasn’t about getting perfect output in one go. It was about clarity and iteration. I could rebuild apps multiple times and still move forward, because every rebuild started from a solid spec instead of scattered fragments of trial code.

Learn by starting, failing, and refining

Here’s something I’ve learned the hard way — you won’t get clarity sitting still. If you’re not clear about what you want, just start. Don’t overthink it. Build the first version, fail fast, and observe what breaks. That process alone teaches you a lot about what can or cannot work.

If you’re not clear about what you want, just start. Don’t overthink it.

Sometimes you’ll find yourself going in circles trying to fix an old foundation; in those moments, it’s almost always better to restart. Each rebuild sharpens your thinking. With every iteration, you’ll naturally learn to articulate your requirements better — whether it’s clarifying the system design, refining user flows, or describing constraints for AI tools to work within.

Mistakes become feedback loops. And with AI in the picture, the cost of starting over is lower than ever.

Why it’s worth mastering

SDD demands a bit more discipline. You need to learn how to move between three modes of thinking:

• Requirement clarity — defining outcomes instead of random ideas.
• Architectural thinking — deciding how pieces fit together.
• Incremental iteration — adjusting as you validate results.

This workflow might sound simple, but it’s surprisingly rare. Many developers (especially when working solo with AI tools) skip straight from idea to code. That’s fine for prototypes — but if you want stable, extensible systems or want to collaborate with AI effectively, it pays to slow down and plan.

With AI improving so quickly, the engineers who’ll stand out are those who can articulate precisely. The better you describe the spec, the more useful AI becomes. Poorly written goals or unclear context, on the other hand, easily create technical debt. That gap between clarity and chaos is where mastery makes all the difference.

That’s also why your technical skills are still relevant, because you’ll need it to articulate better.

A shift in developer culture

I’ve noticed a cultural shift among developers using assisted tools. We’re learning how to prompt AI to draft specs, then refine them — just like we review code. In a sense, we’re rediscovering classic software engineering discipline but different form.

Should we now treat the SDD as a documentation. In my humble opinion, NO. Many are now treating specs as kitchen sink documents for AI. Specs are like code, lesser is better. Use AI to summarize in a way human will read when you want to keep it long term.

I am probably in a world where I see most engineers skips the vibe code and start building with SDD. Because vibe coding never really rhythms with software engineer to begin with.

Closing Thought

Spec‑driven development is not hype — it’s a habit. Thoughtful design and clear communication still matter, even when a machine writes most of the code. The better we master this, the better we can leverage the power of AI into a dependable collaborator.

In the next post, I’ll talk about how MCP and Steering Docs are shaping the ecosystem of agentic coding, and how one of my projects — Jedi MCP — fits into this picture.

Here is a sneak peak of what it does.