Coding assistants produce working code quickly, and working is not the same as safe. The patterns they reproduce come from a vast body of existing code, much of which was written before anyone worried about the problem you are now solving. The result is familiar rather than novel: string-built queries, disabled certificate checks, weak randomness and credentials in examples that were never meant to reach production.
The patterns that keep appearing
Query construction is the most common. Ask for a database lookup with a user-supplied filter and you will often get string concatenation, because that pattern is everywhere in older examples. Certificate validation is another: sample code frequently disables verification to make a demonstration work, and that line survives into production. Then there is error handling that returns full exception detail, authorisation checks that verify a user is logged in without checking what they may access, and cryptographic choices that were reasonable a decade ago and are not now.
Volume is the real change
A team producing three times as much code is producing three times as much to review, and review capacity has not tripled. That maths decides your outcome more than the quality of any individual suggestion. Where review becomes a formality, the defects arrive at the same rate as ever with less scrutiny than before. The guidelines for secure AI system development published by the NCSC with CISA make the same argument about human oversight, which is that it must scale with the automation it supervises rather than lagging behind it.
“The reviews that catch these findings are the ones with a checklist rather than a general read. Ask three questions of every generated block: where does untrusted input enter, what does it authorise, and what does it log. Reviewers who apply that consistently catch far more than reviewers who read for style and correctness.”
Dependencies invented by a model
Assistants sometimes suggest packages that do not exist, and attackers have noticed. Publishing a package under a commonly hallucinated name is cheap, and a developer who installs the suggestion without checking runs whatever the package contains. Verify that every new dependency exists, is maintained and is what the assistant claims it is, and route installations through a private registry that only serves approved packages. A five second check beats an incident review. This is the same discipline that protects against typosquatting, applied to a new source of plausible-looking names.
Adjusting the controls that catch it
Automate what scales and keep humans for what does not. Static analysis in the pipeline catches injection patterns and disabled verification cheaply, and dependency scanning covers the package question. Write tests that assert authorisation behaviour rather than only functional behaviour, because that is where generated code is weakest and where scanners are least useful. Application security assessments then cover the logic that no tool understands, and an independent security testing company gives you a view that is not shaped by the same assumptions your team and its tools already share.
Frequently asked questions about generated code
These questions come up when a development team adopts an assistant.
Is generated code less secure than hand-written code?
Not inherently, and it is produced faster and reviewed less. The risk is a process one: more code, the same review capacity, and a tendency to trust output that reads confidently.
Should generated code be marked in the repository?
It helps for a while, mainly so you can measure defect rates and target reviews. As assistants become part of everyday work the distinction blurs, so invest in review and testing that applies to all code rather than a labelling scheme.
