Is Vibe Coding Bad? What a Real Invoice App Build Showed us

Jeffy Susan October 15, 2026 0 comments

Is vibe coding bad? It’s good at more than developers admit

The pitch I keep hearing goes like this: AI writes the code now, so you don’t need web developers with ten or fifteen years behind them. You need one person who’s good at prompting.

I’m not going to tell you that’s nonsense, because half of it is true.

Vibe coding (Andrej Karpathy’s name for it, from early 2025) means describing what you want and accepting what the AI writes without reading much of it. For a prototype, or an internal tool that five people use, that’s fine. Better than fine. I’ve run a web development company since 2002 and I build with Claude Code myself, and jobs that used to take my team two weeks now take an afternoon. Anyone who tells you the old way is still faster is protecting a rate card.

So the gap between a beginner with AI and a senior developer is shrinking, if you measure it by how much working code each can turn out in a day. Where it hasn’t shrunk is harder to see, and the only honest way I know to show it is with a real build. This will get a little technical (I’ll keep the code to one line, promise).

The app: our own invoicing system

Macronimous exports software services from India, which means our invoices follow rules that ordinary invoicing tools don’t model. We couldn’t find an off-the-shelf product that tied a bank’s remittance certificate to the invoice it paid, so we built our own in PHP and MySQL, with an AI agent doing most of the typing. It was quick. The code was clean.

I’ve already written up the full story for developers, with commits and diffs, in our post on agentic coding mistakes. What follows is the shorter version, for people who pay for software instead of writing it.

Four things happened. Not one of them threw an error.

Four things the AI got wrong, or would have

1. The Void button

Ask any AI for invoicing software and it’ll handle a wrong invoice the way every accounting tutorial does: mark it void, keep the number, never delete anything. Ours built exactly that, with a button and a confirmation box, and it worked perfectly in the demo.

It was also wrong for us. In our reading of Indian GST (Goods and Services Tax), an issued tax invoice creates a liability whether you later mark it void or not. (That’s our working understanding, not tax advice; ask your accountant.) A wrongly issued invoice has to be removed and its proforma put back. I caught it in review, and only because I’ve lived with these rules for years. A perfectly good vibe coder who has never run an export business would have shipped it, and as far as I can tell the first sign of trouble would’ve been a notice from the tax department.

2. The April 1 problem

Here’s the one line of code I promised. It’s from the first version of the function that numbers our invoices:

 

There’s nothing wrong with it. date('Y') is the calendar year, which is what most of the world wants. But India’s financial year starts on April 1, and our invoice numbers restart with it. The fix began with one sentence from me in review: “every business year, April 1st, we change the invoice numbers.”

You can’t find that bug by reading the code, because the code is correct. You find it by knowing something the code doesn’t.

3. Two people, one invoice number

This one I didn’t catch by knowing anything. I asked a question: what if someone on my team creates an invoice on their machine at the same moment I do?

Nobody knew. So we tested it with twelve at once, and eleven failed. The numbering code read the counter and then updated it in a second step, and under simultaneous writes MySQL deadlocks on that pattern (two requests each wait for the other, and one gets thrown out). The fix was a single atomic statement, meaning one database command that reads and increments together so nothing can squeeze in between.

I’d love to say experience handed me the answer. It didn’t. It handed me the question, because I’ve seen “it works on my machine” turn into a support call before.

4. The bug that was never written

AI tools like to store a payment as a yes-or-no flag on the invoice. Ours never did, and I was half expecting it to. Before it wrote a line, our spec said every foreign payment must carry its FIRC (Foreign Inward Remittance Certificate, the bank’s proof that the money arrived from abroad). A yes-or-no flag can’t hold a certificate, so the AI built a proper payments table from the very first commit.

And vibe coding security risks?

Fair question, since security is what most people asking about vibe coding are really worried about. The four cases above aren’t security bugs. Two others from our internal apps are, and I’ll be straight with you: my notes don’t say who spotted them, so I’m not going to claim them for experience.

• A read-only “viewer” role showed up in the interface and was never enforced on the server. Viewers could create and delete records.
• A spreadsheet export would have run a formula on opening if a client’s name began with an equals sign.

Both passed a click-through. And both are the sort of thing an AI won’t raise unless you ask, which you only do if you’ve been bitten.

A vibe coder alone vs. a seasoned developer using AI

Look at the heading on the third column before you read the table. It doesn’t say “developer without AI,” because that person is losing ground too. People frame this as vibe coding vs traditional coding, and I don’t think that’s the real choice anymore. Everyone’s using the AI. What differs is whether anybody who understands the business reads what comes out.

Area	Vibe coder alone	Seasoned developer using AI	What it costs you
Requirements and business rules	Builds the textbook version of the prompt.	Knows where your industry or country differs.	Our Void button would have created a tax liability.
Architecture	Accepts the AI’s first design.	Weighs hosting cost and upkeep.	You outgrow the design and pay twice.
Database	Accepts the generated tables.	Checks indexes and simultaneous writes.	Eleven of twelve invoices failed in our test.
Performance	Fixes it when users complain.	Spots the expensive query before launch.	The slowdown arrives with your busiest week.
Security	Trusts the generated login and roles.	Logs in as each role and tries to misbehave.	Our “viewer” could delete records.
Testing	Runs the tests the AI offered.	Decides what’s risky and tests that.	Customers find the bugs for you.
Faults on the live site	Pastes the error back into the AI.	Reads the logs and finds the cause.	The outage runs longer than it should.
Existing code	Wants to rebuild it.	Can change a site somebody else built.	You fund a rebuild you didn’t need.
Search visibility	Ships pages that only render in the browser.	Checks what Google and AI crawlers receive.	The site works and nobody finds it.
Ownership	Says the AI wrote it.	Signs off on it.	There’s nobody to call when it breaks.

Will AI replace web developers?

Some of them, yes. If all a developer offers is typing speed and framework syntax, the AI has that job already.

What I can’t see it replacing soon (and I’ve been wrong about timelines before) is the person who knows what the software is for. The AI gives you the most common version of whatever you ask for, which is the right version if yours is the most common business, and almost nobody’s is, because you’ve got a tax rule or a shipping exception or a client who pays in three currencies or an auditor who wants the record kept a certain way, and none of that is in the prompt unless somebody who has lived with it puts it there, and that somebody is what you’re paying for when you hire an expert.

Go back over the four cases. Three were caught by knowledge of the business, not of PHP. The fourth was caught by a question that came from years of watching software meet real users. I know that’s a small sample (one app, one company), so treat it as a pattern I’ve seen and not a study.

Questions to ask before you hand over a real system

• Does this software touch money, tax, personal data or legal records?
• Who on the project knows the rules of my industry and my country, and have they read the spec?
• What happens when two people do the same thing at the same second, and is there a test that proves it?
• Has anyone logged in as each user role and tried to do what that role shouldn’t?
• When it breaks at night, who reads the logs?
• Could a different developer pick up this code a year from now?

If the honest answer to the first one is no, go ahead and vibe code it. I would. We’ve written about how our developers use vibe coding, and about the stricter process we call controlled AI coding for everything else.

FAQ

Where that leaves you

That’s what one build taught us. If you’ve put a fully vibe-coded system into production and it has held up for a year, I’d like to hear how, because I haven’t seen it yet.