The code next door is the template
Coding agents write a growing share of production software, and they are known to produce insecure code now and then. A paper posted to arXiv on 8 November asks a different question: what happens to a repository’s security over time when agents keep contributing to it.
The authors ran two experiments. In the first, agents were set 96 tasks that required implementing a new backend application in a repository where other applications already existed. In the second, they looked at repository-level code generation across 20 pairs of tasks in real C and C++ projects, each asking the agent to complete code critical to memory safety.
In both settings, the result went the same way. Insecure existing code led agents to write vulnerable code more often. In backend generation the effect was modest — insecure neighbours cut the share of implementations that were both correct and secure by 3.4% on average. In the C and C++ repository work it was not modest at all: the average gap between secure and insecure contexts reached 35.4%.
They could see what they were doing
The most uncomfortable number in the paper is not the gap but the explanation. When the agents were asked to account for their implementation choices, they attributed them to following another code site in the repository in 76.5% of cases. In 69.9% of cases they recognised the vulnerability they had just introduced.
That combination rules out the simplest reading. This is not a model that cannot tell secure code from insecure code; it is a model that can, and that treats local precedent as the stronger signal. The authors put it bluntly: agents use existing vulnerabilities as templates for new ones indiscriminately, turning each contribution into an opportunity to introduce more.
Prompting moves the dial without closing it
The study also tested the two obvious interventions. Prompting an agent to follow the existing code style increased how strongly it propagated vulnerabilities. Prompting it to be careful about security decreased propagation. Neither stopped it.
That matters for how teams actually configure these tools. “Match the surrounding style” is close to a default instruction in agent configuration files and contribution guides, and this paper says that instruction has a security cost. A security reminder in the prompt helps, but it is a mitigation rather than a fix.
Why the direction of travel is the point
A single insecure function has always been a liability. What the paper describes is a liability that reproduces. If an agent reads the repository to decide how to write, then an unfixed vulnerability is not just a hole in one place — it is a pattern available to be copied into every new contribution that touches similar code.
The authors draw the conclusion directly: as agents write a growing share of production code under decreasing human review, code bases can increasingly degrade in security unless vulnerabilities are thoroughly and continuously fixed. That reframes patching from a backlog item into a condition for everything the agent writes next.
The figures come from the authors’ own experiments and have not been independently reproduced. What would settle the matter is the same measurement on a real repository over months rather than on tasks, and whether the 35.4% gap in memory-critical C and C++ narrows as agents get better at reasoning about the code they are reading rather than imitating it.
