Why we do not assemble components
Ten years ago, if you wanted an app, you paid someone to write code. Today a machine writes the code, and fast. That is a real change and there is no point pretending otherwise.
But what got cheap is building, not deciding.
What the machine does well
The model has seen millions of lines of code and knows what the average solution to your problem looks like. That is useful. For a standard form, a standard screen or a standard integration, the average is often enough, and you get it in a second.
Where the average is not enough
The trouble starts when a decision has consequences that only show up a year later:
- Which part of the system is allowed to know about which other part
- What gets stored in the database and what gets computed on the spot
- Where the line is between what the machine does and what a human must do
- Which dependency you may bring in, and which one will hold you hostage
None of that is a question of syntax. These are questions of judgement, and the wrong answer does not break immediately — it breaks once the change is already expensive.
Everyone is born an original, but many die photocopies.
The sentence is Carlo Acutis's, a teenager who taught himself to program and built websites for communities that could not afford them. He did not write it about software, but it is hard to find a more precise description of what is happening to software now.
What that means for you as the client
When you choose who to work with, it no longer makes sense to ask how fast someone writes code. Ask something else:
- Why they chose that particular architecture, and what they weighed it against
- What happens if you change your mind about a key feature in six months
- Who will understand the system when that person leaves
If there is no answer to that, you will get a photocopy. It will work — until you need something the average did not foresee.