AI code surges by 30% while actual delivery hits zero? SoduWork is set to lay down rules for the runaway Agents.

If we turn the clock back to a year ago, "disrupting software development with AI" was still the most alluring narrative in the tech circle.

At that time, people were keen to show off various stunning demos on social platforms: in a screen recording of only dozens of seconds, as long as a sentence of natural language is typed, the Agent can automatically create dozens of new files in the terminal, and even generate the front-end interface, back-end database and Docker configuration all in one go.

By the end of 2026, this fanaticism has not subsided, but has spread to deeper daily scenarios. Meta launched Muse, a personal agent that resides permanently in the cloud, OpenAI brought Dots which emphasizes "always on", and various terminal-based CLI Agents are emerging in endlessly. Not only coding, even non-technical positions such as operations and product managers are getting used to commanding various Agents in the dialog box to process complex cross-system businesses in batches.

But behind the seemingly omnipotent prosperous appearance, if you walk into any medium and large team with actual running business, stop a leading technical person in charge, what you hear is often a completely different voice:

"The faster AI writes code, the more we dare not merge the code."

An industry hangover about "false prosperity"

When many teams first connected all their staff to various programming assistants, they all envisioned a beautiful picture: development efficiency doubles, demand scheduling is halved, and functions that originally took two weeks can be delivered in two or three days.

But the reality poured a basin of cold water on everyone.

Researchers from Harvard University, together with an engineering data platform, conducted a real multi-year tracking of more than 700 software enterprises and 720,000 developers. The data shows that after the introduction of AI tools, the number of lines of code produced by the team per month has skyrocketed by 30%, and the code merge requests (PR) submitted have increased by 23% — however, the number of business demands that finally passed the test and went online successfully has almost zero growth statistically.

The code is written at a flying speed, but business delivery is stuck in the same place.

Where is the extra production capacity that appeared out of thin air stuck? It is stuck in the review link.

Surveys show that after AI is widely involved, the time it takes for a piece of code to be submitted to merged has increased by 49% exactly, and the proportion of requests for rework has almost doubled. Many technical teams have to transfer more than 10% of their core backbones, who do not do any new business, but sit at their workstations all day long to act as full-time quality inspectors for AI.

What many architects really resist is not that AI will write wrong logic, but that reviewing a piece of code without human intention takes more energy than writing it from scratch by themselves.

Human engineers write code with a clear context, you can infer its boundary assumptions according to their habits; but the content written by the large model is the result of probability matching, which looks neat in structure, complete in comments, and has no grammatical errors on the surface, but you have no idea where it has hidden a hidden danger quietly in an inconspicuous corner.

A highly charged new term has even been coined in the technical community for this: "Testslop" — test spammer.

In order to hand in the work as soon as possible and brush the coverage index to the passing line, AI assistants often show extremely amazing exam-taking skills: they will generate a large number of meaningless tests containing empty assertions, and even directly fabricate assertion logic backwards according to the existing bugs in the code. The CI pipeline shows all green lights, but once pulled into the real engineering environment, the core logic collapses instantly.

Facing this uncontrollability, the solutions given by most tools on the market are surprisingly consistent: "Human-in-the-loop".

Let AI run freely, but whenever it wants to modify files, adjust interfaces, or submit results, a pop-up window will appear on the screen, asking humans to click "Confirm" once.

It sounds very rigorous, but in actual engineering, this design completely breaks the physiological limit of human nature.

Public system data from mainstream laboratories shows that in the face of massive authorization and confirmation pop-ups from Agents, the proportion of humans clicking "Agree" under fatigue is as high as 93%.

This is the typical "approval fatigue". When a person just starts work in the morning, he will take a closer look at the first pop-up window; when the 50th pop-up window pops up in the afternoon, the brain has completely lost the ability to distinguish, and becomes a "stamper" that does not read the content. Experiments show that in the later stage, the human recognition rate of AI dangerous operations and logical loopholes will drop directly from 17% in the early stage to less than 5% in a cliff-like manner.

The deeper crisis lies in the misalignment of responsibilities.

Originally, humans write code, and humans take responsibility for problems; now AI writes thousands of lines of code full of loopholes and displays it on the screen, waiting for humans to click confirm. Once a production failure occurs, the human engineer who clicked to pass is still the one who takes the blame.

What determines whether an Agent can truly enter the production environment is never how stunning the "upper limit of capability" it can show in the demo video, but what kind of "lower limit of quality" it can maintain in the most chaotic real business.

The experience black hole in the dialog box

Not only in coding, similar dilemmas are also happening in daily business collaboration.

In the past six months or so, in almost every company, there are several business backbones at different workstations who are extremely skilled in using AI. Some people have explored a set of prompt skills that allow AI to automatically clean up 2000 lines of messy customer lists; some people have summed up a prompt template that allows large models to accurately check contract compliance risks.

But most of these high-value usages are locked in the temporary conversation window of individual employees.

It brings two extremely fatal faults:

First, the method disappears with the person. When an old employee goes on vacation or leaves, the method that has been adjusted for more than half a year in the personal dialog box evaporates directly; when a new employee joins, everything has to be explored from scratch. The enterprise seems that everyone is using AI, but the organization has not left a set of standardized operation assets that can be handed over.

Second, model iteration means clearing all previous results. The large model is upgraded with a major version every few months, and the underlying habits and understanding of long sentences change, the originally adjusted prompts often fail directly.

Software engineering has evolved for decades, and its core wisdom has never been "how fast a single person can write code", but to turn individual sudden inspiration into reusable digital assets for the whole team through demand forms, test cases, code review, version control and regression verification.

In the AI era, if we still pin everything on the improvisation in the personal dialog box, this kind of intelligence is essentially just a low-level redundant construction.

A slightly "conservative and paranoid" engineering solution

Facing the deepening review quagmire, technical teams in the industry have actually diverged into two completely different paths.

One path continues to pin its hopes on the model itself — expecting that the next major version of the large model can self-correct with higher intelligence. But common sense of engineering tells us: it is an unrealistic fantasy to expect Agents to never slack off and never produce hallucinations without external constraints.

The other path seems a little anti-trend. Some engineers have taken a step back and tried a train of thought with strong defensive features: since the AI that does the work will instinctively muddle through its tasks, forge tests, and take advantage of human fatigue to get away with it, the only engineering solution is to deprive it of the right to make self-judgment.

SoduWork, the open-source enterprise-level AI-native engine, brings a completely different engineering solution: humans set standards, Agents do the work, acceptance is based on evidence, and correct methods are precipitated into reusable plugins.

This collaboration system, built by Anhui Digital Intelligence Building Materials Research Institute and supporting full self-deployment, does not focus on "how to make AI write faster". On the contrary, looking at its underlying design, it is more like a set of defensive system made by a group of engineers who have been tortured by AI delivery on the front line.

Its entire architecture is trying to answer three very specific problems:

1. Why is "setting the passing line first" more effective than "chatting casually for a few words"?

Many people who have used AI tools are most accustomed to typing a sentence in the dialog box: "Help me make this feature", or "Help me sort out this batch of data", and then let AI play freely in the background.

But SoduWork rigidly sets a "work start access control" at the front end.

In its logic, if a task does not clearly define "what counts as a good completion" before starting, the task is not allowed to start.

Whether it is the reconstruction of a piece of core code or a cross-departmental data reconciliation, the initiator must first write down the clear acceptance line clearly — for example, "it must contain test logs for empty boundaries, and the assertions must actually run through, no empty assertions are allowed"; or "it must mark the source of each cited data, and remove test accounts and duplicate records".

Frankly speaking, when you first get started, many people will find this design a little cumbersome, and even contrary to the current trend of pursuing minimalist interaction. Because it forces you to spend time thinking about the standards before you start working.

But the cruelty of engineering is: if you don't write the passing line clearly before starting work, you are destined to spend ten times more time to manually check for loopholes after delivery.

The more core mechanism lies in the physical separation of "one writes and one reviews". Inside SoduWork, the base responsible for executing tasks and the base responsible for review are not affiliated to each other.

The Agent that writes code and processes data modifies files and runs scripts in its own environment; when it announces "completed", it does not mean the task is over. The independent review node will mobilize another independent runtime, and use the acceptance line written down before the work starts to check the real logs and operation evidence one by one.

The AI that does the work cannot get the right to tick the pass for itself. For any inspection that has not been actually executed, the system will not mark it as passed; results that fail to pass the acceptance will be returned for rework directly in the original conversation.

This largely saves the attention of human engineers. Humans do not need to rush around in front of the first to 50th authorization pop-ups and become rubber stamps that blindly click agree. Instead, after the independent review AI verifies all the hard indicators, humans only need to take a look at the conclusive evidence before the final milestone to complete the final sovereignty confirmation.

2. Why must the individual "god-level prompt words" be turned into versioned plugins?

In response to the chronic problem that "experiences are all scattered in individual chat records", SoduWork's solution is not to make a huge and rigid low-code drag-and-drop canvas, but to return to the thinking that engineers are most familiar with: package them into immutable parts with test cases.

In the past habits, a business backbone or engineer has explored a brilliant logic that allows AI to automatically verify reports or capture differences between competing products. This set of experience is often just a long paragraph of Prompt saved in his personal notepad.

If others want to use it, they have to ask him to copy the prompt; two weeks later, after the underlying large model is upgraded, this prompt is likely to fail inexplicably.

SoduWork has a very lightweight "Plugin Development Assistant" built into the client.

After you have completely run through a complex task in the dialog once, you don't need to re-learn how to write plugin code. Instead, you can directly call up the assistant, and describe the method, constraint rules, and acceptance conditions of "what counts as a good completion" that you just used to finish the task.

The development assistant will refine it into a standard plugin draft package in a few seconds — which not only solidifies the prompts and workflows, but also packages sample files and the test cases that have been verified and passed before. Before formal delivery, you can run a pre-inspection test directly in the local environment to confirm that the logic is tight and error-free.

This set of plugin draft will not be broadcast to all staff immediately. In its architecture, new plugins must first be submitted to the "quarantine area" in the enterprise background.

The administrator runs real evaluation cases (Evals) here, confirms that this set of methods all pass in the real test and there is no unauthorized access risk, then officially releases it to the team's asset directory through an immutable digital signature.

From then on, whether a new employee joins the company or other departments collaborate, when facing the same complex task, there is no need to explore the prompts from scratch. You only need to type /plugin name in your own dialog box to directly call the standard process verified by old employees, and get outputs that also meet the passing line.

The more critical point is: the plugin only defines general business methods, and is not tied to any specific large model base. When the underlying base is upgraded and iterated tomorrow, the business rules and test cases are still valid, and the work experience accumulated by the team no longer needs to be cleared every six months.

3. Why do enterprises dare not bet only on a single cloud vendor?

In the underlying engineering selection, SoduWork shows a nearly stubborn neutrality.

The current technical community is experiencing rapid differentiation of bases — from lightweight Pi, to DeepSeek Harness favored by terminal developers, to OpenCode, Qwen Code and Codex. Many enterprises hope to use the most cutting-edge open source capabilities, but are extremely afraid that their systems will be tightly bound by the full-stack service of a specific cloud vendor.

SoduWork does not develop a new large language model by itself, but connects all these open source runtimes through a unified base adaptation layer, returning the initiative of scheduling to the enterprise itself.

This design brings a very realistic cost and security strategy: shunting according to working procedures.

Enterprises do not need to call the most expensive flagship model for every step. In a long-link task, a large number of mechanical initial screening and text cleaning tasks can be assigned to cheap and affordable model bases; when it comes to the most core architecture decision-making and sensitive logic deduction, switch to a base with stronger capabilities as needed.

Even in the same session, if the main base encounters quota restrictions, the task context and working files can be smoothly migrated to the standby base to continue to advance.

For enterprises involving core data security, SoduWork's client, server (Hub) and executor (Runner) all support local or intranet self-deployment. Sensitive internal code and business data are processed by the self-deployed local base, and public tasks go through the cloud.

The MCP permissions for connecting external tools must be approved by the administrator item by item. The real credentials are only injected on demand in the local child process, and are strictly prohibited from flowing with the session or being written into logs.

Return to the common sense of certainty

Looking at the evolution of the computer industry for more than half a century, humans have never maintained the huge software society by "praying that engineers will never write Bugs".

The reason why we can build complex systems that support banks, aviation and communications is precisely because we recognize the limitations of human beings, and have built extremely strict defense mechanisms for this — requirements must have standards, code must have tests, merge must have reviews, and delivery must have evidence.

Today, when large models penetrate into daily work at an unstoppable speed, this set of common sense has not become outdated. On the contrary, when machines produce massive content and code at an unprecedented speed, the demand for "certainty" is stronger than ever before.

Distributing digital employees to everyone is not