AI Broke the Spec Handoff

A PM can sketch a feature in the morning. By lunch, an agent-backed engineer can turn it into a working version with tests and docs. If the spec hides an assumption, the team finds out after it's done.

That changes what a spec has to be. A spec can't stay a handoff that one person writes and another person interprets later. The people who understand the product, design, and system constraints need to build the spec with the prototype together.

The Old Loop Assumed Work Was Slow

Software teams reduce risk by moving slowly in small steps.

Spec
    ↓
Engineering review
    ↓
Design review
    ↓
PM finalization
    ↓
Engineering build
    ↓
QA
    ↓
Customer reaction
    ↓
Adjust
    ↺ back through the loop

Sprints, demos, and backlog reviews all assume the team can learn from mistakes before any bad ideas spread too far. Small steps helped with this product uncertainty, and that worked well because implementation took enough time that small steps is all you could do.

The tail of implementation (testing, hardening) is still real. But work can get much further before the next check-in, which means a small misunderstanding can turn into an implemented pattern that work is being built on top of in a day.

Handoffs Leak Judgment

A good spec saves wasted motion. I like specs.

A spec usually travels as a handoff. The PM clarifies the problem, the engineer reads the document later, and the document is implemented in the product. On complex work, design and product review add more passes, and each pass loses a little context. A document can record decisions but it cannot carry all the judgment behind them.

The PM remembers which user quote mattered most. The engineer knows which service is about to change, which means we should sequence differently. The designer sees where a flow will confuse people. Those details shape the spec, but not every consideration is transferred with the spec.

For example, an engineer might make a small implementation choice to simplify implementation of the spec. To the PM, it removes future flexibility that they wanted to build toward but needed more customer feedback first. Writing and better specs help, but the leak wasn't a big deal when the loop was slow.

The Leak Costs More Now

It's very easy for a document or an idea meant as a conversation starter can become a working flow before the PM realizes it was interpreted as direction. You can just build it. A small engineering shortcut can have tests, docs, and UI assumptions before the person rebuilding a server has time to review and say, "We have to reverse this next week".

These divergences can be in several repos in hours, and untangling them may take longer than creating them. And frustrating to the team. The team followed the process, interpreted the artifact in front of them, and then were told they didn't have the full picture and have to revert it. Demoralizing.

The team needs to catch these leaks while the work is being shaped, before it is customer ready work people are proud of.

Build the Spec With the Prototype

With AI it's possible to build the prototype together with all the people who understand the problem (engineer, PM, designer, etc). Before that would be a live call where everyone waits for an engineer to code, which is miserable for everyone (especially for the engineer). An agent can build and change the prototype in seconds so everyone can stay in the discussion.

The PM is going to have things they learned from user interviews in mind. The designer is figuring out how to make it so a understandable and without footguns that will surprise the user. The engineer is pointing out which decisions require a huge change or new infrastructure, which let's the PM weigh how important that piece would be to users. All of this makes the prototype and the spec that comes from it sticky. The mental model for this feature was built together, and the spec is just solidifying details.

That is the point of a shared agent in a shared workspace. Everyone needs to see the same artifact and steer it while the spec is still forming. By the end there will be some artifact that is the first phase of work (not notes, but maybe a spec, a prototype, or whatever the point of the meeting was)

A Meeting Can Be Engineering Work

I say this as an engineer because my instinct has always been to build first. I used to write code to understand the problem, and a lot of that happened in Jupyter notebooks because the code and visual feedback lived in the same place.

Shared agents move that loop into a room with everyone else on my team. The PM and designer do not have to wait for me to return with an interpretation. They can watch the interpretation form, build prototypes with me, and when I go build the final feature I don't have to guess what the PM/Designer had in mind on all the small implementation decisions that come up as I go.

And PMs often feels like pulling an engineer into a room feels like taking time away from code. That worry is often right. I would often be frustrated with high level notes and decisions. I know there's many layers of product decisions in the implementation details, but when I talk about implementation details I feel like nobody is interested and just want to talk general direction. I end up noting these as things to make a video about when I have a prototype or V1 built, because I can't seem to get the point across otherwise.

I am blocked until I have these discussion with others which means I know I will need another meeting to get the info I actually need. I've been so annoyed at this that, I've done toastmasters speaking clubs and hired communication coaches to try to communicate better so I can get my point across.

But building the whole prototype and getting into those details that's part of my implementation work live in the meetings solves all of that for me. And when the meeting ends I just continue building.

Keep the Reasoning With the Work

The co-built spec only helps if the reasoning stays attached. In many companies, the spec is in Google Docs, prototype in github, debates in Slack, call notes in granola, tasks in linear/jira. That's...normal? Nobody searches five systems well to reconstruct one decision, and the coordination and syncing between all those systems gets skipped.

If you do try to keep all those systems up to date, and update them whenever any of them changes then you've rebuilt the handoff problem. The context cannot split across tools. The next person or agent needs the spec and decision trail in one place, because things will be missed otherwise.

Scaling Without Putting Everyone in the Room

Fifty people cannot sit in every conversation. Some teams avoid coordination by staying tiny. Some let one person make all the taste calls. Some give each person a separate area. These choices work for a while, but they turn into bottlenecks with scale. If adding people feels scary because of management overhead, the team has not solved coordination yet.

Scaling means everything is together for the next person to join later. The prototype, transcript, agent session, spec all stay together. People can read a summary first, then ask their agent to dig into the source material when they need the details.

AI makes the work move faster. The reasoning has to move with it.