The AMAP Automotive AutoSDK team turned domain knowledge into an engineering asset that can be produced, tuned, automatically refreshed, and consumed with Qoder's knowledge engine, lifting the strict one-shot rate from 37.3% to 61.5%.
Title: A Record of AI Native Evolution in AMAP Automotive Engineering | Building Business Knowledge Engineering with Qoder
Author: AMAP Automotive Business
Abstract: AMAP's enterprise business built a "production, tuning, refresh, consumption" system for business knowledge with Qoder's knowledge engine. The same class of error no longer happens twice, and the one-shot task pass rate rose from 37.3% to 61.5%.
For the loop to run, knowledge first needs a map: how many layers there are, where each one lives, and where the boundary of this article is drawn.
AutoSDK's domain knowledge is a full spectrum running from low-level code facts up to top-level constraints and preferences. We divide it into four layers by degree of abstraction, and the relationship among them maps onto the DIKW spectrum of cognition.
L1 Code and configuration (the Data layer): the raw facts underlying all knowledge. Everything above is distilled from it, and whenever knowledge conflicts with code, the code always wins.
L2 Terminology and processes (the Information layer): core terms, module information, and critical paths.
L3 Business domain knowledge (the Knowledge layer): responsibility boundaries, architectural rules, and the reasons behind the status quo, helping the Agent understand the business as a whole and avoid design drift.
L4 Constraints and preferences (the Wisdom layer): this layer covers how something should be written and why it is written that way. It holds design constraints, solution preferences, key decisions, API design methodology, and more. Its reach is broad and it is triggered often, so precision is what matters.
The relationship among the four layers runs both ways. Bottom-up, each layer distills the one below it, since all upper knowledge is abstracted from lower knowledge. Top-down, each layer guides execution: AI reads the L4 constraints first, then consults L3 and L2 to understand the current state, and finally lands at L1 to write code. At the same time, the higher the layer, the more it depends on people, and the lower the layer, the more it depends on the engine.
This article focuses on engine-led factual knowledge (L1 through L3). It can be distilled in bulk and refreshed automatically alongside the code, giving it broad coverage at low maintenance cost, and it solves the problem of not being able to see the current state clearly. L4 leans on human judgment and forms a system of its own, so it is out of scope here.
From first output to continuous appreciation, knowledge goes through a complete lifecycle: upfront intervention delivers the first production run, sustained downstream tuning carries it from cold start to steady-state operation, practice identifies which high-value knowledge deserves priority, and a freshness mechanism keeps it current.
Turn the knowledge engine loose without drawing boundaries and it will partition knowledge by code structure rather than business structure, producing a pile of cards that are too coarse, vaguely bounded, and redundant with one another. Once that misalignment is captured, reworking it later costs more than starting over, because you first have to correct every place AI misread, one by one.
Using Qoder's /knowledge-plan command, we have AI perform a full scan of the repository and generate a draft production plan, which people then review and revise: aligning business boundaries, removing ambiguity and redundancy, and adding missing dimensions. The result is a production blueprint AI can read, one that provides direction and dimensional guidance rather than the final knowledge content.
The value of upfront intervention is this: code can only state the structural fact of what exists here, while the business perspective of how to look at it has to be injected by people in advance. In essence, it turns the business understanding inside experts' heads into a blueprint that precedes AI knowledge production.
Getting it right the first time depends on exhaustive foresight, which is expensive and fragile. Risk inside a complex system can never be fully enumerated, and any unanticipated edge condition is enough to break through.
Downstream tuning runs in three steps with Qoder's /knowledge command: identify, organize, write. We pin down what needs improvement and attribute it to specific cards, AI gathers the code facts and upstream and downstream relationships, organizes them into a structured draft, and finally writes them into the knowledge base.
Cold start: concentrated polishing right after the first output. Once the engine has produced in bulk, people run a dedicated review pass over the entire body of knowledge, checking whether boundaries align with business structure, whether terminology is accurate, and whether redundancy or contradiction exists across cards, correcting the systematic drift of automated distillation in one concentrated effort. Once the first batch of business requirements enters AI coding, bad cases expose blind spots in dense succession, and this is when revision frequency peaks.
Steady-state operation: bad cases drive routine revision. Misread terminology during requirement comprehension, module drift during exploration, architecture violations during design, hallucinated output during coding, all of it signals missing knowledge. The response is a fixed three steps: locate, revise, regress. Regression is not about whether a human can follow the text, but about returning to the original task to verify that AI corrects its behavior, and anything that fails goes back for another round. Internally we commit to closing every bad case the same day.
Bad cases are not the only thing worth capturing. Information from good cases that came at a high exploration cost deserves capture just as much. An implicit dependency that took the Agent fifteen rounds to locate, for instance, makes that very path the knowledge for next time. Failure drives us to close gaps and expensive success drives us to cut cost, and together the two push the knowledge base toward maturity.
After the production and tuning described above, a higher-order question gradually surfaces: plenty of knowledge is worth capturing, but which deserves investment first? You cannot fully enumerate the types of high-value knowledge at the outset. Only once the Agent genuinely drifts off course in the same direction repeatedly can you confirm there is a pitfall there. There is only one criterion: without this knowledge, the Agent will most likely drift or pay an excessive exploration cost. The inverse matters just as much. Knowledge that the code already expresses clearly, and that the Agent can reach cheaply, does not need separate capture. Simple utility function signatures or standard library usage, for example, are documented by the code itself, and writing another knowledge card is pure redundancy.
In practice we converged on four categories most worth prioritizing. What they share is that code cannot provide a reliable answer:
Code changes every day, and no one can watch it line by line. We packaged knowledge refresh as a Skill and bound it to the development process through a WebHook on the code platform: a merge into the trunk triggers a callback that spins up an Agent, the Agent pulls the diff for that merge, and QoderCLI completes the incremental knowledge update automatically, with the result pushed to developers as a single message. Knowledge updates are driven by code change events, refreshing on merge, unattended most of the time, with intervention only when something goes wrong.
For the tuning and automatic freshness above to work, there is an implicit prerequisite: knowledge for the same module is not rewritten by several people at once. Reality does not always cooperate.
The cloud side of Qoder's knowledge engine currently uses overwrite-based updates, so in concurrent editing the later write overwrites the earlier one, and capabilities such as review, staged rollout, and rollback are not yet available. Our interim approach routes each module's knowledge through a single Owner, trading parallel efficiency for consistency. As Qoder's knowledge engine progressively supports concurrent editing and version management, efficiency and consistency will eventually come together.
AutoSDK has four kinds of knowledge consumers: AI Agents need structured recall, developers use document search, non-development roles ask about the business without reading code, and external teams integrate through an existing platform. The temptation to write a separate version for each is always there, but the drift and contradiction that follow forking are more fatal than the maintenance cost.
We hold just one line: a single body of knowledge serves both people and AI, never forked. From one source we open different outlets: developers use RepoWiki, AI recalls through SearchMemory, non-developers read QMind online, and external teams sync to KBase through the CLI or API. The first three are produced by Qoder's knowledge engine from the same source and therefore never diverge, while KBase slots into the existing pipeline unobtrusively, forcing no one to change habits.
Nested repositories are everywhere in AutoSDK, with component repositories embedded inside the main project. A developer opens the project in the main repository while component-level knowledge sits scattered across sub-repositories, and if recall stops at the workspace boundary, the earlier production investment is reduced to zero.
We first hit this in a nested component requirement: the Agent searched for knowledge in the main repository and got nothing but main-repository overviews, finding nothing about the key logic living in a sub-repository, so developers had to switch workspaces by hand and the AI coding workflow degraded completely. Qoder's nested recall capability, which lets you configure whether sub-repository knowledge is recalled by the parent directory repository, upgrades knowledge reachability from workspace-bound to repository-structure-bound: open the project in the main repository, and recall covers knowledge cards in both the main repository and every embedded sub-repository, with no switching required.
AutoSDK's AI coding workflow follows a plan-act pattern overall, and one wrong step during planning means rework for everything after it. Without agreed timing and objectives for recall, knowledge is merely a static asset. Qoder's built-in SearchMemory tool indexes knowledge cards, and each stage of the pipeline has a different recall objective:
We evaluate the knowledge system from two angles. The case view dissects how knowledge corrects bad cases through concrete business scenarios. The data view quantifies the measured gains before and after adoption under a controlled definition.
The two representative cases below both follow the same structure: scenario, deviation without knowledge, knowledge intervention, root-cause takeaway.
Scenario: a large-scale refactor of a business component, involving process changes and the retirement of legacy components, with wide-reaching impact.
Deviation without knowledge: AI touched only the component implementation and missed the bound callback parameters and the associated business interfaces. The change looked complete while the path was in fact broken, and because nothing failed immediately, it surfaced only during integration testing, requiring a backward trace across several files to locate what had been left unchanged.
Knowledge intervention: with panoramic business knowledge, AI enumerated the component implementation, callback parameters, and associated business interfaces completely in one pass, correctly drew the boundary against similar components, and finished the refactor in a single attempt with no manual patching.
Root-cause takeaway: the panorama of complex business logic is scattered across many files and call sites, so capturing a view such as "component equals implementation plus style callbacks plus business interfaces" as knowledge is precisely how the most easily missed implicit context gets delivered up front.
Scenario: add a standalone highlight effect for the target lane, with its own color scheme and animation, fully separated from the existing ego-lane highlight.
Deviation without knowledge: three similarly named objects in the code belong to different semantic dimensions, namely target lane style, ego lane style, and adjacent vehicle target marker. AI conflated all three: it first judged the target lane style to be nonexistent and applied the ego lane style instead, then treated the adjacent vehicle target's isHighlight field as a lane highlight switch, requiring the user to paste header files repeatedly across several rounds of correction.
Knowledge intervention: with terminology knowledge, AI clarified everything in one pass, that StyleA and StyleB are independent structs and must never be reused, and that the isHighlight field is a marker at the adjacent vehicle target level and has nothing to do with lane highlighting. It completed the change directly, with no manual code pasting needed.
Root-cause takeaway: the fact that similar naming does not mean identical semantics cannot be read out of code. Capturing the semantic distinctions among similar objects and the separation of cross-dimensional concepts as knowledge blocks interference-type bad cases at the source.
The case view answers how knowledge works, and the data view answers whether the investment is worth it.
Cost: for first production, an average of two hours per repository to complete planning and proofread the production blueprint, with 20-plus business component repositories covered on a weekly cadence. For routine maintenance, driven by bad cases, the analysis, revision, and regression loop for a single piece of knowledge closes within hours.
Primary metric: the strict adjusted one-shot rate, defined tightly. The denominator is tasks that produced code changes within a given period, and the numerator is tasks completed in a single query where 80% of the code was neither rolled back nor modified within 30 minutes. It measures whether AI can grasp the business panorama and its details well enough to get the task right the first time.
After the knowledge system was adopted, the team ran 120-plus tasks in real day-to-day business, spanning simple, medium, and complex difficulty levels and covering requirement types from new features to changes in existing ones. Using this batch as the basis, we ran both a stage comparison before and after adoption and a controlled comparison within the same window based on whether knowledge was actually recalled.
Taking adoption as the dividing line, the strict one-shot rate rose from 37.3% to 61.5% afterward, and the average number of conversation rounds per completed task fell from 3.49 to 2.53. This shows that knowledge not only raised the share of tasks done right the first time, but also lowered the cost of iteration.
The stage comparison above is influenced by multiple factors such as time trends and task composition. To isolate the effect of knowledge itself more directly, we grouped tasks within the same period by whether knowledge was actually recalled. The recall group's interaction path was 39% shorter on average, most pronounced in scenarios that demand a great deal of implicit context, such as complex tasks and large codebases, consistent with the original intent of lowering exploration cost and filling in the business panorama.
It should be noted that these statistics come from real operation, the sample carries distribution bias and fluctuation introduced by changes in member tasks, and whether knowledge was recalled also correlates with task difficulty, knowledge richness, and Agent behavior, so the conclusions are stronger in direction than in absolute value. Even accounting for all of this interference, however, the stage trend and the same-period controlled comparison point to the same signal: the translation of knowledge into results is positive and observable.
This is AMAP AutoSDK's domain knowledge engineering practice built on Qoder's knowledge engine, spanning knowledge production, tuning, refresh, and consumption. The measured data shows the system lifted the strict one-shot rate from 37.3% to 61.5%, cut average conversation rounds by nearly 30%, and shortened the interaction path by 39% for the group where knowledge was recalled.
Qoder's knowledge engine provided the critical support for this practice: /knowledge-plan aligns boundaries up front and removes ambiguity and redundancy before bulk production, /knowledge tunes the knowledge problems that practice exposes, and the built-in SearchMemory tool recalls knowledge cards precisely during requirement comprehension, exploration, and solution design. Native platform support for nested repository recall and for one source with many outlets (RepoWiki, KnowledgeCard, QMind) lets a single source of knowledge serve people and AI at once, avoiding the fatal cost of version drift.
The core of domain knowledge engineering is not how many documents you write, but making sure the same class of error never happens twice. Once your team reaches that point, AI Coding crosses the threshold from usable to trustworthy.
If your team is also pushing AI Coding toward an engineering discipline, these four points are what we would most want to tell ourselves in advance, after the pitfalls we walked into:
Recommendation one: map your knowledge layers before you discuss tooling. Do not start by rolling out an AI assistant. Spend 30 minutes drawing your team's L1 to L4 map first: what the code already expresses (L1), what is scattered terminology (L2), what is the business panorama (L3), and what are design constraints (L4). Once the layers are clear, tool selection converges on its own: hand L1 to L3 to Qoder's knowledge engine for bulk distillation, and leave L4 to senior engineers writing Skills and AGENTS.md. Steer clear of the myth that one large model solves everything.
Recommendation two: start the mechanism with same-day bad case closure, not with a complete knowledge base. Perfectionism is the biggest enemy. Set one iron rule on day one: every bad case in AI Coding gets located, revised, and regression-verified the same day, without exception. Even if only five knowledge cards are captured in the first week, stick with it for three months and you will have a knowledge base with a high signal-to-noise ratio. That is ten times more effective than quietly writing 200 pages of documentation.
Recommendation three: keep only the knowledge that code cannot express and exploration cannot reach cheaply. Filter with a simple rule: if AI can figure it out within three minutes of reading code, do not write it; if AI took fifteen rounds to locate it, or if similar names make it easy to confuse, you must write it. The four categories worth prioritizing are the complex business panorama, hidden pitfalls in code, terminology distinctions, and cross-repository paths. Everything else is noise.
Recommendation four: one source, one version, held from day one. Do not maintain two copies just because people and AI read different formats. Pick one source, such as Qoder RepoWiki, as the single source of truth, and derive everything from it, whether AI consumption, developer lookup, or external inquiries. Forking feels good briefly, and then drift buries you.
AutoSDK is AMAP's in-vehicle SDK product for the automotive industry. It spans more than a million lines of code across twenty-odd Git repositories. With Qoder's knowledge engine, we built a "production, tuning, refresh, consumption" system for business knowledge. The same class of error no longer happens twice, and the one-shot task pass rate rose from 37.3% to 61.5%.The ceiling on AI Coding capability lies not in the model itself, but in domain knowledge. KoCo-Bench measurements bear this out: general-purpose programming clears 90% Pass@1, while domain code generation reaches only 8.9%. Adding domain knowledge retrieval under an Agent paradigm lifts that to 34.2%, with a peak of 62.5% in the best track (arXiv:2601.13240v3). The practice of the AMAP Automotive AutoSDK team confirms this judgment. Our AI coding already runs as an engineering discipline, with requirement comprehension, solution design, code output, and self-testing connected end to end. Yet the stability of single-pass generation, or one-shot, remained the weak link, surfacing as four classes of failure: exploration drift (sinking deeper in the wrong direction), generation deviation (produced code diverging from the intended implementation), architecture violation (ignoring established layering and module conventions), and constraint omission (missing implicit dependencies or cross-module relationships). Root-cause analysis converged sharply: the meaning of business terms, the boundaries of module responsibility, the trade-offs behind historical decisions. None of this domain knowledge had ever been structured into a form AI could consume. The knowledge gap is the real bottleneck for stability. Our goal, therefore, was to upgrade the domain knowledge dormant in code and experience into an engineering asset that AI can perceive, consume, and evolve. The vehicle is Qoder's knowledge engine: code output becomes capture, AI coding becomes consumption, and practical validation becomes feedback, forming a loop that keeps appreciating in value rather than a static document that is outdated the moment it is finalized.
1 | Layers and Boundaries
For the loop to run, knowledge first needs a map: how many layers there are, where each one lives, and where the boundary of this article is drawn.
AutoSDK's domain knowledge is a full spectrum running from low-level code facts up to top-level constraints and preferences. We divide it into four layers by degree of abstraction, and the relationship among them maps onto the DIKW spectrum of cognition.
L1 Code and configuration (the Data layer): the raw facts underlying all knowledge. Everything above is distilled from it, and whenever knowledge conflicts with code, the code always wins.
L2 Terminology and processes (the Information layer): core terms, module information, and critical paths.
L3 Business domain knowledge (the Knowledge layer): responsibility boundaries, architectural rules, and the reasons behind the status quo, helping the Agent understand the business as a whole and avoid design drift.
L4 Constraints and preferences (the Wisdom layer): this layer covers how something should be written and why it is written that way. It holds design constraints, solution preferences, key decisions, API design methodology, and more. Its reach is broad and it is triggered often, so precision is what matters.
The relationship among the four layers runs both ways. Bottom-up, each layer distills the one below it, since all upper knowledge is abstracted from lower knowledge. Top-down, each layer guides execution: AI reads the L4 constraints first, then consults L3 and L2 to understand the current state, and finally lands at L1 to write code. At the same time, the higher the layer, the more it depends on people, and the lower the layer, the more it depends on the engine.
This article focuses on engine-led factual knowledge (L1 through L3). It can be distilled in bulk and refreshed automatically alongside the code, giving it broad coverage at low maintenance cost, and it solves the problem of not being able to see the current state clearly. L4 leans on human judgment and forms a system of its own, so it is out of scope here.
2 | The Knowledge Lifecycle
From first output to continuous appreciation, knowledge goes through a complete lifecycle: upfront intervention delivers the first production run, sustained downstream tuning carries it from cold start to steady-state operation, practice identifies which high-value knowledge deserves priority, and a freshness mechanism keeps it current.
2.1 First Production: Upfront Intervention and Calibration
Turn the knowledge engine loose without drawing boundaries and it will partition knowledge by code structure rather than business structure, producing a pile of cards that are too coarse, vaguely bounded, and redundant with one another. Once that misalignment is captured, reworking it later costs more than starting over, because you first have to correct every place AI misread, one by one.
Using Qoder's /knowledge-plan command, we have AI perform a full scan of the repository and generate a draft production plan, which people then review and revise: aligning business boundaries, removing ambiguity and redundancy, and adding missing dimensions. The result is a production blueprint AI can read, one that provides direction and dimensional guidance rather than the final knowledge content.
The value of upfront intervention is this: code can only state the structural fact of what exists here, while the business perspective of how to look at it has to be injected by people in advance. In essence, it turns the business understanding inside experts' heads into a blueprint that precedes AI knowledge production.
2.2 Tuning and Revision: From First Polish to Bad Case Closure
Getting it right the first time depends on exhaustive foresight, which is expensive and fragile. Risk inside a complex system can never be fully enumerated, and any unanticipated edge condition is enough to break through.
Downstream tuning runs in three steps with Qoder's /knowledge command: identify, organize, write. We pin down what needs improvement and attribute it to specific cards, AI gathers the code facts and upstream and downstream relationships, organizes them into a structured draft, and finally writes them into the knowledge base.
Cold start: concentrated polishing right after the first output. Once the engine has produced in bulk, people run a dedicated review pass over the entire body of knowledge, checking whether boundaries align with business structure, whether terminology is accurate, and whether redundancy or contradiction exists across cards, correcting the systematic drift of automated distillation in one concentrated effort. Once the first batch of business requirements enters AI coding, bad cases expose blind spots in dense succession, and this is when revision frequency peaks.
Steady-state operation: bad cases drive routine revision. Misread terminology during requirement comprehension, module drift during exploration, architecture violations during design, hallucinated output during coding, all of it signals missing knowledge. The response is a fixed three steps: locate, revise, regress. Regression is not about whether a human can follow the text, but about returning to the original task to verify that AI corrects its behavior, and anything that fails goes back for another round. Internally we commit to closing every bad case the same day.
Bad cases are not the only thing worth capturing. Information from good cases that came at a high exploration cost deserves capture just as much. An implicit dependency that took the Agent fifteen rounds to locate, for instance, makes that very path the knowledge for next time. Failure drives us to close gaps and expensive success drives us to cut cost, and together the two push the knowledge base toward maturity.
2.3 What to Capture: Criteria for High-Value Knowledge
After the production and tuning described above, a higher-order question gradually surfaces: plenty of knowledge is worth capturing, but which deserves investment first? You cannot fully enumerate the types of high-value knowledge at the outset. Only once the Agent genuinely drifts off course in the same direction repeatedly can you confirm there is a pitfall there. There is only one criterion: without this knowledge, the Agent will most likely drift or pay an excessive exploration cost. The inverse matters just as much. Knowledge that the code already expresses clearly, and that the Agent can reach cheaply, does not need separate capture. Simple utility function signatures or standard library usage, for example, are documented by the code itself, and writing another knowledge card is pure redundancy.
In practice we converged on four categories most worth prioritizing. What they share is that code cannot provide a reliable answer:
- The panorama of complex business logic: the full path is scattered across multiple files. Without knowledge the Agent explores divergently at high and volatile cost, and with knowledge it converges quickly onto a precise track.
- Hidden pitfalls in the code: code fragments that look alike are the most likely to confuse the Agent. Here knowledge acts as a guardrail for crossing the pitfall smoothly, flagging in advance the paths that look right but are actually wrong.
- Distinguishing business terminology: terms established by convention lack explicit definitions in code, so an Agent search returns nothing but superficially similar answers. Capturing them moves the Agent from needing human correction to passing on the first round.
- Cross-repository paths: data paths spanning multiple Git repositories, as in AutoSDK's lane-level map layer business. Exploration cost is extremely high, and scenarios where the call chain breaks, such as thread switches and message dispatch, are especially hard for AI to explore. A knowledge card belongs to a single repository while describing cross-repository information, which preserves the per-repository organizing framework while restoring the implicit path across the break.
2.4 Staying Fresh: Hook-Triggered Automatic Updates
Code changes every day, and no one can watch it line by line. We packaged knowledge refresh as a Skill and bound it to the development process through a WebHook on the code platform: a merge into the trunk triggers a callback that spins up an Agent, the Agent pulls the diff for that merge, and QoderCLI completes the incremental knowledge update automatically, with the result pushed to developers as a single message. Knowledge updates are driven by code change events, refreshing on merge, unattended most of the time, with intervention only when something goes wrong.
2.5 Collaboration Mechanisms and Evolution
For the tuning and automatic freshness above to work, there is an implicit prerequisite: knowledge for the same module is not rewritten by several people at once. Reality does not always cooperate.
The cloud side of Qoder's knowledge engine currently uses overwrite-based updates, so in concurrent editing the later write overwrites the earlier one, and capabilities such as review, staged rollout, and rollback are not yet available. Our interim approach routes each module's knowledge through a single Owner, trading parallel efficiency for consistency. As Qoder's knowledge engine progressively supports concurrent editing and version management, efficiency and consistency will eventually come together.
3 | Knowledge Consumption
3.1 One Source, Many Outlets
AutoSDK has four kinds of knowledge consumers: AI Agents need structured recall, developers use document search, non-development roles ask about the business without reading code, and external teams integrate through an existing platform. The temptation to write a separate version for each is always there, but the drift and contradiction that follow forking are more fatal than the maintenance cost.
We hold just one line: a single body of knowledge serves both people and AI, never forked. From one source we open different outlets: developers use RepoWiki, AI recalls through SearchMemory, non-developers read QMind online, and external teams sync to KBase through the CLI or API. The first three are produced by Qoder's knowledge engine from the same source and therefore never diverge, while KBase slots into the existing pipeline unobtrusively, forcing no one to change habits.
3.2 Recall Across Nested Repositories
Nested repositories are everywhere in AutoSDK, with component repositories embedded inside the main project. A developer opens the project in the main repository while component-level knowledge sits scattered across sub-repositories, and if recall stops at the workspace boundary, the earlier production investment is reduced to zero.
We first hit this in a nested component requirement: the Agent searched for knowledge in the main repository and got nothing but main-repository overviews, finding nothing about the key logic living in a sub-repository, so developers had to switch workspaces by hand and the AI coding workflow degraded completely. Qoder's nested recall capability, which lets you configure whether sub-repository knowledge is recalled by the parent directory repository, upgrades knowledge reachability from workspace-bound to repository-structure-bound: open the project in the main repository, and recall covers knowledge cards in both the main repository and every embedded sub-repository, with no switching required.
3.3 Knowledge Consumption in the AI Coding Workflow
AutoSDK's AI coding workflow follows a plan-act pattern overall, and one wrong step during planning means rework for everything after it. Without agreed timing and objectives for recall, knowledge is merely a static asset. Qoder's built-in SearchMemory tool indexes knowledge cards, and each stage of the pipeline has a different recall objective:
- Requirement comprehension: recall knowledge using keywords from the PRD such as interface names, protocol names, functional concepts, and terminology, then assess how well it matches. Strong matches enter the component candidate set and are cross-checked against AGENTS.md, while weak matches and misses are ignored, which prevents misread terminology from routing work to the wrong component.
- Exploration: first recall background such as module architecture, coding patterns, and technical constraints using the exploration topic and target component as keywords, then begin searching code. Every time a key new symbol appears, such as a core class name, a critical interface, or an unexpected dependency, immediately recall its responsibilities and its upstream and downstream relationships. Recall does not block the search and a miss does not impede progress, but a hit narrows the search space substantially and avoids blind traversal.
- Solution design: hold to dual-source fusion, with research leading and knowledge supporting. First recall domain background and evolution direction using domain terminology, key function names, and historical design strategies, retrying with different wording on a miss up to a set limit. Then launch a code investigation and cross-check the prior knowledge against the code on the ground, which avoids design drift.
4 | Evaluating the Results
We evaluate the knowledge system from two angles. The case view dissects how knowledge corrects bad cases through concrete business scenarios. The data view quantifies the measured gains before and after adoption under a controlled definition.
4.1 The Case View: How Knowledge Corrects Bad Cases
The two representative cases below both follow the same structure: scenario, deviation without knowledge, knowledge intervention, root-cause takeaway.
Case One: A Missed Panorama of Complex Business Logic
Scenario: a large-scale refactor of a business component, involving process changes and the retirement of legacy components, with wide-reaching impact.
Deviation without knowledge: AI touched only the component implementation and missed the bound callback parameters and the associated business interfaces. The change looked complete while the path was in fact broken, and because nothing failed immediately, it surfaced only during integration testing, requiring a backward trace across several files to locate what had been left unchanged.
Knowledge intervention: with panoramic business knowledge, AI enumerated the component implementation, callback parameters, and associated business interfaces completely in one pass, correctly drew the boundary against similar components, and finished the refactor in a single attempt with no manual patching.
Root-cause takeaway: the panorama of complex business logic is scattered across many files and call sites, so capturing a view such as "component equals implementation plus style callbacks plus business interfaces" as knowledge is precisely how the most easily missed implicit context gets delivered up front.
Case Two: Semantic Confusion Among Similar Structs
Scenario: add a standalone highlight effect for the target lane, with its own color scheme and animation, fully separated from the existing ego-lane highlight.
Deviation without knowledge: three similarly named objects in the code belong to different semantic dimensions, namely target lane style, ego lane style, and adjacent vehicle target marker. AI conflated all three: it first judged the target lane style to be nonexistent and applied the ego lane style instead, then treated the adjacent vehicle target's isHighlight field as a lane highlight switch, requiring the user to paste header files repeatedly across several rounds of correction.
Knowledge intervention: with terminology knowledge, AI clarified everything in one pass, that StyleA and StyleB are independent structs and must never be reused, and that the isHighlight field is a marker at the adjacent vehicle target level and has nothing to do with lane highlighting. It completed the change directly, with no manual code pasting needed.
Root-cause takeaway: the fact that similar naming does not mean identical semantics cannot be read out of code. Capturing the semantic distinctions among similar objects and the separation of cross-dimensional concepts as knowledge blocks interference-type bad cases at the source.
4.2 The Data View: Investment and Measured Gains
The case view answers how knowledge works, and the data view answers whether the investment is worth it.
Cost: for first production, an average of two hours per repository to complete planning and proofread the production blueprint, with 20-plus business component repositories covered on a weekly cadence. For routine maintenance, driven by bad cases, the analysis, revision, and regression loop for a single piece of knowledge closes within hours.
Primary metric: the strict adjusted one-shot rate, defined tightly. The denominator is tasks that produced code changes within a given period, and the numerator is tasks completed in a single query where 80% of the code was neither rolled back nor modified within 30 minutes. It measures whether AI can grasp the business panorama and its details well enough to get the task right the first time.
After the knowledge system was adopted, the team ran 120-plus tasks in real day-to-day business, spanning simple, medium, and complex difficulty levels and covering requirement types from new features to changes in existing ones. Using this batch as the basis, we ran both a stage comparison before and after adoption and a controlled comparison within the same window based on whether knowledge was actually recalled.
Stage Comparison: Before and After the Knowledge System
Taking adoption as the dividing line, the strict one-shot rate rose from 37.3% to 61.5% afterward, and the average number of conversation rounds per completed task fell from 3.49 to 2.53. This shows that knowledge not only raised the share of tasks done right the first time, but also lowered the cost of iteration.