AI coding tools are rewriting who gets to make software. The question isn’t whether that’s good. It’s what it does to the things we use every day.
In 2023, a controlled study found that developers using GitHub Copilot completed a coding task 55% faster than those without it. That’s your 4-week sprint becoming a 2-week sprint.
By 2025, 25% of Y Combinator’s Winter batch had codebases that were 95% AI-generated. Collins Dictionary named “vibe coding” its 2025 Word of the Year. The AI code generation market hit $4.91 billion.
Thanks for reading Built for People! Subscribe for free to receive new posts and support my work.
A UX designer in an academic study said it best: “What used to take me hours, I can now do in two minutes with AI.”
Everyone celebrated the democratisation of software. And rightly so. But here’s the thing nobody’s spending enough time on: the constraints that made software expensive also shaped the experience of using it.
Remove the constraint, and you don’t just get faster software. You get more software. The question is whether more is better — or just more.
The old world: when software was precious
Let me paint you a picture of product management in 2021.
You’re a PM at a fintech. You have 6 engineers. US-based senior developers cost $150–$200 per hour, and when you factor in benefits, recruitment, and overhead, the true cost of a fully employed engineer runs roughly 2.7x their base salary.
Every sprint is a zero-sum game. Every feature you build means something else you don’t.
The ritual goes like this: spend 3 days writing a PRD nobody fully reads. Two design review cycles. A stakeholder alignment meeting. At least one “can we push this to next quarter?” Get engineering estimates that are optimistic by 40%. Build anyway. Ship late. Celebrate like you conquered something.
The process was slow and annoying. But it had a hidden benefit: it was a quality filter.
The pain of getting anything built meant only things worth building got built. Everything had to survive interrogation. ROI calculations. Stakeholder scepticism. Engineering capacity constraints.
Internal tooling? Almost never.
At Wise, a globally scaled fintech where I worked back then, building tools for operations teams was notoriously difficult — not because it was technically hard, but because engineering resources were too scarce to point at anything that didn’t directly move a customer-facing metric.
The ops team needed a custom dashboard? Great idea. Back of the queue behind the 11 customer-facing features committed in Q1.
Software was expensive, so you built less and built it well.
Enter the Vibe coders
In February 2025, Andrej Karpathy — former head of AI at Tesla, co-founder of OpenAI — coined the term “vibe coding.” Describe what you want in plain English. Let the AI write the code. Don’t even look at it (although you should).
A Meta PM named Zevi Arnovitz, who described himself as someone who finds code “terrifying,” told Lenny’s Podcast that AI coding tools felt like being handed “superpowers.” He rebuilt his entire workflow using Cursor and Claude — no engineering background, shipping features independently.
Figma CEO Dylan Field noted that designers, engineers, PMs, and researchers were all starting to “dip their toe into other roles.” The walls between disciplines were dissolving.
Meanwhile, one designer summarised what this felt like in practice: “From ideas in my head to ideas I can see. It’s like having a thought partner to explore, learn, and debug with.”
If software used to be an expensive, scarce resource, it just became abundant and cheap.
So what happens to the user experience when the cost of building drops to near zero?
The Michelin-Star problem
Here’s the mental model that changed how I think about this.
Every great chef will tell you the same thing: the hardest part isn’t cooking. It’s deciding what not to put on the plate.
Joël Robuchon — the most Michelin-starred chef in history with 32 stars at his peak — was famous for a dish of three ingredients, plated so precisely the kitchen would redo it if a garnish sat one millimetre off.
Compare that to a diner with a laminated 200-item menu. More options. Worse food. The menu isn’t generous — it’s just unedited.
When building is expensive, you’re forced to be Robuchon. When building is free, the temptation is to become the diner.
The constraint wasn’t just slowing you down. It was making you good.
What cheap software actually unlocks
Let’s start with the upside, because it’s genuinely massive — and it’s not where most people are looking.
1. The internal tools revolution.
Remember the Wise ops team? That dashboard request that died in the backlog — not because it was bad, but because a senior engineer costs $150–$200 an hour and the dashboard couldn’t compete for sprint slots against customer-facing features?
Today, that ops manager can build it in an afternoon using Lovable, Bolt, or v0.dev. No sprint slot. No ROI calculation. No stakeholder approval. Done.
Software stopped being a bottleneck for operational efficiency. The internal tools that lived in PowerPoint decks for years are becoming real. And this is happening in a context where the quality bar is naturally lower, the stakes of failure are contained, and users are forgiving colleagues. Perfect fit.
2. Prototyping goes from days to minutes.
This is the one designers should care about most.
A study of 20 UX professionals published in 2025 found that vibe coding fundamentally changed how designers test ideas. Instead of spending days building a static mockup in Figma, they were generating working prototypes in minutes — complete with real interactions, real data flows, and real feedback loops.
One participant described it as overcoming “whiteboard fear” — the paralysis of starting from a blank canvas. AI gave them a starting point they could refine instead of a void they had to fill.
Product designer Kshitij Agrawal summarised the shift perfectly: “Mockups existed because coding was difficult. Now that coding is easy, the future is prototypes.”
Think about what that means for UX research. Instead of testing a static Figma flow and asking users to imagine how it would work, you can test the actual thing. The feedback is richer. The iteration is faster. The gap between what you designed and what users experience collapses.
3. The designer-developer wall dissolves.
Smashing Magazine described the new paradigm: designers are becoming “design engineers”, using AI tools to add not just visual styles but basic functionality to UI components — without programming skills. The deliverable is changing from a spec document to an actual working element.
For the first time, the person who understands the user can also build the thing. That’s a powerful loop.
But here’s what happens to the user experience
All of this speed is extraordinary. The risk isn’t that the tools are bad. It’s that they make it trivially easy to build things that shouldn’t exist.
The pixel-perfect trap.
A UI/UX designer at agency COAX described the core problem: “An AI-generated form looked perfect in Figma but failed basic usability tests. It had no validation, poor error states, and confusing navigation.”
This is the signature failure mode of AI-generated interfaces. They look polished — beautiful layouts, consistent spacing, professional typography. But they’re missing the invisible layer that makes software work: error handling, edge cases, loading states, accessibility, and the dozens of micro-decisions that come from actually watching someone use the thing.
AI builds from patterns. It doesn’t build from empathy.
The Spotify problem.
You don;’t need a history lesson to see what unconstrained feature-building does to a product. Just open Spotify.
It launched as a music app. One job, done brilliantly. Then it added podcasts, audiobooks, AI playlists, AI-generated music, social features, TikTok-style video clips, and a live events marketplace. Each addition made strategic sense in isolation. Together, they turned a music player into something users increasingly describe as cluttered and confusing.
The Spotify Community forums read like a UX case study in what happens when “can we build it?” replaces “should we?” One user in another thread put it plainly: “I will never use the audiobooks features. I will never use the podcasts features. I only care about music. Making your app more confusing in hopes that I stumble upon an audiobook or podcast is incomprehensibly stupid.”
Spotify added audiobooks partly because of a 2022 legal settlement allowed bundled services to pay lower royalties to musicians. The feature wasn’t built for users. It was built for the business model. Users got a more cluttered app as a side effect.
Spotify evolution over time
This is the Evernote trajectory in real time. (Evernote pulled the same move a decade ago — expanded from notes into business cards, presentations, work chat, and eventually a marketplace selling socks and backpacks. Downloads collapsed 82%. Its new owners spent their first year stripping features to return to basics.)
And neither company even had AI coding tools. Every feature they added required real engineering time. Imagine what happens when adding a feature costs nothing.
The state of UX saw this coming
The UX Collective’s State of UX 2025 diagnosed the moment with uncomfortable clarity.
Their observation: teams are “optimizing flows for clicks, not clarity” and have “stopped building tools and started building engagement traps.” Designers are spending their days in stakeholder alignment meetings rather than doing design work. Products get launched because someone needs a promotion. Timelines are built around performance reviews.
They described an industry that was already drifting toward feature bloat before AI made building free. Add vibe coding to this culture, and the incentive to ship more — without asking whether more is better — only intensifies.
The NN Group’s UX Reckoning piece put the positive frame on it: this is the moment where curated taste, research-informed judgment, and critical thinking become the differentiating skills. Not because they’re trendy — but because they’re the things AI genuinely can’t do.
Jakob Nielsen himself noted that by Q3 2025, “the era of pixel-pushing had effectively ended for commercial production” — tools like Figma AI and v0 could generate high-fidelity UI from text prompts. But he also observed that this made UX more important, not less: someone still needs to decide what to build, for whom, and why.
Who wins. Who loses.
The loser is any team whose answer to “can we build it?” is always “yes.” The Evernote trajectory awaits.
The winner is any team that uses the speed for the right things — rapid prototyping, internal tooling, faster research loops — while maintaining the discipline to ask, for every customer-facing feature: does this respect the user’s attention?
The academic study of UX professionals found exactly this tension. They called it the gap between “intending the right design” (using AI to build faster) and “designing the right intention” (knowing what to build in the first place). Speed only helps if you’ve already answered the second question.
There’s an old product design saying that’s about to become the most important sentence in every team’s vocabulary: the best feature is the one you decide not to build.
The opportunity
Product management and UX design have always had an awkward relationship with engineering constraints. Those constraints were frustrating. They were also making you better.
Now the constraint is gone. So the designer, the PM, the researcher — they need to become the new constraint.
Not by slowing things down. By using the speed for prototyping, testing, and internal tools — and holding the line on what ships to users.
For the first time, the person closest to the user can also build the prototype, test it with real people, and iterate in hours instead of weeks. The designer doesn’t need to wait for engineering. The PM doesn’t need to write a spec and hope it gets interpreted correctly. The researcher can go from insight to testable prototype in an afternoon.
This is a great opportunity, but only if the industry resists the temptation to treat speed as the goal rather than the tool. When building is cheap, restraint becomes the most valuable thing a team can practise.
The teams that figure this out will build the next generation of things people actually love.
The rest will spend the next decade undoing what they built this year.
Thanks for reading Built for People! Subscribe for free to receive new posts and support my work.
When anyone can build anything was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.