What nobody tells you before you start with agentic design

I’ve been prototyping in code for a new domain at Quickbase for a while now.

It took a lot of tweaking to get the friction down. But once it clicked, it changed how I think about the whole design process - not solely because it’s faster, but because it changes what’s actually possible.

With static prototypes you’re always hitting a ceiling. You can show the idea but you can’t stress test it. You can annotate edge cases but you can’t surface them without spending tons of time. You can spec interactions but you can’t feel them or fine-tune them without sinking a day or two into it.

Coded prototypes remove that ceiling.

Product-wide color, typography, border radius change? One prompt. Full feature copy rewrite across 30 screens? One prompt. Competitor research that used to mean registering in 6 tools, reading 7 help articles and dragging your mouse around for half a day? Automated. You get a comparison matrix and you make a decision.

Accessibility, keyboard navigation, WCAG compliance - handled live in the prototype instead of buried in annotations on a Figma file that engineers will skim once and ponder on for weeks.

You can deploy and collect real user data while devs are still building the production pieces. Quantitative and qualitative. On your design work. Before a single line of production code ships.

And the animations, the interactions, the things that always died in handoff because they were too painful to spec and too easy to cut - you just build them. You show them running. Nobody debates whether they’re feasible because they’re already there.

This is the future of design. And I say that without a hint of irony.

The part nobody tells you: you will get engineers tilted.

The assumption most designers make when they hit resistance is that engineers feel threatened. That they’re worried about losing their jobs to designers who can now build. I’ve heard this framing constantly and I think it fundamentally misreads what’s actually happening.

Good engineers are not scared of you. They’re protecting their craft.

What they’re actually scared of is AI slop entering the codebase. Decisions made without engineering context that create downstream problems nobody budgeted for. Components that look fine in a demo and fumble under real conditions. Overly-engineered animations so underperformant they’ll brick your average accountant’s computer.

Concerns like these come from someone who cares about what gets built trying to hold a line. And honestly - fair. The friction is real and some of it is deserved. When designers step into this space without understanding what they’re stepping into, the results show. Been there. And the engineers who have to deal with those results are the ones raising their hands.

But here’s the catch. The lines between design and engineering are blurring and there is no turning back. Tilted or not.

The question is not whether it happens but what you do with it. The people treating this as a turf war - on either side - are going to spend the next few years being sour about their day to day. The ones who learn enough to be useful, who respect the craft on both sides and communicate in a language the whole team understands, are going to do the most interesting work of their careers.

Bet.

My workflow was breaking things. It took me too long to figure out why.

I was delivering high fidelity prototypes better than anything I’d shipped before. AI was giving me an on-demand coding bro that tirelessly and effortlessly was implementing the solutions of a great visionary: me. (I hope you catch the irony.)

And yet the team was pushing back. What the? Can’t they see the future is unfolding in front of them? Are they afraid? Resistant to change?

Then reality hit. The issue wasn’t the code per se. It wasn’t the approach as a concept. It wasn’t engineers being resistant to change.

It was everything around it.

Breaking shit on main because I offload all the git work to Mr Robot. No live preview, so nobody outside my machine had visibility into anything. Weak documentation and handoff. Glitchy components that eroded the trust I was trying to build. Communicating updates in design language that meant nothing to the people reading them.

A fix was needed. And a fix was found.

Get a staging URL up from day one. Vercel, Netlify, Github Pages, whatever. Every stakeholder needs a link they can open without asking you. If they can’t see your work without you being in the room, you’re making people worried, confused and frustrated. You don’t exist to them.

Documentation is the one most designers skip and the one that kills adoption fastest. Feature diagrams, user flows with edge cases mapped, state logic - written down somewhere readable for your engineers to drop straight into their AI tools. Bonus if you deliver separate handoff structures for engineering, product and content. Not one doc that tries to serve everyone. Three different entry points for three different audiences.

Ship clean components. Janky prototypes with text bleeds and overflow issues make the case against you faster than any engineer pushback will. The coded prototype is the thing people interact with. If it feels broken, the whole approach feels broken.

Change how you communicate updates. “Updated the tone from steel gray to glacier” is meaningful to zero engineers. “Changed background hex from X to Y, updated border radius from 8 to 4, removed drop shadow on hover state” is meaningful. Write updates in the language of the people reading them, not the language you think in.

The resistance I kept getting - “maybe you should go back to Figma”, “I want screens listed side by side” - wasn’t about the tools at all. It was telling me my setup wasn’t giving people what they needed to do their jobs.

Once that was fixed, most of the pushback disappeared.

Persevere through the initial friction. Listen closely to the pushback. Leave the ego aside - because this new age of design, once it clicks, will change what you’re capable of delivering.

Not incrementally. Fundamentally.