I am coming to understand that different people want very different things from agentic coding.

That should not be surprising. Not everybody is building the same kind of software. Not everybody works in the same kind of organization. Not everybody is trying to solve the same problem when they open Claude Code, Codex, Cursor, Gemini, or any other coding agent.

For some people, agentic coding is a way to explore.

They have an idea, but not yet a settled design. They want to try three versions of a UI, poke at an API shape, test a library, or build a throwaway prototype just to learn what the problem really is. That is a valid way to work. I do it too. When I am feeling out the shape of a piece of software, I often need the software to push back on my assumptions.

But that is not the only mode of software development.

And for many serious software teams, it is not the normal mode.

In most software companies I have worked with, it would not be acceptable to tell developers:

Go prototype several different things and bring them all back so product can decide which one we like.

That is not a process. That is expensive ambiguity.

It may work for a founder hacking on an idea over the weekend. It may work for a solo developer trying to understand a new domain. But in a team with product owners, business analysts, customers, delivery commitments, architecture constraints, compliance expectations, and release gates, the work needs to become explicit before implementation runs away.

That is what spec-driven development (SDD) means to me.

It is not paperwork for its own sake. It is not a nostalgic return to heavyweight requirements documents. It is not a way to slow engineers down.

Spec-driven development is about forming agreement.

Before code is written, the team needs a shared understanding of what the software is supposed to do. Product intent, customer intent, business rules, edge cases, non-goals, vocabulary, and constraints all need somewhere to live.

At this point in history, there is still no better medium for that than words.

We can draw diagrams. We can point to screenshots. We can link tickets and paste chat threads. But eventually, the thing we mean has to be expressed in language clearly enough that another person, or now another agent, can act on it.

This is the gap that agentic coding exposes so sharply.

Coding agents are very good at producing code. They are increasingly good at reading code. They can navigate large repositories, infer patterns, run tests, and make changes faster than any human team could have imagined a few years ago.

But they still need to know what we mean.

If the intent is vague, the output will be vague. If the vocabulary is inconsistent, the implementation will drift. If product and engineering have not agreed on the behavior, the agent will happily encode one interpretation while stakeholders are still carrying three others in their heads.

That is why "just let the agent build something" is not enough for team software.

The question is not whether agents can generate code. They can.

The question is whether the team has created a durable expression of intent that the agent can build from, reviewers can evaluate against, and future maintainers can understand.

This is where Spec Kitty is focused.

Spec Kitty accelerates the path toward those words. It helps break down intent into two different but connected artifacts:

The What: the specification.

What should the software do? Who is it for? What are the user scenarios? What are the acceptance criteria? What is explicitly out of scope?

The How: the plan.

How should the system change? What architecture decisions matter? Which files, services, data models, APIs, or workflows are involved? What are the risks, dependencies, and sequencing concerns?

That distinction matters.

A product owner should not have to specify implementation details to express customer intent. A developer should not have to infer product meaning from a half-written ticket. A reviewer should not have to reverse-engineer the intended behavior from a diff.

The spec and the plan create a bridge.

Then the work can be decomposed into work packages, reviewed against the stated intent, and accepted against clear criteria. Along the way, the team's own rules can be applied: quality gates, common vocabularies, architecture constraints, testing expectations, glossary terms, review policies, and the hard-won best practices that have accumulated inside the organization.

That is the part people miss when they reduce spec-driven development to "write a prompt before coding."

The spec is not just a prompt. It is a point of agreement. A control surface.

It is the place where a team says: this is what we mean, this is what matters, this is how we will know whether the work is done.

There will always be room for exploration. Sometimes you need prototypes. Sometimes you need a quick experiment. Sometimes you need to use the agent as a sketchpad before you know what you want.

But when the work becomes real, when other people depend on it, when the software has to fit into a product, a codebase, a customer promise, and a team process, the intent needs to be written down.

The future of software may be humans expressing intent and AI implementing it. But that future depends on our ability to express intent well.

So for me, it all comes down to one thing:

Read the spec.

Spec Kitty is an open source SDD framework for agentic coding. Try it out!