Article body
Full article
Next-generation Agentic BI from Hengshi, Beijing.
Summary
This article proposes a methodology for turning AI from an assistant into a core R&D participant inside a software company. Through Hengshi’s own practice as a BI software company with a 10-year product history and 57,000 issues, we have validated the feasibility of using a product knowledge base as the memory foundation for an AI R&D hub, or JARVIS.
The core finding is simple: the bottleneck for AI participation in R&D is not model capability. It is the degree to which organizational memory has been structured. This article explains why such a system is needed, what it should contain, and what value it creates. It does not cover implementation steps.
1. The Problem: Why Copilot Is Not Enough
Most software companies still use AI mainly for code completion: GitHub Copilot, Cursor, or IDE plugins. These tools are effective at the tactical level, but they share a fundamental limitation:
They have no memory.
When an engineer faces a bug, the task is not simply to “write code.” The engineer needs to know:
- Why this module was designed this way three years ago: design decisions.
- Whether similar bugs have appeared before: historical patterns.
- Which other modules may be affected by the change: cross-module dependencies.
- Which proposals were rejected and why: rejected requirements.
- Where the test coverage blind spots are: the quality map.
This knowledge sits in senior employees’ heads, scattered across GitLab comments, and buried in historical Slack messages. When senior people leave, that knowledge disappears.
Copilot can help you write a function. It does not know why that function should not be written.
2. The Thesis: An AI R&D Hub Needs Memory
Our core thesis is:
To upgrade AI from a “tool” into a “teammate,” a company must first structure its organizational memory. Model capability is a sufficient condition; structured memory is the necessary condition.
The human analogy is straightforward. A brilliant new engineer, equivalent to the strongest LLM, can still write code that is technically correct but wrong for the business if nobody explains the product history, design decisions, past mistakes, and rejected proposals.
JARVIS is not a better Copilot. JARVIS is an R&D teammate with the company’s full product memory.
3. The Framework: A Three-Layer Time Architecture
The product knowledge base is organized around three time layers.
History: Everything That Has Happened
History covers the key facts from the first line of code to the present day:
- Deep module documentation: the architecture, code paths, known issue patterns, design decisions, and test coverage for each feature module.
- Cross-module dependency matrix: which changes in module A may affect module B.
- Breaking-change index: all historical breaking changes.
- Rejected-requirement index: all rejected feature requests and their reasons.
History answers the question: “Has this happened before, and what was the result?”
Present: The Current State Snapshot
Present reflects the current state of the product in real time or near real time:
- Backlog snapshot: all open issues, organized by module, priority, and release.
- Release plan: schedules for current and future versions.
- Team ownership: who owns each module.
Present answers the question: “What is the current situation?”
Future: AI Judgment Output
Future is where JARVIS creates real value. Based on History and Present, it can make product-manager-level judgments:
- Duplicate detection: is a new issue duplicated with a historical issue?
- Root-cause analysis: is the bug caused by a design flaw or an implementation mistake?
- Cross-module impact assessment: which other modules may be affected by the fix?
- Implementation-complexity estimation: how much effort did similar historical fixes require?
- Lesson retrieval: have similar decisions created problems before?
Future answers the question: “What should we do?“
4. Key Insights
Rejected Requirements Are Some of the Most Valuable Knowledge
In our practice, 7,311 of 57,000 issues were rejected requirements, including by design, wontfix, not a bug, and duplicate.
These rejected requirements contain knowledge that is often more important than implemented features: they document why something should not be done. An AI that does not understand “why not” will repeatedly propose rejected solutions and waste everyone’s time.
Ninety-Four Bugs Can Come From One Design Defect
We analyzed the “filter snapshot” feature in depth. Since it went online in 2022, it had accumulated 94 bugs. But the root cause of these bugs could be traced to the same design defect: the feature launched without a clear boundary definition, such as which scenarios were supported, which were not, and how snapshots should expire after fields were deleted or renamed.
An AI without a product knowledge base would fix those 94 bugs one by one. An AI with a product knowledge base would identify the structural design defect and recommend redefining the feature boundary.
That is the difference between a tool and a teammate.
The Knowledge Base Must Evolve With the Code
A product knowledge base is not a one-off documentation project. It must:
- Be managed in the same source-control system as the Git repository, with versioning, MR review, and branch strategy.
- Automatically update known issues after every bug fix.
- Record decisions after every design decision.
- Regularly synchronize backlog snapshots from the issue system.
If the knowledge base drifts away from the code, the AI will read stale information. The judgment it produces may be more dangerous than having no knowledge base at all.
5. Value Model
For Engineers
For Product Managers
For the Organization
- Knowledge no longer disappears with employee turnover: design decisions and historical lessons are stored structurally.
- AI capability grows as the knowledge base grows: progress depends not only on stronger models, but on richer memory.
- R&D decisions move from experience-driven to data-driven: every decision has historical evidence behind it.
6. Preconditions
This methodology is not a silver bullet for every company. It has clear prerequisites:
- The product must have enough history: at least three to five years of issue-tracking data. If the product is still new, improve issue management first.
- Issue management must be structured: labels, module classification, and milestone management matter. Garbage in, garbage out.
- Someone must understand both product and technology: initial construction requires people who can guide AI with both product logic and technical implementation knowledge. A knowledge base generated purely by AI will be poor.
- The organization must be willing to change workflows: knowledge-base maintenance must be embedded into daily R&D, not treated as extra work.
7. Methodology Levels
We divide the methodology into three progressive levels for companies at different stages.
Level 1: Passive Memory
- Existing documents, issues, and code comments are organized into a structured knowledge base.
- AI can search and cite the knowledge, but does not actively participate.
- Value: faster information retrieval and less duplicated work.
Level 2: Active Participation
- AI can classify new issues, detect duplicates, and assess impact automatically.
- AI participates in code review and raises comments based on historical knowledge.
- The knowledge base integrates with CI/CD and updates automatically.
- Value: AI becomes part of the R&D process.
Level 3: Autonomous Evolution
- AI can maintain and expand the knowledge base autonomously.
- AI can discover knowledge blind spots and fill them in proactively.
- AI can make data-driven suggestions on product direction.
- Value: AI becomes a core participant in product evolution.
Our practice is currently transitioning from Level 1 to Level 2. Level 3 is the long-term goal.
8. How This Differs From Existing Patterns
The key distinction is that this methodology emphasizes memory, not retrieval. Memory is organized, causal, and self-updating. Retrieval only finds similar fragments from a pile of text.
9. Conclusion
The software industry is moving from “AI-assisted coding” toward “AI participating in R&D.” But many companies are stuck in the middle: they have powerful LLMs, but have not given those LLMs structured product memory.
JARVIS is not a product, not a tool, and not a SaaS. It is an organizational capability. The core question is not which LLM or framework to choose. It is how to turn 10 years of organizational memory into structured knowledge that AI can understand and reason over.
Models will iterate and frameworks will change, but structured product memory will only become more valuable.
This article comes from the blog of Thomas Chan, Senior Engineer at Hengshi.
Recommended Reading
- HENGSHI CLI Officially Launches, Opening the Era of Agentic BI Autopilot
- Which Quadrant Is Your Product In? Product AI Depth vs. Commercialization Height
- Back to Fundamentals in the Eye of the Storm: Hengshi’s Thinking and Actions in the AI Era
About Hengshi
Hengshi is defining a new generation of Agentic BI for the Data + AI era. HENGSHI SENSE, its enterprise data-intelligence engine, helps customer partners build vertical-domain AI analytics-agent applications with no code.
Founded in 2016, Hengshi focuses on empowering enterprise application SaaS partners with data analytics platforms. Hengshi serves major enterprise customers including WPP, BMW, GAC Honda, Publicis Groupe, BlueFocus, Sinopharm Group, AWS, Taitai Le, and Genki Forest. It also works deeply with more than 200 enterprise application SaaS partners, including Phoenix Contact, Synagie in Singapore, Travelsky, Sangfor, Kingdee Cloud, Inspur Cloud, Seeyon, Ti-Net, Baozun E-Commerce, Facishare, EC, Mingdao Cloud, and Beisen Cool College, helping partners bring built-in business intelligence online.
