Anand Naidu is a seasoned veteran in the enterprise software space, specializing in the delicate balance between rapid innovation and architectural stability. As organizations navigate the complexities of agentic AI, Naidu provides a grounded perspective on how to transform fragmented development environments into high-velocity delivery machines. His expertise spans the entire stack, allowing him to see where AI-generated code often hits the hard reality of legacy infrastructure and rigid governance. He has spent years advising CTOs on how to move beyond the “pilot” phase of AI and into a state where machine-driven automation truly scales without breaking the underlying business logic.
The conversation covers the amplification of software fragmentation caused by AI, the necessity of prioritizing delivery speed over simple coding output, and the strategic shift toward model-neutral infrastructure. We examine the critical need for contextual boundaries for AI agents, the widening gap in organizational governance, and why human engineering judgment is more vital now than ever before. Naidu emphasizes that the real challenge today isn’t just writing code faster, but ensuring that the entire lifecycle—from security audits to production deployments—can handle the sheer volume of output generated by autonomous agents.
Many organizations built their toolchains piece-by-piece over a decade, leading to fragmented environments. How are you seeing AI agents amplify these existing cracks in the infrastructure?
The reality is that most enterprises are currently running a “frankenstack” of tools that were never designed to talk to one another, and adding AI agents to this mix acts like a stress test that many are failing. When an organization has a separate AI agent for its repository, another for its CI/CD pipeline, and a third for monitoring, these agents are essentially working in silos without shared context. This fragmentation was a drag on productivity long before AI, but now it is becoming a critical failure point because agents operate at a frequency that humans can’t manually reconcile. I often look at the success of companies like Airwallex, which recognized that the only way to truly leverage automation was to move away from this piecemeal approach. By consolidating their toolchain into a single, unified platform, they managed to ship customer-facing features four times faster than they could when their data was scattered across disparate systems. Without that consolidation, agents end up touching dependencies and triggering deployments faster than governance processes can track, which leads to a “hidden cost” of adoption that many leaders don’t see until something breaks in production.
We often hear that AI makes developers more productive, but there is a reported gap between coding speed and actual delivery. Why do you think 78% of organizations see faster code output while only 21% report gains across the full lifecycle?
This is the central paradox of the current erwe are getting incredibly good at the “writing” part of software, but the “delivering” part is still stuck in the slow lane. If a developer uses AI to write a complex feature in two hours instead of two days, but that code then sits in a review queue for a week, the business has gained almost nothing in terms of actual value. This bottleneck is where most AI gains go to die, specifically in the downstream processes like security scanning, manual peer reviews, and staging environment tests. Our research shows that while the volume of commits is climbing, the throughput—the actual number of features reaching the customer—is not moving at the same trajectory. To fix this, engineering leaders need to stop obsessing over coding metrics and start tracking the “idea to production” timeline. We have to look at how often deployments happen and, more importantly, how often they fail, because if AI is just increasing activity without increasing throughput, it is essentially just creating more work for the human reviewers who are already overwhelmed.
As organizations in regions like Asia Pacific and Japan navigate strict data residency and regulatory rules, how is the choice between frontier and open-weight models becoming a core infrastructure decision?
Model choice is no longer just a technical preference for developers; it has become a high-stakes decision for the legal and infrastructure teams. In highly regulated markets across APJ, regulators are increasingly demanding evidence that AI systems are operating within specific policy frameworks and that data isn’t crossing unauthorized borders. This is why a model-agnostic approach is so critical because no single provider can satisfy every global regulatory body simultaneously. By utilizing a platform that supports both frontier models for high-level reasoning and open-weight or self-hosted models for data-sensitive tasks, enterprises can maintain much tighter control over their cost and compliance. Locking into a single provider might seem simple in the short term, but it creates a massive exposure risk regarding latency, data residency, and escalating token costs. The goal should be to turn every model output into something that is governed, tested, and fully auditable, which is why the platform’s neutrality is actually more important than the specific model being used at any given moment.
Reliable agents require deep context to make safe changes, yet giving them unrestricted access is a major security risk. How should enterprises approach the “minimum visibility” principle for AI?
The most dangerous thing you can do is give an AI agent a full, unrestricted copy of your codebase and tell it to “fix things” without boundaries. To be truly reliable, an agent needs context—not just the current state of the code, but the history of why changes were made, the security findings from the last pipeline, and the production behavior of the application. However, we have to apply the same principle to agents that we do to human employees: the principle of least privilege. A successful pattern involves giving an agent the exact slice of data it needs for a specific task, such as a single repository’s history or a specific set of security logs, rather than a wide-open door to the entire enterprise ecosystem. When an agent works off a fragmented or incomplete picture, it might produce code that looks perfect in isolation but fails the moment it interacts with a hidden dependency. By centralizing this context within a unified platform, we can provide agents with a consistent and governed way to access information, which removes the friction that usually leads to security vulnerabilities.
With 80% of organizations admitting they adopted AI tools before establishing clear governance policies, how do we define the stopping point for agent autonomy?
We are currently seeing a “governance debt” crisis where the speed of AI adoption has far outpaced the ability of organizations to control it. The only way to manage this safely is through risk-based autonomy, where we create clear tiers for what an agent is allowed to do without a human in the loop. Low-risk actions, like updating documentation or fixing minor syntax errors, can move autonomously, while medium-risk changes get flagged for a quick human check, and high-risk architectural shifts require a full manual sign-off. The real danger is that many teams have deployed hundreds of agents but cannot actually say what those agents did last week or if they stayed within company policy. Accountability must always sit with the human who initiated the action or approved the policy under which the agent is operating. If you can’t trace an AI-assisted change back to a specific approval trail, you aren’t actually automating; you’re just gambling with your production environment’s stability.
When calculating the ROI of AI, many teams focus on token costs, but you suggest looking at business metrics. How did a company like Agoda prove the value of their transformation beyond simple usage costs?
If you are only measuring token consumption, you are missing the forest for the trees because the real cost of AI includes rework, governance, and the time humans spend fixing agent-generated mistakes. A much better metric is the one used by Agoda, which saw its platform consolidation efforts return 3,000 hours of developer time per single quarter. That is a massive, tangible business outcome that shows developers are actually being freed from “toil” and are able to focus on higher-value tasks. We have to account for the fact that agents often produce code that is ultimately reverted, which means the team might actually be spending more time on rework than they would have if they had written the code manually. The enterprises that will win are the ones that track their AI investments against business-centric KPIs like deployment frequency and lead time for changes. If your AI spend is going up but your 3,000-hour recovery metric isn’t moving, then you aren’t seeing a real return; you’re just paying for more expensive ways to generate technical debt.
As agents take over more of the “heavy lifting” in coding, how does the role of the software engineer evolve, and what skills are becoming the new baseline?
The role of the engineer is shifting from being a “writer” of code to being an “architect” of systems and a “judge” of value. We’ve always had a backlog of software that the world wants built that far exceeds our capacity, and AI is finally helping us close that gap, but it doesn’t replace the need for human intuition. Agents can generate functions, but they can’t tell you if a solution actually solves the right customer problem or if the trade-offs made in the architecture are sustainable for the next five years. This means that skills that were once reserved for senior or staff engineers—such as system design, orchestration, and complex decision-making—are now becoming the baseline expectations for everyone on the team. Orchestration is particularly key because as we add more internal and third-party agents, someone has to decide which ones run in what order and how to handle the handoffs between them. Engineers are becoming the directors of a digital workforce, and their ability to manage that coordination will be the most valuable skill in the region.
What is your forecast for the future of enterprise AI in the software development lifecycle?
I believe we are heading toward a world where “coding” as a manual task will represent less than 10% of a developer’s day, but the “delivery” infrastructure will become 90% of the competitive advantage. We will see a massive shakeout of companies that tried to bolt AI onto old, fragmented processes, as they find themselves buried under the weight of unmanaged agent activity and skyrocketing rework costs. The winners will be those who treat their software delivery platform as a first-class citizen, ensuring that every automated action is governed, contextualized, and aligned with business goals. We will also see a shift in how we hire, where the ability to audit and orchestrate AI will be prioritized over the ability to memorize syntax or algorithms. Ultimately, the real test of enterprise AI won’t be how fast the model can think, but how effectively the organization can act on that thought without creating a trail of operational chaos. Success will be defined by those who can bridge the gap between machine speed and human judgment, ensuring that every line of code—whether written by a human or a bot—is secure, compliant, and genuinely valuable to the end user.
