Hisense built a complete AI-native development system with Qoder, improving new system development efficiency by 3–4x.
The Digital Quality Center at Hisense Group serves 46 product companies across the group, covering more than 100 self-developed systems in R&D, manufacturing, supply chain, marketing, and other domains. The technology stack is diverse and the legacy burden is heavy — no single development model could accommodate this diversity.
What troubled the R&D team most was never "not being able to write code." It was this: when newcomers took over legacy projects, documentation was missing, knowledge was fragmented, and the learning curve was steep; a great deal of time was spent on repetitive work; online error troubleshooting was time-consuming, and code reviews could not catch every hidden risk.
When large language models surged in 2023, we saw the possibility of solving these problems. But the programming tools at that time only stayed at the level of "local completion," while network stability and security compliance were non-starters.
In January 2025, as the SDD development model matured, we began product exchanges with the Qoder team. In February, we organized a pilot with nearly 100 people, and in March, Qoder was officially introduced. To date, more than 900 people are using it.
The essential difference between Qoder and earlier tools is that it is not just a completion engine, but a complete AI-native development workbench — Rules, Skills, Memory, Repo Wiki, and expert panel collaboration together form all the infrastructure we need to land AI-native development.
Around Qoder's capability matrix, we built an internal engineering system called Harness — used to "harness" AI so that it could deliver stably across 109 systems.
● High-code scenarios (accounting for more than 70%) — further divided into three categories:
● Category A: new system development from scratch, with Qoder participating throughout;
● Category B: new module development on legacy systems, using Repo Wiki to understand existing code before generating;
● Category C: modification of existing modules in legacy systems, requiring a large amount of historical knowledge to be injected before the Agent steps in.
● Low-code scenarios — mainly using Qoder to generate configuration logic and glue code;
● Other scenarios — such as documents, test scripts, and other auxiliary outputs.
Qoder's Quest-SDD (Spec-Driven Development) turns requirements directly into executable development specifications. The granularity and clarity of the Spec directly determine the quality of the first code generation, and also affect the number of subsequent human-AI interaction rounds. We conducted two real-world practices:
Practice 1: Big Spec vs. Small Spec. The big Spec had 300 lines and 75 tasks; the small Spec had 70 lines and 12 tasks. The result — the big Spec's first-pass completion rate was only 60%, and it took dozens of additional conversations to barely finish; the small Spec reached a 95% first-pass completion rate.
Practice 2: The Same PRD, Three Ways of Handling It. Letting Qoder generate the Spec directly → first-pass completion was only 70%, and more than 50 rounds of clarification were still needed. After engineers and product managers aligned line by line and updated the Spec → completion improved significantly. Adding human-machine alignment (letting the Qoder Agent ask questions to confirm understanding) → completion approached 100%, with basically no follow-up modifications needed.
From this, we established Spec quality standards:
● Under current mainstream model capabilities, a single Spec should in principle be kept under 100 lines and no longer than 150 lines;
● Every constraint must be convertible into a test case to ensure requirement clarity and verifiability, and to provide a basis for subsequent AI verification;
● If a single Spec requires more than 10 rounds of human-machine correction after code generation, the original Spec quality is likely insufficient, and we should return to the Spec stage to realign.
We say that AI Coding has entered the AI-autonomous stage, characterized by building feedback loops to realize "Human on the loop," executing long-cycle tasks through multi-agent collaboration, and completely liberating humans. With Qoder and various open-source Skills, we were able to quickly build multi-agent feedback loops. On the one hand, in the loop, applications undergo AI verification and review, with automatic repair, ensuring that the software gradually converges on requirements. On the other hand, every workflow process can precipitate knowledge, enabling optimization of Harness.
We believe that testing becomes even more important in AI development, because model hallucination objectively exists and testing is an important means of combating it. After AI generates a Spec, test cases must be generated simultaneously, and the test cases must be strictly reviewed, especially to ensure completeness of boundary conditions. Test cases should be included in the Git repository as an important component of Harness. The testing Agent must use a different model from the coding Agent. In practice, we found that asking the Qoder Agent to fix all defects at once often yields poor results; but asking it to fix only one defect at a time works very well.
Similarly, running 100 test cases in 10 batches across 10 independent contexts yields more defects found and lower missed-detection rates than merging them into one context for a single test run.
Therefore, our feedback loops always break tasks down to the smallest granularity — small-batch execution, fix one by one, and continuous verification. Qoder's Agent capabilities make this high-frequency iteration feasible.
With 109 systems and diverse technology stacks, keeping architecture from drifting over long-cycle iterations requires constraints that are no less important than capabilities. The core principle is simple: without guardrails, the more AI produces, the faster the codebase entropy grows.
Around this principle, we built a set of specifications and Skill systems covering the entire development chain, managed in tiers by priority: P0 locks down architectural boundaries and compliance baselines, P1 covers coding core, and P2 focuses on maintainability. At each stage, the corresponding combination of constraints is injected on demand to limit Agent behavior boundaries and let AI work within the correct framework.
Knowledge governance is the foundation that continuously increases the value of the first three capabilities. We carry it through a three-layer system of AGENTS.md + Repo Wiki + Skills.
AGENTS.md is a project-level structured knowledge map — an approximately 100-line entry file serves as a directory navigator, appropriately replacing bulky, comprehensive manuals. It uses progressive disclosure to push the information needed by AI on demand at different stages of a task, reducing context redundancy. Each project's architectural decisions, coding standards, technology stack conventions, and known pitfalls are all structured and accumulated, so that new members and new Agents reading the same AGENTS.md gain a consistent project understanding.
Repo Wiki automatically generates and continuously maintains project documentation — complete structure, with code references, intuitive and clear. After code updates are committed, the Wiki is synchronized and updated, keeping design and implementation aligned — something that was almost impossible in the past.
Skills turn individual experience into reusable organizational capability. These are not "configuration files," but the real moat for enterprises using AI. With this knowledge, AI is no longer a newcomer but a seasoned hand trained by the enterprise.
We selected 10 pioneer projects for the pilot:
● For new system development, conservative estimates show a 3–4x efficiency improvement, with go-live times greatly accelerated. By year-end, we expect to reach 5–6x.
● Development on historical systems showed limited improvement — the main bottleneck being the implicit knowledge in legacy baggage that needs to be gradually extracted and injected through Qoder Rules.
Projects that improved well shared one common trait: in the early stages of development, they did not rush to generate code, but spent a lot of time aligning requirements in Qoder Spec. The requirements phase accounted for more than 40% of the entire development process — only after requirement quality was up to standard did they move into the generation phase.
To unlock the ultimate efficiency of AI-native development, tool improvement is only half the equation; the other half is process adaptation. Around Qoder, we are exploring a new process:
In the past, the process was linear: requirements → design → development → testing → deployment, with handoffs at every stage. Now coding, testing, and review form a continuous loop within Qoder, and "small steps, fast running" moves from concept to daily practice. Iteration on long-cycle tasks no longer causes architectural drift, because constraints and context remain online.
At the requirements stage, Qoder is used to generate test cases covering boundary conditions. Every constraint in the Spec must correspond to a verifiable test case — this is the key defense line against model hallucination later on. Test engineers shift their focus from "finding bugs" to "reviewing test case quality."
Development engineers no longer write code line by line, but focus on result review, architecture drift detection, and knowledge accumulation. Test engineers focus on test case quality and result review. Product managers deeply participate in Spec quality control.
Process reshaping is the work that yields the greatest returns. We are still exploring, but the direction is clear — redefine the boundary of "what humans do and what AI does" around Qoder.
Do not roll it out to everyone at once. First find a small team willing to embrace AI, and choose a new project as the starting point. New projects have no legacy baggage, making it easiest to run through the complete chain from requirements to delivery, and easiest for the team to build intuition about AI capabilities. Use it first, see results, then talk about scaling.
After the pilot is running, gradually build the Harness engineering system for different business scenarios. AI development without Harness has uncontrollable output, architecture prone to drift, and quality dependent on luck. The value of Harness lies in using specifications, constraints, and feedback loops to frame AI's behavior boundaries, so that every output is stable, predictable, and reviewable.
Rules, Skills, AGENTS.md, and Repo Wiki — these are not "configuration files," but the real moat for enterprises using AI. With Qoder's knowledge system, accumulate the team's architectural decisions, business rules, historical experience, and technical standards as digital assets. The gap between AI tools will gradually narrow, but the accumulation of enterprise private-domain knowledge is irreplaceable. When knowledge governance is done well, AI is no longer a newcomer but a seasoned hand systematically trained by the enterprise — this is the real long-term moat.
Our work used to be "human-led, tool-assisted." Now it is becoming "human and Qoder co-producing."
The most important capability for engineers is no longer writing code, but clarifying intent, breaking down requirements, and building the environment. Qoder helps us solve tedious, repetitive execution, so that creativity is no longer limited by "not knowing how to write a certain kind of code."
We have already seen the direction — Spec quality determines software quality, process adaptation determines the ceiling of efficiency gains, and the knowledge accumulated on Qoder determines the long-term moat. The future of R&D is a process of humans and AI evolving together.