The Builder-User Loop: Why the Best Software Will Be Built by People Who Can't Code

I keep catching myself doing something that shouldn't be possible. And every time it happens, I get this feeling like I'm cheating at something. But I can't figure out what the rules were.

Here's what I mean. I'm using my AI assistant, Atlas, to manage my emails. While I'm reading an email, I notice the threading is broken. In the same breath, in the same session, I fix it. Not "file a ticket" fix it. Not "tell a developer about it" fix it. I just... fix it. And then I keep reading emails. The thing I was using is now better, and I didn't even switch tabs.

That has literally never been possible before. Ever. In the entire history of software.

The Gap That Was Always There

Think about how software has always worked. Someone has a problem. They try to explain it to someone who can build things. That person interprets what they heard, builds something, ships it, and then everyone waits around to see if it's right. It never is. So you do it again. And again. And again.

"Agile" was supposed to fix this. Two-week sprints. Didn't fix it. "Dogfooding" was supposed to fix this. Build it, then use it, then feed back. Still didn't fix it. Better, sure. But the building and the using were still separate things that happened at separate times.

Nobody questioned that. It was just how it worked. Of course building and using are different activities. That's like questioning gravity.

Except it turns out that wasn't a law of physics. It was just a limitation.

I Am Not a Developer

Let me be clear about this because it matters for the rest of what I'm about to say. I can't code. Not really. I run a lead gen agency, I'm the CMO of Thingiverse, I have two kids under three. I build products with AI tools like Claude Code, but if you put a blank code editor in front of me and walked away, nothing useful would happen.

And yet. I'm building an AI assistant. I'm building a visual knowledge graph. I'm building a content engine. I'm building all of them at the same time. And here's the part that makes me feel like I'm losing my mind: I'm using all of them while I build them.

I'm building Atlas while Atlas helps me build Atlas. I'm building Brain Space while Brain Space maps my thinking about Brain Space. The tool is helping construct itself. I don't fully know what to do with that information yet.

The Feedback Loop Collapsed to Zero

Everyone is writing the "non-coders can build software now" article. That's true but it's the boring take. The interesting thing is what happens after that.

When the person with the problem is also the person building the solution, and they're doing both at the same time, you get something that has no precedent. The feedback loop doesn't just get shorter. It disappears. There's no loop at all. There's just... doing.

Here's what the old cycle looked like:

1. Build something based on assumptions
2. Ship it to users
3. Wait for feedback (days, weeks, months)
4. Interpret the feedback through layers of abstraction
5. Prioritise against other work
6. Build the fix
7. Ship again
8. Hope you got it right this time

Eight steps. Weeks at best. Months typically. And every single step introduces noise. The user can't articulate the problem perfectly. The PM hears something slightly different. The developer builds what they understood, which isn't what was meant. It's a game of telephone where the stakes are someone's entire product.

The builder-user loop replaces all eight steps with one: fix it while you're looking at it. That's it. That's the whole thing. And it changes everything.

Why Not Knowing How Code Works Is Actually the Point

Here's the counterintuitive part. Not being a developer might actually make you better at this.

Developers think in abstractions. They think about architecture, patterns, scalability, code quality. All important stuff. But when a developer uses their own product, they're often thinking about implementation details rather than experience. They see the code behind the interface. They tolerate rough edges because they understand why they exist.

Non-technical builders don't have that filter. When something sucks, it just sucks. There's no "well, the reason this is slow is because of the N+1 query problem." There's just: this is slow and I hate it. Fix it.

That raw, unfiltered experience creates better products. You feel friction that a developer might rationalise away. And now you can act on that friction instantly. You don't need to understand why something is broken at a technical level. You just need to describe what should happen instead. The AI handles the translation.

You know exactly what's wrong. You just couldn't fix it before. Now you can.

This Is Bigger Than People Realise

I think the best products of the next ten years will be built by people who deeply understand the problem because they live inside it every day. Not by developers who were hired to solve someone else's problem from a spec.

Doctors building their own clinical tools because they're sick of software that clearly wasn't built by someone who's ever examined a patient. Lawyers building their own contract systems because they're tired of explaining what "material adverse change" means to a product manager. Teachers building their own platforms because no edtech company has ever actually taught a class of thirty eight-year-olds.

All of them iterating in real time. Experiencing the problem and solving it in the same moment. Not writing specs. Not filing tickets. Not waiting.

The wall between builder and user is gone. I keep saying that to people and they nod politely like I'm exaggerating. I'm not exaggerating. I'm barely keeping up with what this means.

The people who figure this out first are going to build things that make traditional software development look like it's moving in slow motion. Because it is. It always was. We just couldn't see it until the wall came down.