AI code has sat at 55% secure for two years. Waiting for a better model is not a plan.

The two headline numbers are one number. Forty-five percent of outputs carrying a known weakness and a pass rate of about 55% are the same measurement read from opposite ends ^[1]. So the quantity worth arguing about is not the level, it is the slope, and Veracode puts that at roughly zero percentage points a year across two years of model releases ^[5][4].

The language spread is where an actual decision sits. Java passed 29% of the time, which means about 71% of Java outputs carried a known weakness, against 38% for Python at its 62% pass rate: close to 1.9 times the defect density from the same models on the same style of task ^[7][2]. One caution on the arithmetic. The four published language figures average 51.5%, which is below the 55% aggregate ^[6], so the headline is not a flat mean of the four and the per-language task mix is the thing to ask about before anyone builds policy on the Java figure alone.

Park's mechanism for this is that the models are not reasoning about security, they are reproducing the posture of whatever they saw most of: SQL injection has been the teaching example since roughly 2005 and parameterised queries are everywhere in the corpus, while log injection is a real weakness that never became a lesson ^[11]. If that is right, the lever is corpus composition, which nobody downstream of a lab controls. It also fits what the report found at the top end. The reasoning-tuned models did better at 70 to 72% ^[6], which still leaves close to three outputs in ten carrying a known weakness ^[3].

That pushes the load onto review, and review is where the Stanford result bites. Neil Perry and colleagues found participants with an AI assistant, codex-davinci-002 in that study, wrote significantly less secure code ^[8], and were more likely to believe they had written secure code ^[9]. The same study found the mitigation: participants who distrusted the assistant and rewrote their prompts produced fewer vulnerabilities ^[10]. Skepticism is a personal habit, not a control you can install across a team on a deadline.

The tooling argument follows from timing rather than accuracy. SAST reads source at rest, DAST hits a running application, IAST instruments runtime, and all three assume the code already exists ^[13]. In a semi-autonomous agent turn, a call like subprocess.run(user_input, shell=True) can be written, saved and executed before any gate runs, with the pre-commit hook firing afterwards if it fires at all ^[14].

Two things to hold at arm's length. Park is the creator of Cencurity, an open-source security gateway for LLM coding agents ^[15], so the conclusion that control belongs inside the loop is also his product thesis. And his four-surface framing, prompt injection, unsafe tool calls, outbound data leakage, and actions with no record, is his enumeration rather than Veracode's measurement ^[12]. The claim that code scanning addresses one surface in four ^[5] is a coverage argument, not a measured 25%. The 45% is measured ^[4]; the other 75% of the problem is asserted.