Struggling to make software work is a really specific type of experience, and you either get that mental place or you don’t. As an objectively poor developer, I avoid writing code whenever possible, which is why I spend a lot of time using stuff like Bubble. But I’m not vibe-coding — every time my application doesn’t do what it was supposed to, it’s because of me. And when I actually figure out what’s wrong, and change it, it stays that way and I move onto something else.

I think one of the reasons I’ve found LLM-based vibe-coding so unsatisfying has been the fact that it fundamentally alters this experience. If you’re purely looking to make a computer do something, and you’re not very good at that (I qualify for that designation), I get that just asking for it to happen a couple times may be a faster and ultimately better way to make the computer do it.

(It’s also entirely possible that it’s not faster and/or not better — this is a different discussion, but an important one for another time.)

But… it’s absolutely not flexing the same muscles as building with a deterministic system. It’s not using them less, it’s actually not using them at all. If you’ve never flexed them, you might not notice. You might have a long back and forth with a chatbot, iterating on some idea, and think you’ve entered the sort of “flow state” your developer friends have talked about. You have not. Seriously, I am telling you, you have totally not done this. You may be in some other sort of state, and maybe that state has value, or maybe it’s the future of work, or maybe you’re just a guy hitting “refresh” and hoping for a different outcome, but you are not doing the thing.

Again, it’s not about code. It’s about systems, learning them, altering them, and ultimately mastering them. You interact with a lot of systems with code, and I suck at that, and I know that I suck at it because I’ve done it more than I probably should have, and I’ve been evaluated and coached and critiqued (heavily) by people who are really good at it. For me, failure was common, but success did happen sometimes and it’s an unforgettable feeling. When I vibe-code decent stuff, it doesn’t feel anything like that.

The Agency Model

The best thing I can compare this sort of thing to is working with an agency. If you’ve never been able to hire one, suddenly having Claude or whatever at your beck and call is probably thrilling. And sure, you can tell a chatbot to interact with you a certain way, to “partner” with you, or pretend you’re pair programming even if you don’t know how to program, and it will indulge you. But guess what? So will a lot of agencies. You’re the customer, dummy! They’ll tell you whatever you want if you let them.

I’ve had more or less involved roles with different agencies. I’ve sat there and barked orders, I’ve been hands off, and I’ve tried to save money by doing pieces of the work myself. It doesn’t matter — asking for stuff is different than figuring out stuff. Really building software is not asking for things; it’s doing things and creating iron-clad decision trees for things and tweaking things so that they must do what you want. No one is coming to help you. No one is going to just make it work, especially not your computer.

It doesn’t have to be about building apps, either. People configure complex IT or DevOps systems, CRMs, automations, and other stuff this way, and a lot of those people get the same runner’s high when they master these systems and bend them to their will.

I can’t predict the future. But I can’t shake the feeling that regardless of how anyone feels about any given tool, moving these experiences, these journeys, to non-deterministic finger crossing is going to create more problems than it solves. I think there’s a reason many of the people most excited about eliminating the journey are people who aren’t on it very often.