AI Native Product Development Workflow

​

Solution Architecture

The real difficulty enterprises face with AI coding is not that the model cannot write code — it is that a single success is hard to reproduce. Requirements are relayed by people round after round, and context leaks across turns. Agents that do not understand business boundaries or historical decisions are especially prone to getting the feature "right" while breaking the system, particularly in legacy codebases. Generation speed has gone up, but review and test capacity has not expanded with it, so defects flow downstream carrying a "passed" label. These three problems point to process, knowledge and quality respectively; missing any one of them makes scaling impossible.

This solution organizes AI coding into a reproducible pipeline along the development timeline, with one horizontal support layer above it and one below:

• Four-stage SDLC pipeline — requirements clarification, solution design, code development and verification unfold in sequence. Stages cannot be skipped, artifacts land automatically, and control flow is separated from data flow. Every stage exit carries an independent gate; a failure loops back in place or escalates to a human, so problems never enter the next stage. While uncertainty remains, work stays in Qoder IDE with a human correcting in the loop; once goals, boundaries and acceptance criteria are stable, the task is delegated to Qoder for asynchronous execution.
• Knowledge supply layer — repository knowledge and code facts form the agent's cognitive base. Hard constraints load deterministically, domain knowledge is retrieved through scope routing plus hybrid recall, and the result is verified against facts and trimmed to a task context package. Precision matters more than volume.
• Quality and evolution layer — deterministic problems go to rules and Hooks; semantic problems go to independent review with bounded evaluation criteria. Execution is separated from inspection, retries are capped and escalation paths are defined. Runtime data flows back for attribution, intervention and verification, turning every lesson into an earlier constraint.

The dependency among the three is as follows. Without the pipeline, guardrails have nowhere to attach and knowledge does not know at which step to be injected. Without knowledge supply, a well-governed process merely completes the wrong thing in an orderly way. Without observability and feedback, constraint density never grows by itself. Enterprise adoption should follow the same order: build the skeleton so that successful runs become reproducible, then thicken the guardrails to stop high-frequency errors, and finally close the loop so the system runs ever more smoothly.

​

Key Advantages

​

Advantage 01: A stage-gate topology that makes delivery reproducible

The stages a delivery must pass through are explicitly defined, each stage exit has an independent gate, artifacts land in structured form, agents pass paths rather than payloads, and execution order is carried by the system instead of maintained by the agent itself. This resolves the losses caused by humans acting as an "information relay": context dropped in transit, constraints forgotten midway, and a process that cannot be traced. The same requirement, run by another person or on another day, no longer drifts.

​

Advantage 02: Human-in-the-loop and contract-driven async as two modes, split by uncertainty

While the requirement or blast radius is still unclear, work stays in Qoder IDE with a human correcting synchronously in small steps. Once goals, boundaries and acceptance criteria are stable, the task is written as a contract and delegated to Qoder for asynchronous execution, with humans intervening only at key gates. This prevents two opposite mistakes: forcing exploratory work into long autonomous agent runs, and keeping already well-defined batch work inside the narrow bandwidth of human attention.

​

Advantage 03: Understand the legacy system first, then design the increment

Runtime exploration, static scanning and business knowledge are cross-checked, and conclusions clearly separate confirmed, uncertain and needs-decision items. Impact analysis covers callers, configuration branches, asynchronous jobs and data compatibility, and from there fixes the regression baseline that must not break. This addresses the failure mode where AI sees only the increment, misses legacy constraints, and treats "not visible" as "no longer needed".

​

Advantage 04: Task contracts and guardrails, with execution separated from inspection

Rules define what may and may not change, Skills capture standard operations, and Hooks fire deterministic checks before and after key actions. The inspecting agent is isolated from the executing agent, and verdicts converge into four states: pass, pass with warnings, fail, and escalate to a human. This removes the structural bias of "grading your own paper", and the drift of boundaries that exist only inside a prompt and erode under context noise.

​

Advantage 05: Knowledge engineering that supplies accurate context

Hard constraints load deterministically first; domain knowledge is recalled through scope routing plus hybrid retrieval, expanded within bounds along dependency and upstream/downstream relations, then verified against status, version and current code facts before being trimmed into a budget-controlled task context package. This resolves the paradox of insufficient and excessive knowledge occurring at once — in a long document, only a small portion actually determines the implementation.

​

Advantage 06: A self-evolving loop that keeps constraint density growing

Runtime data reconstructs execution across three layers — metrics, traces and logs. Anomalies are attributed to process, context or role boundaries; interventions land only after a human decides; and before-and-after comparison verifies that the problem truly converged without introducing new false positives. This addresses lessons that stay in individual memory and the same pitfall being hit repeatedly. There is only one criterion: whether the exposure point of a given error class has moved earlier.

​

Business Scenarios

​

Scenario 01: 0-1 new project development — converge intent first, then amplify generation

Converge fuzzy intent into an explicit contract first, then let the agent amplify generation in parallel under that contract.

• Customer problem: a new project has no legacy baggage — and no safety net either. The moment business goals, domain boundaries, interface contracts and non-functional requirements stay vague, the agent does not stop to ask. It fills the blanks with plausible-looking defaults and hardens those unconfirmed decisions into code at high speed. Once generation cost approaches zero, the biggest waste is no longer writing slowly, but building the wrong thing very quickly.
• Trigger: a new product, module or service starts from scratch; the target may be a throwaway prototype, a market-facing MVP, or a production-grade system.
• Platform and agent actions: requirements clarification converges goals and scope, users and core scenarios, domain model and business rules, then acceptance criteria and non-functional requirements → solution design diverges before converging, fixes product, experience and technical boundaries, and stands up the engineering skeleton, with tech stack, directory structure, test framework and CI/CD designed to be agent-friendly from day one → code development lays down scaffolding and the engineering baseline first, then generates in parallel along the dependency topology once shared contracts are stable, executing in small steps with batch commits → verification establishes the quality baseline while proving the system actually works. Engineering rigor scales with the target: prototypes iterate quickly in Qoder IDE under a lightweight contract; an MVP needs complete requirement and design input and is generated in parallel by Qoder; a production-grade system additionally requires non-functional and security baselines, full CI/CD, and human gates.
• Deliverables: decidable acceptance criteria and non-functional baselines; engineering skeleton and scaffolding; code and tests generated under contract; a reusable set of AI-native development assets, including Rules, Skills, templates and repository knowledge.
• Definition of done: not "the agent produced a system that runs", but the system meets business goals, the design has been confirmed, quality is backed by evidence, and every key decision was made by a human and left on record.
• Human gates: product signs off goals and scope; development and architecture confirm the domain model, shared contracts and engineering skeleton; non-functional and security baselines are approved; acceptance happens before release.

​

Scenario 02: Legacy iteration — understand the existing system first, then design the increment

Establish a traceable understanding of the legacy system and its regression baseline first, then map the increment into a controlled change plan.

• Customer problem: the real rules of a legacy system are scattered across code branches, configuration centers, message consumers, scheduled jobs and people's experience. An agent that sees only the increment and misses those constraints may get the feature "right" while breaking the system. A retired UI does not mean the backend path has stopped, and no static reference does not mean nothing calls it in production.
• Trigger: a legacy module needs an addition or change, with scope ranging from a local edit to cross-module iteration or architectural refactoring.
• Platform and agent actions: requirements clarification states the increment goals and non-goals together, cross-checking runtime exploration, static scanning and business knowledge, with conclusions split into confirmed, uncertain and needs-decision → impact analysis covers callers, callees, configuration branches, asynchronous jobs and data compatibility, and fixes the regression baseline that must not break → solution design builds an impact map that lands on modules, files, classes and code actions, forming a contract with task breakdown, dependency order, edit boundaries, validation plan and rollback path → code development isolates changes in a Worktree execution environment, stabilizes shared contracts before starting upper-layer tasks, and runs each batch through the loop of minimal edit, build and local test, diff review, evidence capture and independent commit, with Hooks performing deterministic checks around key actions → verification expands level by level: engineering correctness, functional correctness, system runnability and behavioral equivalence, while high-risk refactoring also compares old and new behavior to confirm the non-target scope is unchanged.
• Deliverables: legacy cognition baseline and tiered impact list; change contract and impact map; incremental code and tests; dual evidence of functional acceptance and legacy regression; updated repository knowledge, Rules, Skills and regression baselines.
• Definition of done: the new capability meets its goals, and there is no evidence that existing behavior outside the target scope was broken — the change succeeds only when both hold.
• Human gates: product confirms business goals, non-goals and whether a capability is retired, and uncertain capabilities may not be deleted by the agent on its own; development and architecture approve module responsibilities, shared contracts and high-impact code actions; execution stops and escalates when permissions widen, failures repeat, or a prohibited scope is about to be touched; release happens only after independent regression and acceptance pass.

​

Scenario 03: End-to-end agent delivery — requirement in, code out

Hand describable, verifiable, write-back-able small-loop work to the agent as a whole, with humans confirming only at key nodes.

• Customer problem: the supply of tasks is outpacing human processing bandwidth. User feedback and production issues keep accumulating, a long tail of small requests eats development concurrency, and work items can only advance while a person is online and able to switch context. Backlogs like this cannot be scaled away by adding headcount.
• Trigger: defect reports, experience feedback and low-risk small-loop work — configuration changes, rule completion, compatibility fixes, documentation and tooling improvements — enter the queue, with a stable intake and decision rules that can be captured as an SOP.
• Platform and agent actions: work items sync in from the development collaboration platform and a human triages them on the board → once claimed, the agent automatically opens subtasks for clarification, planning, development, testing and code review → context engineering packages the work into something the agent can understand, and team SOPs are hardened into executable process contracts as development templates → each task runs in an isolated, recoverable workspace that can resume after interruption → stage outputs and status are written back onto one timeline, forming an acceptable evidence chain → when information is insufficient, scope changes, or a high-risk decision appears, the agent requests human confirmation.
• Deliverables: claimable work items with a subtask timeline; contract-based development templates and work packages; delivery results carrying an evidence chain of changes, tests and reviews.
• Definition of done: "completed" is not "acceptable" — stage outputs, test and review evidence must be complete and written back to the work item, and delivery counts only after human confirmation at key nodes.
• Human gates: triage and suitability judgement, including whether the intake is stable, whether the rules can be captured as an SOP, and whether nodes exist that must be confirmed by a human; scope changes and high-risk decisions; final acceptance.

​

Reference Practice

​

Practice Name

AutoSDK at AMAP's Automotive Business Unit: AI-native full-chain iteration on a million-line C++ legacy SDK

​

Practice Background

• Customer and business: AutoSDK, from AMAP's automotive business unit, is an in-car navigation SDK for the automotive industry, with a cumulative million lines of legacy C++ code across more than twenty Git repositories. Many automakers build on it through secondary development and have already shipped it in mass production.
• Industry constraints: automotive-grade delivery requires every shipped line of code to withstand long-term validation in real-world conditions. Any breaking change may cascade to dozens of downstream automakers, and can even affect production-line cadence and OTA plans for vehicles already in mass production.
• Prior process: AI coding followed a pattern of generation combined with after-the-fact inspection, backed by human effort. Once scaled, review could not keep up with output and quality varied by individual.
• Core problem: single-shot stability was the weak point, surfacing as four failure classes — exploration going off track, generation deviating from intent, architecture being violated, and constraints being missed. Attribution converged tightly: domain knowledge such as the meaning of business terms, module responsibility boundaries and historical design trade-offs had never been structured into a form AI could consume. Input noise was extreme as well — a PRD carried roughly 200k of context, while the rules that actually determined the implementation accounted for only about 10k.
• Pilot scope: more than twenty AutoSDK business component repositories, covering the full chain of knowledge production and consumption, the end-to-end pipeline, quality guardrails and the self-evolving loop.

​

Practice Approach

• How events enter: once a requirement enters the pipeline, dedicated roles hand it forward; merges into the trunk trigger incremental knowledge updates; gate rejections and degrading observability metrics trigger the improvement loop.
• How the control layer routes: knowledge is first mapped into layers — from code facts, terminology and processes, to business domain knowledge, to constraints and preferences. Factual layers are extracted in bulk by the Qoder knowledge engine, while experience-based judgement is written by senior engineers into Skills and AGENTS.md. Capability assets are isolated across three layers — general, domain and process — and the allow-list is locked once during orchestration, so a development role cannot reach verification capabilities.
• How agents execute: the process is split into stages such as intent recognition, orchestration planning, code investigation, domain design, implementation and automated verification, each handled by a dedicated agent. Every executing agent is paired with an independent inspector that escalates layer by layer — second-level script interception, structural validation, then deep domain checks. Context is governed by category: resident, retrieved on demand, isolated within a role, or settled as a stage artifact. Agents pass paths rather than payloads. Deterministic problems are validated and rewritten by Hooks before a write lands, while semantic problems are graded by an independent review agent.
• How results are written back: knowledge is written into the knowledge base after planning, production and tuning, and the same knowledge serves humans and AI without forking into separate versions. Execution data settles across metrics, traces and logs. Inspection verdicts and rejection records enter the loop and become input for rules, Skills and process optimization.
• How failures flow back: every bad case is handled in three fixed steps — locate, revise, regress. Regression does not rely on whether a human can understand the text; it returns to the original task to verify whether the AI's behavior was corrected, and goes back for rework if not. Gate retries are capped at two rounds before handover to a human.
• Where humans decide: the knowledge production blueprint is reviewed and revised by humans; the two tone-setting steps — design and implementation — add human confirmation on top of machine inspection; improvement proposals are generated by the system and decided by human review, with reasons recorded on rejection to prevent repeated suggestions.

​

Practice Flow

​

Practice Results

• Delivery quality and efficiency: defect leakage down about 73%, code adoption rate at 84%, and instrumented API-convention compliance at 80%. For requirements with clear definitions and mature constraints, the end-to-end delivery cycle shifted from monthly to weekly iteration.
• Direct gains from the knowledge system: after the knowledge system landed, the strict one-shot success rate rose from 37.3% to 61.5%, and the average number of conversation turns per task fell from 3.49 to 2.53. In a controlled comparison over the same period, grouped by whether knowledge was actually recalled, the recall group shortened its interaction chain by about 39% on average, most notably in complex tasks and large codebases.
• Process and cost optimization: after the investigation stage supported parallel instances, its average duration dropped about 50%, and total process time fell from 1.5 hours to under 1 hour. The main agent's average context usage fell from 70% to 50%. The four inspection gates now produce consumable pass and rejection data continuously, with pass rate up 50%.
• Verified loops: the knowledge loop of production, tuning, updating and consumption means the same class of error does not happen a second time; gate rejection records turn into process constraints carried by default after attribution, intervention and verification.
• Not yet covered: post-hoc consolidation remains the least mature of the three defense lines, and turning a piece of feedback into an effective rule still relies mainly on human judgement. Business-logic review is still evolving. Multi-author knowledge editing still lacks mature review, staged rollout and rollback, so the interim practice is to funnel each module's knowledge to a single owner.

​

Recommended Product Combination

Only the products required to deliver this solution are listed. Repository knowledge and retrieval, Rules and Skills, Hooks, Worktree-isolated execution and MCP extensions are built into the products below.