The handoff just flipped, and your process didn't

The tools you kept in the "someday" pile got good this quarter. Not demo good. Ship good. Figma Make now runs on GPT-5.6, Google Stitch shipped real updates, and coding agents moved from autocomplete to something that reads your codebase and opens pull requests. The catch is that your team is already using this stuff, whether you picked it or not. Let me catch you up on what actually shifted, and where you need a hand on the wheel.

Prototypes now start closer to the vision

The first pass used to be the throwaway. Now it's the launch pad. Figma dropped GPT-5.6 into Make and their own tests show it building a working stock tracking app, keyboard shortcuts and search included, from a single prompt. When a build breaks, it investigates and fixes itself instead of stopping. In one case it found the source of a blank build and repaired it alone.

Google's Stitch plays the same game on the early end, spinning a mobile banking home screen from a five-word prompt for exploring directions fast. The practical read: your team can test more ideas in one sitting. The risk is that speed makes it cheap to skip the thinking. Faster first passes only help if someone still owns the direction.

The designer builds it, the engineer reviews it

The assembly line just reversed. In Figma's workflow lab, a designer connects a GitHub repo to Make, makes small accessibility fixes in the real code, and pushes a pull request. The engineer's judgment lands at review, not at implementation. Fixes that would have sat in the backlog for a quarter shipped in a day.

Working against real code surfaces things a mock can't. The designer went to tweak one date picker and Make showed it was a shared component rendering in three places. A ticket would have said "fix the exhibition page" and left two screens stale. This does not turn designers into engineers. It puts each person's judgment where it counts, and it keeps the reasoning attached to the merged change instead of dying in a closed ticket.

The design system is now the input, not the deliverable

Coding agents work only with what you give them. Feed them inconsistency and you get inconsistency back. Decagon built a design system called Deco with designers and engineers side by side from day one, working through edge cases like disabled and error states early. It now holds hundreds of components and logged tens of thousands of inserts in 30 days.

Then they wired it to code. They moved components into Storybook and gave their coding agents a skill to use exact components, with the Figma MCP server keeping specs, code, and canvas in one loop. Product Designer Jennifer Xu says she can paste a Figma link into the agent and get a high-fidelity result mapped to their real components. Their PM builds 10 prototypes for 10 customers instead of gathering requirements and guessing. A design system used to be craft insurance. Now it's the thing that makes your agents worth trusting.

The agent is easy, the system around it is the job

The field grew up fast. At the AI Engineer World's Fair, nobody mentioned AutoGPT, the fully autonomous darling of 2023. The conversation moved to the harness: the workflows, context, permissions, and evals around the model. Engineers now put themselves in an "outer loop," setting direction while agents run the inner execution loop. Full autonomy turned out to be unreliable and not even wanted at scale.

Same lesson on the product side. Paweł Huryn's AI PM roadmap splits the work into workspace agents that run on your own work and product agents that run inside your product, and his flat line lands hard: models and tools are easy to get excited about, reliable systems that create value are the actual job. He tells PMs to build agents visually first, in a tool like n8n, so they feel where the loop lives before they hide it in code.

The deep cut

Ad hoc adoption is the real threat, not the tools. Your designers are already pushing code through Make. Your PMs are already prototyping in Claude and Stitch. If you let that spread without a shared design system and clear review rules, you get ten flavors of the same button and no record of why anything changed. The teams pulling ahead did two boring things first: they built the component library that feeds the agents, and they decided who reviews what. Pick one workflow to pilot on purpose this month, the accessibility-fix pattern or the design-system-to-code loop, and put a named owner on the review step. That is the whole move. The tooling is ready. Your process is the thing that isn't.

Three questions for your team

• Is our design system clean enough to be an agent input, or are we about to feed coding agents our inconsistencies at scale?
• When a designer pushes a pull request, who reviews the code, and does that person have the time and the standing to say no?
• Which one workflow do we pilot on purpose this quarter, and who owns measuring whether it actually shipped faster without dropping craft?