From Automation to Intelligence: The Next Evolution of Engineering Platforms

Enterprise AI has crossed from experiment to budget line. 88% of organizations now use AI in at least one business function, and enterprise spending on generative AI reached $37 billion in 2025, more than triple the prior year. Yet most of that money stalls before it scales: only about one-third of organizations have moved AI beyond pilots. The harder truth sits underneath the spending. Most engineering teams still lose the bulk of their day to something AI budgets rarely target. Developers spend only about 10% of their time writing new code, and the rest goes to understanding systems, hunting for context, and reconstructing how things work. The constraint in modern engineering is no longer how fast you can ship. It is how fast you can understand what you are shipping into.

Sandeep Kanaparthi, a Senior IEEE member, has spent more than 14 years building the infrastructure beneath that problem. A principal engineer at a major U.S. financial services firm, he has led cloud-native architecture, distributed systems, and the integration of AI into regulated enterprise platforms, work that runs from securing software delivery to layering machine intelligence on top of it. He has also served as a judge for international technology award programs, evaluating the work of other engineers and innovators across the field. What makes his vantage point unusual is that he did not adopt the industry's three big shifts, automated delivery, cloud-native modernization, and AI-assisted engineering, as separate trends. He built all three, in sequence, inside the same organization.

We spoke with Sandeep, also a judge at the Builders of Tomorrow: AI Super Hackathon, about how those phases connect, why the engineering bottleneck keeps moving, and what it actually takes to put large language models to work safely inside a regulated financial environment.

Hi Sandeep, thank you for joining us for this interview. You've worked across three distinct phases of engineering evolution: DevSecOps automation, cloud-native modernization, and AI-assisted engineering intelligence. Did you see those as a connected strategy from the start, or did each phase reveal the next problem?

Hi, thank you for having me. I would say, it was the second. I did not start with a ten-year roadmap. I started with a specific, annoying problem: software delivery was slow, inconsistent, and risky, and every team solved it differently. So we standardized it and built security and automated testing directly into the pipeline, so shipping code stopped being a manual, dangerous event. Solving that just exposed the next constraint.

Once delivery was fast and safe, the limiting factor became the infrastructure underneath it. You cannot get the full value of continuous delivery on top of a brittle monolith, so the next move was breaking those systems into cloud-native services that could actually scale. Then the same thing happened again. With the pipelines automated and the infrastructure elastic, the bottleneck was no longer machinery at all. It was knowledge. People could ship fast, but they were spending hours just trying to understand the systems they were shipping into. That is the through-line. Each layer I built moved the constraint one level up, from delivery, to infrastructure, to understanding. The strategy was only obvious in hindsight. The individual moves were driven by whatever was slowing engineers down at the time.

When you were designing the DevSecOps platform and leading the migration of more than 45 enterprise applications to cloud-native infrastructure, what limits did you keep running into that automation alone could not solve?

Automation is excellent at removing repetitive work, and it does nothing to fix bad structure. We standardized CI/CD across teams, embedded automated security scanning, and cut a lot of manual deployment effort and human error out of the process. Embedding security into delivery that way is standard practice now, the DevSecOps market has grown to around $10 billion and is led by financial services. But you hit a ceiling fast. You can automate the deployment of a monolith all you want, and it is still a monolith. It still releases as one giant unit, it still fails as one giant unit, and one team's change can still block everyone else.

That is what pushed the cloud-native work. Moving 45 applications onto Kubernetes and a microservices architecture was not about chasing a fashionable stack. It was about letting each service scale, deploy, and fail on its own. The wider industry has landed in the same place: 82% of organizations now run Kubernetes in production, up from 66% just two years earlier, and in financial services the single biggest obstacle to almost any modern initiative is the legacy infrastructure sitting underneath it. The lesson I took from it is simple. Automation makes a bad architecture faster. It does not make it good. You have to fix the foundation, not just speed up the work happening on top of it.

What made you conclude that the next layer needed to be intelligence rather than more automation? And what did it actually take to integrate large language models into an enterprise engineering environment safely, especially in financial services?

The signal was where engineers were actually losing time. Across the organization, people spent a small fraction of their day writing code. The rest went into reconstructing context: which service owns this, where is the runbook, what changed before this incident, who do I even ask. That knowledge existed, but it was scattered across code repositories, architecture docs, operational runbooks, and years of incident history. No amount of additional automation solves that, because the problem is not a slow task. It is missing understanding. That is exactly what language models are good at. So we built an engineering intelligence platform that connected an LLM to those internal knowledge sources, using semantic modeling and vector indexing so an engineer could ask a question in plain language and get a grounded, contextual answer. The results were concrete. Incident investigation dropped from two or three hours to under 30 minutes, engineers located architecture and ownership information 5 to 10 times faster than the old manual search, and onboarding onto complex distributed systems got roughly 40% shorter.

Doing it safely in financial services is a different kind of hard, and it is most of the work. You are dealing with proprietary architecture, production data, and internal runbooks, so you cannot just point a model at everything and hope. The platform had enterprise governance and security controls built in from the first design review, not bolted on afterward. That matters because the industry keeps tripping on this exact step. More than 85% of financial firms are applying AI now, but only a fraction have scaled it, and the gap is almost always governance, not capability. I designed this to be one of the first systems in the organization to put an LLM directly into the engineering workflow, which meant the security and compliance story had to hold up before a single engineer ever touched it.

A lot of AI initiatives in large organizations stall at the security and governance review. What does it take to build an AI platform that can actually be trusted with proprietary architecture documentation, production data, and internal runbooks in a regulated environment?

You have to assume the answer is no until you have earned a yes. In a regulated environment, the default posture toward a new AI system handling sensitive internal data is rejection, and that is the correct default. So the design has to make trust verifiable rather than assumed. For us that meant strict access controls, so the platform only ever surfaced information an engineer was already authorized to see, hard boundaries on what data the model could and could not touch, and auditability, so any answer could be traced back to its source. The model was never the risky part. The data access around it was.

The other half is restraint. Plenty of AI projects die because they try to do everything at once, and the governance review, correctly, says no to all of it. We scoped this to a problem where the value was obvious and the risk was containable: helping engineers understand systems they already had access to, faster. That made the governance conversation tractable instead of adversarial. AI spending in financial services is on track to reach roughly $97 billion by 2027, but the firms that actually capture it are the ones that solved governance first. I would rather ship a narrower platform that passes every review than a sweeping one that lives forever as a pilot nobody is allowed to switch on.

Now that you've built across all three layers, what does the next evolution look like? Is the goal systems that understand themselves, or something else?

Self-understanding systems is the right direction, and I would put it more concretely than that. Today the intelligence layer is reactive. An engineer asks, the platform answers. The next step is making it proactive and trustworthy enough to act, not just inform. A system that recognizes an incident pattern it has seen before and surfaces the likely cause before anyone asks. One that flags an architectural change that will break a downstream service it already knows about. That is the difference between a system you query and a system that participates in the work.

I am wary of the hype around this, though, because the hard part is not the model. Kubernetes has effectively become the operating system for AI workloads, the models improve every quarter, and none of that is the constraint. The constraint is trust, especially in regulated industries. An autonomous engineering system is only useful if people believe its judgment and can audit its actions, and earning that is slow, unglamorous work. So what is next for me is not chasing more autonomy for its own sake. It is closing the gap between what these systems can technically do and what an engineering organization can safely rely on. Whoever closes that gap, not whoever has the biggest model, is the one who gets to deploy intelligence at scale.