How AI Coding Tools Build Code Agents

1. A Source-Code Leak That Exposed the Real Question

A source-code leak involving an AI coding tool client once sparked extensive discussion among developers. An oversight in packaging configuration exposed hundreds of thousands of lines of core logic to public view. One fact should be clarified first: what leaked was client-side product code, not the weights or training details of the underlying large model. Many developers may ask what is worth examining in client source code. The value lies precisely in how it shows a mature code agent building a complete engineering system above model capabilities—which explains better than the model itself why the tool works well.

This leads to a concept that has appeared frequently: Harness Engineering. The term sounds intimidating, but its essence is a repackaging of common sense: rather than repeatedly “praying” that large models become smarter and less prone to hallucination, it is better to put a harness on the wild horse—using systematic engineering to constrain its behavior and define its track. The output quality of a code agent depends less on the upper bound of a single model call and more on how the surrounding system carefully controls inputs, outputs, tool calls, and the execution environment.

This article focuses on the technical theme of “how to implement a code agent” and breaks down its key components layer by layer from an architectural perspective.

2. Overall Architecture: A Controlled Reasoning–Execution Loop

A code agent is not simply “concatenating user input into a prompt and calling the model once.” Its core is a closed loop of multi-turn reasoning and execution:

1. Input layer: Receives user intent and collects workspace context (file tree, selected code, error logs, dependency information, and so on).
2. Planning layer: The large model decomposes the task and decides whether to answer directly, retrieve information, or call tools to perform operations.
3. Tool layer: Exposes capabilities such as file reading and writing, command execution, retrieval, and test running through controlled interfaces.
4. Execution layer: Runs tool calls in an isolated environment and captures results and side effects.
5. Observation and compression layer: Structurally processes and trims execution results, then feeds them back to the model for the next round of decision-making.
6. Security and permission layer: Approval, allowlists, and sandbox constraints that run throughout the entire process.

The key to this loop is that every tool call is a “bounded action”, rather than letting the model act freely. The system’s responsibility is to transform an open-ended generation problem into a series of verifiable, rollback-capable, controlled operations.

3. Tool System: Capability Exposure and Permission Containment

The most fundamental difference between a code agent and an ordinary chat model is that it can change the environment—writing files, running commands, and executing tests. This is both the source of value and the source of risk. Therefore, the tool system design must satisfy two goals at the same time: capabilities must be expressive enough for complex tasks, and boundaries must be clear enough to prevent privilege escalation.

From an implementation perspective, a tool usually consists of three parts: a name and semantic description (for the model to choose), a parameter schema (schema validation), and an execution function (including error handling). The quality of tool descriptions directly affects the model’s call accuracy, so descriptions need to state “when to use it, when not to use it, parameter meanings, and constraints.”

An illustrative tool registration structure is as follows (pseudocode):

register_tool(
    name="read_file",
    description="Read the text content at a specified path in the workspace; the path must be under the workspace root",
    schema={"path": {"type": "string", "required": True}},
    handler=read_file_handler,
    permission="read",
)
register_tool(
    name="run_tests",
    description="Run the project test command in an isolated environment and return the exit code and output summary",
    schema={"target": {"type": "string", "required": False}},
    handler=run_tests_handler,
    permission="execute",
    requires_approval=True,
)

Note several engineering details:

• Path constraints: All file operations must be restricted to the workspace root to prevent path traversal.
• Permission levels: Read operations can be automatically allowed, while write operations and command execution usually require explicit approval or rule matching.
• Result trimming: Tool return content cannot be fed directly to the model; otherwise long output will quickly overflow the context window. It needs truncation, summarization, or pagination.
• Idempotency and rollback: Write operations should preferably keep change records so they can be reverted on failure.

More tools are not always better. Tool-set expansion significantly increases the model’s selection burden and the probability of incorrect calls. Mature implementations often use layered tool sets: basic file and retrieval tools stay resident, while high-risk or low-frequency tools are loaded on demand.

4. Context Engineering: The Hidden Battleground That Determines Success

If the model is the engine, context is the fuel. Most “the agent got dumber” phenomena in code agents are rooted not in the model but in poorly organized context. Context engineering must solve three problems: what to include, how much to include, and in what order.

What to include: Prioritize information strongly related to the current task, including user intent, relevant file snippets, the latest execution result, and project conventions (such as code style configuration). Irrelevant large files and redundant historical dialogue should be excluded.

How much to include: The context window is a limited resource. A common practice is to maintain a “budget,” allocate quotas to content from different sources, and trigger compression when the budget is exceeded. Compression strategies include summarizing historical turns, sorting by relevance and then truncating, and converting long file output into a structured index.

In what order: Usually, the most stable system constraints are placed at the front, and the freshest execution observations are placed at the end, taking advantage of the model’s attention to recent content. The following is illustrative logic for context compression:

def build_context(task, history, observations, budget):
    ctx = [system_policy(), project_conventions()]
    ctx += select_relevant_files(task, top_k=5)
    ctx += summarize(history, max_tokens=budget * 0.2)
    ctx += truncate(observations, max_tokens=budget * 0.4)
    return enforce_budget(ctx, budget)

It should be emphasized that context compression itself may introduce information loss. Therefore, there needs to be a validation mechanism for “whether key constraints are still preserved after compression”—for example, keeping the key lines of the original error stack after compression.

5. Memory and State Management: Preventing the Agent from “Losing Memory”

In multi-turn tasks, the agent needs to remember modifications it has made, solutions it has ruled out, and preferences the user has explicitly stated. Relying entirely on the context window to carry memory is both expensive and unreliable. In engineering practice, layered memory is usually adopted:

• Short-term memory within a session: The decision trajectory and tool-call records of the current task, discarded when the session ends.
• Project-level long-term memory: Project structure, common commands, code conventions, and other information are deposited into a searchable index and injected as needed.
• User preference memory: Preferences confirmed by the user (such as “do not auto-format”) are stored as structured configuration to avoid repeated questions in every turn.

The difficulty of memory management lies in consistency and timeliness: after a file is modified, the old index must become invalid; after a user preference changes, the old configuration must not continue to take effect. Therefore, the memory system needs versioning or timestamp mechanisms and should label sources and freshness when injecting content into context.

6. Safety Constraints and Sandboxed Execution: A Non-Negotiable Baseline

Letting an agent execute commands is equivalent to handing a shell to a decision-maker that may make mistakes. Safety design must default to “the model will make mistakes,” rather than assuming it will not. Common constraints include:

1. Execution isolation: Commands run in containers or restricted processes, with limits on network access, filesystem scope, and resource usage.
2. Approval gateway: High-risk operations (deleting files, installing dependencies, pushing code) trigger human confirmation, while low-risk operations are automatically allowed according to rules.
3. Command allowlists and pattern matching: Directly block obviously dangerous patterns (recursive deletion, privilege escalation, remote script pipe execution).
4. Output redaction: Execution results may contain sensitive information such as keys and tokens, which must be filtered before being fed back to the model.
5. Audit logs: Record the input, output, and approval result of every tool call for later tracing.

Safety constraints introduce some interaction friction, but this is a necessary cost of engineering. A reasonable approach is risk-tiering: keep high-frequency, low-risk operations smooth, and concentrate approvals on truly irreversible actions.

7. Engineering Implementation Priorities

To combine the above components into a usable code agent, several practical issues also need attention:

• Observability: Record the input summary, tool selection, execution time, and failure reason of each reasoning round. Without logs, tuning is like trying to understand an elephant while blindfolded.
• Failure recovery: Tool-call failure is the norm, not an exception. The system should distinguish “parameter error,” “missing environment,” and “insufficient permission,” and provide actionable correction suggestions instead of letting the model repeatedly retry the same error.
• Evaluation loop: Build a task-level evaluation set covering code modification, defect localization, test generation, and other scenarios, and measure system iteration results by pass rate and rollback rate.
• Gradual autonomy: Start with a semi-automatic “suggest—confirm—execute” mode, and gradually expand the degree of automation as rules and evaluations mature.

8. Conclusion

Returning to the term “Harness Engineering,” its real value is not in coining a phrase but in reminding us that the competitiveness of code agents is shifting from single-point model capability comparisons to a comprehensive contest of system engineering capability. The boundary design of the tool system, fine-grained context scheduling, reliable memory management, and safety constraints in the execution environment—these “reins” determine whether the wild horse can steadily pull the cart. For developers, understanding this architecture has more long-term value than chasing the parameters of any single model; for enterprises, treating the agent as an engineering system that needs constraints and observability is the prerequisite for making it work reliably in real production environments.