Where AI Helps — and Where It Still Gets in the Way

Three posts into writing about how these tools fit into our work, it would be easy to leave the impression that everything’s solved — that the workflow is faster now and that’s the whole story. It isn’t. This is the post where we say plainly what still goes wrong, because pretending otherwise doesn’t help anyone using these tools for real client work.

Where it genuinely helps

Start with what’s true, because it is a lot. The blank-page problem is mostly gone. Early exploration that used to take an afternoon of staring at an empty frame now takes twenty minutes of generating rough directions and reacting to them — and reacting is a much easier creative mode than inventing from nothing. Production work that’s necessary but not interesting — resizing a flow across breakpoints, generating placeholder content that actually looks like real content instead of lorem ipsum, drafting a first pass at states and edge cases — has gotten genuinely faster without a meaningful quality cost.

The handoff has changed the most. A developer working from a design file and a coding agent can produce a working first draft of a screen in the time it used to take to schedule the kickoff meeting. That’s not a marginal improvement. It’s removed a step that used to require two calendars lining up.

Where it quietly breaks down

The failure mode we’ve hit most often isn’t dramatic — it’s drift. Ask a tool to generate a new screen and it will often fill gaps with its own best guess instead of your actual pattern: a button radius that’s close but not quite your token, a spacing rhythm that looks right at a glance and is wrong by four pixels everywhere. None of it looks broken on first view. It looks almost right, which is worse, because almost-right is exactly the kind of error that slips past a fast review and ships.

The second pattern is context blindness. These tools are very good at the screen you asked for and much weaker at the screen next to it — the empty state, the error state, the version with a name that’s forty characters long instead of the placeholder’s eight. Real product design lives in those edge cases more than in the happy path, and that’s precisely where generation tends to guess rather than reason.

The third is subtler and worth naming honestly: speed changes what gets questioned. When a draft appears in ninety seconds, there’s a real temptation to treat “it exists” as “it’s considered.” A slower manual process forced a certain amount of thinking by virtue of taking time. Fast output doesn’t force anything. The thinking still has to happen — it just has to happen deliberately now, instead of by default.

What we actually check for, every time

We’ve settled into a habit that’s less about a tool and more about a discipline: nothing generated ships without being tested against real content, not placeholder content, and against the actual edge cases of the product, not just the primary flow shown in the demo. We compare generated spacing and color values against our tokens directly rather than trusting it by eye, because “looks close” and “matches the system” are different claims. And we’ve made peace with the fact that the review pass now takes real, deliberate time — the time we saved on generation gets partly reinvested in scrutiny, which is a fair trade, not a failure of the tools.

The honest state of things

None of this is an argument against using these tools. It’s an argument against using them uncritically, which is a different thing entirely. The teams getting burned aren’t the ones using AI in their process — they’re the ones who stopped designing the moment the tool started generating. The work didn’t go away. It moved to a different stage, and it’s just as easy to skip that stage now as it used to be hard to reach it.

Coming next month: how we’re rebuilding our design system itself to hold up under an AI-assisted workflow — the guardrails that let generation stay fast without staying loose.