When Snyk Code flags a SQL injection or a path traversal bug, the harder problem was never detection — it was generating a fix that actually compiles, actually closes the hole, and doesn't quietly break the function around it. On May 26, 2026, Snyk rolled out a new agentic architecture for Agent Fix (the successor to DeepCode AI Fix) built around a technique it calls dynamic few-shot prompting: instead of fine-tuning a model on security data, Snyk retrieves the most relevant human-written fix examples from a database of more than 35,000 real vulnerability-and-fix pairs and injects them into the prompt at the moment a fix is generated. Snyk reports the resulting pipeline lifted functional-and-secure fix rates from a 74.6% baseline (Anthropic's Opus 4.6 with no augmentation) to 85.4% — a 14.48% relative improvement — across every language Snyk Code supports. Here is how the mechanism actually works.
What is dynamic few-shot prompting, and why not just fine-tune a model?
Dynamic few-shot prompting means the examples shown to the LLM change on every single request, selected in real time based on the specific vulnerability being fixed, rather than baked into model weights ahead of time. Fine-tuning a foundation model to be "good at security fixes" has two structural problems Snyk has been public about: it locks you to whatever knowledge existed at training time, and it has to be redone — expensively — for every language and every new model generation. Dynamic few-shot prompting sidesteps both. Because the examples live in a retrievable database rather than in model weights, Snyk can add a newly-fixed CVE to the corpus today and have it influence tomorrow's fix suggestions with no retraining cycle, and it can swap the underlying LLM (say, moving to a newer Claude or GPT release) without rebuilding a security-specific fine-tune from scratch. The model supplies general coding competence; the retrieved examples supply the security-specific judgment for that exact CWE at that exact moment.
Where do the few-shot examples actually come from?
They come from a Snyk-maintained corpus of more than 35,000 real-world vulnerable-code-and-fix pairs, drawn from open source projects and written or reviewed by Snyk's own security researchers. This is the productized descendant of research Snyk published in its 2024 "DeepCode AI Fix" paper, which described building an earlier version of this dataset by mining roughly 380,000 candidate fix commits from GitHub's top 500,000 repositories — and finding that only 18% to 38% of automatically-detected "fixes" were genuine security repairs rather than unrelated refactors, deletions, or accidental changes that happened to touch the same lines. That filtering work is what makes the resulting examples usable as few-shot prompts at all: a raw commit diff is noisy, but a curated pair of "this exact vulnerable pattern" and "this exact expert-approved correction" is something an LLM can generalize from reliably. The database is organized by issue type (effectively, by CWE), which is the key that makes retrieval fast and precise at inference time.
How does the system pick which examples to show the model?
At prediction time, when Snyk Code flags an issue, Agent Fix looks up the CWE category of that specific finding and retrieves the fix examples in its database that were tagged to the same or a closely related issue type, then injects those into the prompt alongside the vulnerable snippet before asking the model to generate a fix. This is a meaningful evolution from the mechanism Snyk described in its original 2024 research, where few-shot examples for a given issue type were chosen essentially at random from the training set for that category (one example for GPT-3.5, two for GPT-4) rather than ranked by relevance. The 2026 agentic architecture also builds on a separate technique from that same research called CodeReduce, which uses static analysis to shrink the code sent to the model down to only the minimal snippet needed to preserve the vulnerability's meaning — Snyk's research reported compression ratios of 10x to 57x depending on issue complexity. Smaller, cleaner input plus targeted examples means the model spends its context budget on the parts of the code that actually matter to the fix.
What happens after the model proposes a fix?
The candidate fix doesn't just get handed back to the developer — it goes through an iterative repair loop before that happens. According to Snyk's May 2026 architecture description, the workflow runs in three stages: the system generates a candidate fix using the retrieved few-shot examples, re-scans that candidate with Snyk Code to confirm the original vulnerability is actually gone and no new one was introduced, and if the candidate fails that check, the specific error is extracted and fed back into the model so it can produce a corrected version rather than the whole attempt being discarded. Snyk describes evaluating results against three criteria: security integrity (measured with Pass@1 and Pass@5 metrics — does the first attempt, or any of five attempts, produce vulnerability-free code), functional logic preservation (checked with an LLM-based evaluation that the fix doesn't change intended behavior), and a fixed internal benchmark of roughly 150 "golden tests" built from real vulnerable snippets with unit tests attached, so a fix has to eliminate the flaw and keep the existing tests passing.
Why does this approach scale across languages the way fine-tuned models don't?
Because the examples database — not the base model — carries the security knowledge, Snyk can extend coverage to a new language by adding fix examples for it rather than retraining anything, which is how Agent Fix reached full support across every Snyk Code-supported language, including Java, Python, Apex, and Go, without language-specific model training. That's a direct consequence of the retrieval-based design: a fine-tuned model has to relearn syntax and idioms for every language it supports, while a retrieval system just needs enough labeled examples in that language's CWE buckets. It also means quality in a given language is bounded by how many good examples Snyk has collected for it — a limitation Snyk's own 2024 research acknowledged when it noted that harder, dataflow-spanning issue categories (which it called "SecurityFlow," requiring interprocedural taint tracking) saw exact-match accuracy drop as low as 9%, compared to over 80% Pass@1 on simpler syntax-level ("AST") issues. Few-shot retrieval helps a general-purpose model imitate a pattern; it doesn't substitute for the harder program-analysis reasoning that complex, multi-function vulnerabilities require.
How Safeguard Helps
Snyk Agent Fix is a useful case study in where AI-generated code fixes come from and what they can and can't be trusted to catch on their own — and it's exactly the kind of AI-assisted change that needs independent verification once it lands in a pull request. Safeguard treats every AI-generated commit, whether it comes from an autofix agent, a copilot, or a developer working alongside an LLM, as code that needs the same provenance and integrity checks as anything else entering the software supply chain. That means verifying that the commit's SBOM and dependency graph didn't shift in ways the fix didn't call for, that the change is attributable to a known identity and workflow rather than an opaque automated commit, and that CI/CD pipeline permissions weren't broadened in the process of merging it. Safeguard's continuous monitoring also flags cases where an automated fix reintroduces a previously-remediated CWE elsewhere in the codebase — the kind of regression that a single-PR validation loop, however good its Pass@5 numbers, isn't positioned to see. As AI-assisted remediation becomes a normal part of the AppSec workflow, the organizations that benefit most will be the ones that pair fast fix-generation with supply-chain-level visibility into what actually shipped, not just what the model intended to ship.