What Is Agentic Coding? How AI Agents Modernize Code Transcript, AI Summary & Key Points

00:00 Here's something most software teams know  about but don't always talk about. How developers oftent times spend more time trying  to understand existing systems than they do writing new code. In fact, studies show that  about 60 to 70% of developer time goes toward understanding context before a single change  can be safely made. That's a lot of wasted time.

00:26 It's like being handed the keys to a house that  you didn't build. Sure, you can see the rooms, but you don't know why there's a light switch  in the closet or why one bathroom pipe connects to the kitchen. You need to figure all of  that out before you can safely renovate. Today we're talking about how agentic coding  is changing that and how software development teams are using it to tackle one of their  biggest challenges, modernization.

00:54 Now, let's take a step back for a second. Agentic coding  means AI systems that can autonomously navigate and understand code bases, propose changes, and  execute tasks with minimal human intervention. and modernization. That means taking an existing  application and evolving it to meet new system requirements and use cases without breaking what's  already working.

01:22 We'll be following an example today of how dev teams are using agentic coding,  why legacy code like Java can be tricky to change, and then how this impacts the dev process  overall. Let me set the scene to make this real. We're going to put ourselves in the shoes of  a financial services company that's running a large Java application. This thing handles  customer accounts, loan processing, payments, and reporting pipelines all in one place.

01:57 A  requirement is introduced to add real time AI powered risk scoring so customers can get instant  loan decisions. Sounds great, right? But to get there, the team needs to modernize. As mentioned  earlier without breaking anything that's already working. And that's where it gets interesting  for our team. The challenge with modernization isn't actually the old legacy code itself.

02:23 It's  lost understanding. Think of it like an iceberg. The code that you can see is just the tip. Below  the surface is everything that's disappeared over time. Why the loan approval process run checks  in a specific order. Why a scheduled reporting job runs at 2 am. Why define timing constraints  or why changing one line in a payment flow once froze customer accounts for 4 hours.

02:52 Our team may  have not written this down. The people that built it could have moved on and that knowledge is  now buried under years of patches and updates. So let's talk about three things that make this  especially difficult for our team as they try to add in the new risk scoring tool. First is tangle  dependencies. Different parts of the application have become deeply connected over time in ways  the team never fully mapped.

03:20 Change the way an interest rate is calculated and suddenly the  compliance reporting system starts flagging the wrong accounts. Why? Because two were quietly  sharing a database table that no one on the team knew about. Second is framework gaps. The system  runs on Java 8, which handles threading and memory management very differently from modern versions.

03:49 Something as routine as upgrading to Java 17, can surface dozens of hidden compatibility issues and  libraries that the team hasn't touched in years. Third is undocumented external connections.  This system connects to external credit bureaus, payment networks, and regulatory reporting  systems that each have their own strict data format requirements.

04:14 Change how a single field  is formatted internally, and a nightly compliance report could start rejecting submissions without  anyone on the team immediately understanding why. This all of this right here can contribute to that  60 to 70% of developer time disappearing and it's why our team hasn't been able to move forward  on the real-time risk scoring that the business is asking for.

04:39 Every time they get close, the  complexity of what might break pulls them back. And these are exactly the kinds of problems an  AI development partner is designed to solve. Rather than leaving our devs to untangle all  of that complexity manually, an AI development partner steps in to do the investigative work  alongside of them. Think of it as acting like a building inspector who can x-ray the entire  system, trace every wire, and map every pipe before anyone picks up a hammer.

05:11 And importantly,  this doesn't happen as a one-time pass, but rather as part of an iterative modernization cycle.  We need to understand what exists, make a safe change, validate it, and then expand from there.  Modernization will look a little different for every team, but here's what the cycle is like for  our financial services team as they work to pull the loan decisioning logic into its own system.

05:37 Step one is to analyze the codebase. Our AI development partner analyzes the application and  builds a working model of how everything connects. Call paths, data flows, and hidden dependencies.  And almost immediately, it surfaces something that the team didn't know. Every loan application  actually triggers a very specific sequence; credit checks, watch list reviews, compliance validations  in a strict order that was never written down anywhere.

06:13 Without that discovery, the team would  have separated the wrong logic. Loan decisions would start coming back incorrect, and that's the  kind of issue that shows up in a compliance report very quickly. That risk just got removed before  any code was changed. Step two is identify safe boundaries for change. With that model in place,  our AI development partner proposes where it's safe to separate the loan decisioning logic and  not just what to extract, but what depends on it, what it depends on, and how the new

06:47 service  should communicate with the rest of the system. It flags edge condition, shared data, hidden  coupling. So the team isn't guessing where to draw the line. They're instead validating a  boundary that's already been mapped. Step three is to generate test coverage. Before anything  is changed, the AI development partner generates a broad set of tests based on what it found.

07:12 Not  just happy paths, but edge cases, including credit check timeouts, partial application failures, and  customers getting flagged mid-process. It builds coverage around real behavior, not just what the  team assumed the system was doing. Is it possible in every scenario? No. But it's far more coverage  than the team would realistically have to create from scratch, especially under time pressure.

07:42 Step  four is that our devs review and approve. This is where the developers step back in. They review  the proposed boundaries, validate assumptions, and check the generated tests and then approve each  step before anything moves forward. What they're not doing is spending weeks digging through  legacy code trying to figure out what talks to what. They're coming in with their judgment.

08:11 Step  five is to run old and new side by side. Once the new loan decisioning service is introduced,  it doesn't immediately replace the old one. It's actually going to run next to it. The same  input, two outputs. If there's any difference, the AI development partner flags it instantly.  full context, what changed and where it diverged, so the team can fix issues early before a customer  sees it and before it hits a regulatory report.

08:47 Now, letting AI work on a system that processes  real loan applications, one that feeds compliance reports, and one that regulators expect to  be right every time, that's not something a team should ever take lightly. This only works  if control, validation, and traceability are built in from the start. For any team, this  shows up in three very specific ways.

09:05 First being human approval. Any changes, especially  those affecting reporting pipelines, have to be reviewed and approved before it goes anywhere and  by a developer. Secondly is full change history. Everything's in Git, easy to review, easy to roll  back. And lastly is no autonomous deployment. Devs are always in the loop before anything  goes live.

09:35 These safeguards make the whole approach trustworthy enough for a team to use on  a system that real customers and regulators depend on every single day. Instead of a bunch of time  navigating old code, our dev team delivered that real-time risk scoring feature on schedule. The  time previously lost to legacy code archaeology went straight to the development work needed. So,  how is your team handling modernization right now?