Good morning everyone. Today I'm gonna talk about the most exciting developments in software engineering, how we are using artificial intelligence to transform code at massive scale, far beyond simple auto complete suggestions to intelligent repository. By transformation, we are living in a pivotal moment. Developers have traditionally relied on like line by line tools and manual refactoring for large changes. But what if we could use AI for doing entire package migrations, build and buck fixing, which involves automated error resolutions? COVID refactoring structural improvements, maintaining a specific behavior, fixing code style issues, enforcing a standards automatically static analysis based repair, fixing link, or analyzer phonic. Static analysis annotations, such as adding type hints or documentations. Let me show you how we are actually using AI powered large scale code transformations. Before we talk about solution, let's understand the core problems we are trying to solve. There are three fundamental challenges that prevent Standard L LMS from handling large scale transformations effectively. First context window limitations. Here's the variety. Most code bases are massive. You can't fit an entire repository in a single L-L-M-A-P-I call. We need to break the code base into intelligent chunks and orchestrate multiple LLM calls each with the right context. This requires sophisticated mechanism that understand software structure, not just splitting code randomly at character boundaries. Problem two, knowledge cutoff. LLM are trained up to a certain date. If a code basis use a library that was updated yesterday, the model wouldn't know about it. This is especially critical in programming where API changes happen frequently and outdated knowledge can lead to incorrect solutions. Problem three, hallucinations ELs are fantastic at generating code that looks. Good syntactically correct, but they're also prone to making things up using APIs that don't exist and ignoring edge cases or implementing logic that reasonable, that seems reasonable, but it is fundamentally flawed. For critical transformations, this is unacceptable. These three challenges mean that LMS alone, even powerful ones, simply cannot reliably handle repository scale core transmissions without human interventions at every step. Your Enters code plan. Code Plan is basically a symbolic framework that combines the creative power of large language models with the rigor and precision of traditional symbolic reasoning and static analysis. What does code plan do? It automates large independent code changes. Think package migrations across your code base, multiple file refactorings of modernizing legacy code. The key innovation here is treating repository level coding as a planning problem, not just a generation problem. Code plan integrates LLM with intelligent planning. It doesn't just generate code, it reasons about what needs to happen, breaks it into steps, validates those steps, and orchestrates the execution. Some real use cases are C sharp package migrations across your entire code repository. Python dependency updates that touch multiple services, static analysis driven repairs when you're fixing violations, or compliance issues. Adding type annotations to UN type code at scale. Code Plan is extensible. It's built on modules and transformations, actions and prompts that you can customize for your specific in software engineering tasks. Code plan at a high level, is a symbolic framework for building AI powered software development workflows for inner and outer loops for software engineering. It in the power of LMS with intelligent planning for tackling complex coding tasks that cannot be solved using LLM alones it basically combines the power of LLM and symbolic static analysis approaches. Okay. Let's, lemme walk you through what, how code plan actually works. The architecture has majorly three competence, input, code, plan, engine, and output. The input basically consists of your code repository or directory knowledge based repositories with precise transformation instructions and examples, static analysis reports and logs that identify issues. The code plan engine consists of four major aspects, prompt contests, the first prompts contextualization before we pass. Before we ask anything to the lm, we carefully prepare prompts with most relevant context. This is crucial. Bad context can lead to bad outputs. Second planning and orchestration. Complex transformations are in one short operations code plan, breaks them into structured steps and coordinates the execution, making decisions about which tools to use and in what order. Dependency analysis. Using a ST, we pass your code using abstracts and text trees, a representation that captures the actual structure of your code, not just a text. This lets us understand the relationship between the different components. Static analysis. We validate the transformations and use static analysis to guide them. Is this the, is this transformation correct? Did we break any builds or did you test? Will it break any downstream downstream dependencies stack analysis gives us the confidence. And finally the output is basically the transfer generated code ready to be integrated. Here's a walkthrough of the architecture diagram on the left side. As you can see, the inputs consist of the code repository, the knowledge based repo, or the instructions. The static analysis allows for verifying or for performing static analytics based transformations. The main engine consists of from contextualization planning, orchestration. Dependency analysis, which uses abstract syn tax trees, static analysis, validation, and the LLM. And on the right side, the generated code is the output code which gets generated transforming your repository at a high level the technical magic which happens. And code plan majorly consists of three techniques, LLM planning instead of asking an LLM to solve a problem in one shot. We ask it to plan. Break the complex task into structured steps. Choose which tools and techniques to use decide the order of oxy execution. This enables the goal directed execution rather than hoping on a general purpose model gets it right. Ad based chunking. We don't split the code at arbitrary character positions. We use a ST to, which is abstract syn to identify meaningful boundaries. Function classes, loops. Each chunk remains syntactically valid on its own. This produces better embeddings, better retrieval, and more accurate LLM responses RAG the retrieval. Augmented generation and RAG basically consists of a retrieval and a generator. The retrieval finds relevant chunks from your knowledge base and instructions and the code base. The LLM generator basically integrates the context into its responses. This combination basically reduces the hallucinations, overcomes the context length eliminations, and incorporates, incorporates fresh knowledge into the training data. Together, these techniques create a powerful system for handling repository scale transformations. Okay, now let's go deeper into the abstract. Synex trees as well as the rank. Okay. Let's walk through an a SD con concrete with an example. So here's a simple python code, a function that greets someone. When we pass this a SD with our a SD pass, we get a hierarchical restructure. At the top is a function deaf node. Under that, we have the function name, greet. The argument's name and the return statement. The return statement contains a binary operation string court, which is string contact conation. Combining Hello with the variable name. Name. Now this might seem like a minor detail, but it's transformative when an LLM sees the structure representation instead of raw text. It understands the code at a much deeper level. It knows these are distinct Symantec components. It can reason about how changing one part affects the others. This structure enables meaningful code chunking file, LM, processing, and accurate relationship between the different components, LLMC code as plain text. It's just a sequence of characters they don't inherently understand. The function is different from a loop that a variable declaration is different from a function call. They make educated guesses based on statistical patterns. This leads to generate generic, inaccurate responses and potential hallucinations. The A ST solution breaks the code into organized hierarchical representation. Now, the LLM can understand methods, properties, arguments, data types, and logic flow. It sees the skeleton of your program. This makes the AI responses far more accurate and insightful. When you feed an LLM and a ST in text, you're given a semantic understanding layer. That's the major difference between a generic tool and a specialized tool. Okay. Next chunking. Now we are gonna look at the two approaches for breaking the code into chunks. The first one is traditional and the next one is ESD based chunking. Traditional character based trunking treats code like any other text you might split at 500 characters or a thousand characters. Here's what happens. You end up cutting through middle of functions. A function definition gets split across chunks. An inclusive statement sits alone. The semicolon statement that closes a statement might be in the next chunk. The core structure is disregarded. You get malformed, syntactically invalid fragments, statements lack proper syntax closure. The semantic meaning is completely destroyed. And LLM asked to process this fragments would get completely confused. It's like asking a, someone, asking someone to understand a sequence broken randomly across lines. Next. Now let's see how ad-based chunking. Significantly improves our use case. Each chunk represents a code boundary. The pre-processor include is its own chunk. The using declaration is its own chunk. The complete functions are preserved as a single chunk. This. Which makes more sense and provides better understanding to the LLM. The code is split and meaningful. Boundaries, functions, control structures, usings, declarations, et cetera. Each chunk is syntactically valid and complete. Semantic integration is completely preserved. When an LLM receives syntactically valid code that represents semantic boundaries, it can generate better confirmation. There's no guessing about context that was cut off. The model understands the complete picture of that chunk. This is a foundation technique which we use for enabling repository scale transformation. The planning, along with the A ST analysis, helps us split the task into meaningful sections and loop our irate over the LLM calls providing meaningful chunks of the A SDU back again and again. Next, we are gonna look at rack retrieval, augmented generation. We use RAG majorly for two major aspects, knowledge cutoff and high restoration problems. RAG has two simple components. The retriever searches through your knowledge space, documentation examples, existing core best practices majorly trying to understand what is the transformation you're trying to achieve. It uses the retrieval. It uses a retrieved documentation, combines it with the a SD based chunking and provides it to the generator. The generator takes whatever the retrieval found and process it through an LLM. The model integrates this fresh up-to-date context into its. The beauty of this approach is that the LLM has current information about your specific APIs, frameworks and patterns. It's not operating on the general knowledge from its training data. It's operating on the actual code base and the knowledge base of instructions, which we provided to it. This combination dramatically reduces hallucinations, overcomes context, length limitations, and ensures your transforms use latest frameworks and the best practice from your organization. Okay. Let's talk about real world impact First time savings organization doing mainframe migrations have seen 70% reduction in modernization timelines. Tasks that used to take three to five years are completely automated quality improvements code plan because it integrates with a feedback loop with static analysis. The transformations are. Completely valid and preserves the original behavior. There are fewer manual errors in large scale transformations, higher confidence in the results. Developer productivity developers are free from repetitive error prone task allows focus on high value architecture and design work enables non-experts to perform. Code transformation as well. Enterprise applications, packet transformations across hundreds of files, hundreds of repositories, legacy code modernization, compliance, and security updates at scale. These are real use cases delivering real business value today. Future and challenges we need to be honest about the current limitations. Context, length still limits extremely large code bases. Some code bases are simply anonymous. Model Ations is not completely disappeared. Their reduce, but validation is still essential. Repository scale analysis is computationally heavy. It's not free. Complexity in handling dynamic languages such as Python and JavaScript is higher as we struggle with this traditional tactic analysis with them. Emerging trends. One of the biggest emerging trends is multi-agent systems where multiple specialized agents have the different parts of transformation. Continuously learning from developer feedback as to how developers modify its output. Integration with actual development tools such as your id, CICD pipelines, not just standalone processing. I would like to conclude with some key takeaways. First, we are all, we are moving from a line by line auto complete to a repository wide reasoning from simple text generation to structured planning with validation. Neural approaches are pure LLM based on neural approaches are being integrated and made neuros symbolic hybrid systems that combine the best of both words. Planning frameworks that decompose complex tasks, ad based understanding MULTICONTEXT integration are some of the main aspects which are enabling this transformation. Line, AI powered large core transformations are no longer a theoretical or distant future. They are achieving production ready results on real world repositories. Right now, this technology is transforming what's possible in software engineering. We are not replacing software developers. We're amplifying or enabling them to achieve more. We are automatically. We are automating what's repetitive and error prone so that they can focus on what's creative and strategy. The future of software engineering is at repository scale, intelligent planning and powered by ar. Thank you. I.