I have been writing code for twelve years, and for thirty days I mostly stopped.
Instead of typing functions, I described them. I told an AI what I wanted, watched it write, ran it, and said "no, the other thing" until it worked. People call this vibe coding, and the internet is split between "this is the future" and "this is how you ship a security breach."
After a month of doing it for real work — not toy demos — I land somewhere neither camp will like.
Vibe coding is genuinely fast for the first 70% of a project and genuinely dangerous for the last 30%. It's a real productivity multiplier when you already know what good looks like, and a trap when you don't.
Here's the honest breakdown:
I gave myself one rule: ship things I'd normally build by hand, and measure honestly.
Over the month I shipped a CSV-to-dashboard internal tool, a Stripe webhook handler, a browser extension, a small CRUD API, and roughly a dozen throwaway scripts. Some were personal. Two went into production at work.
The internal dashboard was the best case. I described the columns, the filters, the chart, and the color scheme. Twenty minutes later I had a working app I'd have spent a full afternoon on. It wasn't pretty under the hood, but nobody was going to read that code again, and it did exactly one job.
The Stripe webhook was the worst case, and I'll come back to that.
Three things surprised me.
It removed the blank-page tax. The hardest part of any task is the first thirty minutes of staring. Describing the shape of a solution out loud got me to a running starting point fast, and editing something is always easier than creating it.
It's a phenomenal syntax memory. I haven't written a regex from scratch in weeks. I describe what I want to match, get a regex, and test it. Same for awk one-liners, obscure git incantations, and that one date-formatting call I look up every single time.
It made me write more tests. This is the unexpected one. Asking for "the same thing, with tests" costs me one sentence, so I actually do it now. The tests are mediocre, but mediocre tests beat the zero tests I used to write under deadline.
Vibe coding didn't make me a better programmer. It made me a faster one — which is not the same thing, and pretending otherwise is how people get hurt.
The Stripe webhook is the story I tell people now.
It looked perfect. It ran. It passed my happy-path test. And it had a quiet bug: it didn't verify the webhook signature, so anyone who found the endpoint could have faked a payment event. The AI wrote idiomatic, clean, confident code that was insecure by omission. Nothing was wrong on the screen. Something was missing off it.
That's the core danger. AI code fails by omission far more than by obvious error. A junior writes wrong code you can see. Vibe coding writes plausible code that's missing the thing you didn't know to ask for.
I caught it because I've shipped payment code before and the absence felt wrong. A newer developer would not have caught it. They'd have shipped it, and felt fast doing so.
Here's my real conclusion after thirty days: vibe coding doesn't replace knowing how to code. It changes which part of knowing matters.
The valuable skill is no longer typing speed or syntax recall. It's judgment — the ability to look at generated code and feel where it's thin. To know that auth needs rate limiting, that this loop will choke at scale, that this migration needs to be reversible. That judgment comes from having been burned before, and it's the same muscle I leaned on when I taught myself system design without a CS degree. Year after year the Stack Overflow Developer Survey shows experienced engineers adopting AI tooling fastest — not because they need it most, but because they can tell good output from a confident disaster.
So the cruel irony is this: vibe coding is most safely used by exactly the people who least need it, and most dangerous in the hands of the beginners it's marketed to.
If you're experienced, an AI app builder and a good vibe coding loop are a real edge. If you're new, use it to learn, not to ship — read every line it gives you and ask why each one is there. When I let an AI app builder build a whole SaaS, the same lesson held: the tool nails the happy path and quietly skips the parts that decide whether software survives real users.
For anyone trying this, here's the loop that kept me out of trouble:
| Task type | Vibe coding verdict |
|---|---|
| Prototypes & demos | Excellent |
| Internal tools | Great |
| Glue code & scripts | Great |
| UI scaffolding | Good |
| CRUD APIs | Good, review carefully |
| Auth & payments | Risky — review every line |
| Data migrations | Risky — test on a copy |
| Concurrency | Avoid unless you know the domain |
The strangest effect wasn't on my output. It was on how I think about problems.
When you spend years typing every line, your problem-solving is bottom-up. You start with the syntax and build toward the idea. Vibe coding flipped that. Because describing is cheap, I started thinking top-down — interface first, behavior first, edge cases first — and only then worried about implementation. That's actually how senior engineers are supposed to think, and the tool nudged me toward it almost by accident.
But there's a cost I felt by week three. My recall got lazy. I noticed I was reaching for the AI to write things I used to write from muscle memory, and a small part of that muscle was atrophying. The fix was deliberate: I kept a "no AI" hour each day where I wrote from scratch, just to keep the fundamentals warm. Think of it like a pilot who flies on autopilot most of the time but still practices manual landings, because the day the automation fails is exactly the day you need the skill it replaced.
The other shift was social. I started reviewing AI output the way I'd review a colleague's pull request — skeptically, kindly, line by line. That review reflex turned out to be the single most valuable habit the month gave me, and it transfers to reviewing humans too. Reading code critically is a skill, and vibe coding forced me to practice it constantly. By the end of the month I was a sharper reviewer than I'd been a year before, which is not what I expected to get out of the experiment.
If you're trying to figure out where AI fits in your own workflow without letting it rot your fundamentals, it's worth following along as I keep testing these tools on real work and writing up what actually holds.
Q: Will vibe coding make me a worse programmer? Only if you let it think for you. Used as a faster way to express decisions you understand, it's fine. Used as a replacement for understanding, it rots your skills quietly.
Q: Is the code production-ready? Sometimes, but never assume it. Treat every generated block as a pull request from a fast, talented intern who has never been held accountable for an outage.
Q: What's the biggest mistake people make? Trusting code because it runs. Running and being correct are different things, and the gap is where bugs live.
Q: Do I still need to learn the fundamentals? More than ever. The fundamentals are now your review checklist. Without them you can't tell good output from a confident disaster.
Thirty days in, I kept vibe coding — but only as a tool, never as a crutch.
It's the fastest typist I've ever worked with and the most overconfident teammate I've ever had. The verdict isn't "good" or "bad." It's this: vibe coding amplifies whatever judgment you already have. If you have none, it amplifies that too.
So before you let it write your next feature, ask yourself one honest question: if this code were missing something important, would you actually notice?
I went from 200 to 11,000 subscribers without hiring anyone. AI didn't write my newsletter — it did everything around it.
One person, output that looks like five. It isn't about working more hours — it's about a kind of leverage teams rarely have.
One idea a week to a published issue in under an hour. The boring system behind a newsletter I never dread sending.
Comments
Sign in to join the conversation
No comments yet. Be the first to share your thoughts!