Tools that generate code from a description have changed who can produce a working demo. That is a real and welcome shift. It has also created a widespread impression that building software is now mostly a matter of asking for it.
A demo and a product are different things. The difference is almost entirely engineering, and most of it is invisible when everything is going well.
What sits behind software that lasts
- Knowing what to build. Requirements are usually incomplete or contradictory. Someone has to find the conflicts and make decisions, with the people who will live with them.
- Structure. How the pieces fit together decides whether the fiftieth change is as cheap as the fifth. Code that works today but cannot be changed safely is a liability.
- Data. Schemas, migrations, integrity rules, backups and what happens when two people edit the same record. Data outlives every version of the application.
- Security. Authentication, access control, input handling, secrets, logging and a plan for the day something goes wrong. Generated code can look secure and still not be.
- Compliance. POPIA, retention, audit trails, consent, and standards such as ISO 9001 or ISO 27001 are obligations, not features, and they have to be designed in.
- Testing and release. Automated tests, staging environments, controlled deployment and a way to roll back.
- Operation. Monitoring, alerting, patching, capacity, and someone who answers when it fails at night.
- Accountability. When something goes wrong, a named company is responsible. A tool is not.
Our view
We use AI assistance in our own work, and it makes some tasks faster. What it does not change is that every one of the items above still has to be decided, built, verified and maintained by people who are answerable for the result.
The useful question to ask of any software, however it was produced, is not “does it run?” but “who is responsible for it in three years, and how do they know it is still correct?”