The loudest argument in AI development right now is whether vibe coding counts as real engineering. It does not. The critics are right — and the conclusion they draw from it is wrong.
"Not engineering" is not an insult. It is a category. Vibe coding — building software by describing what you want to an AI and steering the output — is a different job from production software engineering. The mistake is treating the difference as a verdict instead of a map.
The claim: the critics are right, and it changes nothing
Vibe coding is not software engineering, and that is exactly why it is a job worth hiring for.
The backlash assumes there are two outcomes: you are an engineer, or you are a fraud shipping slop. There is a third one the argument keeps missing. You are a builder who uses AI to ship working products faster than a traditional product process could — and the durable skill is knowing what to build and when it is good enough, not typing the code.
That third profile has a name on this board. It is Build Products with AI work, and the 30-day fight over vibe coding is the clearest evidence yet that the market is splitting it off from engineering.
What the vibe-coding backlash actually says
The case against vibe coding got sharp and specific this month, from people who build for a living.
Wes McKinney — the creator of pandas, one of the most-used tools in data work — laid out the distinction in a piece titled Vibe Coding Is Dangerous, Agentic Engineering Isn't. His point is not "AI bad." It is that accepting AI output without review is the dangerous part, and that disciplined, reviewed AI use is a separate practice. The danger is the lack of judgment, not the tool.
Brian Jenney made it concrete in a widely-watched video, Vibe Coding Hell: A Cautionary Tale. He joined an AI-first startup and watched a good team get ground down by one idea: that AI meant you could skip the thinking and that speed was the only metric. His summary of the culture — "half the people, twice the work" — is the failure mode the critics are right to name.
And the developer essay Vibe Coding Is Not Engineering landed on the front page of Hacker News with 71 comments arguing the title. The thread did not really disagree. It mostly argued about what to do with the fact.
Why "not engineering" is a category, not a verdict
The backlash and the believers are arguing past each other because they are grading two different jobs on one scale.
A builder on r/SaaS put the believers' case plainly in a thread asking why people treat vibe coding as a bad thing: "Software engineering has always been about using tools to move faster. Nobody gets extra points for suffering through boilerplate or spending 3 hours debugging something AI could've helped identify in 30 seconds." That is true — for shipping a product.
The critics are also true — for owning a system. Production engineering is graded on what happens after launch: correctness under load, security, maintenance, the subtle failure that shows up in month three. Vibe coding is graded on whether the thing works and solves the problem now.
These are different success conditions. One optimizes for the right thing shipping. The other optimizes for the system staying correct. Calling a builder a bad engineer is like calling a screenwriter a bad novelist. The judgment is true and useless.
What AI changed is who can sit in the builder seat. A no-code MVP, an internal dashboard, a client portal, a directory, a landing-page system — these used to require an engineer or a long product cycle. Now a fluent operator with Cursor, Claude Code, Lovable, or Bolt can ship a working version in days. The product does not need AI features. The defining trait is that AI is part of the building method.
The line that separates this from the pirate seat of bimodal engineering is thin. A builder who ships a product fast and a pirate engineer who decides what to build are close cousins. The difference is depth of code ownership, and the market is increasingly willing to pay for the shipping without demanding the engineering.
Where the line between building and engineering sits
You can tell which job a role is really asking for by what it makes you accountable for after launch.
If the role hands you a product surface, asks you to ship working versions fast, and judges you on whether users got value — that is builder work. AI fluency carries it. Light scripting, APIs, and a willingness to read the code you ship are enough.
If the role makes you accountable for the system staying correct under production traffic — security, scaling, on-call, the codebase other people build on — that is engineering. AI helps, but the bar is software depth, and this board does not index on it.
The trap is the listing that wants builder speed and engineering accountability for one salary. Read the responsibilities, not the title. "Ship fast with AI tools" and "own our production reliability" in the same job is two roles wearing one headcount.
- Does it name a product surface to ship and judge you on user value? Build Products with AI work. AI fluency carries it.
- Does it list Cursor, Lovable, Bolt, v0, Replit, or no-code tools as the method, with light coding as the bar? Builder seat.
- Does it make you accountable for production reliability, security, scaling, or on-call? Engineering. Different bar, different board.
- Does it want demo speed and system ownership for one salary? Two jobs. Read the responsibilities before you spend a screen on it.
What to build before you call yourself a builder
The vibe-coding backlash handed Build Products with AI candidates a free filter. Most people who say "I built an app with AI" cannot show judgment. You can.
Ship one real product and document the judgment, not the prompts. Pick a narrow tool you actually use — a tracker, a directory, an internal dashboard, a client intake form. Build it with an AI coding tool. Then write a one-page teardown that answers the questions the critics raise.
Name what the product does and who uses it. Show one thing you chose not to build and why. Name where you reviewed the AI's output and caught something — a security gap, a wrong assumption, a broken edge case. Show one failure you hit in week two and how you fixed it. Link the live thing.
That teardown is the artifact. It answers the only real question a hiring manager has after the slop discourse: can you tell the difference between shipped and finished? Publish it on your own domain, not a course platform, and put the link above your résumé.
The takeaway
The critics won the argument and missed the job. Vibe coding is not engineering — it is the building half of the work, broken off and handed to anyone fluent enough to steer the tools. Stop trying to pass the engineering test. Show you can ship the right thing and know when it is good enough. That is a different job, and it is hiring.