AI Is an Accelerator, Not a Reframer
Where AI enters my design practice — and, more importantly, where it doesn't.
If you're a designer working in 2026, you've probably had a version of this conversation. Someone in the room says "we need to figure out where AI fits." The answers tend to run from vague ("as an assistant") to grand ("as a new layer above design thinking") to anxious ("should I be worried?"). None of them settle anything, because the underlying question — what does AI actually change about design practice — rarely gets a concrete answer.
This is my concrete answer. Not a manifesto. The working stance I've refined over the last couple of years of actually integrating AI into shipping product work.
Short version: AI is an accelerator inside the making, not a substitute for design judgment. The rest of this is what that means in practice.
Where AI actually enters my practice
There are three places AI has changed what I do. All three sit inside one activity from my broader working process: Make ideas tangible. Prototyping, drafting flows, generating variants, sketching an interface fast enough to react to it. That activity used to be limited by how fast I could produce. It isn't anymore.
Rapid exploration of variants. When I'm shaping an interaction and I want to see three or four ways it could go, AI generates them faster than I could alone. Not better — faster. The judgment about which variant survives is still mine. But the surface area of options I can consider before I commit is much larger than it used to be.
Prototype scaffolding. When I want a prototype interactive enough to actually test, AI drafts the technical scaffolding in an hour instead of a day. That matters more than it sounds. A working prototype exposes gaps in the direction that a mockup never will. If I can build one every time I need to think, I think more clearly. Cheap prototyping changes what design is, not just how fast it happens.
Surfacing edge cases. A model prompted well is unexpectedly good at flagging failure modes I wouldn't have thought of. Empty states. Unusual data. Access patterns for roles I don't normally design for. It doesn't replace the discipline of thinking through edge cases — it augments it, particularly on parts of the surface I have less muscle memory for.
That's the actual list. Three uses. All accelerators. All inside the same activity.
Where AI does not enter my practice
This is the part most conversations don't get to, and it's the part that matters.
AI does not reframe problems. The most important design move — the one where you take an ask and turn it into the actual problem worth solving — is the one AI cannot do for you. Not because the tool is weak. Because reframing depends on evidence you've gathered, users you've talked to, business constraints you understand from the inside, and technical realities that shape what's actually possible. A model with none of that context can produce plausible-sounding reframings. Plausible-sounding is not the same as right. If you take an AI-generated reframing at face value, you're using it to skip discovery, not to accelerate it.
AI does not decide what to ship. Shipping is a trade-off decision. You are choosing what to protect and what to spend. Those are choices with consequences — for users, for engineering, for whatever gets deprioritized. AI can lay out options. It cannot own the consequences.
AI does not make judgment calls on interaction. When a design meets the reality of implementation and something has to give, someone with taste and context has to decide what gives. That decision draws on your model of the user, your understanding of what the product is trying to be, and an accumulated sense of what feels right in this domain versus another. None of that is in the model.
AI does not partner with engineering. Delivery is a relationship. Trust between designer and engineer is what makes hard implementation calls resolvable in real time. A tool doesn't do this. A designer does.
If it helps, arrange this as a boundary: on one side AI is a useful tool. On the other, it's a hazard — because it produces outputs that look like design decisions but haven't been made by anyone with responsibility for them.
Why the boundary matters more than the toolkit
Here's the piece I want to get right, because it's the one most easily lost.
Design judgment is the reason a designer is in the room. Not the pixels. Not the Figma file. Not the prototype. The judgment about what problem to solve, what shape the solution should take, and what trade-offs to make when the ideal collides with the possible.
If you let AI produce work that appears to be judgment — a reframing, a scope decision, a set of prioritized trade-offs — and you ship it without doing the actual thinking, you are shipping unowned decisions. They may be reasonable. They may even be right. But nobody has made them, and when they turn out to be wrong there is nobody who can explain the reasoning, defend it, or evolve it.
This is worse than shipping a bad decision that was actually made. A decision that was made can be argued with, revised, learned from. A decision that was generated is inert. There's no reasoning to interrogate, because there was no reasoner.
The boundary between accelerator and reframer isn't about protecting designers' jobs. It's about protecting the integrity of the decisions the product is built on.
A working example
The interactive prototypes in this portfolio are AI-scaffolded. I designed the flows, the interaction model, the states, and the visual direction. AI drafted the HTML, CSS, and behavior scaffolding fast enough that I could get from idea I want to test to working prototype in an evening. If I'd had to hand-write every scaffold, the prototypes wouldn't exist — I'd have static mockups instead.
That's an accelerator use. Every design decision inside the prototypes is mine. AI made it possible to make more of those decisions in the same amount of time.
If I had asked AI to design the Report Library discovery layer, the output would have been fluent. It would have looked like a design. But there would be no evidence base, no user research, no reframing from search to lifecycle, no principle stack to defend when trade-offs came up. It would be a plausible-looking artifact with no reasoning underneath.
Different use. Different value. Same tool.
What this means for how designers should work
A few things follow from the accelerator/reframer distinction.
Insert AI where it accelerates a specific activity. Not around the whole process. Not as a layer above design thinking. Inside the making, where speed compounds. If you can't name the specific activity you're accelerating, you're not accelerating anything — you're just adding a tool.
Own the judgment even when AI generated the artifact. If you kept a variant AI produced, you chose to keep it. You can defend that choice. If you can't defend it, you don't own it, and you probably shouldn't ship it.
Prototype more, present less. The single biggest shift AI has enabled in my practice is that prototyping is cheap. That means design should move earlier from presenting an idea to building a rough version of it and reacting to it. This is a better practice regardless of AI. AI just makes it viable in more situations.
Be honest about what AI touched. In writing, in portfolio work, in delivery. Not because AI is disqualifying — it isn't — but because the specific value you bring as a designer is judgment, and hiding what was judgment versus what was generation makes it harder for anyone (including you) to see what your judgment actually looks like.
What to be careful of
Two failure modes I've watched other designers walk into.
The plausibility trap. AI outputs are stylistically confident. A generated reframing sounds like a reframing. A generated principle stack sounds like a principle stack. If you don't have your own evidence-grounded view, you'll find the AI's outputs persuasive by default, because they read as competent. The way out is to do the underlying work anyway and then compare. When the AI's output aligns with what you'd have found through evidence, it's confirmation and it's cheap. When it doesn't align, you have a signal that one of the two is wrong — and you can go check which.
The framework-shopping trap. There's a temptation to build a new design process around AI. New phases, new frameworks, new terminology. This nearly always makes the process worse, because the process was never the bottleneck. The bottleneck was how quickly you could get an idea into a form you could react to. AI removes that bottleneck. It doesn't require a new process. It asks you to run the existing process faster in the making step and no differently anywhere else.
If a proposed AI framework doesn't map cleanly onto activities you were already doing, it's probably not helping you do those activities. It's probably a shape that would collapse under the weight of a real project.
The stance, restated
AI has changed what I can produce in an evening. It has not changed what I am accountable for. That distinction is the whole thing.
The accelerator inside Make ideas tangible is legitimately useful, and I'm not conflicted about using it. The reframing, the judgment, the trade-offs, the delivery partnership — those remain design work, and design work is what I'm paid to do. If a tool ever encroaches on that side of the line, it stops being an accelerator and starts being a substitute for me. That would be a bad trade for the product and a bad trade for the practice.
I don't think that trade is imminent. AI is remarkably good at the making and — for reasons that are structural, not temporary — much worse at the deciding. The making has always been where speed matters. The deciding has always been where seniority lives. That symmetry is probably going to hold longer than the current discourse suggests.
Use AI. Not to design for you. To let you design more.