There's a comfortable story about AI coding agents that goes something like this: give the model good context, let it iterate, add more agents for more coverage, and the system gets better — more consistent, more secure, cheaper per unit of work — as it scales. Six months of running agents against real remediation work, and a stack of 2025–2026 papers that quietly contradict each piece of that story, changed my mind on all three counts.
None of these are hypothetical concerns. Each one below is backed by a measured result, not a vibe. Here's what the evidence actually says, and what I've changed as a result.
1. Stop chasing determinism. Split "decide" from "apply."
The instinct when an agent produces a different diff on the same prompt twice in a row is to assume you're doing something wrong — bad temperature setting, sloppy prompt, missing seed. The research says otherwise, and it's more interesting than a config bug.
Thinking Machines Lab traced the actual root cause in late 2025: it isn't floating-point non-associativity or GPU thread scheduling, as the folk wisdom held. It's that reduction kernels (matmul, RMSNorm, attention) are batch-size dependent. In production, the batch size an inference server is handling fluctuates with load, so the exact same prompt takes a different numerical path through the model depending on what else is being served alongside it — even at temperature 0. They proved it by replacing three kernels with batch-invariant implementations and got 1,000/1,000 bit-identical outputs on Qwen3-8B, where the naive setup produced 80 distinct completions (Thinking Machines Lab, "Defeating Nondeterminism in LLM Inference"). A parallel arXiv study reached the same conclusion by testing 12 GPU/batch-size combinations and found greedy decoding itself isn't safe from this (Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference).
The catch: fixing this requires owning the inference stack down to the kernel level. Almost nobody consuming a hosted model API has that lever. So the practical takeaway isn't "eliminate nondeterminism" — it's "stop pretending you can, and design around it." Use the LLM to decide what should change; hand the actual patch application to a deterministic tool (a diff engine, a codemod, a linter's autofix) that behaves the same way every time given the same decision. This also gives you something the model output alone doesn't: a stable, diffable artifact you can audit, roll back, and regression-test cheaply — which is exactly the gap tools like AgentAssay are built to close, by making regression testing of nondeterministic agent workflows token-efficient instead of re-running everything from scratch every time.
2. Unsupervised repair loops don't converge toward secure — they can converge away from it.
This is the one that should worry anyone treating "just let the agent keep iterating on the scan results" as a reasonable default.
A study accepted at IEEE-ISTAS 2025 ran 400 code samples through 40 rounds of LLM-driven "improvement," using four different prompting strategies (efficiency-focused, feature-focused, security-focused, ambiguous). Without a human in the loop, critical vulnerabilities didn't plateau or slowly decline — they climbed. Five rounds in, critical-severity vulnerabilities were up 37.6%. The authors call this feedback loop security degradation: each round of unverified self-improvement has a nonzero chance of trading one class of risk for another, and over enough rounds those trades compound (Security Degradation in Iterative AI Code Generation).
This lines up with something else the prompting-technique literature has been finding piecemeal: security prompting doesn't fail uniformly, it fails selectively. Recursive-criticism-and-improvement prompting meaningfully cuts hardcoded-credential bugs (CWE-259) but does almost nothing for OS command injection (CWE-78), regardless of how the prompt is phrased (Prompting Techniques for Secure Code Generation: A Systematic Investigation). So "keep iterating with the same prompting strategy" isn't neutral — it's actively unlikely to touch the vulnerability classes it already isn't touching, while burning rounds that could introduce new ones.
The fix isn't "don't iterate" — it's "don't iterate blind." Put a verification gate (real tests, real exploit checks) between rounds, and put a hard stop on the loop itself: if the same finding reappears after N attempts, that's not a signal to try again, it's a signal to hand the case to a human. A circuit breaker, not a retry counter.
3. The bill isn't for the scan. It's for everything that happens after.
If your cost intuition says "the expensive part is generating or scanning the code," the numbers disagree. A 2026 study instrumenting real ChatDev/GPT-5 traces across 30 software-engineering tasks found input tokens make up 53.9% of total consumption on average, and stated the conclusion plainly: the dominant cost in agentic software engineering is refinement and verification, not initial generation (Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering). A separate token-distribution study of multi-agent systems (Planner/Reasoner/Verifier roles) found the same pattern from a different angle: reasoning and verification dominate spend, and a 2:1–3:1 input-to-output ratio means the cost driver is re-serializing and re-transmitting context, not producing new text — something the authors termed the communication tax (AgentTaxo).
This is the concrete argument for splitting a coding agent into roles — generator, scanner, fixer, verifier — but it comes with a warning label most "just add agents" advice skips: every hop between roles that passes raw data instead of a distilled result adds to that communication tax. Passing an entire SAST report between agents on every remediation round is exactly the anti-pattern. One measured fix: research on shared-context, skill-based single-agent architectures found that replacing redundant re-encoding of context across separate agent calls with a single shared context — i.e., passing compressed results instead of re-transmitting everything — cut token consumption by 53.7% on average across benchmarks (58.4% on HotpotQA, 56.2% on GSM8K) with no meaningful accuracy loss (When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail; measured breakdown discussed in Augment Code's agent-loop cost analysis). Translated to a security pipeline: the remediation agent needs file:line, CWE-ID, failing test, not the full scanner dump.
4. Prompt caching helps less than it sounds like it should — cache the right thing.
Prompt caching is the first thing everyone reaches for once the token bill shows up, and it does work — Claude Sonnet's cached-prefix reads run at roughly a 90% discount versus uncached input. But caching only compresses the fixed part of a call: the system prompt, static policy text, tool schemas. It does nothing for the part that actually grows round after round — the accumulating conversation history, the fresh scan output, the new tool result each iteration produces. That growing tail, not the static prefix, is the dominant cost in a multi-step loop (Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks).
So the actionable version of "set up caching" is narrower than it sounds: draw a hard boundary around what's genuinely static (system prompt, security policy, CWE taxonomy) and cache only that. Don't let volatile, per-round scan results anywhere near the cache path — not because caching them is harmful, but because it can't help, and treating it as a solved problem there is how teams end up surprised by the bill three rounds into a remediation loop.
5. Let the cheap thing decide the easy cases.
The last lesson is less a research finding than a corollary of the first four: if verification and refinement are where the tokens go, and unverified LLM iteration can make things worse, then the highest-leverage move is keeping the LLM out of decisions it doesn't need to make. Static linters and rule-based SAST are cheap, fast, and — for the class of vulnerabilities they're designed to catch — reliable. Reserve the expensive, occasionally-wrong LLM reasoning for the cases that are genuinely ambiguous: context-dependent judgment calls, business-logic flaws, cases where a static rule would either miss the issue or drown it in false positives.
This tiered design shows up independently in how commercial security tooling is architecting agentic review pipelines in 2026 — splitting "obvious case triage" from "nuanced judgment" into different tiers rather than routing everything through the most expensive reasoning path by default. It's the same principle as Pattern 3 from the cost research above (reasoning-execution separation): don't pay premium-model prices for a decision a linter would have made for free.
The pattern underneath all five
Read together, these aren't five unrelated tips — they're one argument. Every one of them says: stop asking the LLM to be the thing that guarantees correctness, consistency, or security, and start asking it to be the thing that makes judgment calls inside a system that guarantees those properties by construction. Deterministic tools apply the patch. Verification gates and circuit breakers bound the iteration. Compressed handoffs and cache boundaries bound the cost. Cheap gates absorb the easy decisions. The LLM's job shrinks to exactly the part nothing else can do — and that's precisely where it stops being the bottleneck.
References
Thinking Machines Lab — Defeating Nondeterminism in LLM Inference
arXiv 2506.09501 — Understanding and Mitigating Numerical Sources of Nondeterminism in LLM Inference
arXiv 2603.02601 — AgentAssay: Token-Efficient Regression Testing for Non-Deterministic AI Agent Workflows
arXiv 2506.11022 (IEEE-ISTAS 2025) — Security Degradation in Iterative AI Code Generation: A Systematic Analysis of the Paradox
arXiv 2407.07064 — Prompting Techniques for Secure Code Generation: A Systematic Investigation
arXiv 2601.14470 — Tokenomics: Quantifying Where Tokens Are Used in Agentic Software Engineering
AgentTaxo (ICLR 2025 Workshop) — Dissecting and Benchmarking Token Distribution of LLM Multi-Agent Systems
arXiv 2601.04748 — When Single-Agent with Skills Replace Multi-Agent Systems and When They Fail
Augment Code — AI Agent Loop Token Costs: How to Constrain Context
arXiv 2601.06007 — Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks
