The question for an enterprise isn’t how many lines of code AI generated today. It’s how quickly it can deliver software that is secure, works in production and creates value for the business.
You have spent much of your career working with enterprise technology and software delivery. What experiences shaped your perspective on the challenges organizations face when trying to modernize complex technology environments?
I spent years at Symantec and Adobe dealing with software delivery inside large enterprises. So when I talk about modernization, I’m not just talking about new technology. I’ve seen what happens when a business has hundreds of teams, different tools, decades of code and a process where everybody has to hand something off to somebody else before software can move forward.
That experience is why we started Opsera. The issue was never simply that developers couldn’t write code fast enough. You had the business analyst, the architect, the developer, DevOps, security, QA and operations. Each had a piece of the picture, but nobody necessarily had the whole thing. The original intent gets lost along the way.
Now bring AI into that environment. We can produce code at a pace that wasn’t possible a few years ago, but we’re still trying to move it through the same process. When you’re modernizing a 20- or 30-year-old system, the code often contains business knowledge nobody has documented. If you don’t understand that context, you can make the technology newer without making the business better. That’s the lesson I’ve carried through my career: you have to rethink the process, the people and the technology together.
AI coding assistants have significantly accelerated software development, but faster code generation does not necessarily translate into faster software delivery. Where do you see the biggest bottlenecks in the enterprise software development lifecycle today?
Our software development lifecycle was built for human-paced work, and it breaks down with AI. It’s like putting a Ferrari in stop-and-go traffic. If AI has to wait at every handoff, what’s the point of having it?
Coding was maybe 30% of what a software engineer actually did. The other 70% was architecture, security, testing, fixing bugs, documentation, integration and understanding the business. AI has made that coding portion dramatically faster. It hasn’t magically fixed the rest.
Look at our AI coding benchmark across more than 250,000 developers. We saw time to pull requests improve by 48% to 58%. That’s a real gain. AI-generated pull requests also took 4.6 times longer to review, and the analysis found 15% to 18% more security vulnerabilities. You have code arriving faster and then sitting in another queue, or creating work somebody has to clean up later. That’s not end-to-end productivity. We’ve moved the bottleneck.
The question for an enterprise isn’t how many lines of code AI generated today. It’s how quickly it can deliver software that is secure, works in production and creates value for the business.
As organizations adopt AI across engineering teams, how should technology leaders rethink the traditional software development lifecycle to accommodate collaboration between developers and AI agents?
I think a lot of companies are making the same mistake. They buy an AI coding tool, give everybody a license and expect the existing development process to suddenly move at AI speed. It doesn’t work that way. You can’t bolt smart agents onto a process that was never redesigned for them.
Think of a factory. If you install intelligent robots but keep every old handoff and approval exactly where it was, you’ve made one station faster. You haven’t rebuilt the production line. That’s what needs to happen to the SDLC. Start with what the business is trying to accomplish. Give agents the architecture, the business rules and the context behind that decision. Turn the intent into a living specification, break it into manageable work and build security checks and human decisions into the workflow.
This also changes what it means to be an engineer. AI is increasingly taking on the ‘how’ of producing code. The engineer’s value moves toward the ‘why’: knowing what to build, understanding the customer, making architectural decisions and recognizing when the output is wrong. You still need people who can conduct the orchestra, even if each instrument can play on its own.
Also Read: AITech365 Interview with Sumeet Arora, Chief Product Officer at Teradata
Legacy modernization remains a major challenge for enterprises, particularly when critical business logic is embedded in systems built over decades. How can organizations use AI to modernize these environments without compromising business continuity or losing institutional knowledge?
I actually think legacy code is the gold mine inside the enterprise. Everybody gets excited about how fast AI can build a new application. Think about the systems companies have been running for 20 or 30 years. That’s where their customer intelligence, business rules and hard-earned knowledge live. Those systems weren’t built to expose that information to AI.
If you just translate the old code into a new language, or put an AI interface on top of it, you haven’t necessarily modernized anything. You may have moved the same problems into a different environment. The first job is to understand what the system does, why it does it and what will break if you change it. AI can help uncover dependencies, reconstruct the architecture and turn undocumented business logic into specifications that people and agents can actually use.
Then you modernize in stages. Keep the existing business behavior as your reference, test the new implementation against it and make sure the people who understand the business are involved. Just as important, keep that intelligence under the enterprise’s control. The objective isn’t simply to replace old code. It’s to preserve decades of institutional knowledge and finally make it useful for what comes next.
What does effective AI governance look like in software development? How can enterprises balance the autonomy of AI agents with the need for security, compliance, accountability and human oversight?
Governance is the tax you pay for AI. You don’t get to opt out of it. I don’t believe you can solve it by setting up one central governance team that reviews everything after the work is done. By then, the agent may already have made hundreds of decisions.
I use the autopilot analogy. A plane can fly much of the journey on autopilot, but there is still a pilot in the seat who is responsible for safety. The same principle applies to an AI agent. Let it execute inside defined boundaries, but be very clear about what it can access, what it can change, what gets tested and where a person has to approve the decision.
Those guardrails can’t be static. They have to operate continuously, through the technology, the security layer and the risk controls. Every agent should work from the right business context and specifications, with permissions and traceability so you can see what happened and why. If it starts drifting from the architecture or policy, you need a circuit breaker. Autonomy without accountability isn’t innovation. It’s just a new way to accumulate risk.
Developer productivity is often measured through output, speed and deployment frequency. Are these metrics still sufficient in an AI-driven development environment, or should enterprises rethink how they evaluate engineering performance and business value?
No. Some of the metrics we use today can become very misleading when AI starts generating code at scale. I know an enterprise that produced roughly 300 million lines of code over 35 years. Then it generated another 100 million or so in one year using AI. One of its executives asked me, essentially, ‘What am I supposed to do with all this code?’ That’s exactly the right question.
I’ve seen pull requests double in size, and teams reach their previous year’s commit volume in the first six months. You can look at that dashboard and say productivity is exploding. Didthe business release more useful products? Did revenue change? Is the code easier to maintain? Or did we just create a much bigger black box?
We still need delivery metrics, but they have to be connected to outcomes. Measure the time from idea to production, review and rework, quality, security, maintenance and the cost of the tools themselves. Then ask what the business actually got for that investment. A developer writing more code is not the same thing as a company creating more value.
As AI-generated code increases, how can organizations ensure that software quality, architectural consistency and security standards keep pace with development speed?
The first thing is to stop assuming that because the code compiles that it’s ready for the enterprise. AI can produce something that looks perfectly reasonable in isolation and still violates the architecture, duplicates functionality or creates a security problem somewhere else in the system.
We’ve already seen the cost of this. Our benchmark found 15% to 18% more security vulnerabilities in AI-assisted code, along with more duplication. In my conversations with enterprises, the concern isn’t just the obvious bugs. It’s the technical debt nobody understands six months later. One team generated the code, another team has to maintain it, and the original context is gone.
That’s why I’m so focused on persistent context and specifications. An agent needs to know what the application is supposed to do, the architectural rules it must follow and the tests it has to pass. You need checks while the work is happening, not just one security gate at the end. Humans remain accountable for high-impact changes, but the routine validation should be built into the system. Otherwise all that extra coding speed simply turns into more rework.
Enterprise technology teams often work across multiple development tools, cloud platforms and AI models. What should organizations prioritize when building an integrated and scalable AI-driven software engineering environment?
The most important thing is not to bet the entire enterprise on one model or one coding assistant. Models are changing too quickly for that. I think open models will have an impact similar to what Linux had on older proprietary systems. Enterprises want choice, especially when they’re putting their own business data and intellectual property into these workflows.
Why should a company give its intelligence to a model provider and then pay to rent it back? For critical work, businesses may still choose a leading closed model. For documentation or a more bounded task, they may be perfectly happy with something cheaper or a model they host themselves. The latest and most expensive model isn’t always the best answer.
The one thing an enterprise can’t hand off is its context. That means the business logic, the architecture, the security rules, the specs, and the institutional knowledge of how its systems actually work. Then you need an orchestration layer that carries that context across models, code assistants and delivery tools. That is where I think a lot of the long-term value sits. If you can change the model without losing your company’s intelligence or rebuilding the workflow, you’ve created an architecture that can actually scale.
How can CIOs and CTOs measure the return on investment from AI-powered software development beyond developer productivity, particularly in terms of operational efficiency, modernization costs and time to market?
I would start by asking a simple question: what did the business get that it couldn’t get before? Too many AI dashboards show how many licenses were activated, how many tokens were consumed or how much code was generated. Those are measures of activity. They’re not a return on investment.
You need to follow the money and the work all the way through the lifecycle. How long did a project take before AI, and how long does it take now? What happened to review, security, rework, deployment and maintenance costs? If I save one hour writing code but create two hours of work for someone reviewing it, the economic benefit is pretty questionable.
Cisco is a useful illustration. In the published customer study, the Cyber Security Group saw a threefold improvement in time to pull requests and a 62% faster cycle time to merge. ead time to deployment improved by 7%. That doesn’t mean the tools failed. It tells you exactly why measuring just one stage of the process can give leadership the wrong picture.
For a CIO or CFO, the real scorecard is faster time to market, lower total cost of modernization and maintenance, fewer issues reaching production and more capacity to deliver something customers need. If the numbers don’t connect to those outcomes, we’re not measuring ROI yet.
With Opsera recently relaunching as an AI-native software factory for the enterprise, what is the thinking behind this repositioning? How does Forge address the challenges that traditional DevOps platforms and standalone AI coding assistants may not fully solve?
We didn’t reposition Opsera because the market needed another AI coding tool. There are plenty of those. The bigger problem is that AI has changed how code gets written, but it hasn’t fixed how enterprises actually deliver software. Traditional DevOps helps automate parts of the pipeline. Coding assistants help generate code. The gap sits in the middle, where business intent has to become working software. That takes shared context, a sound architecture, security controls, clear approvals, and a way to measure what actually shipped.
That’s why I talk about a secure software factory. A factory doesn’t become more productive just because you put a faster machine in one corner. You have to redesign how the whole operation works. With Forge, we’re moving from a lifecycle designed around individual developers and handoffs to one where people and AI agents work from the same specifications, with guardrails built into the process.
For a new application, that means taking an idea and preserving its intent through the tasks, code, testing and release. For legacy modernization, it means starting with the existing system, recovering the business logic inside it and making that context usable for agents without losing control of it. Forge provides the persistent context, work orders, checks and traceability around the models and coding tools an enterprise already uses.
Faster code generation only solves the easy part. What remains is getting reliable software into production at enterprise scale and showing the business return it delivers. None of that requires replacing engineers or writing off what a company has already built.
Thanks, Sumeet!
About Kumar Chivukula,
Kumar Chivukula is the co-founder and CEO of Opsera, an AI-native software factory that helps enterprises modernize legacy systems and build new software with governance built in. His background spans enterprise IT, cloud infrastructure and software delivery, including leadership roles at Adobe and Symantec. At Opsera, he focuses on helping engineering teams adopt AI across the software development lifecycle while maintaining security, governance and human oversight.
About Opsera,
Opsera is an Enterprise AI Software Factory that helps organizations modernize legacy applications, build AI-native software, and accelerate software delivery across the entire software development lifecycle. Its platform combines AI-powered development, intelligent automation, governance, security, and engineering insights to help enterprises deliver software faster, safer, and more efficiently. By integrating with existing development tools, AI models, and cloud environments, Opsera enables businesses to scale AI-driven software engineering while maintaining enterprise-grade security, compliance, and control. The company also helps organizations measure the business value and return on investment of their AI and software modernization initiatives.
