Keywords: vibe coding, AI coding, natural language programming, no-code AI, Google Antigravity, beginner coding, AI pair programming, AI-assisted development

Reading time: ~9 minutes

The first time I heard the term "vibe coding," I wasn't sure what it meant either. I'd been writing scripts for 25 years — Python, Bash, the occasional Go — so the idea that someone could describe what they wanted in plain English and get working code felt somewhere between promising and suspicious. Then I tried it, building a small internal monitoring tool by describing what I wanted and letting the AI generate the code. The result wasn't perfect. The result was a working application I'd written without touching a keyboard for syntax.

That experience is what vibe coding actually means: describing what you want well enough that the AI can build it, and iterating on the result through conversation rather than code. For someone like me who scripts as a secondary skill, it's a meaningful shift. For someone who has never written a line of code, it's a more dramatic shift — the kind of capability access that changes who can build things.

This post explains what vibe coding actually is, how it differs from traditional coding in practical terms, and where it's useful and where it isn't. I'm not going to oversell it. I've found both real productivity gains and real limitations, and the gap between the two is what determines whether vibe coding is a good fit for a given task.

What Vibe Coding Actually Is

Vibe coding is building software by describing what you want in natural language and having an AI generate the code, then iterating through conversation. The name captures the idea that you're setting direction and tone rather than writing syntax — the "vibe" is the description, the AI does the typing.

Three things make vibe coding work in practice:

First, the description has to be specific enough. "Build me a website" doesn't work. "Build me a single-page site with a header, three feature cards, and a contact form that emails me when submitted" works much better. The more concrete the description, the more useful the first output.

Second, iteration is built in. The first output is rarely the final output. You see what the AI produced, identify what's wrong or missing, and ask for changes. Each round of feedback is another short description. "Make the cards stack on mobile" or "Add a search bar that filters the table" — these are the kinds of requests that work well.

Third, you don't have to read the code unless you want to. For a lot of small tools — internal dashboards, simple automations, throwaway scripts — the code is intermediate. The output is what runs, and the output works. If something breaks, you describe the problem to the AI and let it diagnose.

The pattern matters because it changes who can build. It's not that everyone can build everything — they can't. But the floor for "I can build a small tool that does what I need" is much lower than it was five years ago.

How Vibe Coding Differs From Traditional Coding

The practical differences, in the order they show up in a project:

How you give instructions. Traditional coding starts with a programming language. Vibe coding starts with a description. The skill shift is from "writing code that does X" to "describing X well enough for code to be written." That's a real skill, but it's not the same as learning Python or JavaScript.

How you handle errors. Traditional coding: you read the error, trace it, fix it. Vibe coding: you describe the error to the AI, the AI diagnoses, the AI proposes a fix, you approve or adjust. The debugging mental model is different — you're supervising the AI's debugging rather than doing it yourself.

How you maintain the code later. This is where vibe coding gets harder. If you didn't write the code, understanding it later takes more effort. The AI can help you understand it, but that's another step you didn't need with code you'd written yourself. For long-lived projects, this matters.

How you scale. A small tool built by vibe coding works fine. A complex application built by vibe coding works, but the description overhead grows with complexity. Eventually you're describing a system so complex that you need to read the code to verify it does what you described. At that point traditional engineering practices start to matter again.

Where Vibe Coding Works Well

From my own use and from watching others, vibe coding works best for:

Small internal tools. Dashboards, automations, data transformations, status pages. These are common needs, often specific to one team or workflow, and rarely worth hiring an engineer to build from scratch. Vibe coding fills the gap between "I need this tool" and "I have time to learn enough to build it from scratch."

Prototyping. When you want to test an idea before committing engineering time, vibe coding lets you build a working version in hours instead of days. The prototype may not be production-quality, but it's enough to validate whether the idea is worth investing in.

Personal projects. Scripts that automate something tedious, websites for a specific event, tools that solve a personal problem — anything where the stakes are low and the value is personal. The AI makes the cost of building low enough that things you wouldn't have built before become worth building.

Learning a new domain. When you're learning a new tool or framework, vibe coding lets you generate a working example and then study what the AI wrote. It's a different way to learn — less reading documentation, more reading code that does what you wanted.

Where Vibe Coding Doesn't Work Well

Equally important to know where it doesn't work:

Production systems with real users. The AI can produce code that works, but it doesn't produce code that's been thought through for security, performance under load, edge cases, or long-term maintainability. For production systems, you need engineers reviewing the code, not just approving outputs.

Anything where you can't describe what you want clearly. Vibe coding depends on the description. If you don't know what you want — or can't articulate it — the AI can't build it. This is more common than people expect. A lot of "I want to build an app" requests are really "I have a vague problem and want to see what solutions look like." Vibe coding can produce something, but the result may not be what you actually need.

Code that needs to integrate with systems you don't understand. If the AI is generating code that talks to an API or a database you don't know well, you can't verify the code is correct. You'll either trust the AI blindly (risky) or spend as much time verifying as you would have spent learning the system.

Anything where the cost of being wrong is high. Security-critical code, financial calculations, anything that affects people's data or money. The AI can help, but the verification burden is on you, and vibe coding doesn't reduce that burden — it just shifts who does the verification.

The Skills That Matter for Vibe Coding

Vibe coding doesn't eliminate the need for technical skill — it changes which skills matter:

Describing what you want. The skill of being specific about requirements — what the system does, what the user sees, what happens when something fails — becomes the primary skill. This is project management, not programming, but it's technical in its own way.

Verifying what you got. You don't have to write the code, but you do have to know whether the code does what you wanted. For simple tools, running the tool and seeing if it works is enough. For anything more complex, you need enough technical understanding to evaluate the output.

Iterating on the description. When the AI produces something that doesn't match what you wanted, the question is whether to ask for a fix or to reconsider your description. The skill of refining descriptions based on what the AI produced is a meta-skill — you get better at it with practice.

Knowing when to stop. Vibe coding makes it easy to keep adding features. The skill of recognizing when the tool does what it needs to do and shipping it is the same as it ever was — but vibe coding removes the natural friction that used to slow that decision.

A Real Example: The Monitoring Tool I Built

To make this concrete, here's what I built with vibe coding and how it went.

I needed a small internal tool that would check the status of a handful of services every five minutes and post to a Slack channel when something was down. Existing monitoring tools were overkill for this — too many features, too much configuration. I wanted a single script that did one thing.

My first description to the AI: "Write a Python script that checks if these five URLs are reachable, and if any of them are down for more than two checks in a row, post a message to a Slack webhook." That description was too vague — the AI generated code that mostly worked but had issues with the retry logic and the Slack message format.

I iterated. "Add exponential backoff to the retry logic." "Format the Slack message to include the URL, the time it went down, and how long it's been down." "Run the checks in parallel instead of sequentially." Each request was a short description. Each round took 30 seconds to a minute.

Total time to working tool: about 45 minutes, including the iteration rounds. The final script is about 80 lines. I didn't write any of those 80 lines directly — I described what I wanted and let the AI generate, then read the code once at the end to make sure I understood what was running.

Would I have built this faster in Python directly? Probably not. Would I have built it at all if I had to write every line? Probably not — the value of this tool is real but modest, and the time it would have taken to write from scratch exceeded the value. Vibe coding changed the calculation.

A Note on the Underlying Shift

Vibe coding is part of a broader shift in how people interact with software creation. For decades, the answer to "I want to build X" was "learn to code" — learn the language, the frameworks, the deployment, the maintenance. Vibe coding replaces part of that with "describe what you want" — learn to be specific about requirements, learn to evaluate outputs, learn to iterate.

That's not a replacement for engineering. It's a different access path. For people who would have learned to code anyway, vibe coding makes them more productive. For people who wouldn't have learned to code, vibe coding opens up a category of building that was previously closed to them.

The mistake people make is treating vibe coding as either a revolution that eliminates the need for engineers or a fad that doesn't produce real results. Both miss the point. It's a real capability that's useful in specific contexts and limited in others, and the most useful thing to do is learn where those lines are.

For me, the bottom line is: I built a tool I needed, in less time than I would have spent thinking about whether to build it. That's a real win. It's not a win for every project — but it's a win for a meaningful category.

Related Reading

Sources

— Justin

📅 First published: 2026-04-30 | 🔄 Last updated: 2026-06-22