Deciding what to build

These days it’s normal to ask an AI for an entire app. You describe what you want, wait a few minutes, and there it is: a form, a database, even a decent design. Five years ago that took weeks.

So, is the job done? Not exactly.

Two kinds of complexity

In 1986, Fred Brooks published an essay that people still quote almost forty years later: No Silver Bullet. In it, he split software complexity into two kinds. Accidental complexity is the kind we create while building: the language, the tools, the configuration. Essential complexity comes with the problem itself: what the system has to do, for whom and under what conditions.

Every big leap since then (high-level languages, frameworks, the cloud) has chipped away at the accidental kind. AI is the biggest leap yet: writing code has become almost free. Essential complexity, though, is exactly where it was. Brooks said it back then: the hardest part of building a system is deciding precisely what to build.

Let’s look at three places where that complexity lives.

Context, the part nobody writes down

G. K. Chesterton told the story of a fence standing across a road. A reformer comes along, sees no use for it and wants it gone. A wiser person replies that this is exactly why it must stay: first, go and find out why it was put there.

Software is full of fences. An odd validation, an extra step in a process, a field that seems to serve no purpose. Often they are the scar of a problem that happened years ago and that nobody wrote down.

On 1 August 2012, Knight Capital, one of the largest traders on the US stock market, deployed new code to its order system. An old function, unused for years but still there, was triggered by mistake. In 45 minutes it sent more than 4 million orders, and the company lost more than 460 million dollars. Before the market opened, its own systems had sent 97 emails warning about the problem.

An AI sees the code you show it. The story behind each fence is something you have to go and find.

Edge cases, where the risk lives

A user taps “Pay” and the connection drops a second later. Did the payment go through? The app doesn’t know, so it tries again, and the customer ends up paying twice.

Payment systems solve this with a lovely idea: idempotency. Every operation travels with a unique key. If it arrives twice, the server recognises the second one and returns the result of the first, without charging again. Stripe, for example, does it with a header called Idempotency-Key.

The happy path (the user fills in the form, taps the button and everything works) is exactly what AI generates best. What turns a prototype into a product is everything else: the double tap, the dropped connection, the data that arrives half-complete. To ask for it, you first need to know it exists.

Decisions with no way back

In his 2015 letter to shareholders, Jeff Bezos described two kinds of decisions. Two-way doors are ones you can walk through and, if you don’t like what you see, walk back. One-way doors have no way back, and they deserve time.

Choosing the colour of a button is a two-way door. Deciding what personal data you keep, how you protect passwords or which part of a process runs without human review is not. Data you never stored can’t leak; data that has leaked can’t be recovered.

For the first kind, the speed of AI is a gift. For the second, it pays for someone to stop and think.

Three questions before you generate

AI is the best tool anyone building software has ever had, and it’s worth using to the full. What changes is where we put our attention: less on writing, more on understanding.

Before you hit “generate”, three questions go a long way: why is this the way it is? What happens if something fails halfway? Can this decision be undone? Whoever can answer them has already done the hardest part of the job.