Enterprise AI in Production: Mumbai Call for Proposals

Understanding legacy code with an LLM is only step one. This session walks through the full pipeline we run in production: ingest, build and validate a knowledge base with the client’s experts, generate BRDs and use cases, turn them into test cases, modernise with a coding agent, and re-run the same tests to prove behaviour has not changed.

The problem and the setting

At Tiramai AI we built ProductSphere, a platform for modernising large legacy applications, and deployed it into production at a transportation technology company that operates across several countries (anonymised). Its codebases range from a few MB to 3 to 4 GB, mostly Pascal, C, C++ and C#, with some older Angular front ends.

Before, every change started with a hunt. A developer would read the code and outdated documents, still be unsure, and go to a subject-matter expert (SME), who had little time and often had to make a best guess. The common pitch for AI modernisation is “point an LLM at the code and rewrite it”. In practice that fails, because nobody can prove the new system does what the old one did.

The pipeline

1. Ingest code from repositories and storage buckets, plus documents.
2. Understand by extracting facts and code relationships into a knowledge graph. Code and documents tell you what the system does, rarely why it was built that way. That “why” lives with SMEs still in the organisation.
3. Validate the knowledge base before anyone relies on it: SME-verified golden question-and-answer sets, and replaying the business flows the LLM describes through the live applications.
4. Generate requirements: BRDs and use cases, drawn only from the validated knowledge base and reviewed by SMEs.
5. Generate test cases from those requirements and run them against the existing system to set a baseline.
6. Modernise with a coding agent, then run the same test cases against the new application. If they pass, behaviour has been preserved.

From POC to production

1. POC: our team ingested a single codebase. The client’s maintenance engineers checked the platform’s answers against fixes they had already made.
2. Integration: single sign-on through the client’s identity provider, code ingestion through controlled storage validated with their internal team, and ticketing enabled and verified.
3. Security gates: a penetration test, then approval from the client’s CISO.
4. Handover: access for the client team, a training session, and feedback captured through an in-product form and their ticketing system.
5. Live use: code understanding, business analysis, impact analysis and modernisation in production. We now reuse the same playbook with BFSI organisations.

Architecture

• Identity and access: single sign-on through the client’s enterprise identity provider, with role-based access per codebase
• Ingestion: connectors for source repositories and object storage inside the deployment boundary, built to recover from rate limits and failed loads; documents uploaded separately
• Staging and approval: uploaded documents are compared with the code and existing knowledge; conflicts and version mismatches are flagged; an SME approves before anything enters the knowledge base
• Knowledge layer: a knowledge graph of facts and code relationships, with our own versioning so each fact is tied to the code version it came from
• Model layer: model-agnostic, so the client can bring its own LLM or run open models; no data is kept by any third-party model provider
• Grounded retrieval: answers come only from the client’s code and approved documents, never general world knowledge, and link back to source files
• Requirements and tests: BRD and use-case generation from the validated knowledge base, then test-case generation from those requirements
• Modernisation: a coding agent produces the modernised code, which is checked against the same test cases as the legacy baseline
• Delivery: findings, impact analysis and fixes flow into the client’s ticketing system

Tool choices, as selection criteria

• A knowledge graph, not vector search alone: code meaning sits in relationships between modules, calls and data, which flat chunks lose
• Model-agnostic layer: regulated clients choose or host their own model, so the platform cannot depend on one provider
• Our own versioning and staging layer: nothing off the shelf handled documents that contradict the code
• Ingestion inside the deployment boundary: code never leaves the client’s control, which the security review required
• Coding agent judged by tests: generated code is accepted only when it passes the same test cases as the legacy baseline

What went wrong and what we changed

• Ingestion at scale: repository and storage rate limits caused failed and partial loads, so ingestion had to recover from failures rather than assume one clean load.
• Retrieval quality: early answers were weak. Better extraction of facts and code relationships into the graph mattered as much as the choice of model.
• Documents versus code: some documents confirmed the code and strengthened the graph; others described an older version and contradicted it. Mixed in blindly, they make answers confidently wrong. This is why we built versioning and the SME approval step.
• The missing “why”: no amount of parsing recovers design intent. SME time has to be planned in from the start.
• Expectations: users expected 100% correct answers in one shot. Some answers arrive first time, others take a few rounds. Grounding every answer in their own code and being explicit about what the system cannot answer did more for adoption than chasing perfect accuracy.

Before and after

User counts and timelines are withheld for client confidentiality.

Three takeaways

1. Validate the knowledge base before you generate anything from it: SME-verified golden Q&A sets plus replaying real business flows.
2. Let the requirements drive the tests, and let the tests judge the modernisation: the same test cases run on the legacy system and the modernised one.
3. Never let documents silently override code: version every fact, flag conflicts, and put a human approval step between staging and the knowledge base.

Audience and prerequisites

Architects, platform and ML engineers, and delivery leads modernising legacy systems or bringing LLM retrieval and coding agents into an enterprise. Familiarity with RAG and LLM applications helps; no deep ML background needed.

Format

45-minute deep dive, including questions, as it is a multi-stage implementation with an architecture walkthrough. Can be compressed to a 30-minute talk if the panel prefers.

Draft slides

https://docs.google.com/presentation/d/16to8dJ-iUkD-3YNYPv5tZxt5RoPKoB7U/edit?usp=sharing

About me

Akash Raj, AI Product Manager at Tiramai AI, Bengaluru, which builds a security-first, model-agnostic AI platform for regulated and mission-critical industries. 8 years in product and analytics across HDFC Life, IDC Digital and Aptean (Lead Product Owner for Microsoft Business Central ERP solutions). Four-time TEDx speaker.
Email: workwithakashraj@gmail.com | Mobile: +91 77607 10039 | LinkedIn: https://www.linkedin.com/in/akash-raj-product
Talks: https://youtu.be/0SYVpX9CHUw and https://youtu.be/jIU2RjmA3CM

Disclosures and availability

I work for Tiramai AI, which builds the platform discussed; the talk shares implementation lessons and is not a product pitch. The client is anonymised, and user counts and timelines are withheld. I am available to speak in person in Mumbai on 31 October 2026 and to take part in editorial review.