Platform for AI-Assisted Software Understanding

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.

At its core, the system had five official sources of truth- 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.

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, forcing the team to rely on personal knowledge rather than the official record.

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.

The developer had to move between the repository, Jira, Confluence, and test cases to reconstruct the surrounding context. While some dependencies were obvious in the code, others only emerged once the team traced relationships across systems. The team eventually had to involve an experienced engineer who remembered why one of the less obvious branches existed in the first place.

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. They are four different pieces of evidence about the same behavior. 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. Devox was engaged specifically to solve this, as the project required deep expertise in modeling software provenance, dependencies, and testing—moving beyond simple AI integration to create a structured evidence graph.

With the platform in place, it integrates those sources into a single model. Rather than treating them as isolated repositories, it compares what was intended in Jira and Confluence with what was actually implemented in Source Code, what was validated through Test Cases, and what actually 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

Starting with source code as the anchor. Documentation could be outdated, and tickets could describe behavior that changed during implementation. The repository became the technical anchor because it reflected the implemented system. 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.

Moving from search to a dependency model, the graph exposed a downstream component that the Jira ticket never mentioned, and that 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.

Connecting the code to the reason behind it. 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.

Bringing tests into the same model. 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. 

Adding production evidence. 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.

Keeping the platform inside the client’s environment. None of this required 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.

Grounding AI in the technical graph. AI answers are backed by the underlying graph evidence, which allows engineers to distinguish between hard facts derived from the source and inferred relationships. This transparency ensures the platform doesn’t treat everything as certainty, encouraging engineers to treat the AI output as a starting point for their investigation rather than a final verdict.

Living documentation and release intelligence. Because every Git event triggers incremental re-analysis, the platform keeps documentation and dependency maps in sync. This transforms the graph into release intelligence: the platform maps changed paths to their tests, allowing QA to identify missing coverage or weak evidence before regression begins, rather than manually working backward from the entire test suite.

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. System context is no longer a slow, manual reconstruction—it’s a verifiable, living map that stays up to date as the code evolves.