Two things happened to delivery teams over the past three years, and they happened separately.

Design got faster. Concepts that took a week take a day. Content variations that took an afternoon take minutes. The documentation nobody wanted to write now arrives as a serviceable first draft.

Engineering got faster too. DORA's 2025 research found that 90 percent of technology professionals now use AI at work, and more than 80 percent believe it has increased their productivity.

Between those two accelerating functions sits the handoff, which runs on the same mechanism it ran on in 2019: a specification, a set of files, an annotation layer, a walkthrough meeting, and roughly forty Slack messages spread across the sprint.

Both sides sped up while the thing connecting them stayed where it was. DORA's headline finding shows what that produced: higher AI adoption correlates with an increase in software delivery throughput and an increase in software delivery instability, at the same time, in the same organizations.

More work shipped, and more of it broke.

Why this gap is structurally different from the others

The rest of this series covers stages where one team owns both the input and the output. Research to synthesis stays inside the research function. Journey to prototype stays inside design. Those are handoffs between activities performed by people who share vocabulary, tooling, and a manager.

Design to engineering is a handoff between two disciplines with different tools, different definitions of done, different quality standards, and usually different reporting lines. It is the only point in the lifecycle where the receiving party has to reconstruct intent rather than continue work already in progress.

That reconstruction is where design decisions quietly die, and they die by omission rather than negligence. The specification never stated what happens when the API returns partial data, so a developer made a reasonable call at 4pm on a Thursday. The component looked like the design system's card, so it got built as one, even though the interaction rules differ in a way the mockup could not express. The empty state was never designed because it was never discussed, so it shipped as a blank region.

None of these register as defects. They register as an experience slightly worse than the one that was approved, and nobody can point to the moment it changed.

What AI changed here, and what it left alone

It made the omissions arrive faster and in far greater volume.

A design team producing four concepts a week creates four opportunities for under-specification. A design team producing twenty creates twenty. If the specification practice did not change, and in most organizations it did not, the ambiguity per unit of design output held constant while the units multiplied.

The engineering side shows the same dynamic with a sharper edge. DORA found that 30 percent of developers report little to no trust in AI-generated code. That is a rational position given the volume being produced, and it carries a cost: review load rises, and review capacity is the constrained resource, not authorship.

The accessibility data makes the compounding visible. The 2026 WebAIM Million recorded the first regression in six years, with detectable WCAG failures on 95.9 percent of home pages and average errors per page up 10.1 percent. WebAIM attributes part of it to "increased reliance on 3rd party frameworks and libraries and automated or AI-assisted coding practices," alongside page elements growing 22.5 percent in a single year.

That is the handoff gap expressing itself in public, across a million home pages: design intent that was never specified, implemented by generation that was never fully reviewed, at a volume nobody planned for.

The three specification failures worth fixing first

Most handoff pain traces back to a small number of recurring omissions. They are boring, which is exactly why they persist.

States that were never designed. Loading, empty, error, partial, offline, permission-restricted, over-length content, and the state where a customer has one item instead of twelve. Designers document the happy path because the happy path is what gets reviewed. Developers build something for the rest because something has to render. This is the single largest source of drift between approved design and shipped product, and it is entirely preventable.

Behavior that a static file cannot carry. A mockup cannot express what happens on validation failure, what retains focus after a modal closes, what a screen reader announces when content updates asynchronously, or what a transition communicates about causality. Annotation layers help with this, and they also go stale the moment the design changes, which is why they are usually wrong by sprint two.

The reason a thing exists. The most expensive question in any handoff is "can we simplify this?", asked in week six about a step that exists for a regulatory reason nobody wrote down. Without traceability back to the requirement, every simplification proposal turns into a research project, and most get settled by whoever answers Slack first.

AI handles all three well, which makes this the highest-return application in the lifecycle. Enumerating missing states against a component's documented state list is mechanical comparison. Drafting acceptance criteria from a validated requirement is translation. Maintaining the chain from research finding to requirement to interface decision is retrieval. None of that requires judgment, and all of it currently gets done by hand, inconsistently, by people who would rather be doing something else.

Why this requires seeing both sides

Most guidance on this subject skips the part that decides whether any of it works.

You cannot fix a handoff from one side of it. A design team can produce immaculate specifications against a mental model of the platform that is two years out of date, and those specifications will be immaculate and wrong. An engineering team can define a rigorous intake standard that design cannot practically produce, and the standard will be ignored by March.

A specification only works when it reflects what the implementation platform does, which means somebody must be able to answer these questions before a design is called finished:

• Which components exist in the codebase rather than only in Figma?
• What can the content model express, and what does it refuse to hold?
• Which interaction patterns does the framework support natively, and which require custom work that will not survive the next upgrade?
• What can the personalization engine key on?
• Where does the commerce platform enforce its own rules regardless of what was designed?

That knowledge lives in implementation. Design organizations that have never shipped on the platform they are designing for are guessing, and they tend to guess wrong in the same places every time.

This is where the standard advice to "improve your handoff documentation" breaks down. The constraint is the accuracy of the mental model behind the documentation, and no amount of better templating repairs that.

What to do about it

Start by measuring the gap rather than asserting it. Three numbers are available from any project retrospective:

• Elapsed days from approved design to development readiness
• Clarifying questions raised after development began, sorted by whether they concerned states, behavior, or rationale
• Rework attributable to design decisions that were never specified rather than changed

Most teams have never counted these, and the counts usually come in worse than the estimate. They also form the baseline that makes any later improvement provable, which matters when someone asks what the AI investment returned.

Then fix the specification practice before adding tooling on top of it. Automating the production of an incomplete specification produces incomplete specifications faster. The order of operations runs like this: define the required states and behaviors for your component set, encode them in the design system, then let generation enforce the checklist. Post 4 in this series covers what that encoding looks like.

What this costs you

Speeding up design and speeding up engineering while leaving the interface between them untouched produces exactly what DORA measured. More throughput, more instability, and a workforce convinced it is more productive while the delivery dates hold steady.

Calling this a documentation problem misses what it is: the seam between two organizations that now generate faster than they can align, and the place where the industry's AI productivity gains are currently going to die.

For most organizations, it is also the cheapest item on this list to fix.

Schedule an AI-Enabled Experience Design Working Session Learn more

Sources

• DORA, "Balancing AI tensions: Moving from AI adoption to effective SDLC use," 2025. https://dora.dev/insights/balancing-ai-tensions/
• WebAIM, "The WebAIM Million," 2026 report. https://webaim.org/projects/million/