The real difference between engineers and non-engineers “vibe coding”
Part 2 of a three-part series on AI, engineering, and what actually changed. Part 1 argued that the code was never the hard part – holding the architecture was.
The pitch is intoxicating and, up to a point, true: you no longer need to know how to program to build software. Describe what you want, and the agent builds it. Founders are shipping apps they couldn’t have written a line of. So the question naturally follows – is the distinction between an engineer and a non-engineer just gone now, at least for building things?
Not quite. And the cleanest way to see why is to take the fashionable term for this – vibe coding – completely literally.
The word gives the game away
Vibe coding. Coined by AI researcher Andrej Karpathy to describe a state where you ‘forget the code even exists’. The input is a vibe. A feeling, a gesture at what you want, a description of the shape of the thing. You hand that to the machine and it resolves the vibe into code. Most people using the phrase don’t stop to take it literally, but the moment you do, the whole distinction is right there in the name. Building to a vibe is not the same activity as building to a design, even when the tool in your hands is identical.
That’s the real fault line – not “engineer with an agent” versus “non-engineer with an agent,” but coding to a design versus coding to a vibe. An engineer using an agent all day long is, if they’re any good, still not vibe coding: they’re supplying the architecture, the constraints, the “no, not like that, and here’s why.” The vibe coder supplies the vibe and lets the model fill in everything underneath it – which is precisely everything that was ever hard.
So the term isn’t derogatory and it isn’t hype. Taken at face value, it’s an accurate description of what’s been handed to the machine: the feeling, not the structure. The machine gets the feeling. Someone still has to be responsible for the structure – and the question is only whether that someone is you or nobody.
When “nobody” holds the structure
When an engineer vibe-codes a throwaway prototype, “nobody holds the structure” is a fine trade – it’s throwaway, the stakes are zero, speed is the whole point. The danger isn’t vibe coding as an activity. It’s vibe coding as a foundation: software that nobody architected quietly becoming something people depend on.
Because the failure mode is rarely “the code doesn’t work.” AI-generated code often works fine – it compiles, it demos, it does the thing. The failure mode is everything the vibe didn’t specify and the builder didn’t know to check: the missing auth check that defaults to open, the unindexed query that works for ten rows but locks up at ten thousand, the swallowed error that hides a failing dependency, or the API key hardcoded into the source because it made the deployment step ‘just work.’ The model will happily produce all of them while passing every test the builder thought to ask for.
And underneath the individual bugs sits the structural absence: there is no version control tracking intent, no CI/CD pipeline verifying stability, no centralized observability logging runtime failures, and no rollback strategy when things go sideways. The engineer builds inside that scaffolding by default because they know code decays. The non-engineer builds entirely outside it – a standalone app or script on someone’s laptop, with nothing underneath to catch what goes wrong.
We’ve seen this movie: it was called shadow IT
If this pattern feels familiar, it should. Remember the VBA macros buried in a spreadsheet? The Access database one person built on their own machine? The “quick tool” that quietly became mission-critical, with no source control, no tests, no owner, and no one who understood it once its author left?
That’s shadow IT, and AI-assisted building by non-engineers is the same phenomenon with a faster engine bolted on. It lives outside the scaffolding, nobody can maintain it, its architecture was never chosen, and its risks were never reviewed – and it works fine right up until it’s load-bearing. We keep meeting this pattern, and we keep convincing ourselves this time is different because the new tool is exciting. It isn’t different. The generalised lesson still applies; we just refuse to see it.
There’s a revealing twist in the current version. Where AI does seem to let non-engineers ship real, durable software, look closely and you’ll usually find engineers one layer down – on the platform, holding the architecture on their behalf, building the systems that catch the failure modes the end user can’t see. The scaffolding didn’t disappear. It moved somewhere the person typing the vibe can no longer see it. Which is the whole point: someone is always holding the structure. The only question is whether they’re in the room.
So – can everyone build software now?
Everyone can now generate code. That’s real, and it’s genuinely valuable: a non-engineer can prototype something real in an afternoon, test an idea, build the throwaway tool that saves a hundred hours. Democratising that is a good thing.
But building software – the kind that’s maintainable, secure, and safe to depend on – still requires someone to hold the structure the vibe leaves out. AI hasn’t erased the line between engineers and non-engineers. It’s relocated it. The line used to fall at “can you make the computer do the thing?” Now it falls at “do you know what the machine left out, and whether it matters?” The first question, the machine answers for you. The second, it can’t – and that’s the one that was always the job.
Next in the series: if all this is true – if code is the easy part and the hard part is exactly what AI doesn’t touch – then why are boards being promised enormous productivity gains, and why haven’t they shown up?