Picture a product designer on a Thursday afternoon. The feature she spent a month on went live on Monday. It works, and customers are using it. But the card spacing is slightly off, the loading animation feels stiff, and the empty state she designed never made it in. She files three tickets, attaches annotated screenshots, and posts a friendly note in the team channel. Everyone agrees the fixes matter. Everyone is also busy with the next release. Six weeks later, the tickets are still open.

Most people who build digital products will recognise that story. I have lived some version of it many times over more than twenty years in UX, product and AI-led design. For most of that time I treated the gap between what we designed and what we shipped as a cost of doing business. This year, I have watched that gap start to close in a way I did not expect.

A shift in how products get built

AI coding tools are no longer only for engineers. Designers and product managers are opening real codebases in AI-assisted editors, asking an agent to explain how a screen is built, making a small change, and proposing it for review.

Atlassian described this clearly in a post about their designers' workflow. A designer noticed that a visual effect in a desktop app had shipped short of its intent. Instead of producing another round of specs, she opened the repository with an AI agent, tuned the effect against the running app, and opened a pull request for engineers to review. Their working rule is simple and wise: always create a pull request, never merge directly.

That rule is the heart of the shift. The handoff has not disappeared. It has moved from a design file attached to a ticket to a pull request with a diff, a preview and a reviewer. Communities like Into Design Systems are now teaching designers this kind of hands-on "vibe coding" as a practical skill rather than a novelty.

Old and new, compared fairly

The spec handoff was not a mistake. It served teams well for a long time, and in many situations it still does. The fair question is which approach suits which kind of work.

In my experience, the healthiest teams will use both. Specs remain the right tool for shaping new ideas. Pull requests become the right tool for protecting quality once the idea is real.

What it means for the people using the product

It is easy to talk about this only as a productivity story. I think the more important story is what users feel.

Users never see our handoff process. They see the result. They notice when a button feels sluggish, when an error message is confusing, or when a screen looks unfinished on a smaller phone. These details shape trust far more than most roadmaps admit, and they are exactly the details that used to wait longest.

When the person who cares most about a detail can propose the fix directly, those small moments get attention sooner. Over months, that adds up to a product that feels considered. The reverse is also true. If teams move fast without care, users will feel that too. Speed only helps the experience when quality checks keep pace.

Guardrails that make it work

The teams doing this thoughtfully share a few habits. They keep changes small and contained, so a reviewer can understand them in minutes. They write down rules for the agent, such as what it must never touch in their codebase. They ask for evidence, not just code. Guides like Plannotator's agent handoff notes suggest that a good handoff states what was requested, what changed, what was checked and what remains uncertain. And they route by risk. A colour token can be approved on evidence, while anything touching payments, data or permissions goes to a named engineer. The Developer Toolkit shipping workflow makes a similar case for structured review before anything reaches production.

The leadership view: keep a human yes at the end

As a leader, this is where I spend most of my attention. AI agents can make the work faster, but they cannot own the outcome. Someone still has to look at the change, understand its effect on users, and say yes.

That human yes is not a formality. It is where judgement, accountability and craft meet. It protects the people using the product, and it protects the trust between design and engineering. A team that keeps that moment meaningful can adopt new tools with confidence.

If I were starting this with a team this quarter, I would keep it simple. Choose one product area and let a few designers ship polish fixes through pull requests for a month. Agree with engineering on a short template for those pull requests. Give review time a name and a budget, so it does not quietly compete with everything else. Then compare how long quality issues used to wait with how long they wait now.

My take

Tools will keep changing, and the goalposts will keep moving. What I find encouraging is that this shift brings design and engineering closer rather than replacing either. Designers learn the real system. Engineers get clearer, smaller proposals to review. Users get the version the team actually intended.

For most of my career, the handoff was the place where quality slowly faded. I believe it can now become the place where quality is defended, as long as we keep a human yes at the end of it.

Naresh Pentapati writes about design, product and building with AI. More at www.nareshpentapati.in.