Designers and PMs should learn to spec code over vibe coding.

And if that made you uncomfortable, good. Keep reading.

Welcome back to Gyanesh on Product, This week we uncover the latest trend in the AI space, "spec-coding" over what we know today as "vibe-coding". I share such insights for free regularly, and you can show your support by subscribing to the newsletter.

Let me tell you about the moment I realized most people are using AI at a fraction.

Not wrong in the "you'll get fired for this" way. Wrong in the quiet, invisible way — where you're putting in the hours, shipping things, feeling productive, and somehow the output still feels like it was built by someone who almost understood what you wanted. Because it was. That someone is the AI. And you gave it a vibe instead of a blueprint.

We've collectively convinced ourselves that vibe coding — dropping a prompt into an AI agent, getting code back, tweaking, repeating — is the new way to build. And for a certain kind of work, it absolutely is. Quick experiment? Throwaway prototype? Vibe away. But somewhere along the way, vibe coding stopped being a starting point and became the entire process. And that's where it quietly breaks down.

Here's the thing nobody's saying out loud: the bottleneck in AI-assisted building was never writing code. It was always knowing what to build. Vibe coding doesn't solve that. It just makes the guessing faster.

So here's my controversial take, and I mean it sincerely:

Designers and PMs are better positioned to spec code than most developers. They've just never been told the door was open.

Spec-driven development — the thing the video I watched this week articulates so cleanly — isn't a developer skill. It's a thinking skill dressed up in technical clothing. Instead of prompting an AI on how to build something, you start by writing what the system should do: its behaviour, its constraints, its edge cases, its failure states. That document becomes a contract. The AI executes the contract. You don't get surprised two weeks later.

The flow is: Describe behaviour → Lock requirements → Approve design → Then and only then: build.

Nothing gets coded until you've said yes to the blueprint. And here's what's wild — that's just a PRD. That's a design brief. That's the thing Designers and PMs have been writing for years, for human engineers, and filing away after handoff. The only thing that changes now is that your document doesn't go into a Notion graveyard. It becomes the instruction set for an AI agent that will actually build the thing.

That realization hit me hard enough that I started putting a /PRD folder at the root of every project I ship. NotebookLM for Windows — 150+ downloads, v2.0 with Ghost Mode, native drag-and-drop, and Windows toast notifications for audio generation — started as a spec. Gemini for Windows — multi-view sessions, resizable panels, a global shortcut — started as a spec. Neither of them felt like MVPs at launch because the AI wasn't guessing. It was executing a contract I had already approved.

Go look at either GitHub repo. The PRD folder is sitting right there, public, before a single line of code was generated.

The quality of what you ship is now a direct function of the quality of your spec. Not your coding ability. Your thinking ability.

This is why the "learn to code" argument is aging badly. The new skill isn't syntax. It's specification. It's the ability to describe a system's behaviour so precisely, so completely, that an AI agent has no room to improvise in ways you didn't intend. Developers spent years learning to communicate with machines through code. Spec-driven development says: communicate in your language, and let the machine translate.

And designers and PMs? They've been communicating system behaviour to humans for their entire careers. User flows. Edge cases. Failure states. Acceptance criteria. They've been writing specs. They just didn't know it counted.

Meanwhile, a lot of developers are vibe coding their way into a mess they'll have to maintain for months. Not because they're bad developers — but because vibe coding quietly skips the entire planning phase of the software development lifecycle, and the AI picks one of thirty possible implementations without ever being told which one you actually wanted. Sometimes you get lucky. Usually you get a codebase that works but that nobody fully understands, including the person who prompted it.

Here's where I land, and yes, I'm ready to defend this in the comments:

Vibe coding and spec coding are not competing methodologies. They're different phases of the same process. Vibe code to explore — to test whether an idea is worth building at all. Spec code to ship — to build something that holds up, that scales, that you're not embarrassed to put your name on.

The people who figure out how to do both, in the right order, are going to ship circles around everyone arguing about whether AI will replace developers.

The future isn't prompt engineers. It's spec writers who know how to wield an AI agent like a contractor, not a magic box.

Designers. PMs. Researchers. Strategists. If you've been waiting for your invitation to build — this is it. You've had the most important skill all along. You just needed a workflow that knew what to do with it.