Almost exactly two years ago, I wrote Don’t build it to explain why I habitually pushed people away from building software in the process of creating a business.

I made the case that software is typically only a part of the solution to some problem, and that it’s non-trivial to know whether it’s the hard or the easy part. Building software is expensive and time-consuming and very often your money and energy are better invested elsewhere.

Now the time and cost of software creation are trending rapidly towards zero. Should you still take the role of neo-luddite, cobbling together with Zapier and Google Forms what Claude Code could whip up in a couple of kilotokens and deploy to Vercel before you can stir your coffee?

Everything is theory building

The ultimate aim of all these activities is to build not just the system, but a deeper understanding of the system. So in most cases, the software “assets” of a nascent business did not ever have very high cost to recreate - the real value has always been the intangible knowledge that enables the creation of these systems.

You’re trying to understand your customer and what the product that serves them looks like. The software is just a representation of that understanding.

programming properly should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand. - Peter Naur

In this great democratisation of programming, the distinction between programming and <literally everything else> has blurred. You can substitute programming with “creation” above. Everything you are doing is theory building, so the only pertinent questions to ask are about the speed and quality with which you are building theory.

So how does the dynamic fundamentally change? Is being able to build product instantly and at zero cost going to make you better or worse understanding your customer?

The answer to that question depends on whether you match the amount that you’re building to how well you understand the problem.

If your implementation outpaces your theory building you can blindly build something that has a huge surface area, and completely confuse both yourself and your customer about what problem you’re trying to solve. Now you have N problems.

If your theory building matches your implementation, AI can instantly build a beautiful, slick, polished surface, maybe even the whole product. The gap between sound theory and functional reality is small, your customers are delighted.

Theory building is still hard

From the previous post:

  1. generally it’s hard to tell the difference between easy-but-tedious, hard, and impossible
  2. that a lot of the value of technical expertise is some sort of gut feeling as to which of these categories the various parts of a proposed system will fall into.

AI is amazing at “easy-but-tedious”, mediocre at “hard” and terrible at telling the difference.

The customer is describing holes. They need a drill. Focus on understanding, not building.

You still can’t outsource your understanding, and getting AI to build things that you don’t understand isn’t helping your customers. Everything is theory building.