There’s an experiment I would love to see.
Give a designer and a developer the same product brief.
Give them the same amount of time. The same access to users. The same AI tools.
The designer needs enough technical awareness to understand that architecture, performance, accessibility, and security are real constraints. The developer needs the design awareness to recognize familiar interaction patterns and make a coherent interface.
Let them work independently.
At the end of the time, don’t judge the codebase. Don’t count the features. Don’t ask which interface is more polished.
Put the products in front of users and see which one better solves their problem.
My bet is on the designer.
That wouldn’t have been the case a few years ago.
The gates were never symmetrical
Designers understand users. They can frame a problem. Structure the information they have into useful conclusions. Take all that, and determine what the experience should be.
But they couldn’t ship it.
They could make screens. They could have a click-through Figma prototype of the interactions. Explain the behavior with notes, annotations, tickets, meetings, and the all-important handoff.
So that someone else could make it real.
Developers had an opposite advantage. They can take an idea and make a working piece of software. What’s behind the interface - dependencies, data, performance implications, and how simple requirements get complicated very quickly when they meet reality.
But they didn’t have the judgement to decide how that software should work for a person.
Obviously these aren’t universal limitations. I know plenty of great designers who can code, and developers who have excellent design judgment.
But disciplines are training. They point our attention, so we notice different things.
Design trains people to see what’s confusing. What is incorrectly emphasized. The breaks between what a system allows and what a person is actually trying to do.
Engineers are trained to see fragility and bad abstractions. Understand the architecture and hidden dependencies. Bridge the gap between a convincing demo and a system to survive production.
Both those kinds of judgement are important.
AI hasn’t affected them equally.
Didn’t we always want designers who code?
AI gives the technically aware designer a remarkable amount of implementation capacity.
Scaffold an app. Connect it to APIs. Generate components or use the ones that exist. Explain unfamiliar code. Debug when things go wrong. Write a test suite. Take a clear spec around intended behavior and execute on it.
It will still need direction. A designer will need some technical understanding - enough to recognize if the system is making dangerous assumptions. To know if something is moving beyond their competence.
But it’s not the hard stop it used to be.
Designers don’t have to persuade a production chain to make something in order to discover whether it works.
They can make it.
AI also gives developers greater access to design production.
It can generate a clean dashboard. Use a familiar onboarding flow, or a plausible settings screen. It knows visible conventions of software very well. Sensible spacing, tidy cards, useful empty states - everything to make a product feel like it’s finished.
These upgrades aren’t symmetrical.
The system can increasingly perform implementation on the designer’s behalf. But design judgement can’t be acquired by a developer asking a system to produce design artifacts.
The artifact isn’t as valuable as the judgement. As the critique. As the understanding of the user.
AI passes the “first look” test
AI can make some very plausible interfaces. Many product generation tools lead with that capability. Here’s an immediate, visual, impressive interface.
The product appears before your eyes.
That looks like the design was the easy part.
It’s evidence of something else.
The presentation layer is the part of software applications where it’s easiest to manufacture the appearance of correctness, and hardest to verify if it’s actually correct.
If code is plausible but wrong, there are usually backstops. It doesn’t compile. The tests fail. There’s an error.
Engineering is great at detecting what’s incorrect because - if they don’t - the machine doesn’t execute its instructions.
Plausible-but-wrong design is dangerous because it can work perfectly.
The interface renders. The button works. The form submits cleanly.
It’s a great demo.
And there’s no alarm because the dashboard surfaced the wrong metric, and hid the one the user needed to make a decision.
There isn’t the same binary test when we cleanly and efficiently guide our user to the wrong outcome.
If we make a destructive action overly convenient, the app still builds.
We’ve got something usable.
We’ve got something wrong.
Those costs will come later - after it ships. Abandoned tasks. More support tickets. Bad business decisions because the information was wrong. Seemingly inexplicable churn.
It’s because AI is so fluent in the generalities of finished software that discrimination becomes more valuable, not less.
It’s not a matter of taste
This isn’t domain protection.
I’ve led design systems. Of course I think designers are important.
But the argument only works if design judgment means something tangible.
It’s not about choosing better typography, or adding visual polish. It’s not “make the logo bigger”. If it is, then AI has eaten up most of it already.
Some design execution can be automated - because production work in every discipline is getting easier and easier to automate.
Designers don’t have better taste.
Designers are best trained to determine if an experience represents what the user actually wants and needs to do.
What decision is the user trying to make? What information changes their decision? Which actions are reversible?
Does the structure of the product match the structure of the problem?
That’s judgement rather than taste. And, while not exclusive to designers, it’s what their discipline is supposed to train.
The design-aware developer knows that a destructive action may need confirmation.
The designer asks why the destruction is even an option.
It’s different below the waterline
The argument works on the surface. At the level the user sees.
Deeper than the presentation layer, and the results invert quickly.
Ask those same two people to create an infrastructure for high-scale transactions. To protect sensitive data. Recover from partial system failure. Avoid making an architectural decision that will constrain the company for a decade.
Now it’s the engineer’s judgement that’s the scarce thing.
AI produces plausible architecture, too.
So it’s not that designers now outrank developers. That’s dumb. And it reproduces the same mistake companies always seem to make - taking multidisciplinary product development and trying to turn it into a contest between the disciplines.
But AI shifts capability based on the nature of the missing skill.
AI is good at execution.
AI is bad at judgement.
If your historical limitation was execution, then AI gives you more benefit than the person whose historical limitation was judgement.
At the interface layer, that person is probably a designer.
Our org charts were built for the world before AI
Companies are making headcount decisions right now.
They’re compressing design teams, and ensuring engineering is the presumed center of their product creation.
And there’s plenty of logic to that. Hard engineering problems still exist. Software needs to work. And their AI investment is framed around making developers faster.
But that assumes the old distribution of capabilities.
The ability to ship is the decisive gate. Whole organizations have formed around that gate.
Now more people can go through it.
A designer who understands enough about software can increasingly go through it. Move from problem framing to working product, without a bunch of translation layers.
The reverse gate isn’t widening in the same way.
A developer can ask AI to produce a convincing interface. They can’t easily tell if that interface has the right understanding of the person who’ll be using it.
AI won’t be reliable at warning them.
Companies cutting design while concentrating on engineering investment “because AI can do the UX” might be reinforcing a discipline whose historical advantage is eroding the fastest. And reducing or removing the discipline whose central value AI is least suited to reproduce.
AI has made it much easier for designers to become builders.
It has not made it equally easy for builders to become designers.
Further reading:
Execution is cheap. Coordination is not. - on catching what’s organizationally wrong and codifying it.
The Intersection of Design Thinking and AI: Enhancing Innovation. IDEO U, Jun 2025.
Hill, M. Half of developers say AI can code better than most people. AI Data & Analytics Network, Aug 2025.
Morton, P. Why is AI bad at design? Phil Morton, Jul 2026.
Article photo by Eyre June Bustamante on Unsplash.