Stop Selling Code — Start Selling Understanding in the AI Era

I have had a software development studio for years. For many years, it had perfect sense: I was selling teams, hours and delivery. Clients understood it, I understood it, and everybody knew exactly what was being delivered in exchange for money.

And then, somehow, in the last year or so, I started to notice that the thing that I was selling wasn’t becoming harder to deliver; it was becoming easier to deliver elsewhere. Not in some abstract “future of work” kind of way that we all like to discuss from stage at conferences, but in a very real, very tangible way.

One week, another AI tool comes out, then another tool and I just assumed that it would slow down at some point. It didn’t.

What surprised me was that I wasn’t terrified by it. If anything, it made something clearer: my work was never really about code. Code was the visible part — the part you could scope, deliver and charge for.

But whether a product actually worked had much less to do with code itself than with how well you understood the problem behind it. In the end, code is just where your understanding of reality (or your misunderstanding of it) shows up.

We’re about to be flooded with software

I keep thinking about the early days of YouTube. Before that, making video — or becoming a public voice in any serious way — usually required budget, equipment and a team. Then, suddenly, the tools became available to almost everyone. A lot of people in traditional media were afraid this would destroy the value of good work — but it didn’t. It simply made bad content easier to spot and good content easier to recognize.

Software feels very similar right now. More and more people can build, including many who would never have seen themselves as builders before. Yes, we’ll be flooded with products within just a few years. But that doesn’t mean we’ll be flooded with good products. The thoughtful, well-designed, genuinely useful ones will still stand out — and in some ways, they may become even easier to find.

Easy to build doesn’t mean easy to get right

What I resist is the idea that as a problem becomes easier to build, so does a good solution to that problem. I think the opposite is more likely true. I’ve worked on enough products, enough industries, enough businesses, to see this pattern repeat over and over again: a system, perfectly logical until it meets the real-world user, begins to fall apart.

The user does not behave as the user persona document predicted they would behave. The edge case, thought to be a small percentage of the population, turns out to be the majority. The assumption, thought to be safe, fails in all ways at once. This is not necessarily a bad plan; this is just what happens when an idea meets the real world.

This has not changed with the advent of AI. What has changed, I think, is the notion of something being too technically difficult to test, to build. Once that’s cleared away, the real problems are immediately apparent.

The new advantage is your relationship with reality

That’s why, for me, this moment is fundamentally about data. Especially in an AI era — and even more in a multi-agent era — the key question is no longer who can write code fastest. The key question is who is in the best relationship with reality.

What matters most is not code by itself, but the underlying structure of understanding behind it: what problem is being solved, what is known, what is assumed, and how it’s designed to learn.

That’s the logic behind my Data First Development approach. It’s not just a way of thinking about product thinking; it’s a response to the world we’re about to enter.

The three boxes that matter before you build anything

Before you design a product, think in three boxes. Start with the actual problem — not the business goal layered on top of it.

The second box contains all we actually know: behavior we’ve seen, constraints we’ve documented, signals we’ve identified from reality itself — things that have actually happened. The third box contains all we assume: inference, projection, belief without evidence, blind spots we can’t yet identify, and information we’re still missing.

A well-built product has two tasks at once: it must act intelligently on all we already know, but it must also generate new information to move assumptions into knowledge. If we’re only doing the first, we’re just executing on our own story. We’re not really learning. The learning happens in the transition.

AI makes iteration cheaper — not thinking optional

AI definitely plays a role in that loop because it can speed up the process. You can test faster, generate faster and learn faster. The cost of being wrong is reduced because it’s less expensive to correct yourself. But it doesn’t change the fact that you need to pick the right problem, that you need to understand what you still do not know.

In fact, it may heighten the importance of that. I do not think that can be outsourced, and I’m not sure it can be made optional.

I think another change is not getting as much attention as it deserves, and that is that the software itself is evolving in terms of how it’s presented to the user. For a while, we were very focused on the user interface as the main container of value — screens, clicks, and flows.

And that’s no longer as true as it used to be. Now, what’s becoming much more important is how the software works as part of the larger system — how it works with information, actions, other tools and actors, how it works when some of the work is being done without any human ever clicking on the screen. In that world, the user interface is just part of the picture; the underlying behavior is much more important.

What wins in the AI era

AI is also destroying value in parts of the old software business model. The market for what I was selling has gotten harder. The winners will not be those who produce the most code, but those who define the problem clearly, separate knowledge from assumption, and build systems that learn from reality. In a way, this has always been the work. The difference now is that we can no longer pretend otherwise.

I have had a software development studio for years. For many years, it had perfect sense: I was selling teams, hours and delivery. Clients understood it, I understood it, and everybody knew exactly what was being delivered in exchange for money.

And then, somehow, in the last year or so, I started to notice that the thing that I was selling wasn’t becoming harder to deliver; it was becoming easier to deliver elsewhere. Not in some abstract “future of work” kind of way that we all like to discuss from stage at conferences, but in a very real, very tangible way.

One week, another AI tool comes out, then another tool and I just assumed that it would slow down at some point. It didn’t.