Skip to content
Darab Ahmed
Doc
CS-01
Employer
i2c Inc.
Role
Design and build, end to end
Status
In development

Code-knowledge system for an enterprise fintech codebase

Autonomous agents read legacy Java services, learn their business logic and publish a versioned knowledge graph. A retrieval server answers questions over MCP, and every fact is cited to code or database evidence.

  • Python
  • Kotlin
  • IntelliJ Platform SDK
  • Claude agents
  • MCP
  • Neo4j
  • Qdrant
  • PostgreSQL
  • OpenAI embeddings
  • Podman
  • Docker

Context

The card platform has grown over many years. Its business logic is spread across many Java services, stored procedures and database reference data. Much of the reasoning behind the code lives in tickets, wiki pages and the memory of senior engineers.

Problem

Finding the code behind one business rule is slow. General AI coding tools do not solve this. They read a few files, guess the rest, and do not know company conventions or business logic.

In a payments system, a confident wrong answer is worse than no answer. We could not let the AI decide what is true. Every statement it makes has to be traceable to code or data.

Approach

Separate facts from interpretation

A static-analysis worker built on headless IntelliJ provides the exact structure of the code. The AI never guesses this part. Its job is to explain the structure: business meaning, decisions, rules, and the SQL that the code really builds.

  • Classes, methods, call graphs and real entry points
  • Decision trees: every branch and its arms
  • SQL, messaging and HTTP call sites

A team of agents with fresh context

A lead agent plans the work and hands slices of coverage to worker agents. Each worker starts with a fresh context, so long sessions do not degrade. Agents use read-only tools: the code-analysis worker, reference data, version control, the issue tracker and the wiki.

Tools check the agent, the agent checks the tools

  • Coverage: a deterministic list names everything that must be explained, including flows, methods, decision sites, SQL sites and coded values. Training is not finished until each item is explained or acknowledged with a reason.
  • Validation: every write is checked against code facts. A wrong id, evidence outside the method, or a constant name in place of SQL is refused.
  • SQL: static detection is treated as a lower bound. The agent rebuilds the SQL from code fragments, and an independent scan catches what both missed.

A versioned knowledge graph

Knowledge is stored in Neo4j and versioned by generation. Each publish switches the view atomically, and a failed publish rolls back. Shared resources such as tables, columns, topics and endpoints have one identity, so services link to each other in any training order.

Qdrant holds embeddings, which are used only to find starting points for vague questions.

Retrieval as graph planning

The retrieval server is a planner over the graph. It parses a question into an intent and entities, resolves them to graph nodes, and follows the relevant edges: rules to decisions to SQL to tables, or a trace across services. It returns a compact answer with citations. Results are paged and never truncated.

It runs as an MCP server, so engineers use it from Claude Code, VS Code or Claude Desktop.

Built to be operated

  • Incremental training: after the first full run, only changed methods are learned again on each new commit.
  • Resumable stages: clone, setup, skeleton, learn and publish are recorded, so a stopped run resumes where it stopped.
  • Parallel trainers share the stores safely through leases and conditional claims.
  • Runs as 3 containers with Podman and Docker on WSL.
  • Tested before spending on real agent runs: scripted-agent rehearsals, chaos tests (kill -9, SIGTERM, budget stops) and a scale rehearsal with parallel trainers.

Architecture

Code-knowledge system architectureRepositories feed a training pipeline. A static-analysis worker and a team of agents check each other. Their output passes coverage and validation before it is published to a versioned Neo4j knowledge graph and a Qdrant vector index. A retrieval server reads both and answers engineers and coding agents over MCP.Repositoriescode, commits, tickets,docs, schemasTraining pipelineresumable stages,incremental per commitStatic-analysis workerheadless IntelliJ, Kotlinexact facts: calls, branches,SQL sitesAgent teamlead plans, workers explainbusiness meaning and rulescheck each otherCoverage, validationnothing unexplained,writes checked vs codeNeo4jversioned graphQdrantconcept anchorsRetrievalserver (MCP)graph planner,cited answersto engineers andcoding agentsEach publish is atomic per generation. A failed publish rolls back.
Simplified architecture. Exact code facts and agent explanations check each other before anything is published. Scroll sideways to see all of it.

Verification

  • Coverage list derived from code, not from the model
  • Every write validated against code facts
  • Rebuilt SQL cross-checked by an independent scan
  • Atomic, versioned publishes with rollback
  • Every answer cited to code or database evidence

Stack

  • Python
  • Kotlin
  • IntelliJ Platform SDK
  • Claude agents
  • MCP
  • Neo4j
  • Qdrant
  • PostgreSQL
  • OpenAI embeddings
  • Podman
  • Docker

What I learned

  • Deterministic tools and LLMs work best when each one checks the other. Neither is reliable alone on a large legacy codebase.
  • Coverage has to come from the code. A model will often report that it is finished before it is.
  • Answer quality depended more on the graph model and query planning than on vector search.