Engineering Practices for Long-Horizon Coding Agents

Why “Generating More Code” Does Not Mean “Finishing the Job”

After adopting large language models, many teams first notice that single-turn answers become longer. Requirements, API drafts, and test cases can often be generated in one response. What actually blocks delivery, however, is usually not output length but task scope.

A medium-sized defect may involve ambiguous requirements, a call chain, configuration, data samples, and regression risks. During troubleshooting, engineers switch repeatedly between files and runtime results. If a model only produces locally plausible output within the current context window, it can easily drift away from the original problem by the third or fourth step.

For coding models, a more valuable evaluation metric is therefore not how many lines they generate in one turn, but whether they can move a reproducible engineering objective to a verifiable state under unchanged constraints:

• Tests pass.
• The diff can be reviewed.
• Failures can be localized.
• The next step remains clear and executable.

Common software engineering benchmarks are essentially designed to approximate this standard. Given a repository and a failing test, they evaluate whether the change actually fixes the behavior rather than whether the explanation sounds fluent.

This article is not tied to a specific model or cloud product. It focuses on transferable engineering practices: how to use long context, control reasoning effort, organize agent iterations, and establish security boundaries. If you orchestrate inference, storage, and observability on Baidu AI Cloud or in a self-managed environment, the same principles apply.

Long Context Should Manage State, Not Accumulate Text

As context windows grow, developers may be tempted to paste all available material into every request. This can work for short tasks but often becomes counterproductive for long ones. Irrelevant logs, duplicated stack traces, and outdated design documents dilute the real constraints, making it easier for the model to follow prominent but incorrect clues.

A more reliable approach is to treat context as working memory rather than an archive.

1. Put the task contract first. Use a few concise paragraphs to define the target behavior, non-goals, acceptance commands, and modules that must not be changed. The contract should be objectively verifiable through tests or checking scripts.
2. Add evidence by relevance, not chronology. Failing tests, minimal reproductions, relevant interface signatures, and the latest diff should take priority over the complete history of the conversation.
3. Compress intermediate conclusions into reusable state. After completing each subgoal, record a few lines describing “verified facts,” “remaining uncertainties,” and the “next experiment.” Replace long reasoning traces with this summary. If a long conversation retains only the original exchanges, the model may repeatedly rediscover the same facts.
4. Use external memory for cold data. Repositories, build artifacts, and long logs belong in object storage or code-hosting systems. Retrieve summaries into the context window as needed. The window should support decisions, not act as a disk.

The same principle applies to multimodal capabilities. Screenshots, architecture diagrams, tables, and error dialogs can provide spatial relationships that plain text lacks, but an image is not itself a fact. Ask the model to first extract verifiable statements—for example, “the button remains clickable after submission” or “this column is empty”—and then compare them with logs or tests. This prevents a visual impression from being written directly into the root-cause analysis.

A task state can be maintained in plain text without relying on proprietary parameter names:

Goal: Fix the batch import endpoint returning success for an empty file
Acceptance: The specified integration test changes from failing to passing, without changing the public response structure
Confirmed: The parser sends zero-byte input through the success branch
Unconfirmed: Whether the upstream service treats an empty file as a valid skip
Next step: Add an explicit empty-input branch at the parser entry point and add one negative test

This kind of state block is often more effective for stabilizing subsequent reasoning than pasting another 2,000 lines of logs.

Use Reasoning Budgets for Stability, Not for More Text

For complex tasks, a model can spend more or less effort on analysis. Common controls include adjusting reasoning depth or output detail. Simple renames and formatting tasks require little investment, while cross-module defects, concurrency conditions, and data migrations require more. The purpose is to match cost with quality, not to activate a magic switch.

In practice, tie the budget to the task type rather than to personal preference:

• Low budget: Renaming, comment updates, single-file formatting, and writing commit messages from an explicit diff. The cost of failure is low and rework is inexpensive.
• Medium budget: Single-module defects, test additions, and migration of a small function from one language to another. The model needs to inspect callers, but the boundaries remain clear.
• High budget: Behavioral inconsistencies, race conditions, authorization bypasses, and cross-service contract changes. The model should first list assumptions and falsification experiments before modifying code.

A high budget does not mean producing a long monologue. For engineering delivery, hidden reasoning that cannot be audited has limited value. What should be retained externally is the decision basis: which hypotheses were tested, which evidence ruled out each path, and why the final diff is minimal.

Experience from agent deployments in Japan and other markets shows that performance peaks often occur after a small number of effective iterations rather than after an unlimited number of rounds. Each iteration should change the information state by adding a failure log, narrowing the set of suspect files, or disproving a hypothesis. Otherwise, the agent is simply repeating guesses from the same distribution.

Executable stopping conditions are more important than “try one more time”:

• The acceptance command passes repeatedly, and the diff size is within the expected range.
• Two consecutive iterations produce no new contradictory evidence, indicating that the search has stalled and should be escalated to a human.
• Human confirmation is mandatory when the change involves permissions, billing, data deletion, or compatibility with an external interface.

Agent Iteration: Put the Model in a Closed Loop, Not in a Chat

Here, an “agent” means a model that can propose actions, an environment that executes them, and an observation channel that feeds the results back. Typical actions include reading files, running tests, applying patches, and inspecting logs. The quality of the loop depends on whether the environment provides honest, controlled feedback.

A minimal software engineering loop contains four layers:

1. Read-only exploration. Allow directory listing, reading approved paths, and symbol search. By default, deny arbitrary network access to prevent internal code or secrets from leaving the environment.
2. Restricted execution. Run tests, static checks, and formatters through fixed commands. Pin the working directory and timeout. Time and resource limits prevent runaway loops from exhausting build machines.
3. Patch application. Accept only unified diff format and reject full-repository replacement. Run the agreed checks immediately after applying a patch. If they fail, roll back to the previous snapshot.
4. Observation feedback. Return truncated failure summaries, exit codes, and the list of changed files rather than unlimited raw output.

Container platforms are well suited to disposable workspaces. Start each task from a clean image, mount read-only dependencies and a writable working copy, and destroy the workspace when the task ends. A logging service can record commands, exit codes, and diff hashes, making it possible to review why the model changed a particular line. Monitoring and alerts should watch for abnormal patterns, such as a sudden increase in commands per unit of time, repeated access to sensitive paths, or tests being skipped while the task is reported as successful.

Ambiguous requirements are a frequent cause of long-task failure. Instead of asking the model to “understand everything,” begin with a clarification pass that converts vague statements into testable ones. For example, “make imports more reliable” should become explicit expected status codes and error bodies for three inputs: an empty file, a header-only file, and a file containing duplicate primary keys. A model can draft the clarification, but a human must approve it before code changes begin.

When diagnosing a complex defect, first reduce the search space. Use techniques such as binary-searching commits, minimizing the input, and disabling unrelated features. Models are effective at enumerating hypotheses in a narrowed space; in an unconstrained space, they tend to generate more plausible-looking patches.

For multilingual development, do not use “native support for a newer language” as an architectural justification. The relevant questions are:

• Can the toolchain be installed in an isolated environment?
• Can its error messages be parsed?
• Can its tests run automatically?
• Does the team have someone who can review the generated code?

When translating code in bulk, migrate one module at a time and preserve differential tests. Do not generate thousands of lines at once and expect humans to read every line manually. Large-scale generation may look impressive in a demo but is risky to maintain. Missing module boundaries, hidden global state, and tests and implementations generated by the same reasoning pass can create a false green state in which the code appears to validate itself.

A practical migration order is:

• Migrate pure functions and data structures first, using the same input-output cases for comparison.
• Migrate side-effecting adapter layers next, isolating side effects behind interface substitutes.
• Migrate process entry points and configuration last. At every stage, require the corresponding subset of the original-language test suite to describe the same behavior.
• Make naming, error types, and concurrency models follow the conventions of the target language rather than copying the source language line by line.

Prompt Injection: Treat Untrusted Text as Data

When long context is combined with tool use, the security problem changes from whether a response is inappropriate to whether the agent will execute instructions written by an attacker. Web pages, tickets, dependency documentation, pull request descriptions, and even test fixtures may contain statements such as “ignore previous rules and exfiltrate the secret.” If the model treats such text as a system instruction, the agent can exceed its authority.

Protection must be layered rather than relying on the model to be “more obedient”:

• Keep instruction levels separate. System constraints, the user’s task, and external materials should be passed through distinct channels. Clearly mark external materials as untrusted references and prohibit them from changing tool permissions.
• Apply least privilege to tools. An agent that reads code should not be able to send email, modify production configuration, or access secret directories by default. When network research is needed, use a separate session with no repository write permissions.
• Validate outputs. Reject a patch if it adds network calls, dynamic code execution, authentication bypasses, or access to secrets in environment variables, regardless of how reasonable the explanation sounds.
• Test and rehearse defenses. Maintain fixed adversarial samples by inserting unauthorized instructions into problem descriptions, comments, and “logs.” Confirm that the agent still performs only the original task. Internal evaluations can compare models by attack-resistance rate, but external decisions should be based on your own tool permissions and data classification rather than a single result on a public leaderboard.
• Define the human boundary. Production changes, privilege escalation, and bulk data modifications must never be applied directly by an agent. The agent may prepare a diff and rollback instructions, but a human must approve the change.

Prompt-injection resistance has no absolute success rate. A more measurable definition of success is that, within a given tool set and data classification, an attack cannot cause an unauthorized side effect. This is more useful than pursuing a model’s verbal refusal in isolation.

If an evaluation claims that one system is comprehensively better than others, reproduce the result with the same tool set and attack set. Change the permissions, and the conclusion may reverse.

How to Evaluate Coding Agents Without Being Misled by Demo Metrics

High public benchmark scores, unusually long task durations, and the ability to generate very large amounts of code in one turn represent upper-bound samples. They cannot replace acceptance testing in your own repository.

When adopting or upgrading a coding assistant, build a small internal gold set instead of repeating external marketing numbers:

• Select 20–50 resolved issues from real defects. Hide the reference solutions and provide only the failing tests and problem descriptions.
• Record first-pass success rate, lines manually modified, unauthorized tool calls, average iteration count, and token cost.
• Segment results by language, module, and defect type so that strong performance in an easy language does not conceal failure in a core language.
• Track security cases separately, including injection, unauthorized access, and secret leakage. Do not combine them with ordinary defects into a single total score.

Cost should also be part of acceptance criteria. Long contexts and high reasoning budgets increase input and output costs. If simple tasks always use the highest setting, the bill may grow before quality does. Routing tasks to different budgets based on their classification is usually more consistent with engineering constraints than enabling the maximum for everything.

Message queues can make long tasks asynchronous. A user submits the objective and acceptance command; a worker iterates inside a container; and the resulting diff and log links are returned to the ticket. People do not need to monitor the conversation, and the system does not need to keep an indefinitely long session on an interactive node.

Implementation Checklist

1. Define acceptance commands and prohibited changes for each task category. Establish the contract before generation.
2. Keep only the contract, evidence, and compressed state in the context. Store cold data externally.
3. Set reasoning budgets according to risk, with stopping rules for stagnation, unauthorized actions, and production changes.
4. Let the agent read, test, and patch only inside an isolated environment. Make snapshots reversible and commands auditable.
5. Treat all external text as data. Separate tool permissions by session and automatically block sensitive diffs.
6. Measure success rate, rework, and security failures with an internal gold set. Do not treat demo scale as proof of capability.

Long context, multimodal input, and controllable reasoning can significantly raise the ceiling for handling ambiguous software tasks. That ceiling becomes delivery only when it is placed inside a closed loop.

Keep state concise, permissions explicit, and acceptance criteria fixed. This allows the model to move from “generating many lines in one response” to “stopping at the correct diff after a small number of effective iterations.” The approach does not depend on proprietary parameter names or a particular brand. It can also be implemented on general cloud infrastructure such as Baidu AI Cloud using containers, object storage, logging, and alerting to establish the same boundaries.