Requirements are Dead Weight: Why JTBD is the New Interface for AI

It is 2026, and the “How” of software development has been solved.

We’ve seen the headlines: Anthropic’s Claude is roughly 80% AI-generated. Forward-thinking firms like NVIDIA are moving toward mandates for AI-authored codebases. While the debate over pure “logic” vs. “speed” continues, one thing is undeniable: AI can now out-pace and out-structure the vast majority of manual coding tasks.

In this reality, the traditional, granular “Requirements Document” isn’t just a bottleneck—it’s an artifact of a bygone era.

The Traditional (and Broken) Pipeline

For a long time, the standard product flow looked like this:

1. The One-Pager: Convince the business this is worth the investment.
2. The Great Leap: Jump immediately into epics, user stories, and acceptance criteria.

Let’s be honest: many Product Managers skip the “why” entirely. They go from a business goal straight to a technical spec. The irony is that the teams with the worst outcomes were always the ones who thought they could specify exactly how a feature should work before a single line of code was written. That’s just Waterfall in an Agile mask.

The “Best” PMs—the ones I’ve always looked to for inspiration—have always used a different lens: Jobs to be Done (JTBD).

The Vibe Coding Reality

As a “Vibe Coder,” I’ve had to lean into this philosophy out of necessity. I’m a Product Manager, not a developer. I can’t write the syntax, but I can define the outcome.

There’s a framework circulating about the Six Levels of Vibe Coding. Most people are stuck at Level 2—treating AI like a junior intern that needs a checklist of instructions. Because I couldn’t “micromanage” the code, I organically moved to Level 4. I give the AI direction based on the job the user is trying to do, and I test the results.

I’ve realized that AI doesn’t need your user stories. It has written authentication loops a million times. What it lacks is empathy and context.

A Radical Shift in The Product Product

In my product, The Product Product, we are making a strategic pivot to reflect this shift.

We aren’t deleting our “Requirements & Epics” feature—not yet. Human teams still need them for alignment, and clients still want to see the “bill of materials.” But we are radically deprioritizing them.

In the new workflow, the “Requirements” list is being moved to the background. It will be used maybe 20% of the time. Instead, we are doubling down on our Jobs to be Done feature as the primary engine for AI generation.

Why? Because in 2026, JTBD is the new prompt engineering.

When you provide an AI with a sophisticated JTBD framework, you aren’t telling it what to build; you are telling it what the user needs to achieve. You are describing the “hole in the wall,” not the “drill.” This builds the empathy bridge that allows the AI to navigate the technical “how” with far more creativity and efficiency than a rigid ticket ever could.

Moving Forward: The Job is the Requirement

If you want to move from a Level 2 “Manager” to a Level 4+ “Vibe Coder,” you have to stop specifying and start empathizing.

I’m calling it out to the pioneers of the Jobs to be Done movement—Bob Moesta, Anthony Ulwick, and the legacy of Clayton Christensen. I believe your framework, originally designed for business strategy, is actually the ultimate technical interface for the AI era. I’ll be tagging them on LinkedIn to see if they agree.

Requirements are for humans who don’t have context. Jobs are for AIs that have all the technical skill in the world but need a reason to use it.