MIIT’s AI+software plan needs one unit of proof: the accepted change

MIIT officials and software-industry representatives at the September 11, 2026 “AI+software” press briefing. Photograph by Zhang Rui for Daily Economic News; this copy is resized from the published original.[3]

China has put a large number on the spread of coding AI. By 2028, the Ministry of Industry and Information Technology wants high-level intelligent programming tools and development platforms to cover 20,000 software companies above the designated-size threshold. The same plan calls for 100 intelligent-transformation projects at software companies, 100 exemplar agent-software applications in important industries, at least five high-quality open-source projects, and at least 15 adaptation centers for foundational software and hardware.[1]

Those targets reveal ambition and distribution capacity. They do not, by themselves, reveal whether a generated patch survived contact with a real repository.

The more useful unit of progress is an accepted change: a bounded modification whose origin is recorded, whose tests and policy checks are attached, whose reviewer understands the remaining risk, and whose release can be observed and reversed. This is not a metric named in MIIT’s September plan. It is an analytical unit suggested by the plan’s own architecture, which joins coding tools to repositories and cloud services, makes code quality and R&D efficiency relevant to policy support, embeds security testing through the lifecycle, and calls for access controls and security review of AI-generated code.[1][2]

That distinction matters because “20,000 companies covered” measures the mouth of a software supply chain. Value appears at the other end.

A reach target is not a performance result

The plan, issued as MIIT document No. 209 of 2026, places software-production transformation first among six workstreams and makes intelligent programming its opening task. It asks for agent-driven tools with project-level, end-to-end development ability and for integration with code-hosting platforms, cloud services, and open-source communities. It also encourages local authorities to treat code quality, R&D efficiency, and other demonstrated outcomes of intelligent-programming adoption as important evidence when directing existing support toward software companies.[1]

That is more substantial than a mandate to buy assistant seats. Yet the published document does not define what qualifies a company as “covered.” It does not say whether one activated account, a monthly-active-user threshold, a share of repositories, or verified use across the development lifecycle satisfies the target. Nor does it publish a common baseline for code quality or development effectiveness.[1]

This leaves two very different implementations compatible with the headline. In the thin version, a vendor connects a tool, reports licenses or users, and declares adoption. In the thick version, a company changes how work moves from requirement to code, test, review, deployment, incident response, and maintenance. The first can scale quickly and still leave the economics unknown. The second is slower to document, but it can show whether AI shortened or merely displaced work.

MIIT’s accompanying explainer leans toward the thicker reading. It describes intelligent programming across requirements analysis, code generation, and test validation; it also anticipates jobs in code review and AI security rather than treating generated code as a finished product.[2] The plan says implementation should use code quality, R&D efficiency, and other demonstrated outcomes as evidence and should refashion software-development workflows.[1] The acceptance gate is where those ambitions become measurable.

The coding model sits at the start of a longer stack

A prompt-to-patch demo compresses the system into two visible objects: a request and some code. An enterprise change depends on at least five layers.

The first is the generation layer: model, coding client, agent runtime, retrieval method, and tool versions. A provider can improve one of these without changing the rest. A model alias can also move while the product name stays constant, so a result that records only the assistant brand is difficult to reproduce.

The second is the context and authority layer. The tool sees some combination of source files, issues, build logs, internal documentation, secrets, and dependency metadata. Its identity may be allowed to read a repository, open a pull request, run a build, or deploy an artifact. More autonomy increases the number of useful tasks it can finish—and the blast radius of a compromised instruction or an incorrect plan. MIIT explicitly calls for access control around development tools and code repositories and for defenses against malicious instruction injection.[1]

The third is the change artifact. A patch needs a declared purpose, links to the requirement or defect it addresses, and enough provenance to distinguish human-written, AI-suggested, and agent-executed work. Recording provenance need not mean retaining every sensitive prompt. A compact receipt can bind the change to a tool and model version, the authorized repository scope, relevant input references, and the human who submitted it for review.

The fourth is the verification layer: build, unit and integration tests, static analysis, dependency and license checks, security review, and—where the behavior matters—an executable acceptance test. MIIT asks companies to use large models and programming tools for vulnerability discovery, defect recognition, and risk classification, while embedding intelligent security testing throughout software development.[1] That makes AI both a producer and an inspector. It does not make the two judgments independent; a test generated from the same mistaken interpretation as the patch can confidently confirm the wrong behavior.

The fifth is the release layer. A reviewer accepts residual risk, the change is merged into a named branch, a build becomes a deployable artifact, and production evidence determines whether it stays. Feature flags, staged rollout, monitoring, incident linkage, and rollback turn a code review decision into an operationally accountable one. Without this layer, “accepted” can mean only that a plausible diff reached the main branch.

The chain can therefore yield several honest denominators: generated changes, changes proposed for review, changes accepted, changes deployed, and changes retained after an observation window. Collapsing them into “AI-written code” erases where the work and failures went.

The receipt should travel with the patch

For a conventional change, teams already keep fragments of this evidence in issue trackers, commits, continuous-integration systems, review logs, artifact registries, and deployment platforms. Coding agents make the joins more important. A useful acceptance receipt would connect:

the requirement, repository, base revision, model and tool version;
the patch plus any generated migrations, tests, or configuration;
the exact checks run, their environments, and their results;
security, dependency, license, and policy findings;
the reviewer’s decision and material overrides; and
the built artifact, rollout, monitoring window, and rollback route.

This is a proposed evidence structure, not a disclosed Chinese reporting template. A useful outside comparator is the US National Institute of Standards and Technology’s Secure Software Development Framework. NIST organizes secure development as practices that span preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities; its AI-focused community profile extends that lifecycle view to generative-AI and dual-use foundation models.[6][7] MIIT has not said it is adopting NIST’s framework. The comparison is narrower: both make little sense if assurance begins and ends with scanning the final text of a patch.

The receipt also prevents a measurement trap. Suppose an assistant cuts initial coding time by 30 minutes but adds 20 minutes of review, 15 minutes of test repair, and a small increase in later rollback work. A dashboard that stops when the patch is emitted records a gain. A change-level record can show whether the total path improved, for which task class, and at what quality cost.

This does not require ranking individual developers by accepted AI output. That would encourage small, easy-to-approve changes and discourage necessary rejections. The better level is a team and a stable class of work—bug fixes in one service, for example—compared against its own pre-adoption baseline, with review burden and downstream quality beside elapsed time.

External evidence makes the denominator problem visible

Two widely discussed 2025 studies point in different directions, which is exactly why rollout counts are insufficient.

Google Cloud’s 2025 DORA research drew on nearly 5,000 technology professionals. It reported AI use among 90% of respondents, perceived productivity gains among more than 80%, and low or absent trust in AI-generated code among 30%. Its statistical analysis associated greater AI adoption with higher delivery throughput and product performance, but also with lower delivery stability.[4] These are observational associations and self-reports, not proof that AI caused any of the outcomes. They nevertheless show that faster movement and safer movement can diverge inside the same survey.

METR ran a randomized controlled trial with 16 experienced open-source developers completing 246 tasks in mature repositories they knew well. With early-2025 AI tools allowed, the developers took 19% longer, even though they had expected AI to make them faster and still believed afterward that it had done so.[5] That result has a strong design but a narrow boundary: a small group, particular repositories, a particular period, and tools that have since changed. It cannot be generalized into a claim that 2026 coding AI slows Chinese software companies. Its relevant lesson is more modest: experienced users’ perception of speed is not a substitute for timed, task-level outcomes.

Together, the studies argue against a single universal productivity coefficient. Tool version, repository familiarity, task type, test quality, review conventions, and deployment risk all mediate the result. A national program can discover those differences only if its evidence survives below the company count.

Agents turn accepted changes into accepted actions

The plan reaches beyond coding assistants. It calls for safe, reliable industrial agents with behavior that can be verified, especially where they interact with industrial control software or core business systems. It also proposes agent application stores and Skills repositories with regulated listing review and operations.[1] At the September 11 briefing, Zhu Min of the China Center for Information Industry Development described the agent program in technology, product, and application layers, with verifiable industrial behavior and reviewed Skills markets among the product and application requirements.[3]

For an agent, the acceptance unit broadens from a code change to an authorized action. The receipt must identify the agent, requested objective, tools and data it was allowed to use, calls it actually made, approval boundaries, side effects, and recovery path. A skill that reads a catalog is not equivalent to one that changes a production schedule. A store badge that ignores permissions, dependency versions, and behavior under denied access would certify packaging, not operational safety.

The same principle applies to the plan’s proposed high-quality datasets for code generation, intelligent testing, and operations. A dataset can improve a model and still carry incompatible licenses, secrets, duplicated evaluation examples, or stale vulnerable patterns. Its supply-chain receipt needs sources, collection dates, license and consent basis, transformations, deduplication rules, access restrictions, and known exclusions. MIIT’s plan calls for data labeling, cleaning, synthesis, governance, and sharing through open-source communities and code-hosting platforms.[1] Whether those records travel with released datasets will determine how much downstream users can verify.

What would make the 2028 target legible

The plan calls for an intelligent-programming capability-maturity grading and evaluation standard, improved quality-management and evaluation specifications for software products and services, and agent-security management specifications spanning development, deployment, and application.[1] Those future instruments are the opportunity to connect national reach with project-level results.

Four disclosures would make progress easier to interpret:

Define coverage. Publish the eligible-company denominator and the activity threshold that turns installation into use. Separate trials, active teams, and lifecycle integration.
Report the acceptance funnel. For stable task categories, show proposals, rejections, accepted changes, deployments, and retained deployments—not generated lines of code.
Price the review tail. Track time to first proposal alongside reviewer time, rework, test repair, security findings, escaped defects, incidents, and rollbacks.
Bind results to versions. Preserve the model, tool, policy, repository scope, evaluation window, and baseline behind each reported improvement. Aggregates can protect company and developer privacy while still stating what was measured.

These are analytical recommendations, not promises in the plan. They would, however, let the 100 transformation projects do more than showcase polished demonstrations. Each could become a bounded case: a named workflow before and after adoption, a declared acceptance chain, a quality outcome, and conditions under which the result did or did not transfer.

MIIT’s 20,000-company target is useful because diffusion matters. Tools improve through real use, smaller firms need access to integrated infrastructure, and national programs must count something. But distribution is the beginning of this supply chain. The accepted change—reviewable, testable, attributable, deployable, observable, and reversible—is the point at which code generation becomes software production.

cronfeed.work