Engineering Frameworks for AI Coding Assistants: From Prompts to Controllable Execution

Scope of This Article

This article does not analyze unauthorized or leaked source code. The discussion focuses on general design concepts verifiable through public materials, and all examples are hypothetical. Unauthorized source code is typically protected by copyright and trade secrets; reading, reproducing, or copying it may entail legal risks. For in-depth learning, prioritize reading official vendor documentation, authorized open-source projects, and publicly published research papers.

What is an Engineering Framework?

In the context of agent engineering, an engineering framework (often referred to as a Harness) is the software layer that wraps around the model. It provides the model with tools, defines what the model can and cannot do, and manages the state required for the model to operate. The usage of this term varies across teams, but for the purpose of this article, the definition is: the model generates judgments, while the framework executes actions and enforces boundaries.

This definition can be verified with a simple question: If the model is replaced by a different one, does the system’s security boundary and execution flow remain unchanged? If the answer is yes, it means the constraints reside at the framework layer rather than relying on textual instructions within the prompt.

Three Stages: From Prompts to Engineering Frameworks

The capabilities of AI coding assistants typically evolve through three stages. The table below compares their characteristics:

Stage	Typical Approach	Suitable Tasks	Primary Cost	Main Risk	Checkpoints
Prompt Stage	Using carefully designed instructions to guide model output	Single-turn Q&A, simple rewrites	Trial-and-error debugging	Unstable behavior; fails when switching models	Is the output format consistent?
Skill Stage	Encapsulating common operations into reusable templates	Repetitive tasks with fixed workflows	Templates require manual maintenance	Lacks task decomposition and failure handling	Are template parameters validated?
Engineering Framework Stage	Establishing mechanisms for tools, permissions, context, and sub-tasks	Multi-step, cross-file complex tasks	High design and testing costs	Misconfigurations may cause erroneous actions	Are permissions, logging, and rollback in place?

The core shift from prompts to engineering frameworks is the transition of constraints from text to mechanisms. Textual constraints rely on the model’s understanding, while mechanism constraints are guaranteed by the program. The reliability difference between the two is significant.

Core Module Breakdown

1. Query Loop: The Main Process for Orchestrating Models and Tools

The query loop is responsible for receiving user input, calling the model, executing the tools requested by the model, and feeding the results back to the model until the task is complete.

• Input: User messages, conversation history, current task state
• Output: The model’s final response, or a tool call request
• Key Parameters: Maximum loop iterations, single-call timeout, token budget
• Failure Boundary: Terminate the loop if the maximum iterations are reached, returning partial completed results; when a tool throws an error, convert the error into structured information for the model rather than crashing the program.

For example, if the maximum iteration is set to 20 and the model has not produced a conclusion by the 20th iteration, the system stops the loop and outputs an explanation like “Completed modifications to 3 files; the 4th file was not processed.”

2. Tool System: Defining the Capabilities the Model Can Invoke

The tool system registers operations like reading files, searching code, and running commands as interfaces with parameter definitions. The model can only interact with the environment indirectly through these interfaces.

• Input: Tool name and parameters, e.g., read_file(path)
• Output: Execution result, or a structured error
• Failure Boundary: If a path is outside the working directory, the tool refuses execution and returns an error code without performing any read operation.

The more specific the tool definition, the easier it is to validate. read_file reads only a specified file, which is much easier to restrict than “executing arbitrary shell commands.”

3. Permission System: Controlling Execution Conditions Per Tool

The permission system checks permissions before every tool call. There are three common strategies:

• Allow by Default: The tool executes directly, suitable for read-only operations like reading files and searching code.
• Deny by Default: The tool is completely unavailable without authorization, suitable for high-risk operations like deleting files or accessing the network.
• Ask for Confirmation: Requests user approval before execution, suitable for medium-risk operations like writing files or running builds.

The principle of least privilege requires that each task only exposes the tools and directories necessary to complete it. For example, when fixing tests for a module, reading src/ and tests/ is allowed, writing to src/ requires confirmation, and deleting files is denied by default. Temporary authorizations should be revoked once the task is complete.

4. Context Compression: Handling Overlong Histories

Models have limited context windows, and long conversations can exceed this limit. A compression mechanism summarizes early content when the history approaches the limit.

• Trigger Condition: When the historical tokens exceed a certain percentage of the window. This percentage needs to be adjusted based on the model and task; no universal value is provided here.
• Compressed Content: Retain task goals, unfinished items, key decisions, and the most recent few turns of dialogue; remove duplicate tool outputs.
• Failure Rollback: If summarization fails, retain the most recent N turns of dialogue and the task goals, log the compression failure, and notify the user.

Directly truncating history upon compression failure may lose critical constraints. Therefore, the rollback path must be designed and tested independently.

5. Sub-Agents: Isolating the Execution Environment for Sub-tasks

A sub-agent delegates a sub-task to an independent context. Its value lies in isolation: the intermediate output of a sub-task does not pollute the main session, and a sub-agent’s failure does not directly break the main flow.

• Isolation Granularity: Each sub-agent has its own context and tool whitelist.
• Permission Rules: A sub-agent’s permissions do not exceed those of the parent agent; there is no inherited expansion of privileges.
• Result Return: The sub-agent returns conclusions, a list of modified files, and unresolved issues in a structured format.
• Failure Handling: On timeout or error, the parent agent takes over the task or marks the sub-task as incomplete.

6. Multi-Agent Collaboration: Parallelism and Cross-Validation

When multiple agents work simultaneously, the most common issue is write conflicts on the same resource.

• Conflict Resolution: Only one agent is allowed to write to the same file at the same time, achieved through locking or ownership assignment.
• Result Aggregation: The main agent merges results by field and annotates the source agent for each conclusion.
• Cross-Validation: Prioritize test results and static checks over an agent’s self-evaluation.

Without these rules, parallelism in a multi-agent system only generates more conflicts.

Design Principles

First, constrained freedom. The model has strong generative capabilities, but without boundaries, it may go off-topic, hallucinate, or execute dangerous operations. The framework’s role is to define boundaries and make them effective at the program level.

Second, mechanisms over prompts. Writing permissions into configurations is more reliable than repeatedly emphasizing “do not delete files” in the prompt. Structured mechanisms do not rely on the model correctly understanding instructions every single time.

Third, observable and intervenable. Every tool call, permission check, and compression operation should be logged. Humans need to be able to see what the agent did, why it did it, and be able to interrupt or correct it when necessary.

Industry Impact

The architectural approach of AI coding assistants is being discussed by an increasing number of teams. It is expected that similar products will increase, and competition will drive improvements in tool experiences. However, the implementation details of specific products can only be based on official vendor documentation.

For different readers, the most reliable learning paths are as follows:

• Developers: Read the tool calling documentation from model providers, try building a read-only code assistant using an open-source framework, and gradually add write and confirmation mechanisms.
• Technical Decision Makers: Evaluate the failure impact of each component, prioritize investing in permissions, logging, and rollback mechanisms before considering feature expansion.
• Researchers: Review public papers and evaluation benchmarks related to agents, focusing on measurable metrics such as task success rate, error rate, and cost.

Implementation Checklist

When building or evaluating an AI coding assistant, you can check the following items one by one:

1. Does each tool have independent authorization rules and parameter validation?
2. Does context compression have a defined trigger threshold and a tested failure rollback path?
3. Do sub-agents have independent tool whitelists, timeouts, and structured return formats?
4. Do high-risk operations like deletion, writing, and network access have confirmation or default-deny policies?
5. Are the referenced code and documentation from authorized sources, and have the licensing terms been confirmed?

Conclusion

The engineering framework transforms the model’s judgments into controlled actions. Prompts determine what the model “wants to do,” while the framework determines what it “can do” and “what happens if it makes a mistake.” For developers, designing permissions, logging, and rollback mechanisms first, and then gradually expanding capabilities, is usually more reliable than pursuing complex multi-agent collaboration from the very beginning.