In the age of AI-driven development, speed is the new baseline. But as AI agents accelerate the pace of coding, they also amplify the risk of security bottlenecks. At Snyk, we believe a superior Developer Experience (DX) is the only way to secure this new frontier. DX is not just a layer on top of the product. It is the foundation that allows developers to unleash AI innovation securely.
We think of DX as a system of decisions that compound over time. Every interaction, every default, and every piece of information a developer encounters shapes how effectively they can use our platform.
The five principles that emerged from our journey of evolving and refining the Snyk platform now serve as the foundation for delivering an excellent DX. These principles continuously guide the thousands of small decisions we make across the entire product surface, underscoring our commitment to this ongoing process.
1. Go to where developers work, don't ask them to come to you
The most common challenge in developer tooling is the assumption that a beautiful dashboard is the primary destination. Experience shows that developers prioritize their existing workflows, which they have optimised over the years: their IDE, the terminal, their Git flow, and their pull request (PR) process. Context switching out of those workflows has a tremendous cost.
We saw this directly at Snyk. We had built a detailed findings interface in the Snyk platform with prioritized vulnerability lists, remediation guidance, and full data flow traces. Developers did not visit it. We learned that even the most valuable data is often bypassed if it requires a context switch. By moving security into the existing PR conversation, we aligned with the developer’s natural flow.
We changed our model. We stopped asking developers to come to Snyk and started bringing Snyk to them. Security findings became part of the pull request conversation, surfaced directly in the SCM in the same thread where code review was already happening. Same information. Zero context switch, but dramatically different adoption.
The principle goes beyond PRs. It is why we invest heavily in IDE plugins, AI coding assistant and, CLI integrations, and CI/CD gates. The question we ask is always the same: where is the developer already working, and how do we show up there?
There’s a broader shift underway from traditional IDEs to agentic development environments. At the velocity that AI coding assistants drive, context switching becomes a much bigger bottleneck, since higher agent productivity amplifies the cost of breaking flow. As agentic platforms become a core part of developer workflows, Snyk is already integrated in those environments to secure AI-generated code at inception.
2. Developers are not security specialists, so speak their language
When we designed security findings in PRs, we optimized for the developer’s mental mode. CVSS scores or CWE classifications made sense to security professionals, but to developers they were jargon that required translation.
We surface a contextual, natural-language description generated from Snyk's own data flow analysis. For a SQL injection vulnerability, for example, rather than citing a generic advisory, we would explain that unsanitised user input from the HTTP request body is directly interpolated into an SQL query string, naming the source, the sink, and the mechanism in the developer's own code.
That one sentence tells a developer, who is often not a security specialist, exactly what and where (to the exact file and line number) the problem is, in terms they already understand. The full trace is still available for those who want it. But most developers do not need to go deeper. They need to understand enough to act.
And every surface of Snyk’s product attempts to apply this principle. We aim to answer, "What does this developer need to understand, at this moment, given what they know?"
3. Every piece of information is either signal or noise – there’s no middle ground
There is a tendency in security tools to surface everything. It feels comprehensive, but it often overwhelms rather than helps. When we examined our PR experience, we reframed the problem: what information truly belongs in the developer’s view?
We chose to be deliberate. What we show depends on the workflow. In prevention, developers need fast, actionable guidance. In remediation, they need depth and more paths when they are optimising for risk reduction. In a PR, every piece of information should either answer an immediate question or enable a clear next step. This context matters a lot as developers in a PR are focused on shipping the functionality. Vulnerability resolution becomes secondary. This is very different from a backlog context, where fixing issues is the primary task.
Progressive disclosure also helps balance this. The primary view focuses on the issue, its severity, and the next step. Deeper layers provide additional context, such as data flows, when needed. This keeps the experience focused and noiseless.
4. Detection is not the product, resolution is
For a long time, security tools measured success by what they found. The more vulnerabilities surfaced, the more complete the tool felt. What this metric missed was the thing that actually mattered: whether those vulnerabilities got fixed.
Most developers do not want awareness. They want to know what to do next. A vulnerability report with no clear next step is just noise with a severity score, and developers, quite rationally, learn to treat it that way.
The motivation behind building fix suggestions directly into the PR experience was to close the loop: not just identify vulnerabilities, but fix them without ever leaving the workflow. When Snyk detects a vulnerability in code, it does not just flag it. It proposes a concrete, AI-generated fix as a diff, inline in the PR as a review comment, red lines out, green lines in, applicable as a commit with a single action.
For the SQL injection example, rather than flagging the string interpolation and leaving the developer to figure out the solution, the AI Fix suggestion replaces it with a parameterized query. The developer does not need to research secure SQL practices, the fix is already there. The path to resolution becomes the default path.
Good DX tells them how to fix an issue, but a great DX makes fixing the default path.
5. Trust is built when developers understand why, not just what
When we launched the suggested fix, we saw a pattern repeatedly in developer feedback: the question was not "does the fix work?" It was "Why does this fix work?" Developers were applying suggestions and then struggling to explain them to colleagues. The fix was solving the immediate problem and creating a different one.
So we added something that turned out to be one of the highest-signal changes we made to the PR check experience: a plain-English explanation of exactly why the suggested change eliminates the vulnerability. Not a link to documentation. Not a reference to the CVE. An explanation, derived from the code's specifics, of how the fix addresses the vulnerability.
For the SQL injection example, the explanation would describe how replacing dynamic string interpolation with parameterized queries ensures that user input is treated as data rather than executable code and why that distinction closes the vulnerability.
The combination of these two features, suggested fix and its explanation, mirrors how a senior security engineer would actually review code with a colleague: first making sure they understand the problem, then showing them what good looks like.
Trust is built through reasoning. Every time Snyk explains its thinking, it gives developers the tools to develop their own security instincts, which is, ultimately, the most durable outcome.
Great developer experience does not happen by accident
These five principles got solidified by watching what broke, understanding why, and changing our approach.
Great developer experience requires principles like these that can guide thousands of small decisions across product, engineering, and design. As we move into a future where AI and human developers collaborate more closely, these principles ensure that security remains a tailwind, not a hurdle. At Snyk, we are constantly striving to get better; one decision, one fix, and one successful deployment at a time.
See how the developer experience Snyk has built can accelerate your program. Get a demo today.
Top comments (0)