Vibe coding is building software by describing what's needed in plain English instead of writing the code. The name comes from Andrej Karpathy, who described it as "you just see things, say things, run things, and copy-paste things, and it mostly works."
Simon Willison makes a useful distinction: vibe coding in the strict sense means building software with an LLM without reviewing the code it writes. If you review, test, and understand the output, that's AI-assisted programming. In practice, what produces reliable results is more structured than the name suggests. The human tells the AI what the output should look like, the AI writes the code, and the human reviews the result. Karpathy named the phenomenon. The Anthropic data below shows what actually makes it work.
Most of the conversation around vibe coding has been aimed at developers and startup founders (which makes sense considering that they were the first to adopt it) but that's changing as AI systems continue to evolve. Anthropic just published an article analyzing data from Claude Code sessions showing that vibe coding is actually being done by a much wider group than just developers and founders.
The data that surprised me
Anthropic analyzed roughly 400,000 Claude Code sessions from October 2025 to April 2026. They looked at who was using AI coding tools, what they were doing with them, and how often they succeeded.
The headline: across occupation groups, non-software professionals succeeded 26% of the time compared to 30% for software engineers. In sessions that actually produced code, the gap narrowed further: 29% versus 34%.
Across 400,000 sessions the gap between "professional developer" and "person who knows their problem space well" is four to five percentage points. That's the headline for me.
A 26% success rate might not sound high on its own, but consider the baseline. These are people who couldn't have attempted any of this a year ago. One successful session out of four means an operations lead who used to wait weeks for developer time can now build working tools independently, today. Those numbers are also per-session. Many successful projects take two or three sessions of iteration to get right, which means the per-project success rate is higher than any individual session suggests.
An interesting finding highlighting why experts are seeing so much success is the data about what happens when things go wrong. In sessions that ran into trouble, experts recovered at a 15% success rate versus only 4% for novices. The expertise gap shows up when the AI stumbles because knowing the domain makes it possible to spot where the output went wrong and steer it back.
I'm the person in that data
I should probably explain why this resonated with me. I'm not a developer, I work in operations. I took a game design program in college and dabbled in some code over the years, but my day job is marketing, sales analytics, and operations.
Over the past few months, I've been using Claude Code to do things that I would have needed a developer for a year ago:
- Migrating our CRM to a new platform. The whole data layer, schema changes, configuration, etc. I described what each piece needed to do and the AI handled the implementation. It went smoothly and is still working well.
- Building analytics dashboards. Custom PostHog dashboards tracking where our leads come from, including AI-assistant referrals. I couldn't have written the API integration code myself, but I didn't need to. What mattered was that I could describe exactly what metrics I needed to see and why.
- Processing meeting transcripts. An automated pipeline that takes a call recording, extracts decisions and action items, and puts them where the team can find them. It's not a product, it's a tool I built because I wanted to reduce friction that I was experiencing every day.
None of these are impressive to a senior engineer. All of them would have likely taken weeks in a conventional company's development queue. I built each one in a day or two because I knew exactly what I needed, I just didn't know how to turn it into code.
That's the pattern the Anthropic data confirms at scale: knowing what to build matters more than knowing how to build it.
The three questions that tell where to start
When Rand and I presented a framework for this at a Toronto Board of Trade webinar earlier this year, we kept coming back to three questions for any task being considered:
1. Is this repeatable? Doing roughly the same thing each time makes it a candidate. If every instance varies enough to require unique judgment, it's probably better left to a person.
2. Is it execution or judgment based? Drafting a proposal from a template is execution, which means a strong AI fit. Deciding whether to pursue a deal is judgment. The AI can still assist, but ultimately a person needs to decide. Failing to make this distinction is where many companies get burned when using AI.
3. What's the cost of getting it wrong? If the error is catchable before it matters (a draft that gets reviewed before sending), automate freely. If it's high stakes and not easily reversible (pricing, contracts, sensitive communications), the AI assists and a person decides.
If the answers are "yes, execution, and low/catchable" that task is a strong candidate for vibe coding, and it doesn't require engineering time.
Why this is different from no-code
No-code platforms are great for structured workflows, and many problems fit that mold. Forms, approval chains, simple apps. If the platform supports the use case, no-code is often the fastest path.
Where vibe coding differs is on the long tail: the bespoke tool that no platform anticipated. No-code works within the boundaries the platform designers built. Vibe coding with an AI produces actual software that can do whatever is described, including things no platform has a template for. The trade-off is that it takes enough understanding of the problem to guide the AI and evaluate its output. Knowing what's needed and how to explain it is the key skill needed to succeed.
The Anthropic study actually quantifies this: expert users triggered about 12 AI actions per prompt, compared to 5 for novices. Experts are delegating more precisely and iterating, since they know what to ask for and when to push back on the result.
The ceiling and what's beyond it
It's important to know where this breaks down. Using AI for one-off tasks works from day one, but there's a ceiling.
Prompting the AI fresh each time means being the intermediary between the AI and everything that ships. It doesn't know the company, the standards, or the terminology in most cases. It gives different people different answers to the same question, and nothing accumulates. Each session starts from zero.
The fix isn't just a better prompt. Good prompting makes a difference, but the root of the problem is context rather than prompting. There's only so much that can go into a conversation before the AI runs out of space. The solution is giving the AI organizational context to work from: processes, standards, and accumulated knowledge. That's where individual productivity becomes something that compounds. We covered this progression in our Board of Trade session: building (one-off tasks built to certain specifications) to growing (systems that learn from the organization's work). It's also the problem we spend most of our time on at Rangle, helping organizations build the context infrastructure that turns individual wins into compounding capability.
One simple habit that helps bridge the gap: before ending a session, ask the AI to write a summary of what was built, how it works, and what's left to do. Save it as a text file (AI generally works well with .txt and .md files). Next time you're working with a new agent, paste that summary at the start of the session. The AI picks up the context instead of starting from scratch. It's not a full solution to the accumulation problem, but it's a meaningful step that anyone can do from day one. The individual wins are real and available to experts who aren't developers right now without any of that infrastructure.
How do I start vibe coding?
Try it in fifteen minutes
Open claude.ai or ChatGPT (free tier works), think about a task from this week that was repetitive and felt like it should be automated, and describe it in plain but detailed language.
For example, if you spend time reformatting data between systems, you might type:
"I have a CSV export from HubSpot with columns for company name, contact email, deal stage, and deal value. I need a script that reads this CSV and creates a summary showing total deal value by stage, with the stages sorted from earliest to latest in our pipeline. Our stages are: Lead, Qualified, Proposal, Negotiation, Closed Won, Closed Lost."
If the idea of running a script or using a terminal feels intimidating, you're not alone. Most non-developers feel the same way the first time. The good news is that you can tell the AI that directly. "I don't know how to run this, can you make it something I can open in my browser?" or "Can you make this work in Google Sheets?" are perfectly valid prompts. The AI will adapt its output to match your comfort level. We're also working on a detailed companion guide that walks through the entire first session step by step, from opening the tool to running the result.
Even without code or technical language the AI will produce a working solution. If something's wrong, explain it to the AI ("the Closed Lost deals shouldn't be included in the total", or "the stages are in the wrong order", or even "I don't know what to do with this output"). Even if it doesn't work right away, you can iterate and refine until it does. Most tasks like this take two or three rounds the first time, but once you have a working approach you can ask the AI to make it repeatable. What took a few rounds today can be done at the push of a button tomorrow.
Pick a real problem
The fifteen-minute test shows the mechanism works. The real payoff comes from applying it to something that's actually costing you time.
Think about the last time you said "I wish I had a tool that..." or "why do I have to do this manually every time?" That's a sign that there's an opportunity to build a solution. Some starting points by role:
- Operations: A script that pulls data from one system and formats it for another. Reconciliation reports. Compliance checklists that auto-populate from source data.
- Marketing: Content performance dashboards that pull from multiple platforms. Automated report formatting. Lead scoring calculations based on criteria you define.
- Finance: Invoice processing workflows. Budget variance reports that flag outliers. Data validation scripts that catch the errors you're tired of finding manually.
- HR: Onboarding checklist trackers. Headcount reporting across multiple systems. Survey response analysis that groups feedback by theme.
The common thread is that you know exactly what the output should look like. You've probably been producing it manually, the AI just helps you create what you need to remove the manual part.
When it goes wrong (and it will)
The first attempt rarely works perfectly, but that's a part of the process. It's actually where domain expertise matters most.
The Anthropic data shows experts recover from AI errors at nearly four times the rate of novices (15% vs 4%). The expertise isn't in coding, the work is done entirely in plain English. Experts just need to know how to spot what's wrong with the output. "These numbers don't add up because you're counting the header row" is the kind of feedback that turns a failed first attempt into a working second one. "The dates are in the wrong format" or "this is pulling from the wrong column" are corrections any domain expert can make.
The pattern that works: describe the problem, review the output, describe what's wrong, iterate. If that sounds like an OODA loop (observe, orient, decide, act), it is. Think of it as working with a new hire who understands the tools but doesn't know the business yet. The AI is fast and precise at execution while the human brings the understanding of what "correct" looks like in context.
The new-hire analogy extends further: start with small, well-defined problems and build up. Trying to hand the AI a massive, ambiguous project upfront is like asking a new hire to redesign the whole system on their first week. It might occasionally produce something good, but the results will be inconsistent. Starting with a small problem, getting it working reliably, and then expanding the scope over time produces something much more resilient. Each iteration teaches both you and the AI what "correct" looks like in your specific context.
Building from there
Once one useful tool is built, the second one comes faster. The pattern of describe, review, correct, and iterate becomes easier over time. Doing this consistently and applying this process to different problems will create a set of tools that remove daily friction. As working tools accumulate, the AI can also help manage them. "Help me build a dashboard and automation for these scripts I run every day" is another good use of AI once you've got a working process established.
"Am I just automating myself out of a job?"
The way that a person engages with AI strongly influences whether it can replace them or not.
Harvard Business School researchers studied 244 professionals using AI across a full problem-solving workflow and found three distinct patterns. Professionals who directed the AI using their domain expertise actually got better at their jobs over time. They articulated requirements more precisely, understood their own processes more deeply, and developed new capabilities in the process. A separate group went deeper, learning how the AI itself worked and developing entirely new skills that didn't exist before their collaboration started.
The group that didn't grow was the one that handed everything to the AI without engaging. They treated it as a black box, accepted whatever came back, and learned nothing from the exchange. If the human isn't leveraging their expertise and is instead relying on the AI for everything, they're effectively just replacing themselves.
The difference maps directly to what this article describes. Vibe coding the way it works in practice means directing the AI with domain knowledge, evaluating the output, and iterating when it's wrong. That process builds on expertise rather than replacing it. Each tool built is a clearer understanding of the problem it solves. The person who built the CRM migration, the analytics dashboard, and the transcript pipeline is the person who understands those systems well enough to have built them.
