I watched a video the other day that got me thinking. An Android developer with zero design training used Claude Code and the Figma MCP to generate a full set of mobile app designs out of a markdown requirements document, in about an hour. Then he compared the result to what a professional design agency had delivered from the same brief – and the AI designs came out… surprisingly close.
The video is called “We don’t need designers anymore”, and honestly, watching it, I understood the impulse. I’ve had the mirror image of that thought myself, watching an AI write surprisingly functional code in domains I know nothing about. Maybe I don’t need an engineer for this.
Worth noting that the guy sells courses and mentorship to mobile developers, and his YouTube channel is part of that marketing. It doesn’t invalidate his experience, but it does mean his incentives align with a particular narrative: developers can now handle all of it by themselves. A bold title like “we don’t need designers anymore” is great for engagement, and one anecdotal comparison between one agency’s output and one AI session makes for a convincing video, but not for a complete picture.
I’m not writing this to bash the video. I’m writing it because the things it doesn’t get into are the ones I find most interesting, and because I want to think about where this industry is going and not where the hype says it’s going. That feeling of “I can do it all myself” is what I want to talk about, and I think it’s real and misleading at the same time.
What changed
What these tools did to creative and technical work is remarkable. Someone who openly admits his “design skills are garbage” produced a set of Figma screens that any designer would look at and recognize as real work. That’s well past a sketch or a wireframe. There’s a proper design system in there, the typographic hierarchy holds up, and the components are consistent. Two years ago that didn’t exist, and it’s worth celebrating.
The same is happening on the other side. I’ve seen designers with no engineering background ship working React components, deploy small backends, write scripts that solve real problems. Things that would have taken months of learning or a development budget now take an afternoon. More people can build more things, and that’s generally a good thing.
The confidence trap
AI lowered the barrier to producing work, and it also lowered the barrier to feeling good about what you produced. You generate something that looks polished and complete, and the polish rubs off on you. Because you can’t see the flaws you don’t know to look for, you conclude it’s fine.
Beginners have always overestimated themselves, and that’s a well-documented cognitive bias. But there’s a recent study published in Computers in Human Behavior that I found unsettling: people using AI on logical reasoning problems improved their actual performance by about 3 points, and overestimated that performance by 4 points. The classic Dunning-Kruger pattern, where the worst performers overestimate the most, was gone. With AI, everyone overestimated. Higher AI literacy correlated with worse self-assessment accuracy, not better. The more comfortable you are with these tools, the easier it gets to mistake the tool’s output for your own understanding (and yes, I’m including myself in that).
The distance between “this looks done” and “this is done” used to be much easier to see, because the raw output of a beginner was a lot rawer. A first-year design student’s mockup looked like a first-year design student’s mockup. Now it can look like something a mid-level designer put together on a Tuesday afternoon, and the two look indistinguishable even though they are not the same thing. The beginner doesn’t know why any of those decisions were made, or what got sacrificed to arrive at them, and can’t tell you whether the navigation holds up as the product grows, whether the colors survive dark mode, or whether the information hierarchy still makes sense once real data replaces the placeholder text. The AI doesn’t know those things either. It optimizes for looking right.
The same thing happens to me in the opposite direction. I can prompt an AI into code that compiles, runs and passes basic tests, and to me it looks correct. But I don’t have the engineering intuition to know if it holds up under load, if the architecture scales, if there’s some subtle race condition hiding in the concurrency model. A senior engineer would spot those issues in minutes. I wouldn’t know they existed until something broke in production.
The limits of good enough
Back to the video: when he compared his generated designs to the agency’s work he did notice real differences. The agency’s step counter component came out better, their dashboard was more considered, and he caught a UX mistake in the AI output, a destructive action (“reset today’s steps”) buried in the navigation drawer where users wouldn’t expect it and might trigger it by accident. He caught it because he’s a developer who has thought about interaction patterns before. A complete beginner might not have.
What the video glosses over is that he was comparing his output to one specific agency’s work, and found the two roughly equivalent. If he had hired a better agency the gap would have been much wider. Professional design exists on a spectrum, and a really good product design team, one that does research and interaction design and thinks in systems, would have produced something meaningfully different. Harder to compare in a screenshot, but the gap in the details that matter over time would be significant.
And it goes both ways. These tools raised what a beginner can produce. They didn’t touch the ceiling. A vibe-coded backend might handle your 50 beta users just fine. Then 50,000 people hit that same endpoint at the same time, and the architectural choices that were invisible at small scale become the difference between a product that works and one that falls over.
The pattern we keep repeating
Every few years a wave of tools shows up that makes it easier for one discipline to do another discipline’s job. Squarespace let non-designers build websites, then Webflow made that easier, then no-code tools let non-engineers build apps. Every time, someone publishes a piece about how we don’t need [fill in the blank] anymore.
And every time, the professionals in the supposedly deprecated discipline go through a rough patch and then find out that demand for them went up, because more people were building things and sooner or later those things had to get serious. The Squarespace websites needed to scale, the no-code apps hit their limits, and the vibe-coded systems ran into problems that required real expertise to solve.
Designing or developing a whole product with AI help is perfectly fine when the stakes are low. A personal project, a quick prototype to test an idea, an internal tool three people use. When it gets serious, when real users depend on it, when the product has to grow and be accessible and maintainable, you can’t trust yourself with the parts that fall outside your expertise. Being clever doesn’t cover it, because so much of expertise is knowing which questions to ask in the first place. I can vibe code a feature. I just won’t know what I don’t know until it breaks.
AI as a translator
I think these tools made the collaboration between designers and engineers more necessary than it was, and at the same time gave us a much better way to do it. That’s the part I’m optimistic about, and it’s the one that comes up least in this whole conversation.
Think about what used to happen when a designer pushed for a subtle animation and the engineer read it as unnecessary polish. The designer couldn’t fully articulate the technical cost of what they were asking for, and the engineer couldn’t fully see why that useless little detail would help someone understand a state change and trust the interface more. Each of them was right about their own half, and they were speaking different languages.
AI can translate between the two. As a designer I use it to understand the technical constraint behind a pushback, to see why something that looks simple in Figma might be a lot harder to build and keep alive than it looks. An engineer can use it the other way around, to dig into why a decision that reads as cosmetic is solving a usability problem. Instead of each side guessing at the other’s reasoning, both can go and check.
Using AI as a tutor and a translator, to help designers and engineers work better with each other, may be worth far more in the long run than the short-term rush we get from vibe coding and vibe designing everything on our own. The person who understands both sides well enough to ask the right questions and spot the right problems is going to keep being needed. Every good product team I’ve worked on had a few of them.
What I try to keep in mind
One thing that helps is developing taste in the discipline next to yours. You don’t need to be a developer to recognize when generated code is structurally a mess, and you don’t need to be a designer to know when a generated layout won’t scale. Learning enough about the other side to be a useful critic is a much lower bar than becoming competent at it.
Whatever the AI hands you is a first draft, often a good one, but a draft. The developer in the video needed his own judgment to catch the navigation drawer problem, and that judgment was his, not the model’s. Your job is to bring yours to whatever the AI produces.
Then there’s the question of what’s at stake. For a side project, vibe code the whole thing and have fun. If real users depend on it, bring in people who know what they’re doing, because the cost of getting it wrong compounds over time. And protect the conversations AI can’t have for you. The conversation between a designer and an engineer who both understand the product deeply isn’t something you can prompt for, and it produces better decisions than either of them would make alone.
These are uncertain times for everyone doing creative or technical work. Whether AI replaces you depends on what you bring to your work beyond execution. If most of what you bring is turning a specification into a file, a brief into a layout, a ticket into working code, then yes, that part is being automated. But if you bring judgment and craft, and the curiosity to keep asking why something works, plus enough stubbornness to not call it done until it does, you’re not going anywhere, and you’re probably more valuable than you were two years ago. The products I admire are still built by people who care a lot about what they’re making, who push back on each other, and who can tell when something isn’t good enough yet. No tool has automated any of that. The floor came up on its own; moving the ceiling is going to take actual work.
Yes, I used AI to help me structure and refine this article.