How Does an Agent Move from One Generation to Long-Term Maintenance? — Lecture 8 of Nanjing University's Generative Software Engineering

Course page: Agent Native Development · Slides · Video

AI can turn out a working page quickly, and it can keep adding features, tests, and documentation inside the same project. An engineering question sits between those two abilities: whether each change actually moves the goal forward, whether what stays behind is easy to understand, and whether the next session can pick up the work. A project whose implementation keeps growing can also keep piling up duplication, contradictions, and designs that have stopped working.

Agent Native development treats agents as developers that take part in the work, and organizes tools, context, collaboration state, feedback, and verification around them. The human role expands to the whole production process: comparing candidate designs, deciding which states may enter the trunk, keeping records complete enough to restore a judgment, and changing direction when the architecture starts to fail. Fast generation creates more chances to try; engineering mechanisms decide whether those attempts accumulate into a system that can be maintained over the long term.

1. Managing breadth and depth in the search space

Between Intention, Specification, and Implementation, the relation is one-to-many: the same goal can carry different business rules, and the same set of rules can take different architectures and technical implementations. Even a reasonable idea is only one path through the design space. Implementing a prototype along that path, optimizing its performance, and adding experiments can go very deep without coming close to a better overall design.

Depth-first work gets real feedback on one idea. Breadth-first work compares the forks that appear early, such as which facts to store, how to divide modules, and whether to adopt event sourcing. Choices made closer to the starting point are more likely to affect later maintainability and observability. Compute and time are limited, so engineering work has to allocate effort between the two: compare the far-reaching candidates first, then take the options worth verifying as far as a state that runs.

Review is one way to widen the search. Discussing the same design with different models can surface different preferences, omissions, and counterexamples, and having them check each other may keep the group from settling around the first idea too early. A single model playing different roles over and over may quickly endorse the route it has already proposed. Different models do not guarantee independent views, and both sides agreeing does not prove the conclusion right. The value of review is that it raises differences that can be checked, which requirements, materials, and experiments then settle.

The Deeper Research experiment puts this exploration inside an agent loop built for the purpose. Beyond the material in the original personal digital assistant, it can organize papers, blogs, open-source projects, and book excerpts, giving the search a richer basis. Watching the actual execution trace shows when the model is comparing designs, when it has sunk into a local implementation, and what information the extra compute actually added.

The prototype's job here is to test a hypothesis. While a discussion has not yet converged, you can have AI produce a version and then check it against typical cases: whether the goal is clear, whether the specification misses interactions, whether dependencies appear between modules that no one considered. Letting prototypes fail is what allows an earlier discovery of which layer of decision should change. Versions are generated faster, and that gives you the conditions for comparing different directions.

2. What a minimal agent shows

An agent that can call tools can start as a very small program. A Python prototype of about 150 lines that offers the model nothing but a Bash tool can still do file generation, command execution, and browser-related tasks. The mechanism at work is a repeated exchange of messages between the model and the environment, with the tools performing the actual operations.

The program reads the user's input first and puts the task and the tool definitions into the request. The Bash tool declares its own name, description, and parameters, such as the command to run. When the model returns plain text, the program prints the text; when it returns a tool call, the program parses the arguments, runs the corresponding command, and sends the result back to the model as a tool message. A tool call ID links the request to the result, and the model picks its next action from that.

This is a ReAct-style interaction loop: decide an action from the current information, execute it, observe the result, and continue deciding. Bash is a general entry point through which the model can read and write files and call existing programs, or generate a script and then run it. A small number of tool types does not mean few composable operations; the real capability still depends on the model, the environment, the available programs, and the actions that are permitted.

The idea that "a sufficiently intelligent model needs only a Bash entry point" works as a thought experiment for understanding how much a general tool can express. It does not show that today's models can finish any research problem. Using tools, running for a long time, and finding the right solution are abilities at different levels, and one of them does not imply the other two.

A small prototype also exposes what productization has to fill in. If tool execution hard-codes a timeout, a task reaching a slow network resource may be cut short while it is still working normally. The model may decide to retry with a different timeout, while the runtime does not necessarily offer that parameter. Environment awareness, execution control, and error feedback therefore become architectural questions, and these gaps only become easy to see once the prototype is running.

In the same way, the model having produced an answer only means this round of interaction reached its output stage. Whether the user's whole task is satisfied still has to be judged by the goal and the acceptance conditions. The basic tool loop gives a starting point that works; continued development needs more complete surrounding machinery.

3. The Harness organizes autonomous action into an engineering process

A model can compare designs inside its own reasoning, and it also forms a tendency to act from the context it has. Generating a page, it may open several browser windows, check screenshots, and then ask whether the result is satisfactory. For a task that has to keep moving forward, this behavior is not necessarily the right working rhythm. The Harness organizes the tools, context, permissions, and feedback available to the model, so that autonomous action happens inside a defined engineering environment.

Existing code shapes the model's judgment too. When a project has already adopted a structure, an agent tends to keep patching along that structure, working until the function runs. For a failure that needs service restored immediately, such a local fix has real value; for an architecture that has stopped working, continued patching can make the project harder and harder to maintain. The goal and the range of permitted change have to be explicit before anyone can judge whether this round should restore a function, compare designs, or refactor a module.

The Harness manages the search space as well. It can have the model review a design first, run checks after a round of changes, arrange for another model to check the result, or examine the overall architecture at intervals. Which actions are worth taking, when to take them, and how to judge the next step afterward can all go into the workflow, instead of relying on the model to remember every constraint on its own across a long conversation.

None of these arrangements has a final version that fits every task. After a model update, system prompts and Skills that used to work may become unnecessary, or they may keep doing their job. Taking a familiar task and comparing results with and without a given constraint helps show whether it is still useful. Prompts, models, and runtime mechanisms need to be evaluated together, and configurations accumulated over time need re-examination.

4. Ralph Loop: the prompt stays the same, the workspace keeps changing

The Ralph Loop takes a plain form: hand the same task to an agent again and again, and each round checks, modifies, and verifies before the next one starts. The prompt stays the same, while the workspace left by the previous round has changed. Code, tests, documentation, and pending-item records become the input to the next round, so the task can advance across many sessions.

Two layers of loop need to be told apart here. The loop inside a minimal agent connects model requests, tool calls, and result feedback; the outer Ralph Loop organizes multiple rounds of task execution and the handoffs between them. When one inner session ends, the outer layer can still start the next round. It splits a large task, which tends to drift across a long context, into a series of smaller advancing steps.

The workspace can be treated as development state. It may start as nothing but a specification; the next round adds an implementation, the one after that locates a test failure, and a later one fixes it and leaves verification results behind. One agent run is one state transition. Git can store these states, while requirements, code, tests, and logs give them an interpretable meaning.

This state is far richer than the sentence "the feature is done". Unfinished parts need the next step recorded, important conclusions need their basis kept, and a failed run needs information left behind that can be reviewed. Only after a new session reads this material can it judge which work stands and which is still only a plan. Experience that lives only in the previous round's chat context may not be recoverable once the session ends or is compacted.

The outer loop needs a stopping condition as well. A special completion marker can work as a program convention for ending the run, while the marker itself does not prove the task is finished. Acceptance requirements, verification results, and unresolved problems still decide whether it has reason to emit that signal. Repeating the same prompt does not guarantee quality rises monotonically either, so the loop needs feedback that can recognize progress and failure.

5. After a small step, verify and evaluate immediately

A practical requirement for the loop: each round checks the current state first, advances only one clear step, then verifies and evaluates the result. Small steps mean fewer changes to check and an easier time finding where things drifted from the goal. When a check fails, later work deals with the failure first, rather than adding features on top of an unreliable state.

Verification can come from different levels. Tests and check scripts confirm explicit conditions, another model reviews the current change, and people check the goal, the architecture, and the experience. Each supplies different information: tests check behavior that has already been expressed, review can question an omitted assumption, and actual use may expose problems the specification never described. Which check to choose should follow from what this step could break.

A business-card page generation experiment shows how the way effort is spent affects the result. One version had glass effects and terminal decoration, but the email and the institution mark were wrong; a plainer version had an email and a GitHub profile that matched the actual subject. Visual polish and factual correctness are two properties that have to be checked separately.

The comparison has clear limits: generation is random, the prompt and the number of rounds changed at the same time, and the existing context can influence style. One demonstration can show that two results differ; it cannot prove that any Loop is reliably better than a single generation. What is worth keeping is the evaluation method: check facts, function, and presentation separately, then see which of them the repeated rounds actually improved.

A small-step loop also allows the mode of advance to be swapped. On the same workspace state, you can choose to implement a feature, switch to a model review, run tests, or examine the architecture. The next step of the task follows from the current evidence. A state transition therefore includes moving the implementation forward as well as correcting the route and cleaning up existing results.

6. Checking at state transitions becomes CI/CD

"Developers are untrustworthy" states an engineering starting point: a change cannot be accepted on the developer's confidence alone. A person may think that editing one line of documentation or moving a loop's starting point will cause no trouble, and an agent may ignore other effects after finishing a local task. Writing important requirements as checks and running them automatically on key events is what brings them reliably into the development process.

Committing, pushing, opening a merge request, updating the trunk, and releasing a version can all be nodes that trigger actions. A local pre-commit fits fast formatting, static analysis, or local checks; an integration environment can run builds, tests, and more complete verification; a release process checks the artifacts about to be delivered. Requiring developers to remember to run everything by hand is far less reliable than wiring the corresponding checks into a required flow.

CI, continuous integration, integrates changes continuously and verifies them automatically. CD can mean continuous delivery or continuous deployment: the former keeps artifacts ready to deliver while people decide the actual release, and the latter goes further by deploying changes that pass their requirements automatically. Which one is in use has to be explicit in the workflow; "there is an automated build" does not imply that releasing to production is done.

Lint is static checking that needs no execution of the business program under inspection, and it can cover formatting, naming, and problems decidable statically. It blocks a class of basic errors, and it cannot replace verification of system behavior. Unit tests, integration tests, and long-running fuzz tests each have their own scope as well, so the process needs to know which one to run after which change.

An agent can help generate pipeline configuration, while human understanding still decides what the checks mean: which events should trigger which actions, what problem has to be handled after a failure, and which requirements can block integration or release. The value of CI/CD is turning these requirements into executable feedback; every known check passing only means the conditions expressed so far are satisfied.

7. AI Slop grows between documentation and code

AI produces large amounts of content quickly, and it easily leaves behind generated material that people find hard to maintain, usually called AI Slop. Long documents that retell the implementation in full detail, record a debugging process that is already over, or wrap a simple behavior in many similar paragraphs look complete, and they add to the burden of searching and updating.

The more dangerous problem comes from implicit relationships. A document describes a piece of code, and the two may agree at the moment they are written; after the code changes, a new session may not know that this document needs to be synchronized. Both texts go on existing as authoritative material, and the project now has contradictory interpretations. Copying an interface declaration or writing the same rule in several places establishes correspondences that will need maintenance later.

A file directory can hold this material, and it does not automatically express which contents must agree, which one is the source, or what change should trigger an update. The important objects in a software project therefore include relationships: documentation and source code, Chinese and English, architecture and modules, tasks and implementation status. Recording these relationships explicitly and checking them is what keeps them from depending on the memory of one particular agent round.

Agent development makes decidable documentation constraints more valuable. Examples include setting a length budget for key documents, verifying that links reach their targets, and checking type declarations in documentation against the source. When overlong or mismatched content triggers a failure, the agent sees specific feedback before continuing its work. A prompt line saying "do not let the documentation balloon" may not be followed once the context grows.

These checks have limits too. Short text does not guarantee a clear meaning, a valid link does not guarantee an accurate explanation, and matching interface text does not guarantee the whole system meets its requirements. Mechanical rules find one class of problem reliably, and semantic review goes on judging whether the content is useful and consistent with the design. A gate needs an accurate object of inspection, and its failure messages need to help with the correction.

8. How DeepSeek Harness maintains Chinese and English documentation

The documentation consistency practice in DeepSeek Harness puts relationships that used to be implicit into the repository. A document governed by the pairing rules is represented by Chinese and English Markdown together with an i18n YAML pairing manifest. The pairing manifest is a Sidecar that stores the link between the two versions and metadata such as hashes, so updates can be detected and tracked.

The two languages have equal authority. Either side can be modified first and becomes the source for that synchronization; the other side updates the corresponding content from the differences. The hash shows whether content has changed relative to the record, and the version history supplies earlier states. A hash says nothing about which side is newer, still less that the two documents mean the same thing, so change detection and semantic correspondence need separate handling.

Synchronization uses patch-style updates: first see what changed in the source document, then modify the corresponding passages in the other one, leaving the rest stable. Retranslating the whole document widens the review scope and can set terms, expressions, and content that had already been aligned drifting again. Handling only the differences confines the effect of one change to parts that are easier to check.

The translation pairing gate wires this requirement into the verification flow. The agent does the translating and revising, the program checks the correspondences that need mechanical guarantees, and review then confirms whether the meaning is accurate. Terminology conventions and style examples make the way of writing more explicit, so each translation does not have to choose its vocabulary again.

Checking term frequencies or paragraph correspondence can help find omissions as well, and the thresholds have to be set with care. Natural language allows different reasonable expressions, and a rule that is too strict may reject a correct translation. An executable condition needs to cover real errors while leaving room for semantic judgment.

This structure increases the number of files in the directory. An IDE can hide the Sidecar or display only the language a reader needs, giving a cleaner browsing view. Simplifying the display layer improves the reading experience while the information used to maintain relationships stays in the repository. The human view and the actual engineering state can therefore be organized differently.

A similar method can maintain the relationship between documentation and source code. A designated interface, type, or code block in a document needs checking against the corresponding source file; after the source changes, a mismatch becomes an explicit check failure. Attaching lightweight check semantics to Markdown code blocks can also say where a passage should appear and which object it stays associated with. The clearer the association, the easier it is for an update to get feedback.

9. Layered instructions, on-demand loading, and collaboration state

Cramming every rule into one always-resident document makes the model face a large amount of irrelevant detail on every task. Layered AGENTS.md files can state rules at the appropriate scope, and documentation length budgets control the size of what stays resident. Specific processes such as translation, writing, and review go into Skills, loaded when a task of that kind needs to run.

This progressive disclosure gives tasks and methods different homes. A task record describes what is to be done now and how far to take it; a Skill describes how to carry it out and how to check it. Style samples, terminology conventions, and check programs each carry their own responsibility too. The agent gets the context it needs for the current work, and maintainers can update rules at the matching location.

A Logbook or Agent Notes holds the collaboration state. Plans, steps already executed, verification evidence, open questions, and statuses such as proposed, implemented, rejected, and archived help later sessions understand what is happening in the project. A status word is only an entry point; the record itself still has to say what was done, why something was accepted or rejected, and which work is still missing.

These records can also be linked to architecture diagrams, CI results, and progress dashboards. Seeing which module is changing, which tasks have dependencies, and which checks have passed lets maintainers plan the next step. A progress estimate on a dashboard cannot replace evidence of completion, while the correspondence between architecture and tasks lowers the cognitive load of coordinating many agents.

Verification also needs an understanding of the change's scope. Adjusting a task plan needs different checks from modifying actual code, and a type or documentation update has its own related verification. Only when it is clear what a change affects is it possible to arrange fitting feedback, instead of mechanically repeating the whole process at every step.

10. Parallel collaboration needs tasks that really can be split

The workspace is state, so it can fork from the same state. Different agents advance different modules in separate Git Worktrees and the results are integrated at the end. Version control provides isolation and merge mechanisms, while module boundaries, task division, and check mechanisms decide whether this parallelism works.

If several agents see only that "the whole project failed", they may all rush at the same error, repeat the same fix, or overwrite each other's changes. Adding more executors does not automatically produce more independent progress. Tasks need to state their object, responsibility, and dependencies; the scheduling mechanism needs to know which work is running; and integration checks need to handle cases that are correct alone and fail in combination.

Cross-model review and parallel implementation carry different responsibilities as well. The former tries to obtain different perspectives, and the latter tries to advance separable work at the same time. Both need to exchange necessary information, and neither should put every execution detail into every session without conditions. Reviewable results and concise handoffs give other participants a basis for judgment and cut the cost of repeatedly reading irrelevant traces.

Human management capacity is limited too. Once agents output faster, the bottleneck may shift from coding to judging requirements, review, and coordination. Architecture diagrams, task records, and automated gates organize the state more clearly, which is what keeps a growing volume of execution inside the range a person can still understand and adjust.

11. Continuous cleanup has limits, and engineering experience comes from real trial and error

Periodic architecture review, documentation correction, and duplicate-code cleanup keep technical debt from piling up quickly. Comparing this maintenance work to garbage collection helps explain what continuous tidying does; the subject here is engineering maintenance, which is not the same thing as reclaiming memory while a program runs.

Continuous cleanup cannot fix everything. If a system is built on unsuitable module boundaries or design assumptions, local patches can make it more complicated with each fix. When necessary, a module has to be refactored, or a new structure built altogether, and the existing functionality migrated into it step by step. Refactoring rests on architecture problems that have already been identified, and the migration has to check function and behavior too.

These judgments usually come from actual failure. A design works at small scale and reveals its limits once growth or a new requirement arrives; a gate begins as a terminology convention and becomes automatic verification only after a mismatch. Reading an open-source project's code, documentation, and history shows how mechanisms grew out of real problems, rather than only memorizing the set of names that ended up appearing.

Practical resources also affect access to experience. More tokens and a larger run budget let people attempt longer tasks and compare more designs; understanding feedback, questioning failures, and absorbing good designs decide whether the attempts turn into judgment. Consuming more resources and learning more do not correspond automatically.

An education and training risk sits here as well: an organization that pursues only short-term output may prefer to have experienced people coordinate large numbers of agents, putting less into training beginners. Beginners then have a harder time getting the practice that forms experience. This is a possible trend that needs discussion, and an immediate impression of one model cannot be taken as the settled fate of every student, occupation, or educational institution.

Open source lowers the barrier to observing good engineering mechanisms, and running, modifying, and failing firsthand adds experience that reading alone cannot give. A good idea still needs a team to organize it into a reliable system, and fast generation still needs people who can compare directions, recognize problems, and arrange verification.

Agent Native development thus forms an interconnected process: Intention and Specification give action its goal, the workspace holds state that can be handed over, tools and the Harness organize execution, gates and review provide feedback, and real failure pushes the design to keep evolving. Whether a project can advance over the long term depends on whether these parts together preserve the ability to judge and correct.