UseAIHere
Video: Lecture 9 of Nanjing University's Generative Software Engineering
When one person begins managing several agents at once, familiar software engineering problems take on a new shape. Each agent may handle a task in a different workspace, read or write files, and call tools. Their work still has to come together as one product and pass through integration and release. Version control must answer more than how to preserve history: it must also help determine which tasks can proceed in parallel, which resources they touch, and how conflicts will be found and resolved.
This lecture uses DeepSeek Harness as a case study. It starts with the complexity introduced by multiple agents and real products, then compares architectures that prescribe a product shape with an extensible plugin kernel. A compact harness can provide sessions, an event bus, and a few collaboration interfaces, leaving much of the UI and application capability to plugins. This design lowers the cost of extension, while leaving new coordination problems for the ecosystem to solve.
1. Multi-agent work turns version control into coordination
When a person writes software alone, they usually work serially: read code, change it, check the result, and move on. With agents in the process, one person can assign several agents at once, and an agent can further divide its task. The person takes on a role closer to a technical lead responsible for delegation and acceptance, while the system must manage multiple changing workspaces.
Tasks do not all touch the same resources in the same way. One may only read code, another may modify a module, and a third may refactor system boundaries. Access to the same repository can be thought of as different kinds of locks: read-only tasks can run in parallel; code-changing tasks need a write scope; refactors that affect interfaces or structure may need a larger exclusive scope. Even when several independent small fixes all require writes, they do not necessarily have to run one at a time.
This brings concurrency ideas from databases and operating systems back into software development. A system can lock resources before acting or allow parallel work and detect conflicts afterward; it can authorize work by task scope or apply different policies to different kinds of change. Git still preserves commit history and the final deliverable, but a multi-agent system also has to manage workspaces, task boundaries, file conflicts, and integration order. Version control therefore expands from preserving history to coordinating parallel work.
2. A working agent prototype is not a reliable product
A small agent loop can already complete a meaningful task: the model selects a tool, the runtime executes it, the result goes back to the model, and the next round begins. This proves that the basic mechanism works, but it does not solve reliability problems in long-running tasks. The network may drop, an API request may time out, or a process may stop midway. Without persistence, recovery, and retry mechanisms, the task may have to start over.
Retrying is more than “send the request again after failure.” Networks have different latency and failure patterns, so a fixed timeout may be too short or may leave a task stuck. Exponential backoff can prevent excessively frequent retries after repeated failures, but the system still needs to decide which errors are retryable, how long to wait, and how to show the state to the user.
The client and server can also have different understandings of an operation. If the client loses connectivity after sending a request, the server may have completed it even though the client never received the result. The local state is then neither success nor confirmed failure; it is unknown. A robust product must preserve that uncertainty and realign through a query or recovery protocol. It cannot treat “no response received” as “nothing happened.”
A production agent also needs cross-project task views, session history, project tools and Skills, runtime permissions, and an isolated environment. Handing an agent a detailed request to build something that “looks like an existing product” can produce an implementation that appears complete but has not been tested against long-term use. An MVP lets assumptions meet reality: network stability, task switching, and permission prompts may all change after people use it.
3. Changing requirements test the boundaries of an architecture
An architecture divides a system into modules and specifies how they collaborate. Clear boundaries reduce dependencies in parallel development: different agents can implement separate modules and connect them during integration. But each agreement limits freedom. When a new requirement falls outside the existing boundaries, abstractions can leak and previously independent modules may begin to depend on one another.
Unrestricted message passing has its own costs. If every module can send messages however it wants, the system may seem to impose fewer design constraints, but it becomes difficult to reason about message meaning, ordering, ownership, and failure handling. Without stable boundaries, every task must understand more global behavior, and changes become harder to predict.
Architecture is therefore not a search for one permanently correct answer between strictness and flexibility. It is a choice among costs. Modularity makes local development easier but makes future cross-boundary requirements more expensive. Event sourcing gives state changes a historical basis but adds cost to deriving current state from history. More freedom can accommodate more applications, but it also demands clearer protocols and coordination. Architecture quality depends on the changes it supports, the constraints it exposes, and the cost of maintaining it.
4. A thin kernel leaves room for an ecosystem
DeepSeek Harness demonstrates a design centered on sessions and an event bus. The kernel provides agent sessions, event registration, history projections, and interfaces for submitting, appending, or injecting input into a session. Plugins can listen to agent lifecycle events, participate in context construction, or project persisted events into their own views. Most plugin state stays local; only information that needs to be shared crosses agreed events and interfaces.
This kernel can support different interfaces. A native web UI can assemble pages from slots; a terminal UI can listen to the same session events and project them in a command line; developers can add terminals, sidebars, extra sessions, or real-time status panels through plugins. The application does not need to build every mode into its main program in advance. Plugins can create capabilities around shared session and event protocols.
Creator Mode takes this extensibility into runtime: developers can install or adjust plugins while an agent is working, and even create new interfaces and workflows. The Harness becomes more like a kernel that an ecosystem can continue building on, rather than a single product whose feature set is already sealed. Adding a capability shifts from modifying the main program to following a protocol, making prototypes and community experiments easier to create.
But a plugin architecture cannot automatically reconcile the semantics of different plugins. If two plugins can both modify context, the order of checking and rewriting affects the result. If multiple compression plugins are combined, information may be removed too aggressively. If one plugin requests a stop while another requests continuation, the event system needs an explicit conflict rule. Matching message types only confirms that a message has the expected shape; it does not mean the plugins' behavior is semantically compatible.
Plugins reduce accidental complexity in extending the system; they do not remove the essential complexity of software. Permissions, event ordering, shared state, conflict handling, and ownership still need design. The more powerful Creator Mode becomes, the more important runtime permissions and isolation are. The freer the plugin ecosystem, the more it needs protocol governance and failure diagnostics.
5. Bringing existing applications into an agent workflow
The event bus can also connect a Harness to existing super-apps. An editor, spreadsheet, or drawing tool could expose a thin bridge: lock the objects selected by the user, hand them to the model, and submit the result back to the original application. The application remains responsible for its editing experience, the agent generates or modifies content, and the bridge manages object handoff and locking.
This approach can bring AI capabilities into an existing workflow without first rebuilding the entire application editor. After the model makes a change, users can still move, delete, or edit the generated objects. An application can also insert a dynamic interface into a session as a plugin and send interaction state back to the model through events. This expands what can be combined, while requiring stable agreements about object identity, modification scope, and commit timing.
A broader idea is to let personal data, tools, and multiple applications collaborate within one agent ecosystem. An application submits a task, the agent calls suitable plugins to retrieve information or act, and the result returns to the original work surface. This cannot rely on the model understanding context alone; it also needs explicit authorization, data boundaries, and traceable operations. The ecosystem depends on whether these interfaces can be combined safely and clearly.
6. Architecture creates opportunities and leaves coordination work
A small kernel does not have to decide every product shape for every user in advance. Stable session and event protocols leave room for plugins. Developers can quickly experiment with interfaces, tool bridges, and workflows, allowing useful ideas to grow in the ecosystem. Compared with implementing a huge requirements document all at once, this makes it easier for new requirements to first appear as local extensions.
The cost is that no single team fully controls the system anymore. Plugins may conflict, semantic agreements may be insufficient, and permissions may cross application boundaries. The infrastructure must clarify which capabilities belong to the kernel, which state belongs to plugins, how plugins compose, and who handles conflicts. The thinner the kernel, the less ambiguous ecosystem governance must be.
The change brought by Agent Native development is not only faster code generation. More roles, tools, and applications participate in software production at the same time. Engineering work therefore expands to task decomposition, state coordination, permission control, architecture evolution, and ecosystem protocols. A good Harness does not need every capability in advance, but it needs clear enough boundaries for new capabilities to be connected, understood, verified, and maintained.