Is AI-generated code safe to ship? What to check, and what a second AI catches
Originally published on the SPOE blog. AI-written code usually works. Whether it is safe is a different question, and the answer depends less on the model than on what checks the code before it reaches your users. The
Originally published on the SPOE blog.
AI-written code usually works. Whether it is safe is a different question, and the answer depends less on the model than on what checks the code before it reaches your users.
The good news: the mistakes are predictable. The same handful turn up again and again, and most can be caught without you reading a line of code.
The mistakes that matter
A secret in the code. An API key, a database password or a payment key pasted straight into a file. Once that file is in a public repository or shipped to a browser, anyone can use the key. This is the most common and the most expensive.
Database queries built from text. When the code glues what a user typed into a database query instead of passing it separately, a crafted input can read or delete data that is not theirs. The fix is boring and standard: parameterised queries.
Routes that change data without asking who you are. A page or endpoint that deletes a record or changes a price, open to anyone who finds the address.
Raw HTML from users. Showing something a visitor typed as HTML lets them run their own script in other people's browsers.
Cookies accepted from any site. A loose setting that lets another website act as your signed-in user.
Pages search engines cannot read. Not a security hole, but an AI-built site often ships without a title, a description or a sitemap, and then nobody finds it.
Why the same AI should not check its own work
Ask the model that wrote the code whether it is safe, and it tends to agree with itself: it shares the blind spots that produced the mistake. A reviewer from a different model family reads the change fresh, with different habits and different training. It is the same reason a writer does not proofread their own book.
What SPOE does
A second AI reviews every change. Every change the builder makes is reviewed by a model from a different family before it reaches your project. If the review finds something serious, the change waits for you in a side-by-side diff instead of going in, and one click sends the findings back to be fixed. A review that times out or fails is never treated as a pass.
Check before you ship, free. The Check button runs a scan with no AI and no credits: keys in the code, SQL built from text, raw HTML, cookies accepted from any site, routes that change data without sign-in, and what search engines will miss. A critical finding holds a publish until you decide, and that decision is recorded. The same check ships inside every export as check.mjs, so you can run it on your own machine, or in your own CI, for as long as the app lives.
Secrets stay out of the code. Keys you add go into the project's vault, sealed, and reach your app's server as environment variables. The builder is told the names of your keys, never their values.
Every change is a version. If something slips through, you roll back in one click.
What is still your job
No checker finds everything. Before you put real customers' data in an app, built by AI or by people:
- Click through every page signed out, and try to reach what you should not.
- Try the forms with nonsense, very long text and odd characters.
- Look at what the Check finds and fix the critical ones.
- Keep keys in the vault, never in a message to the builder.
- Have someone technical read the parts that handle money or personal data.
AI makes building fast. Checks are what make it safe to ship. Start free and run the Check on your first build, or read how SPOE compares with other builders.
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.