AI Code Is Causing New Security Bottlenecks for Software Teams in Singapore 

Artificial Intelligence (AI) coding tools are helping developers produce software faster than ever. But in Singapore, they are also creating a new security challenge—specifically AI code.

A recent GitLab survey of DevOps practitioners in Singapore shows that while AI now generates one-third of code, security vulnerabilities and data privacy risks are the biggest barriers to wider adoption.

Teams expect AI to accelerate software development, but it is also creating security bottlenecks faster than it is improving coding efficiency.

Faster coding means far more code to review. Security engineers who once checked hundreds of lines of code each hour now face tens of thousands as AI generates code across entire projects. Output has surged, but security capacity has not kept pace.

Attackers are also moving faster. Many now use autonomous agents to scan for weaknesses in existing systems. As risks increase and security backlogs grow, defenders fall further behind.

Security models built around human review worked when code volumes were manageable. At the scale of AI, they start to break down. Unless organisations rethink how they embed security in development, they risk slowing delivery while leaving gaps that attackers can exploit.

Two structural problems are driving these bottlenecks, and organisations in Singapore need to address both to scale AI-assisted development safely.

AI Code Is Scaling Faster Than Security Reviews

The push to “shift left” aimed to ease security bottlenecks by moving security responsibility to developers earlier in the software lifecycle. In practice, it has often had the opposite effect. Security checks added to development workflows frequently flag false positives, forcing developers to spend hours resolving issues that may not pose a real risk. With deadlines to meet, many look for ways around them.

Teams are now repeating the same mistake with AI code assistants, which failed to account for the entire SDLC and created new downstream bottlenecks.

These assistants optimise for code generation while leaving the review process unchanged. The solution isn’t adding more people or more tools in isolation. Instead, organisations should think holistically about their entire pipeline and map their value streams before adding more AI tools.

This also means documenting processes that rely on tacit, institutional knowledge, which complicates how teams define and measure the value AI delivers. If a process isn’t documented, teams can’t measure whether AI improved it.

Leaders should implement scalable review methodologies that combine AI with practical human oversight, establishing prioritisation frameworks based on measurable risk. For instance, code that touches sensitive customer data or production databases requires a much more intensive review than a feature to customise an application’s theme.

Security Models Built for Humans Are Struggling with AI Agents

Most security frameworks were designed around predictable human behaviour. AI agents operate very differently, and traditional controls don’t cover the risks they introduce.

The complexity multiplies when agents interact with other agents across organisational boundaries. When your internal agent receives instructions from a third-party agent that itself received instructions from another external system, your security model must account for potentially malicious requests you can’t see.

Teams need to develop security controls that limit agent permissions and monitor agent behaviour. Emerging approaches, like establishing composite identities for AI systems, can help tie AI activity to human accountability by tracking which agents performed specific actions and who authorised them.

In conjunction, fostering system design fluency within security teams can make it easier to accurately assess how a new AI implementation may impact existing security boundaries. Many security engineers today struggle to articulate how the backend of an LLM actually works, but understanding how an AI system is designed is fundamental to understanding AI security risks.  This doesn’t require deep engineering expertise for every component, but rather a basic understanding of how the pieces fit together to achieve outcomes, much like security professionals understand how web applications work.

Build Secure Foundations Before Scaling AI

Most organisations in Singapore will spend the next few years building AI capabilities on systems they know are not perfect. Right now, perfection is unrealistic. What matters is recognising the risks, managing them deliberately, and strengthening controls as AI adoption grows.

Security teams cannot carry that responsibility alone. Recent DX research shows that while many developers now use AI tools and save several hours each week, meetings, interruptions, slow code reviews, and CI delays hold those gains back. Some organisations deliver software faster and with greater stability. Others simply generate more technical debt.

The difference comes down to the quality of the engineering practices behind the tools. As continuous delivery expert Bryan Finster notes, “AI is an amplifier. If your delivery system is healthy, AI makes it better. If it’s broken, AI makes it worse.”

AI is exposing weaknesses that were already there. Security teams often sit at the end of the pipeline, dealing with the consequences of fragile processes and inconsistent controls.

To keep pace, organisations need documented workflows, disciplined testing, and continuous delivery approaches that build security into every stage of development. In many cases, the real constraint is not security teams themselves, but the quality of what reaches them.

The organisations that move fastest will be those that address these structural issues now, before rising volumes of AI-generated code make them far harder to fix