The recent conversation around AI and software development has focused heavily on code generation. How much faster can developers work? How much of the development process can AI accelerate? How soon can organizations turn that productivity into shorter development cycles?
Meanwhile, many enterprises are sitting on decades of existing code that still runs critical parts of the business. Before developers can safely change, extend, or modernize those applications, they often have to spend significant time figuring out how they work. That creates a different role for AI: helping developers better understand the applications already running the business.
What gets lost when code changes hands
Applications evolve over time. They can be modified by different developers, written across different languages, and shaped by various undocumented business requirements. Even when the code still works exactly as intended, the reasoning behind it may be difficult for the next developer to reconstruct.
Programming standards help, but they do not eliminate individual style. Two developers can work in the same language, follow the same rules, and still solve the same problem in very different ways. Over time, those choices become embedded throughout the application.
The problem becomes even more complicated when the person who wrote the code is no longer there to explain it. Experienced developers understand why a system was designed a certain way, where historical workarounds exist, and which seemingly insignificant pieces of logic may make a big difference. AI cannot replace that experience, but it may help newer developers make sense of the code they inherit.
What AI could tell us and what it couldn’t
At RRMac Associates, we recently saw this firsthand. Our team needed to work with code written by a former colleague in a language none of us regularly uses. Before we could address a bug, we first had to understand what that unfamiliar section was doing.
We gave AI small portions of the code and asked specific questions about what each section appeared to do. That helped us interpret the unfamiliar language and follow the logic well enough to continue investigating. When we asked AI to fix the bug, however, its suggestions were wrong. Repeatedly.
But the exercise was still valuable. By then, we understood enough of the program to diagnose the issue and develop the fix ourselves. AI didn’t solve the problem, but it helped us get to the point where we could.
Understanding code is not the same as understanding the system
That usefulness does have limits. In my experience, AI tends to be most useful when the task is well defined. Asking what a specific piece of code appears to do is very different from giving an AI tool a large enterprise application and expecting it to explain the entire system accurately. The code alone does not necessarily contain everything required to do that.
An application interacts with data, other systems, and business processes. It may include logic created to address a requirement that no longer appears in the documentation, or a workaround that only makes sense if you know what was happening elsewhere in the environment when it was written.
AI can help interpret what is in front of it but may not be able to tell you why it’s there or what else depends on it. Giving AI too much at once also increases the likelihood that it loses the thread or fills in information it does not actually have. A confident explanation can easily be mistaken for a complete one, and developers still need enough knowledge of the environment to recognize missing context, question the interpretation, and verify its output. AI can be a valuable source of information, but it should not become the source of truth.
Helping developers learn the systems they inherit
That same investigative approach can also become a learning tool. Rather than using AI only to get past a specific problem, developers can use it to ask questions, trace logic, and build context as they work.
Organizations can also use AI to make internal knowledge and training resources easier to navigate. At RRMac, for example, we are using it to help newer employees access information about coding standards, established practices, and the way our team approaches certain problems.
The hope is to make technical knowledge easier to access without short-circuiting the learning process. A developer who simply asks AI for an answer may get past the immediate problem but learn very little from the experience. Using it to ask questions, investigate unfamiliar logic, and build context helps the developer build the expertise needed to make more consequential decisions later.
Start where knowledge is hardest to access
For leaders, one of the clearest opportunities for AI in software development is making technical knowledge easier for developers to access and use. A good place to start is where that knowledge is currently hardest to reach: an application few people understand, an unfamiliar language, sparse documentation, or a process that depends heavily on a small number of experienced employees.
Choose a focused use case in one of those areas. Give developers a defined problem, appropriate guardrails, and a way to validate what the tool tells them. Then evaluate whether the experiment makes important knowledge easier to find, helps developers investigate issues more independently, or reduces reliance on a handful of people to explain how an application works.
That gives leaders a concrete way to evaluate AI’s value within their organization. If the technology can make the knowledge embedded in existing applications (and in the people who understand them) more accessible across the organization, it can strengthen the organization’s ability to support, maintain, and eventually change the systems it already depends on.
