Vibe coding is getting a bad name, and rightfully so. The idea behind it is that anyone can vibe their way through to a successful product. You describe what you want, accept whatever the AI writes, and keep going until it seems to work. Maybe some people can get there that way. From what I have seen go wrong with vibe coding, I wouldn’t bet on it.
The claim that usually comes with it worries me more. It says that if anyone can prompt their way to working software, we don’t need engineers or developers any more. I don’t think that is feasible. I think it is exceptionally dangerous. If you haven’t kept abreast of everything, and don’t understand everything that has been implemented, you are surely heading for a WTF moment when something goes wrong. And when it does, why are you surprised?
Where vibe coding is fine
For a demo, vibe coding can be good enough. If you want to show an idea to an investor, try out a screen layout, or build a throwaway tool for yourself, it is quick and the stakes are low. If it breaks, you throw it away, and hopefully there were no losses or ramifications along the way and nobody got hurt.
AI also seems to do mockups well: documentation, illustrations and even video. We made our new snapWONDERS Vaultify video with AI in a Sunday afternoon. It is good enough to convey an idea to others and gather feedback on a concept.
The trouble starts when the demo turns into the product. Real users bring real data, real accounts and real money. Now the code has to handle all the cases nobody prompted for: the bad input, two people doing the same thing at the same time, someone trying to break in.
Why replacing engineers with it is dangerous
AI writes code that looks right. It sounds just as confident when it is wrong as when it is right. Someone without the background to check it has no way to tell the difference. They see a working screen and assume the rest is fine.
The problems sit where they can’t see. A permission check that isn’t there. A database query that loads a whole table to find one row. A library added with a licence that doesn’t allow the way it is being used. Each of those has its own written rule on my project, because each one is easy to get wrong and expensive to find late. None of them shows up in a demo.
AI also doesn’t always choose the best algorithm or the right architecture. It doesn’t always understand how everything fits into the big picture, simply because it doesn’t have the full context, or doesn’t understand your idea yet. And, as I explain further down, it doesn’t have original ideas or human intuition.
I asked an AI if I was vibe coding
Out of curiosity, I described how I work to an AI agent and asked if it counted as vibe coding. It said no, then spent several paragraphs telling me how well I was doing.
So I asked it a harder question. If a business analyst is good at vibing with AI, can they replace an engineer? Again it said no. In its view, an AI-savvy BA can build impressive prototypes, internal tools and first-draft test cases, but hits a hard wall with production software. They can’t debug a failure when they don’t understand what is happening underneath, so they end up asking the AI to “fix it” and getting more patches on top. They can work safely inside the guardrails, but they can’t build or maintain them. And without an engineer enforcing a design, the AI builds each feature the fastest way for that one prompt, until the code base becomes a tangle. It summed up the result as a system that “works beautifully on day one, and collapses under its own weight by day one hundred.”
For whatever it’s worth, and if we can trust the AI’s output, even the AI doesn’t endorse the idea that engineers can be replaced by vibe coding.
That “if” matters. An AI assistant tends to agree with whoever is driving it. I described a careful process, so it praised a careful process. I asked a sceptical question, so I got a sceptical answer. Someone hoping to hear that engineers aren’t needed any more may well have been encouraged too. If the person at the keyboard can’t judge the output, nothing in the loop can.
What it looks like when a strong developer drives
AI is part of the snapWONDERS ecosystem as a powerful assistive tool. Where it helps, I don’t count that as vibe coding, because of what happens around it:
- The design comes first. Architecture gets decided and reviewed before any code is written. For the forensic scoring there is a design document that wins any disagreement with the code. If the two disagree, the code is the defect.
- The work comes in small pieces. Each change is small enough for me to read in one sitting, in its own copy of the code. I wrote about running many of these at once in One AI Agent Found a Bug. Three Others Needed to Know.
- Every change gets a real review. Nothing reaches the main branch until I have read it and approved it. Deploying to production is a separate decision after that.
- Tests decide, not confidence. There are hundreds of test files, and one of them fails the build if the code drifts from the design document. Why that check has to sit outside the conversation is in How a Corrected Rule Stays Corrected.
- Measure, measure and measure. “This way is faster” and “this way is better” get measured against real data, not argued. This is something AI does very well. It can run the measurement, crunch the results and report back quickly. Deciding what is worth measuring, and whether the result actually matters, is still my job.
- Mistakes become rules. When the AI gets something wrong in a new way, the correction goes into a short rule file that every session reads. There are dozens of them now.
- The documentation is kept up. A change that affects the database, the deploy or the API updates its documentation in the same commit, so the next person, or the next AI session, isn’t guessing.
Who writes the tests?
The AI agent ended with a good question: does the AI write the tests too, or do people write them so the check is independent?
AI helps write tests too. What they check is not up to the AI. They are written against the design document and the rules, and those are things I decided and reviewed. A test the AI writes to match its own idea of correct proves very little. A test written to match a document a person signed off on is a real check, whoever typed it.
Original ideas still come from people
There is another reason the lead matters. Last month I wrote about six months of running AI hard against my own forensic and steganography research, in I Kept Waiting for AI to Have an Original Idea. It Never Did. Every genuinely new direction started as a hunch of mine. The AI was very good at testing a hunch and building on it. It never came up with an original idea itself.
Other research points the same way. In 2024, Stanford researchers had more than 100 NLP experts blind-rate research ideas, some written by people and some by an AI. On paper, the AI ideas looked more original. In a 2025 follow-up, the same team had 43 experts actually carry the ideas out, and that advantage disappeared. The AI ideas’ scores fell further than the human ones on every measure, novelty included, and on many measures the human ideas came out ahead. An idea that only looks original until someone builds it isn’t much of an original idea.
A 2026 paper by Dhruv Trehan and Paras Chopra, “Why LLMs Aren’t Scientists Yet”, tried four fully automated research projects. Three of the four failed.
Vibe coding asks the AI to supply the original idea as well as the code. That is the part it is weakest at.
The era of lead-driven synthesis
Others have started calling this agentic engineering, a term Andrej Karpathy and Simon Willison have both used. I call it lead-driven synthesis, because the lead is the part that matters. The lead brings the original idea and sets the intent, the architecture and the standard. The AI assists, and does it very quickly. The lead reviews the result, and the tests, measurements and guardrails decide whether it stays.
In practice the AI works like a very fast junior developer who never gets tired and is sometimes confidently wrong. The lead’s job moves away from typing and towards design, review, and deciding what correct means. That is the same verification habit from AI-Assisted Development vs the Old Outsourcing Model: trust nothing until it has been checked, whoever or whatever wrote it.
This is a tool for technical leads and strong developers. It amplifies what you already know. If you know what good looks like, you get there much faster. If you don’t, you get to a bad result faster as well.
So no, I don’t think AI replaces engineers. It replaces a lot of typing. The original idea, and the judgement, still have to come from someone who knows what they are looking at. Vibe coding will keep its place for demos. For real products, I think we are entering the era of lead-driven synthesis development.
If you lead a development team, I’d like to hear how you are handling code review now that code arrives this fast.
Kenneth Springer is the founder of snapWONDERS, a digital forensic analysis platform for images and video. Every forensic check on the platform goes through the same discipline: a locked design, automated tests and a person’s review decide what ships. snapWONDERS forensic analysis — no account required.