Simon Willison has spent the past year arguing that the responsible way to use AI for coding is to stay deeply involved in every line — review it, understand it, test it. He even coined a term for it: vibe engineering, published in October 2025 on his blog. This month, he vibe coded two full SwiftUI applications anyway.
The receipts are posted on GitHub. Bandwidther, an app showing network bandwidth by process, comes in at 1,063 lines. Gpuer, which tracks GPU activity, is 880 lines. Both were built using Claude Opus 4.6 and GPT-5.4. Both are real apps that do real things on a 128GB M5 MacBook Pro. And in the README for each one, Willison writes exactly what you'd expect him to write if he were being honest: "I do not have deep knowledge of macOS networking or SwiftUI such that I can confidently evaluate the end result."
That sentence is the exhibit. The man who defined vibe engineering as the antidote to vibe coding just shipped two apps he can't verify, documented every prompt he used, and pointed at the gaps himself. It's the most Simon Willison thing Simon Willison has ever done.
The full prompt transcripts are live on his blog, hosted on gisthost.github.io. He walked readers through the process on March 27, 2026. The Gpuer memory bug is where the story gets interesting. The app was reporting that just 5GB of memory was available on a 128GB machine — a figure that was obviously wrong. Willison caught it, traced the mistake to a macOS API call returning a value in the wrong units, opened a GitHub commit to fix it, and moved on. He found his own bug. He just couldn't have caught it without actually running the code and noticing the number was absurd.
That gets at the thing vibe coding advocates actually mean when they say "just build." The point isn't that you should ship code you don't understand. It's that the loop — generate, run, notice something wrong, fix — is faster and more educational than the alternative of reading documentation until you feel qualified. Willison knows this. He also knows he genuinely cannot evaluate whether the SwiftUI networking code is correct in ways that would matter in production. He shipped it anyway.
The deeper tension is one Willison has been honest about for months. His definition of vibe coding is blunt: if an LLM wrote every line of your code and you reviewed, tested, and understood all of it, that's not vibe coding — that's just using an LLM as a typing assistant. Vibe coding, as he originally described it, is the fast, loose, and irresponsible version: prompt, ship, move on. Vibe engineering is supposed to be what responsible engineers do instead.
Except Willison just spent several days vibe coding and learned a lot about macOS networking APIs in the process. The distinction between the two approaches is blurrier than the framing suggests, and he's now living that contradiction publicly.
He is also, it should be said, better positioned than most to do this. He has been writing about AI-assisted coding since Andrej Karpathy coined "vibe coding" in February 2025 — a term that went on to become Collins Dictionary's Word of the Year for 2025. He has published more than 80 vibe coding experiments. He knows what he's doing, even when he doesn't know what the code is doing.
What he built with Gpuer and Bandwidther are real tools. Willison uses them. The memory bug got fixed. The process got documented. Whether that constitutes vibe coding, vibe engineering, or just coding with better tools is a question that probably matters less than the fact that the person who drew the clearest line between responsible and irresponsible AI use just crossed it deliberately, published the results, and seems to feel fine about it.
The broader lesson, if there is one, is that the responsible-vs-irresponsible framing may be a false binary. The real distinction might just be: did you notice when something broke? Willison did. He fixed it and logged the fix. That's not a workflow guarantee. It's just good engineering hygiene — and it's available to anyone willing to look at what the machine actually shipped.
