The Line Between Vibe Coding and Real Engineering Is Disappearing — Here's Why That Matters

Simon Willison, creator of Django and one of the most respected voices in developer tooling, published something uncomfortable recently. In a post titled "Vibe coding and agentic engineering are getting closer than I'd like," he admitted that the line between casually prompting an AI to build something and professionally engineering software has started to blur. In his own work. On production code.

The post hit 785 points and 884 comments on Hacker News. It clearly struck a nerve.

And I think the implications for no-code builders are bigger than anyone in that thread acknowledged.

What did Willison actually say?

The short version: Willison used to draw a firm line. Vibe coding was for personal tools, throwaway projects, situations where bugs only hurt you. Agentic engineering was the professional version, where you bring 25 years of experience, review the AI's output, and maintain high standards for security, performance, and maintainability.

But he's noticed something happening in his own workflow. When Claude Code builds a JSON API endpoint with tests and documentation, he's not reviewing every line anymore. He knows it's going to be correct. He's started treating AI agents the way he'd treat another engineering team at a large company: as a semi-black box that produces reliable output, which he only digs into when something breaks.

His exact words: "The problem is that as the coding agents get more reliable, I'm not reviewing every line of code that they write anymore, even for my production level stuff."

He calls this the "normalization of deviance," and he's clearly uncomfortable with it. But he's doing it anyway. Because it works.

The spectrum is actually a circle

Willison originally framed vibe coding and agentic engineering as opposite ends of a spectrum. One is casual, the other professional. One ignores the code, the other scrutinises it.

But his own admission reveals something interesting: as AI gets more reliable, the professional end of that spectrum starts looking a lot like the casual end. You prompt, you get output, you verify it works, you ship. The difference is supposed to be that professionals review the code itself. But if you're not doing that anymore (because the output is consistently correct), what's actually different about your workflow?

The HN thread was split on this. One commenter argued that "good engineers won't continue to be good when vibe-coding, because the thing that made them good was the learning loop." Another pushed back: "The craft/learning just moves... I run more experiments and try out more different solutions than I ever could before, and that leads to better decisions."

I think the second commenter is closer to the truth, and I think they accidentally described what no-code builders have been doing for years.

This is what no-code has always been

Here's the thing that nobody in that 884-comment thread seemed to notice: no-code builders have been operating in exactly this mode since the beginning.

When you build an app in Bubble, or configure a workflow in Make.com, or set up a database in Stacker, you are trusting abstracted systems to produce working software. You don't inspect the generated code. You can't, usually. Instead, you specify what you want, verify it works, and iterate when it doesn't.

That's the same workflow Willison just described for his production engineering. Prompt, verify, ship.

The traditional developer response to no-code has always been some version of "but you don't understand what's happening underneath." It's the gatekeeping argument. You're not a real developer because you can't read the code your tool generates.

But now Simon Willison, a developer with 25 years of experience who literally created a web framework used by millions, is admitting he doesn't read the code his tool generates either. And he's shipping it to production.

So where does that leave the gatekeeping argument?

Dead, I think. Or at least mortally wounded.

The skill that actually matters now

If writing code by hand is no longer the defining activity of software engineering (and it increasingly isn't, even for senior engineers), then what is?

I'd argue it's this: knowing what you want the software to do, being able to verify it does that thing, and iterating effectively when it doesn't.

That's the same skill whether you're prompting Cursor, configuring a Stacker app, wiring up Make.com automations, or building in Bolt.new. The abstraction layer is different. The underlying competence is identical.

You need to understand your problem deeply. You need to be able to specify what "working" looks like. You need to test edge cases. You need to know when something is good enough to ship and when it needs more work. You need to make architectural decisions about how pieces fit together.

None of that requires writing code by hand. All of it requires thinking clearly about software.

One HN commenter put it well: "The point of an engineer is to ship a product or release that matches someone's vision of what should come next, and doesn't cause additional noticeable problems in the next quarter or three." That's a definition of engineering that includes no-code builders. Comfortably.

Where does this convergence end up?

Willison made another observation that I think is underappreciated. He said he can now "knock out a git repository with a hundred commits and a beautiful readme and comprehensive tests of every line of code in half an hour" and it looks identical to projects that had months of careful attention. He can't tell the difference. Even for his own projects.

If a 25-year veteran can't distinguish AI-generated code from hand-crafted code by looking at it, then code quality has become a property of the output, not the process. It doesn't matter how the code got written. It matters whether it works, whether it's maintainable, whether it handles edge cases.

This is where AI-native platforms have an interesting advantage. Tools that were built around AI from the start (rather than bolting AI onto an existing workflow) can optimise for exactly this: reliable output that you verify through use rather than through line-by-line review.

The conversation has moved on. "Is no-code real development?" was always a boring question, but now it's an irrelevant one. Even "real development" doesn't look like what it used to. The engineers are vibing. They just won't call it that yet.

The next time someone tells you that building with no-code tools isn't "real" engineering, you can point them to Simon Willison's blog. One of the most respected developers alive just admitted his production workflow looks increasingly like what no-code builders have been doing all along: trusting automated systems, verifying outputs, shipping what works.

The only remaining difference is vocabulary. And vocabulary was never a good reason to gatekeep.