Dominic Jainy stands at the forefront of the modern technological frontier, possessing an expansive background in artificial intelligence, machine learning, and the evolving world of blockchain. His career has been defined by a restless curiosity regarding how these high-level technologies can be stitched into the fabric of enterprise operations to drive efficiency. As the industry navigates the massive surge in agent-led development, Dominic has become a go-to voice for understanding the delicate balance between the raw speed of AI and the rigid requirements of enterprise governance. His insights are particularly vital now, as organizations grapple with a volume of code that has reached astronomical proportions, fundamentally altering the traditional software development lifecycle.
The following discussion explores the critical intersection of autonomy and oversight in modern software delivery. We delve into the complexities of governing non-deterministic AI agents, the psychological gap between perceived and actual security in automated pipelines, and the necessity of risk-based frameworks. The conversation also illuminates the role of specialized knowledge graphs in providing agents with the context they need to make intelligent decisions and identifies which legacy processes, such as change advisory boards, are most ripe for full automation to prevent systemic bottlenecks.
The shift toward agentic AI has introduced a level of unpredictability that traditional DevOps pipelines weren’t designed to handle. When we consider that these agents are non-deterministic—where the same prompt might lead to different code outputs—how should engineering leaders rethink their deployment strategies to maintain quality without sacrificing the speed these tools provide?
The reality is that we are no longer dealing with the predictable, linear logic of traditional software; we are managing systems that can be temperamental based on model tuning or even slight adjustments to temperature settings. To handle this, we have to borrow and adapt the most rigorous patterns of software delivery, such as canary rollouts and progressive, percentage-based delivery. If you are updating an agent’s prompt or logic, you cannot simply push it to the entire environment and hope for the best; you must test that change with a tiny fraction, perhaps just 1% of your customers, to ensure the response hasn’t degraded or become a liability to your brand. It is about creating a safety net where the non-deterministic nature of the AI is bounded by deterministic deployment controls. By applying gradual testing phases, we can catch deviations in agent behavior before they scale into systemic failures, ensuring that the surge in code production doesn’t result in a surge of production incidents.
Recent data suggests a striking disconnect in the industry: while over 80% of organizations see agentic AI as a strategic priority and are investing heavily in infrastructure, there is a deep-seated anxiety about actually seeing a return on that investment. What is driving this “governance gap,” and why do so many leaders feel safe despite lacking the actual tools to control these autonomous agents?
There is a fascinating psychological phenomenon happening where leaders see the velocity of their teams increasing and mistake that movement for progress and safety. Our recent survey of 700 engineers and leaders highlighted this exact blind spot—roughly 80% to 90% of organizations claim they are deploying agents in production and feel secure doing so, yet when you press them on the specific tools they use to govern those agents, they come up empty. This governance gap exists because we are deploying production agents faster than our policies can keep pace, leading to a situation where we have more code than we know how to manage. The investment in infrastructure is there, but without risk-based controls, companies are prioritizing speed over quality, which is the primary reason that 80% of IT leaders express concern about achieving a positive ROI. We have to move past the “feeling” of safety and implement actual agentic DLC tools that can test, secure, and govern these autonomous entities in real-time.
You’ve often discussed the three levels of risk-based autonomy as a way for companies to find their comfort zone with AI. Could you walk us through these levels and explain why the majority of the market seems to be lingering at the “human-in-the-loop” stage rather than jumping into full autonomy?
The framework is designed to help organizations calibrate their risk appetite: Level 1 is zero runtime autonomy, Level 2 involves agents executing tasks but with a human in the loop for final approval, and Level 3 is full autonomy within pre-defined policies. Currently, only about 10% of organizations have reached that third level of full autonomy, while nearly half of app development leaders describe their maturity as high but still rely on basic or process-centric automation. The reason for this gradual migration is that throwing a light switch on full autonomy is terrifying for an enterprise architect who is responsible for security and cost controls. Most companies, about 40%, are still finding their footing with process-centric automation because they need to see the agent work correctly a thousand times before they trust it with a single autonomous decision. It’s a transition from being a manual laborer to being an orchestrator, and that shift requires a massive cultural and technical adjustment.
One of the biggest hurdles for an AI agent is the lack of “context”—the subtle organizational knowledge that a human developer picks up over years. How does the concept of a software delivery knowledge graph help solve this context problem, and what role does runtime data play in making these agents actually “smart”?
An agent without context is just a fast way to make mistakes, which is why the integration of a knowledge graph is a game-changer for the SDLC. In a typical enterprise, critical information about architectural standards, security protocols, and cost limits is scattered across a dozen different teams, Jira tickets, and meeting notes, leading to significant “signal loss” whenever a developer tries to move a project forward. By ingesting telemetry and runtime data—an area where our merger with Traceable has been pivotal—we can provide an agent with a holistic view of how software actually behaves in production, not just how it looks in a repository. This means an architecture review agent or a security agent can see the full context of an application’s dependencies and its live performance, allowing it to make decisions that are grounded in reality rather than isolated logic. When an agent understands the “blast radius” of a change through runtime data, it transforms from a simple code-generator into a sophisticated collaborator.
As the volume of code produced by agents continues to grow at an astronomical rate, certain traditional processes are becoming massive bottlenecks. Which specific areas of the software development lifecycle do you believe are the best candidates for full automation, and how do we determine if a change should pass through a human gate or an automated one?
The most immediate candidates for full automation are the processes that simply cannot scale as code production quadruples, specifically change advisory boards (CABs), code reviews, and the tedious removal of feature flags. A traditional CAB will break under the sheer weight of agent-generated updates; it becomes a bottleneck that negates all the speed gains AI provides. To manage this, we use a scoring system where every code submission is evaluated for complexity, its “diff” score, and its potential blast radius. If a change scores low on risk and high on compliance with our established policies, it can bypass the human gate entirely and move straight to production, allowing the human experts to focus only on the high-complexity, high-risk anomalies. This policy-driven approach ensures that we aren’t just moving faster, but that we are moving faster on the things that are safe, while maintaining a strict human-in-the-loop requirement for anything that could significantly impact the business.
What is your forecast for the role of the human engineer as agents take over more of the execution and governance tasks?
I predict that by the end of this decade, the role of the “developer” will have fully transitioned into that of a “system architect and policy orchestrator,” where the primary skill is no longer writing syntax but defining the guardrails within which autonomous agents operate. We will see a shift where 90% of routine coding and deployment tasks are handled by Level 3 autonomous agents, but the value of the human will skyrocket in the remaining 10%, which involves defining the strategic “intent” and managing the ethical and architectural boundaries of the system. The engineers who thrive will be those who can leverage knowledge graphs and runtime telemetry to fine-tune agent behavior, moving away from being the “doers” of the SDLC to being the ultimate governors of a vast, automated ecosystem. Ultimately, the human-in-the-loop will not be a bottleneck, but the essential source of high-level context that ensures AI remains a tool for innovation rather than a source of technical debt.