Platform for AI-Assisted Software Understanding

A mature software system had accumulated years of technical knowledge across source code, requirements, tests, logs, and documentation. For the people responsible for changing it, understanding why the system worked the way it did had become increasingly difficult. The team relied on five systems: code, Jira, tests, documentation, and production history- and one unofficial one: the engineers who had been around long enough to remember how they fit together.

No one person could explain the whole system anymore. One senior engineer had become the person everyone relied on to make sense of the older parts of the platform. Developers regularly came to him when they needed to understand an unfamiliar component or assess the risk of a change. If he was unavailable, the investigation often slowed down. A routine-looking Jira ticket could turn into hours of investigation before anyone felt ready to make the change: What else depended on it? Why did that branch stay untouched? Which tests confirmed the current behavior remained safe? To make matters worse, manual documentation went stale as soon as the code changed.

Finding the information was only part of the problem. The team needed a reliable way to reconstruct the technical context around the system — and keep that understanding up to date as the product continued to change.

The issue became clear on what looked like a routine PaymentService change. The ticket made it look like an isolated fix, but the change reached well beyond PaymentService.

Eventually, the team had to ask an experienced engineer who still remembered why one of the less obvious branches existed in the first place. That was the real warning sign: understanding the system still depended partly on finding the right person and hoping they remembered the answer.

The client turned to Devox Software to find a more reliable way to reconstruct that context — without forcing engineers to rebuild it manually every time they needed to make a change.

Better search wasn’t enough, because finding the right artifacts still didn’t reveal whether they actually described the same behavior. If an AI explanation sounded convincing but missed a dependency, an engineer could make a decision based on incomplete information. Where did this conclusion come from, and which source supports it?

• AI/ML Engineer 
• Backend Engineer 
• QA Automation Engineer 
• Solution Architect

Early in the project, the team considered building the knowledge base the straightforward way: ingesting the client’s documentation, indexing the repository, and putting an AI interface on top. While that approach would have been quicker, it would also have reproduced the very problem the team was trying to solve. A Jira ticket saying that a payment retry should happen three times, a method implementing five retries, a test expecting five, and a production log showing repeated sixth attempts are not four versions of the same document.  Flattening those artifacts into a search index would make them searchable without revealing how they related, which source reflected the current system, or why they disagreed. The work focused on building a structured evidence graph connecting code, requirements, tests, and production evidence.

Instead of manually reconstructing context across separate systems, engineers could now work from a single model that connected those sources. The platform compared what was intended in Jira and Confluence with what was actually implemented in Source Code, what was validated through Test Cases, and what occurred in production according to Server Logs, with existing READMEs providing initial context.

Engineers could trace dependencies, see what a change might affect, and follow the documentation back to its source evidence.

• Knowledge Graphs
• LLMs
• RAG
• LSP & AST Analysis
• Vector Search
• Jira & Confluence APIs
• CI/CD Integrations
• Log Ingestion

Start With the Code. Documentation could be outdated, and tickets could describe behavior that changed during implementation. The repository became the anchor because it showed what was actually implemented. The repository ingestion layer parsed the code into symbols rather than treating files as text. LSP data resolved definitions and references across modules, while AST analysis handled structural relationships that plain-text search could not reliably infer. PaymentService, for example, did not behave like a self-contained service: one of the dependencies was especially easy to miss because there was no direct call from the service being changed. The relationship only became visible when the team followed the reference chain through a shared component.

Build the Dependency Graph. The graph revealed a downstream component that the Jira ticket never mentioned, which was easy to miss when reading the service in isolation. The team could also see that not every affected path had an obvious corresponding test. Direct code links were treated as facts; inferred links stayed explicitly marked as inferences.

Trace Why the Code Exists. What initially looked like leftover technical debt turned out, once its history was traced, to be defensive logic preserved after an earlier integration failure. The platform identifies these connections by combining explicit code links with semantic matching, marking them as inferred until more evidence appears or an engineer confirms the relationship.

Connect Tests to the Changed Paths. A conventional coverage view could indicate that the team’s tests had executed that code. It could not tell them whether the particular behavior now at risk had been validated. Instead of asking whether the codebase was “covered,” they could ask whether the paths affected by this specific change were tested. 

Check the Changed Paths Against Production. From the code and tests alone, one of the affected paths looked peripheral. The logs showed a different picture: the same path recurred repeatedly in production, clustered around a specific failure condition. It wasn’t necessarily causing the failures, but it appeared often enough in production that the team couldn’t dismiss it as an edge case.

Keep the Platform Inside the Client Environment. None of this requires sending source code or production logs outside the client’s environment. Beyond data locality, the platform secures access via role-based controls and maintains a full audit trail of AI-assisted work, requiring engineering approval for all protected workflows.

Back AI Answers With Evidence. AI answers are backed by the underlying graph evidence, which allows engineers to distinguish between hard facts derived from the source and inferred relationships. The platform labels inferred relationships separately from confirmed ones.

Keep Documentation and Release Context Current. Because every Git event triggers incremental re-analysis, the platform keeps documentation and dependency maps in sync. The same graph also supports release planning.

Before the platform, assessing a change required manually reconstructing context across Jira, code, documentation, and the personal knowledge of long-tenured engineers.

After the platform, developers start with the change and follow the dependency graph outward. They can immediately see what behavior is affected, how it’s tested, and what production logs say. Engineers now work from a current graph with evidence behind each relationship.