A PM spent 45 minutes on a planning call last week walking an engineer through the edge cases of a refund flow. The engineer kept asking about user outcomes and release risk. On paper this was a handoff, one person passing work to the next. In practice, both of them were doing product work. Both were thinking about implementation. Neither one's job description covered what was actually happening on that call.

This is how most teams operate now. Product and engineering overlap more than the org chart suggests, and that overlap is only growing as AI agents take on more of the build. The problem isn't the overlap itself. The problem is that product intent, the reasoning behind what you're building and why, keeps dying during the handoff between the person who understands the goal and the system that writes the code.

In the old world, a missed requirement meant a clarifying meeting. Maybe a day lost. With AI agents in the loop, missing context doesn't slow anything down. The agent just guesses and keeps going. That's what makes this different from every other coordination problem in software: speed without intent creates confident, well-structured code that solves the wrong problem.

This article breaks down where intent gets lost, what that costs in practice, and how spec-driven development gives teams a way to close the gap before agents start writing code.

Velocity without direction is just expensive rework

AI made execution cheap. A working feature can come together in an afternoon. But most teams are finding that speed alone doesn't translate into shipping the right thing, and the data backs that up.

Bain's 2025 Technology Report found that teams using AI assistants see only 10 to 15 percent productivity gains, and the time saved rarely turns into business value. Their research also showed that writing and testing code accounts for just 25 to 35 percent of the development lifecycle. Speeding up that one slice without fixing the inputs just moves the bottleneck somewhere harder to see.

A frontend lead audited a feature that an agent had completed overnight. It worked. The buttons clicked. The data saved. But when he looked at the code, the agent had imported three different date-parsing libraries to handle a single timestamp and hard-coded the timezone to UTC-8 because the prompt didn't specify otherwise.

The code wasn't broken. But it was heavy, wrong in ways that wouldn't surface until someone tried to extend it, and expensive to fix after the fact. He spent the next two days untangling dependencies that didn't need to exist, which is roughly how long it would have taken to write the feature from scratch.

This pattern shows up constantly. One developer described giving up on a project after three months: "Every time I want to change a little thing, I kill 4 days debugging other things that go south." The agent keeps fixing symptoms because it doesn't know the root cause. The developer doesn't know the root cause either, because they didn't write the code.

The uncomfortable truth is that teams are spending less time typing and more time auditing code they didn't author.

The agent doesn't know why you chose boring technology over clever technology, why you picked Postgres over Mongo, or why the payment flow needs to be idempotent. It ships its best guess, and its best guess is statistically reasonable but architecturally wrong for your specific system.

If this sounds like your team, the fix isn't better prompting. It's giving agents structured context before they start writing. See how spec-driven development works in Devplan.

Where intent goes to die

Intent doesn't disappear all at once. It leaks out at specific points in the workflow, and each leak compounds downstream.

The first leak happens in planning. A PM writes a ticket that says "User sees error on failed payment." That ticket contains an outcome but not the constraints around it. It doesn't say which error component to use, whether the system should retry, or what the logging behavior should be. A human engineer would ask follow-up questions. An AI agent treats the ambiguity as a design decision and makes one.

A team running a checkout flow learned this the hard way. Their agent added a "Retry" button to a payment screen for a transaction type that legally cannot be retried. The prompt didn't say "no retries," so the agent optimized for UX and guessed wrong. The feature passed QA because the testers were checking functionality, not legal compliance. It made it to staging before someone from the payments team caught it.

The second leak happens in context transfer. Architecture decisions, past trade-offs, and team preferences live in Slack threads, Notion docs, and people's heads. None of that reaches the agent. A paper on vibe coding documented what happens when constraints are absent: a team asked an AI to fix display issues, and it responded by rewriting state management, adding new API endpoints, and creating debugging panels. The codebase grew by hundreds of lines. The root cause, a simple API mismatch, stayed unfixed because the agent lacked the constraint that would have pointed it to the actual problem.

The third leak is cumulative. Every project that runs without structured intent makes the next one harder, because the codebase now contains decisions nobody documented and patterns nobody chose deliberately. Six months later, a new agent working on a related feature treats those accidental patterns as intentional architecture and builds on top of them.

Anthropic's engineering team wrote about a version of this problem: if a human cannot definitively say which tool to use for a task, an AI agent will not do better. The fix isn't better models. It's closing the gap between the person who understands the reasoning and the system that executes the code.

Spec-driven development is the missing layer

Spec-driven development has been getting a lot of attention since mid-2025, with GitHub's Spec Kit, JetBrains' Junie, AWS Kiro, and Augment all building some version of it. The core idea is the same across all of them: write a structured specification before any code gets written, and use that spec as the source of truth that agents work from.

The concept isn't new. As Martin Fowler's team at ThoughtWorks pointed out, specs have been used in software engineering for decades, from model-driven development to behavior-driven development. What's different now is the audience. Specs used to be written for future developers. In AI-assisted development, specs are written for machines, and machines need a different kind of clarity than humans do.

Humans need explanations. Agents need prohibitions.

A good spec for an agent includes three layers that most PRDs skip entirely:

Decision logs that include the losers. Not just "we chose Postgres" but "we chose Postgres over Mongo because we need ACID compliance for the payment ledger." If you don't feed that constraint to the agent next week, it will write code that assumes eventual consistency. Architecture Decision Records have been around since 2011, but the format needs to shift. The audience is no longer a human who can infer intent from context. It's a machine that will do exactly what you don't tell it not to do.

Hard constraints that act as guardrails. These are the things that cannot change: no new npm packages without approval, use the internal UI library for all buttons, no external API calls from client-side code, payment flows must be idempotent. These constraints stop an agent from fixing one thing and breaking three others, which is the failure mode that showed up with the date-parsing libraries.

Specificity about edge case behavior. Instead of "user sees error," the spec says "if API returns 400, display Toast Component ID ERR_400, do not auto-retry, log to Sentry with payment_id." Ambiguity in a spec is functionally the same as a prompt injection. It tells the agent "use your judgment," and the agent's judgment is a statistical average of every codebase it was trained on, not yours.

Here's what the difference looks like in practice:

The left column is what most agents receive. The right column is what they need.

Making the intent layer stick

Individual specs help on a per-project basis, but the real value shows up when the context compounds across projects. A spec for Feature A that documents why you rejected a particular approach becomes context that Feature B's agent can reference three months later. The system remembers what was tried, what was rejected, and why, so each project makes the next one better.

This is where most teams hit a wall. Static docs rot. A Notion page written in January is outdated by March because nobody updates it when the architecture changes. The spec layer needs to be connected to the actual codebase and updated as decisions are made, not maintained as a separate artifact that drifts from reality.

An engineering manager at a 30-person SaaS company described the before and after. Before, her team's agents were producing code that technically worked but kept introducing patterns the team had explicitly moved away from. An agent would use Redux in a component because the older parts of the codebase still had Redux, even though the team had migrated to Zustand six months earlier. Nobody had told the agent, and the codebase itself sent mixed signals.

After implementing structured specs with their codebase context attached, the agents started following the team's actual conventions. Not because the model got smarter, but because the inputs got better. The specs told the agent which patterns to follow and which to ignore, and the codebase analysis gave it the information to distinguish between the two.

The pattern she described is exactly what Bain's research predicted. The companies seeing 25 to 30 percent productivity gains aren't the ones with better models. They're the ones that redesigned the workflow around the model, feeding it structured context instead of raw tickets and hoping for the best.

Devplan builds this intent layer into the development workflow. Specs are grounded in your actual codebase, connected to your project management tools, and available as context for every agent run. Start for free.

What to do this week

You don't need to overhaul your workflow to start closing the intent gap. Pick one project that's about to kick off and try these three things:

Write the decision log before the first line of code. Document what you chose, what you rejected, and why. Include the constraints that aren't obvious from the ticket. "We need ACID compliance" is more useful to an agent than "use Postgres."

Define five hard constraints for your codebase. These are the rules that never change: approved libraries, required components, forbidden patterns. Put them somewhere the agent can access them, not in a Slack message from four months ago.

Rewrite one vague ticket as a spec. Take a ticket that says something like "handle error states" and expand it with specific component IDs, retry behavior, and logging requirements. Run the agent against the spec instead of the ticket and compare the output.

If the agent produces better code from the spec than from the ticket, you've found your bottleneck. It was never the model. It was the input.

The teams that get this right will compound the advantage

Whether your team blends the PM and engineer roles or keeps them separate doesn't matter as much as whether intent survives the handoff. Both approaches work when there's a layer that carries context across people and tools.

The good news is that this isn't a massive process overhaul. It starts with writing better inputs. A spec that includes constraints, decision history, and edge case behavior gives every agent run a better starting point, and each project that captures those decisions makes the next one faster.

The teams adopting spec-driven development now are building a compounding asset. Every documented decision, every logged constraint, every structured spec feeds into the next project. Six months from now, their agents are working from a rich, accurate picture of how the system works and why. That gap between teams who structure their intent and teams who don't will only widen as agents take on more of the build.

The shift is small but the payoff is real: less time re-explaining the same things every sprint, less time auditing code that missed the point, and more time spent on the work that actually moves the product forward.

Devplan makes spec-driven development the default. It turns messy product input into structured, executable specs, connects them to your codebase, and builds the shared context layer that keeps your AI interactions grounded in your team's actual decisions. Get started for free.