Cisco Says Codex Cut AI Defense Delivery From Quarters to Weeks
Cisco’s DJ Sampath says Codex became central to building AI Defense, Cisco’s security product for monitoring and validating AI systems, rather than serving as a peripheral coding aid. According to Sampath, Codex wrote the majority of AI Defense, is writing every new feature for it, and helped move delivery timelines for some features from several quarters to weeks.
Cisco says Codex moved AI Defense work from quarters to weeks
DJ Sampath presents Cisco’s AI Defense work not as a limited experiment with AI-assisted coding, but as a development effort in which Codex became central to how the product was built. His opening claim is direct: Codex wrote the majority of AI Defense, and every new feature Cisco is building for it is “100% written by Codex.”
The product shown alongside that statement is Cisco AI Defense, a security interface for monitoring and validating AI systems. The dashboard view includes areas for applications, gateways, APIs, and model deployments, with an “Events detected” count of 89k. A validation view for a “Chatbot Foundation” model shows attacks blocked, technique scores, and risk labels including “Medium risk” and “High privacy risk.”
Sampath ties the use of Codex to a change in delivery time. Every engineer working on AI Defense, he says, was equipped with Codex. Features that would previously have taken several quarters to reach customers instead moved to a timeline measured in weeks.
The features that we were working on for AI defense would have taken several quarters for us to be able to get out in the hands of our customers, and that dropped down to weeks.
That quarters-to-weeks contrast is the central operating point. Cisco is describing Codex as part of the build process for AI Defense, not just as a tool used around the edges. In Sampath’s description, the technology affected both how much of the product was produced and how quickly new work could get to customers.
DefenseClaw is the clearest compressed-cycle example
Sampath’s concrete example is an open-source tool called DefenseClaw. Cisco built it, he says, from ideation through delivery to developers using it in an open-source community in under one week. The “start to finish” framing matters: the example is not only about writing code quickly, but about moving from idea to usable tool on a compressed timeline.
The screen shown with this example displays a “defenseclaw” repository and an OpenAI Codex interaction. The visible prompt asks Codex, “can you please review this repo quickly.” Codex’s visible response says it will do “a fast code-review pass focused on concrete bugs, security risks, and broken setup paths.” Another line reads: “Warning: DefenseClaw observed a HIGH Codex hook finding.”
The visual puts Codex inside the engineering loop beyond initial generation. In the displayed interaction, it is being asked to review a repository, focus on bugs and security risks, and identify broken setup paths. That supports Sampath’s broader description of Codex as something Cisco engineers used across the work of building AI Defense and related tools: a repository review, a security-oriented pass, and a high-severity finding surfaced in the interface.
DefenseClaw also shows why the speed point matters to the rest of Sampath’s remarks. If a tool can move from idea to developer use in less than a week, the backlog no longer has to be viewed only through the older effort estimates teams had been using. That is the shift he turns to next.
The backlog question changes from effort size to run time
DJ Sampath says Codex allows Cisco engineers “to be a lot more ambitious.” His explanation starts with a familiar planning practice: teams look at a backlog and assign rough effort sizes — small, medium, large, or “t-shirt sizing.” In that frame, a large item is treated as a large effort.
Codex changes the frame of reference, in Sampath’s telling. The planning question becomes less about whether a backlog item is small, medium, or large, and more about “how long will a Codex run take to be able to get these things done?” He calls that shift “fascinating.”
There’s a fundamental change in the frame of reference that people look at that backlog.
The supporting screens make the point concrete. One shows a “Product backlog” board with Backlog, In Progress, and Review columns next to an assistant panel reporting a short run: “Working for 34s,” “Edited 1 file,” “explored 1 file,” and “1 search.” Another shows an assistant log at “Working for 40s,” identifying that “The overlap is coming from the generic SettingsRow,” stating “I’ve made the row itself responsive,” and then running git diff.
Those are small units of work, but they illustrate the planning shift Sampath describes. A backlog item can be considered in terms of an agent run that explores files, makes an edit, explains the change, and prepares a diff for review. His point is not that all work becomes trivial. It is that engineers begin to judge some work by the time and output of a Codex run, rather than only by the old small-medium-large sizing frame.
For Cisco’s AI Defense work, Sampath’s claims are concrete: Codex wrote the majority of the product; new features are being written by Codex; every engineer on the effort was equipped with it; features that would have taken several quarters dropped to weeks; and DefenseClaw reached open-source developers in under a week. The change in ambition follows from those operating details. Engineers, as Sampath puts it, look at the backlog with a different frame of reference.