The hard part of software is not writing it.

The hard parts are two fold: first, generalizing it, and second, maintaining it.

Generalizing it requires bombarding the system with disconfirming evidence.

And then tweaking the code to be resilient to the disconfirming evidence.

Software in use in the real world is naturally getting bombarded with disconfirming evidence all of the time.

But be careful: if the disconfirming evidence is powerful enough, it could kill you or the software.

Scary!

Programmers also develop an ability to bombard the code with disconfirming evidence in their heads.

Imagining the kinds of assumptions that could be violated at runtime and adding in defensive checks.

Disconfirming evidence hurts! Most people don't have the patience or pain tolerance to bombard their things with disconfirming evidence.

Maintaining software is the other expensive part.

When a family member says "can you make me a quick app?" The reason we shy away from it is not creating it, it's the ongoing working relationship and responsibility.

But what if the cost of creating software got so low that it was more often cheaper to regenerate than reuse?

Apps that will only be used by one user, or one time, don't have to be robust.

They can be cheap and jury rigged.

If you have a small enough audience (one person, one time) then the bar for "good enough" drops to the floor.

LLMs can write crappy small software on the cheap.