In February 2025, Andrej Karpathy posted a tweet about a new way of working he called “vibe coding.” Accept All, don’t read the diffs, copy-paste errors back in and hope for the best. He meant it for throwaway weekend projects. He later described it as “a shower of thoughts throwaway tweet.”
Then the term escaped. Within months it was applied to everything — careful, test-driven AI-assisted engineering lumped in with reckless prompt-and-pray prototyping. By November it was Collins Dictionary’s Word of the Year. And somewhere along the way, it became a way to dismiss people.
I’ve watched “vibe coding” turn into shorthand for “not a real engineer.” A label to make anyone using AI tools to build something feel lesser — especially if they don’t have a computer science degree. Peter Steinberger called it a slur on the Lex Fridman podcast. Andrew Ng said the name was misleading. Karpathy himself retired the term after exactly one year, proposing “agentic engineering” instead. The person who coined it doesn’t want it anymore.
Product Hunt’s 2025 survey found that 63% of people using AI coding tools aren’t developers. They’re designers, product managers, domain experts, founders. People who understand their customers deeply and can now pair with AI tools to turn that understanding into working software.
That should be welcomed, not dismissed.
I run a startup where our automotive expert has decades of knowledge about how parts catalogues actually work. Our product designer understands garage workflows because he’s sat with mechanics and watched them order parts under real pressure. When those people contribute more directly to what we’re building — prototyping ideas, testing hypotheses, building internal tools — the product gets better. Not because they replaced an engineer, but because they brought context no engineer had.
The research backs this up. Boston Consulting Group found that companies with diverse management teams generate 19% higher revenue from innovation. McKinsey’s research across 1,000+ companies showed organisations in the top quartile for diversity were 39% more profitable. Harvard Business Review reported that cognitively diverse teams solve problems faster and consider more solutions. Calling someone’s contribution “vibe coding” because they aren’t a traditional engineer doesn’t protect quality. It keeps good ideas locked in people’s heads.
The whole point of a cross-functional team is that different people see different things. Engineers bring technical rigour and years of hard-won lessons from maintaining production code — they know what breaks at scale, what’s expensive to change later, what looks simple but isn’t. Designers bring heuristics and deep customer insight from watching real people use the product — they’ve seen where users get stuck, where they give up, where they find workarounds nobody planned for. Commercial stakeholders keep us honest about business constraints — what we can actually charge for, what the contract requires, what the timeline looks like. And domain experts bring industry knowledge and on-the-ground reality that means we’re building for how things actually work, not how we imagine they work.
None of those perspectives live in the code. They live in conversations. AI tools don’t change that. They just mean more people can act on what comes out of those conversations.
But more people building doesn’t mean everyone building alone.
I’ve seen it happen. Someone picks up a ticket, builds the thing in isolation, shows it to the team, and the solution isn’t right. Back to the drawing board. Wasted time and energy regardless of whether you wrote the code by hand or prompted it. Melissa Perri called this the Build Trap — organisations that measure success by shipping features rather than solving customer problems. AI tools make it worse because they compress the time between “I have an idea” and “I have a working prototype” to almost nothing. The conversations before building — about constraints, edge cases, what we tried before, what the customer actually said — those matter more than ever now. The speed of execution has gone up. The importance of knowing what to build hasn’t changed.
And quality is still on you. “I used AI” isn’t an excuse for not understanding what you shipped. The tools actually make that easier. Ask Claude Code to explain every decision. Review screenshots, check API outputs, write tests, ask for feedback. Automate parts of the quality process as you learn the codebase. The responsibility shifts from “can you write this?” to “do you understand this, and should it exist?”
Simon Willison’s rule is a good one: don’t commit code you couldn’t explain to someone else. Kent Beck coined “augmented coding” as the disciplined middle ground. Addy Osmani argued that conflating vibe coding with AI-assisted engineering devalues the discipline entirely. These are all useful frames.
But I think the fix is simpler than finding the right two-word replacement. We already have a word for what’s happening. It’s building.
When a product designer prototypes a feature because they’ve spent weeks watching users struggle with the current one — that’s building. When a domain expert creates an internal tool that saves their team hours — that’s building. When an engineer ships a complex system with AI writing 80% of the first draft — that’s also building. The tool doesn’t define the work. The understanding does.
What I’d rather see is teams where everyone can contribute to building, where conversations happen before code gets written, and where quality is everyone’s responsibility regardless of how the code got there. That already has a name. It’s just good product development.
Karpathy’s tweet was a year ago. The term has done enough damage. Let it go.