What Developer-First Security Looks Like in the AI SDLC
|
Thought Leadership
Amit Mahbubani, Head of Engineering
Security has never fit cleanly into developer workflows. As coding agents become the primary development interface, we have a chance to change that-with developer UX as a first-class requirement.
The problem: security doesn’t fit the developer workflow
Security tooling has never fit particularly well into the way developers build software.
Many security tools now surface findings directly in CI or on a pull request, but they still evaluate an artifact—a dependency, container image, or code diff—after it exists. They rarely understand the intent behind the change or the organization’s business context. A developer must then determine whether the finding is relevant, connect it to the work, and translate it into an implementation change, often after the context that produced the artifact has already been lost.
Security becomes another feedback loop that developers have to operate.
This was a problem before AI. Security portals and policy pages sat outside the development workflow, while scanners and pull-request bots brought security closer to the code. Each added value, but developers still carried much of the heavy lifting needed to connect a finding to the intent behind the work. The result is many developers who push security to the back burner.
The issue isn’t that developers don’t care about security. The issue is how, and when, security reaches them. Much of it lands late: on a pull-request diff or a deployed artifact, after the design decision is already made. Useful security input should arrive while the work is still taking shape, in a form developers can act on, without making them operate a separate security process.
The coding harness is now my primary development interface
Most of my development workflow now happens inside a coding harness - a coding agent environment such as Claude Code. I use it to explore an approach, understand code, make design decisions, write technical specifications, implement changes, review, and generate tests.
Design and implementation used to be distinct phases in my workflow. With a coding harness, I now move from exploring a design to writing and reviewing the code in the same continuous interaction with the agent. As a result, the agent understands my intent, codebase, design decisions being considered and implementation.
Most security tools enter only after an artifact exists. They see the document, diff, or deployed application, but not necessarily the intent and decisions that produced it. The agent and harness is present earlier, while intent is still becoming design and code. That makes it a natural interface for bringing security into the work before that context is lost, giving security a new place in the development workflow.
With the AI SDLC, we have an opportunity to fix this
The obvious response to more AI-generated code is more AI-powered scanning. That scales the existing process without fixing the workflow. Moving the same interaction into an agent doesn’t solve it either - a disconnected security workflow is still disconnected inside the terminal.
The larger opportunity is to make the coding harness the developer-facing interface to security. Relevant security context becomes an input to the work. For example, when developers are designing an internal endpoint, the coding agent should understand the organization’s authentication, API gateway, and rate-limiting requirements. Developers should not need to phrase a security-specific question to receive those rules.
This context must be selective. Loading every policy into every session would add noise, consume tokens and eventually get ignored. Security-relevant work should receive the context it needs; trivial changes should see nothing.
Deeper reviews should fit into the same workflow. Developers should be able to start a review from the coding harness, continue working, and receive the results in the same session. They should not have to act as the integration layer between the security tool and their development environment. That loop should continue into implementation. As design turns into code, the same workflow should help check whether the implementation still honors the security intent and decisions that shaped it.
CI and governance still matter. Some operations belong at the PR stage, and security teams need visibility. But the local agent, CI and security platform should operate as one connected workflow. Security context and decisions should follow the work from design to implementation, with results returning through the surfaces developers already use.
The AI SDLC opportunity is larger than putting a scanner inside a coding agent. It is to make the coding harness the developer-facing interface to security.
Developer UX principles
Putting a security capability inside a coding agent does not automatically make it developer-friendly. Skills, hooks, and plugins are easy to ignore or disable when they add friction without enough value.
Security inside the coding harness should meet the same bar as any good developer tool.
Work across existing developer surfaces end to end. Developers already work through coding agents, terminals, pull requests, and CI. Relevant context and results should appear in those surfaces rather than creating a parallel route on a different platform.
Require no security-specific prompting. Routine security context should not depend on developers remembering a special command or phrasing the task in security language. Deeper reviews can still be explicit operations when the change requires them.
Work for developers and their agents. The output also needs to fit its consumer: an agent needs precise, actionable context it can apply, while developers needs a concise explanation they can evaluate. Copying the same detail into both experiences is not enough.
Stay lightweight. Local development is where approaches are explored and mistakes are cheap to fix. Security should add minimal latency and token cost and never block automatically - it can steer or recommend a deeper review without turning every local decision into an enforcement event. Whatever slows the loop or gates routine changes gets ignored, regardless of its security value.
Stay relevant. Security context should be hyper-specific to the task and the organization. Generic advice applied everywhere is just another form of noise.
Developers will keep a security capability enabled when it helps them build better software without making them operate a security process. Adoption is not only a rollout or enforcement problem. It is a product and developer-experience problem.
What we’re building at Seezo
A developer-first security workflow needs four connected capabilities: selective guidance while work is taking shape, deeper assessment when warranted, persistent security requirements, and validation that carries those requirements into implementation. At Seezo, this is the model we are building toward.
While developers and their agents are working, Seezo can supply the security context relevant to the task. The context comes from the organization’s security standards and is selected based on the area of work. It becomes part of the working context, helping shape the design and implementation without taking over the session or changing code independently.
Some changes still need an explicit, deeper review. Developers should be able to start that review from the coding harness and continue working while it runs. The assessment happens asynchronously, the result returns to the same workflow, and the resulting security requirements persist beyond the conversation.
Those persisted requirements connect design review to implementation. When code exists, Seezo can validate the implementation against the requirements from the assessment-locally or through CI. This is not a replacement for every form of code scanning. It answers a focused question: does the implementation honor the security design decisions and requirements that were reviewed?
CI is another surface for the same operations. Depending on the artifacts in a pull request and the organization’s configuration, CI can run an assessment on a design document, validate an implementation against an existing assessment, or run both where appropriate. Results return through the pull request instead of sending developers into another interface.
The Seezo platform persists the assessments and requirements and gives security teams the visibility and governance they need. Developers continue working through the coding harness, terminal, and pull request-the surfaces already central to development.
The complete flow looks like this:
For developers, the important property is continuity. They should not need to restart the security conversation in every tool. The relevant context, review, and requirements should follow the work from design to implementation to pull request.
Security should follow the work
Security did not fit cleanly into developer workflows before AI. If we respond to the AI SDLC by adding more disconnected scans and findings, the dissonance will get worse.
Coding agents give us a chance to fix it. They are becoming the interface where developers understand problems, make design decisions, implement solutions, and interact with other tools. That makes them a natural place for relevant security context and a natural way to connect developers to deeper review when it is needed.
This does not remove assessment, CI, or governance. It connects them into a workflow that starts where developers are already working and carries security decisions through to the code that ships. Developers shouldn’t need to change their workflow to operate a security process. Security should follow the work-from design, to implementation, to pull request - while letting developers stay focused on building software.