What your AI-built software needs before it goes live
An AI coding tool can produce a working application in an afternoon. That is the easy part now. The hard question is what happens on day thirty, when a security update is due, a customer reports a fault and the person who built it has moved on.
If the answer is "open the folder and hope", the business is carrying a risk it has probably not priced in.
This post is for the owner or founder who has been handed, or is about to be handed, AI-written software. It sets out the minimum checks that make it safe to run, change and hand over. You do not need to understand the technology to ask for them.
Why AI-written software without checks is a risk
AI-written code has a particular weakness. It works on the day it was written, for the situations the AI thought of. Nothing makes sure it keeps working.
Three things make that dangerous:
- No tests means no memory. The next change, by a person or an AI, can quietly break the last one. Nobody finds out until a customer does.
- No test version means your customers are the testers. Every release is a live experiment on the business.
- No way back means every mistake stays until someone fixes it. At two in the morning, with an order stuck, that is not a plan.
These risks have always existed. AI adds speed: it makes it cheap to produce a lot of unchecked code very quickly, and more code means more places for things to go wrong. The 2024 DORA report, a large study of software teams, found AI use was linked to less stable software. It recommends exactly the basics below.
The seven checks to ask for
You do not need a large team for this. You need seven habits, written into the project itself so they run every time, whoever is making the change.
1. Every change passes automatic checks before it is accepted. Style, errors, tests and a full trial build run on every change. If any fail, the change is refused. This is what engineers call continuous integration.
2. Tests are written from the plan, before the code. The test states what the plan asked for. When a later change breaks it, you know exactly which requirement was affected.
3. Every release is labelled. Each version of the software is saved and labelled, so you always know exactly what is running.
4. A test version comes before the live one. New releases go to a private test version first. You check it against the plan. Only then does it go live.
5. Releases check themselves. A release only takes over once the new version reports that it is healthy. If it does not, the previous version keeps running.
6. Going back is quick. Because every release is labelled, going back means putting the previous one back, with no rebuild and no guesswork.
7. Passwords and keys stay out of the code. They are supplied when the software runs, never saved in the code itself. The ready-made components it uses are checked for known security weaknesses on every change.
What it runs on
None of this needs expensive equipment. A private place to store the code, a service that runs the automatic checks, and a secure server are enough for most business software. Smartible sets all of this up in your own cloud account or on your own servers, so you control it.
Easy to change after launch
These checks are what make support affordable. When you ask for a change three months after launch, the same routine applies: write down the change, update the plan, write the test, make the change, watch the checks pass, review the test version, release. It is the same routine that built the software in the first place.
It also means you are not tied to whoever built it. Software that comes with its tests, its checks and clear running notes can be picked up by any competent engineer.
What to do with this
- Ask your developer to show you the automatic checks every change must pass.
- Ask to see the test version before anything reaches staff or customers.
- Ask how you would go back to yesterday's version, and see it done once.
- Confirm passwords and keys are kept out of the code.
- Make sure the code, the checks and the running notes are handed over to you.
If you are starting a build, the release checks belong in the plan, not in a later phase. A Specification Sprint writes them into the plan and prices them before any code is written.