AI-built software still needs an engineer

AI 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

The same problems repeat across AI-built systems. 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.

Who takes responsibility after the prototype?

A tool does not take responsibility for operating the application. Agree who understands the system, checks proposed changes, receives alerts and can restore the data. Those responsibilities need named people and an agreed scope, however the first version was produced.

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.

Future changes can then be checked against a system the team understands.

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; our application repair service starts with the actual problems in the existing application.