There is a fight running through the developer world right now, and on the surface it looks like a fight about tools. One camp says AI can already build software better than most people. Another says vibe coding is a disaster waiting to ship. A dozen widely shared posts this month argue past each other about whether letting an AI write your code counts as real work. We run AI across our WordPress and product engineering every day at Wbcom Designs, so we have watched this argument closely, and we think almost everyone is fighting about the wrong thing. The fight is not really about whether AI can code. It is about one word: engineering. And the reason it will not resolve is that both sides have quietly agreed on a wrong definition of it.

This piece is our attempt to draw the line where it actually sits. Not between AI and humans, and not between good tools and bad ones, but between two different things that happen to produce similar-looking code. Get that line right and the whole argument gets simpler, the hiring question gets clearer, and the way you use AI in your own work gets a lot safer.

The argument everyone is having

If you have been anywhere near developer social feeds this month, you have seen the pattern. A post titled Vibe Coding Isn’t the Problem, Calling It Engineering Is collects hundreds of reactions. Another, AI Didn’t Remove the Engineering Work, It Just Made It Easier to Pretend You Did, makes the rounds the same week. Alongside them sit pieces about AI outgrowing the tests we use to measure it, and about the slow cognitive atrophy of engineers who let the machine think for them.

Read them together and you notice the argument has moved. A year ago the question was whether AI could write working code at all. That question is settled. It can, and often quickly. So the debate has shifted to something harder to pin down: now that the machine can produce the code, what exactly is left that we were being paid for, and what do we call the people who do it. That is a definitional fight, not a technical one, and definitional fights are the kind that go on forever because nobody agrees on the terms.

The reason it stays stuck is that both sides treat engineering as a set of tasks. One side says AI now does those tasks, so engineering is mostly done. The other side lists tasks AI still does badly and says see, engineering is safe. Both are counting the wrong thing, because engineering was never the tasks.

Engineering was never the typing

Here is the definition we work from, and it changes everything downstream. Engineering is not writing the code. It is being accountable for what the code does after you walk away.

Think about what you were actually paying a senior engineer for, back before any of this. Not the typing. The typing was always the fast part. You were paying for the judgment that the thing would hold up: that it would not fall over under real traffic, that it would fail safely when a payment gateway timed out, that the next person could understand it, that the data would not leak, that the 2am outage would be short because someone had thought about the 2am outage in advance. Engineering is the set of promises a competent person makes about the future behavior of a system, and then stands behind.

The code is just the artifact those promises are attached to. Two people can produce the identical function, and one of them is engineering and the other is not, based entirely on whether they can answer for what happens when it breaks. That sounds like a small distinction. It is the whole distinction.

Engineering is not the code you produce. It is the accountability you carry for what that code does at 3am, months after you wrote it, when you are asleep and someone else is holding the pager.

Why vibe coding is a perfectly good word

Once you hold engineering to mean accountability rather than typing, vibe coding stops being an insult and becomes a useful, honest label for a real and valuable activity. Vibe coding is describing what you want and letting the machine produce it, without reviewing every line, without owning the internals. That is a genuinely good way to work whenever the cost of being wrong is low, which covers a lot of real situations:

  • A prototype you are going to throw away once it has proven the idea.
  • An internal script only you will ever run.
  • A weekend experiment to see whether something has legs.
  • A rough draft of a feature you fully intend to harden later.

In all of those the accountability bar is low, so skipping the engineering is the correct, efficient call. We vibe code constantly for exactly these things, and we are not embarrassed about it. The writer George Kobaidze drew a useful three-way split in the discourse: pure vibe coding where nobody reviews, AI-assisting where the human reviews everything the AI writes, and AI-assisted work where human and machine collaborate with the human driving. Those are three different levels of accountability, and each fits a different job. The mistake is never using the fast, low-accountability mode. The mistake is using it and then claiming you did the high-accountability one.

The real problem is the label swap

So here is where the actual harm lives, and it is not in vibe coding at all. It is in taking work done at the low-accountability bar and shipping it under the high-accountability word.

When you tell a client, a boss, or a user that something is engineered, you are making a promise. You are saying someone understood this, someone is answerable for it, someone has thought about how it fails and made sure it fails safely. That word is a warranty. It is the reason people trust the software with their money and their personal data in the first place.

Vibe coding a real product that handles payments and personal information, and then presenting it as a finished, engineered system, is not a tooling choice. It is making a warranty you have not backed. The code might even work on the day. The problem is that nobody can answer for what it does on a day you did not test, because nobody engineered it. The word promised an owner. There isn’t one.

This is why the fight feels so heated even though the tools are not the villain. People are not really angry about AI writing code. They are angry, correctly, about the warranty being counterfeited: about work that skipped the accountability being sold as work that carried it.

The bill does not disappear, it just gets deferred

The most useful observation in the whole discourse came from the engineer writing as DJ29, and it is the part every founder should sit with. The penalty for skipping engineering has not gone away. It has been moved in time, to someone else.

It used to be that being wrong about architecture hurt you fast. The site fell over, the bill spiked, the users complained, the pager went off, and the person who cut the corner was the person who felt it. That quick, personal penalty is what taught people to engineer in the first place. It was an unpleasant but effective teacher.

AI, and the free tiers around it, quietly removed that fast penalty. You can stand up something that looks complete and runs fine on launch day for almost nothing, with almost no understanding of why it works. The corner you cut does not bite on launch day. It bites in month four, when traffic grows, or the edge case arrives, or the security gap gets found, and by then the person who vibe coded it has moved on. The bill lands on whoever inherits the code. Usually the next hire, who now has to reverse engineer a system nobody ever understood, under pressure, at 3am.

That is the sharp point of the whole thing. The engineering work was not eliminated. It was deferred and reassigned. Someone still has to understand the system, be accountable for it, and fix it when it breaks. The only question the label swap answers is who, and when, and whether they signed up for it. The honest version names that person up front. The counterfeit version hopes it is not you.

A pattern we see all the time

This is not a hypothetical for us. A version of the same story comes through our door regularly, and it always has the same shape. A business builds a store or an app quickly, often with an AI tool, and it works. It takes orders, it looks professional, everyone is pleased. Then, months later, something goes wrong in a way nobody can explain, and it lands on us to fix.

One recent example: a store where the discount logic had been vibe coded and never truly understood. It behaved perfectly in every normal case for months. Then a big sale hit, several promotions overlapped in a combination nobody had tested, and coupons started stacking in ways they were never meant to. The store lost real money for a day before anyone noticed, and when they came to us, there was no one who could say why the code did what it did, because no one had ever engineered it. It had been generated, it had passed the easy tests, and it had been shipped as if it were owned.

The fix was not hard once a person actually read the logic, understood it, and added the handling for the overlapping case that the original generation skipped. That reading and understanding and taking responsibility is the engineering. It was always going to have to happen. The only thing the fast build changed was that it happened later, cost more, and happened during a live sale instead of before launch.

How to spot a warranty nobody is backing

Because the counterfeit is the dangerous case, it helps to know how to spot it, whether you are buying the work or doing it yourself. The tells are simple, and they are all about accountability rather than code:

  • Ask why it works, not just that it works. Someone who engineered it can walk you through the design and the failure cases. Someone who vibe coded it and stopped there describes the happy path and goes quiet on the rest.
  • Ask what happens when a step fails. When the payment provider times out, when two users hit the same record at once, when the input is malformed. Engineered work has an answer, often an unglamorous one. Counterfeit work treats these as somebody else’s problem.
  • Ask who fixes it at 3am. If there is a named person who understands the system and will answer for it, it was engineered. If the answer is a shrug, it was not.

That last question is the one this whole piece is built around, and it is worth asking out loud of any system about to carry real weight. It cuts through every other signal, because it goes straight to the thing that actually matters: not who or what typed the code, but who owns what it does.

How we draw the line in our own work

Because we ship real products that real businesses run on, we cannot afford to be fuzzy about this, so we have made the line concrete in how our team works. It comes down to a single question we ask before any piece of AI-produced work goes anywhere near a customer: does someone here own this, or did we just watch it get made?

For anything that will only ever be a prototype, a spike, or an internal convenience, the answer can be we watched it get made, and that is fine. We move fast and we do not pretend otherwise. For anything a customer will touch, anything that handles money or data, anything that has to survive contact with real traffic, the answer has to be someone owns this, and that ownership is not a feeling. It is work. It means a person read the code, understood the design, thought about the failure modes, and can answer for all of it. The AI can write as much of it as it likes. The accountability is not transferable to the machine.

We built our whole AI setup around making that ownership real rather than assumed, which we described in detail in our piece on the config layer that makes a coding agent trustworthy. The short version: the agent plans before it acts so a human approves the approach, hard checks run automatically on every change so nothing ships unreviewed, and our real procedures are encoded so the machine follows them. None of that makes the AI accountable. It makes it possible for a human to stay accountable while the AI does the volume. That is the difference between AI-assisted engineering and vibe coding wearing an engineering badge.

For the developers reading: where the ownership actually lives

If you want the technical version of this, ownership shows up in the boring places. It is the error handling around the call that can fail, which AI-generated code loves to skip. It is the test that covers the edge case the happy-path generation ignored. It is the code review comment that says this works but the next person will not understand why, so we are changing it. It is the architectural decision to not add the fifteenth plugin or the third caching layer. AI can draft all of these when asked, but someone has to know to ask, and someone has to judge whether the answer is right. That knowing and that judging is the job. It always was. We wrote more about where those hard parts moved in our earlier piece on how AI moved the hard parts of engineering rather than removing them, and this is the same idea seen from the accountability side.

What this means if you are hiring, or being hired

Reframe engineering as accountability and the hiring question, which is really the business question underneath all of this, gets much clearer.

If you are paying someone to build software, you are not paying for keystrokes anymore, because keystrokes are close to free now. You are paying for the warranty: for a person who will own the outcome, answer for the failures, and still be there, understanding your system, when it matters.

A quote that is cheap because the work is really being vibe coded and handed over unowned is not a bargain. It is a deferred bill with your name on it.

And if you are the person being hired, this is genuinely good news, not a threat. The part of your job the machine took, the typing, was never the valuable part. The part it cannot take, being the accountable owner of a working system, is exactly the part that was always worth the most. The engineers who will do well in this era are not the ones who type fastest or resist AI hardest. They are the ones who use AI to produce volume and then do the human work of standing behind it. The label stops being about who wrote the lines and starts being about who answers for them, which is where it should have been all along.

Why this matters beyond the argument

It would be easy to read all of this as a semantic quarrel, a fight over words that does not touch anything real. It touches something very real. Every business now runs on software, and a growing share of that software is being produced faster than anyone is being made accountable for it. The gap between how quickly we can generate a working-looking system and how quickly anyone truly owns it is widening, and that gap is where the next wave of outages, breaches, and quiet data losses is going to come from.

The way through is not to ban the fast tools or to pretend the slow craft is dead. It is to be honest about which mode you are in, and to make sure that anything carrying real weight has a real owner. Use AI to go fast where being wrong is cheap. Insist on human accountability where being wrong is expensive. Never let the fast mode borrow the trusted word. That is the entire discipline, and it is not complicated. It just requires telling the truth about which one you are doing.

The line, stated plainly

Vibe coding is fine. It is a real, useful way to work, and we would defend it against anyone who calls it lazy, because used in the right place it is simply efficient. Engineering is also fine, and still necessary, and now more valuable than ever, because the one thing it has always meant, accountability for a system’s behavior over time, is the one thing AI cannot generate for you.

The only thing that is not fine is confusing the two, because that confusion is how a business ends up trusting its money and its customers to software that nobody actually owns. So the test we would leave you with is the simplest one we know. Before you call something engineered, before you ship it, before you trust it, ask who owns this at 3am. If you can name the person, and they can answer for the system, it was engineered, whoever or whatever typed it. If the honest answer is nobody, then it does not matter how clean the code looks. It was vibe coded, and it is still waiting for the bill to come due.

If you are building something your business will actually run on and you want it owned properly from the start, that is the work our team does every day, AI and all. The tools got faster. The accountability is still ours to carry, and we would rather carry it up front than hand you a warranty nobody is standing behind.