AI-built software still needs an engineer
AI changes how code is produced. It does not remove technical responsibility. Software generated quickly still needs someone who understands it and answers for it in production.
Paul BădărăuAI changes how code is produced. It does not remove technical responsibility. A working application built in a week with AI tools has the same obligations as any other software in production: it has to stay up, protect its data, survive its dependencies, and be changeable by someone who understands it. Those obligations do not disappear because the code was cheap to write.
What has actually changed
Producing code used to be the expensive part. Now it is often the cheap part. A founder with a clear idea can have a functioning product without hiring a developer, and many do. That is a real change and mostly a good one. More things get built, and more of them get built by the people who understand the problem.
What has not changed is everything that happens after the code exists. Deployment, monitoring, backups, security updates, access control, performance under load, data migrations, and the slow accumulation of changes that a real business demands. This work was never about typing speed. It is about understanding a system well enough to be responsible for it.
Where AI-built software gets into trouble
We have taken over enough AI-built systems to see the same problems repeat. None of them are about code quality in the usual sense.
Nobody can explain the system. The team can describe what they asked for. They cannot describe what they got. When something breaks, the debugging conversation starts from zero every time.
The design is local, not global. Each feature was generated to satisfy its own prompt. Together they form a system with three ways of doing the same thing, duplicated logic, and data that lives in more places than it should. Each piece is reasonable. The whole is hard to change.
Security is assumed. Authentication, authorization, input validation, secrets handling, and rate limiting are present in the form the tool produced by default, which may or may not be the form the business needs. Nobody checked, because nobody knew what to check.
Operations were never designed. There is a deployment because the hosting platform made one. There are no backups, no alerts, no staging environment, and no plan for the day the database fills up.
Dependencies are frozen. The generated project pinned whatever versions existed that week. A year later, several are unsupported, and upgrading means understanding code nobody has read.
This is not an argument against AI tools
We use them. They are good at producing a first version, at explaining unfamiliar code, and at removing the tedious parts of engineering. The failure mode is not using the tools. It is believing that the tools have taken on the responsibility along with the typing.
They have not. Responsibility for software in production belongs to a person or a company who understands the system, and AI tools do not currently hold that role. Someone has to.
What an engineer adds to AI-built software
Not rewriting it. Usually the right move is to keep what works and add what is missing.
- Understanding. Read the whole system and write down how it actually works, so the next change starts from knowledge.
- Coherence. Consolidate the three ways of doing one thing into one. Give the data one home.
- Safety. Review authentication and authorization by hand. Move secrets out of the code. Add validation where user input meets the database.
- Operations. Backups that are tested, monitoring that alerts a human, deployments that can be rolled back.
- A dependency plan. Upgrade what is unsupported, and schedule the rest.
After this, the AI tools become more useful, not less, because changes land in a system someone understands and can verify.
The position
Code has become cheap. Responsibility has not. Software that a business depends on needs an engineer who understands it and answers for it, however the code was produced. Getting that in place early costs far less than discovering its absence during an incident. The concrete criteria are in the production-readiness checklist for AI-generated applications; productionizing AI-generated software is how we help.