Five things technology and security leaders must get right before shipping AI-generated code to production
By Nitin Dang – VP APAC, Middle East and Africa at Checkmarx
My conversations with security and engineering leaders across the region are changing. A year ago, the question was “how do we get our teams using AI to ship faster?” Today, it’s “we’ve been shipping AI-generated code for months now what?” Copilot, Cursor, Windsurf, agentic coding assistants writing entire pull requests that often go live with little to no human review; this is production reality, not a pilot project. In fact, our Future of AppSec research found that while 96% of developers have security tools available right in their IDE, only 18% actually use them.
And a meaningful share of the code running mission-critical systems across APAC was never read line-by-line by a human before it went live.
I don’t think that’s a reason to panic. But I do think it’s a reason to get five things right when it comes to keeping code clean, because I’ve watched organisations get each of these wrong in ways that either slow them down or leave them exposed sometimes both.
1. Trust the detection, not just the volume
Every AppSec vendor, us included, can point to a scanner that finds more issues than it used to. That’s not the flex it sounds like. When AI accelerates code output, it also accelerates the flood of findings. If your detection can’t tell the difference between a real exploitable flaw and noise, you’ve just handed your security team a bigger haystack.
What actually matters is accuracy: can the tool correlate related findings, understand the context a piece of code sits in, and tell an AppSec engineer which five things out of five hundred need attention today. More alerts is not more security. It’s often the opposite, because teams start tuning things out.
2. Don’t let security slow developers down
I’ve sat in enough steering committees to know the fastest way to get a security control disabled is to put it somewhere a developer has to leave their workflow to deal with it. If triage happens in a separate portal, on a separate timeline, owned by a separate team, developers will route around it, quietly, and nobody finds out until an audit or a breach.
Security guidance has to show up where the code is being written, in language a developer can act on immediately, not a fifty-page PDF two sprints later. The teams doing this well have stopped treating “developer experience” and “security” as competing priorities. They’re the same problem.
3. Budget for AI’s real cost curve
This one gets underestimated constantly. AI-assisted scanning across a large, fast-growing codebase isn’t a flat cost. Token usage scales with the volume of AI-generated code, and that volume is only going up.
I’ve seen CISOs budget for AI security tooling the way they’d budget for a traditional SAST license, and then get blindsided a few quarters in when usage-based costs catch up with them. Efficiency needs to be part of the evaluation from day one, not a conversation you have after the invoice arrives.
4. Build flexibility in, not lock-in
AI-generated code isn’t confined to one language, one framework, or one IDE anymore. A security approach that’s hard-coded to today’s toolchain becomes a liability the moment your teams adopt the next one. In this market, that moment comes faster than most procurement cycles. Whatever you put in place needs to evolve at the same pace development does, without a multi-year replatforming project every time a new coding assistant shows up.
5. Weigh experience in high-stakes environments
Here’s the part I feel most strongly about, having spent this career largely in regulated markets across APAC, the Middle East and Africa. AI may write the code, but if something goes wrong, no regulator, board, or customer is going to accept “the AI did it” as an answer.
Governance and accountability sit with the organisation, full stop. That means when you’re choosing who helps you secure AI-generated code, proven experience in complex, regulated environments, banking, government, healthcare isn’t a nice-to-have. It’s the difference between a vendor who understands what “compliant” actually has to mean under audit, and one who’s only ever sold into low-stakes environments.
Put those five together and the pattern is obvious: this was never just a development story. AI-generated code is a governance shift, and it needs to be owned collectively — by security, by engineering, and by the C-suite, together, not handed down to one team and hoped for the best.
The organisations I see managing this well aren’t the ones with the flashiest AI adoption numbers. They’re the ones where security, engineering and leadership are having this conversation in the same room.
The code is moving faster than ever. The accountability for it hasn’t moved anywhere. That gap is exactly where the next hard lessons in this industry are going to come from — unless we close it first.