AI Coding Agents: Two Technical Paths and Who Should Control Them

1. A Common Usage Scenario Exposes an Architectural Split

The same developer can have very different experiences with AI coding agents in two different environments.

In one environment, the agent proposes a plan first, waits for confirmation, then modifies files. Each step can be interrupted and rolled back.

In another environment, the developer only describes the goal. The agent decomposes the task, writes code, runs tests, and corrects errors on its own.

This difference is often attributed to “stronger vs. weaker models.” From an engineering perspective, however, it is more accurately described as a difference in architectural paradigm. The real question is not which model is smarter, but who holds control.

The split can be compressed into one sentence:

• One path is “humans control the AI.” Control is given to the user and the outer framework, allowing precise intervention at every step.
• The other path is “AI controls itself.” Control is given to the model. The human only defines goals and acceptance criteria, while the model orchestrates the process.

This distinction matters because it determines three practical outcomes:

1. How failures can be recovered.
2. When costs may become uncontrolled.
3. Whether the system can be incorporated into enterprise-level development workflows with auditability.

2. Defining the Two Paradigms

Route A: Model-Native Agent

In this model, agent capabilities are built into the model itself. The model decides how to reason, when to call tools, and how to control the execution loop.

The system shape is close to “one brain plus a fixed toolset,” without an independent external scheduler. Decision authority stays on the model side.

Route B: Model Plus External Control Framework

In this model, the model is treated as a relatively pure capability unit. It may generate code, make judgments, or produce plans.

An independent outer control and scheduling system handles workflow state, permission arbitration, failure retries, context assembly, and output validation. Decision authority stays with the framework. The model can act only within authorized windows.

Dimension	Model-Native Agent	Model Plus External Control Framework
Main loop ownership	Model	Framework
Context modification	Model may add or remove content	Framework strictly assembles context; humans can intervene
Tool exposure	Fixed toolset with unified authorization	Authorization differs by stage or role
Failure recovery	Model self-correction	Framework retries, rolls back, or switches strategy
Behavior controllability	Harder to constrain	Strong; suitable for high-compliance scenarios
Ceiling and flexibility	High	Limited by preset workflows
Observability and auditability	Weak; reasoning process is opaque	Strong; each step has structured records
Main cost risk	Long loops and repeated trial-and-error	Workflow redundancy and multiple round trips

3. Architecture Analysis: Separation of the Control Plane and Execution Plane

The most effective way to determine which paradigm an agent belongs to is to ask four questions:

1. Who owns the main loop?
2. Who can modify context?
3. Who can change permissions?
4. Who recovers from failure?

1. Main Loop Ownership

A typical externally governed framework uses an explicit state machine. The framework decides whether the system is in the planning phase or execution phase, while the model returns structured results.

# Illustrative main loop for an externally governed coding agent
# Pseudocode; not a specific product API
state = State(phase="plan", history=[])
while not state.done and state.rounds < MAX_ROUNDS:
    if state.phase == "plan":
        plan = llm.invoke(PLAN_PROMPT, ctx=readonly_context(repo), schema=PlanSchema)
        state.plan = validate(plan)              # framework-side validation
        state.phase = "build"
    else:
        result = llm.invoke(BUILD_PROMPT, ctx=state.plan + diff_of(repo),
                            tools=write_tools, schema=BuildResultSchema)
        ok, report = run_tests_and_lint(result.patch)   # objective feedback loop
        state.phase = "verify" if ok else "plan"        # framework decides rollback target
        state.record(result, report)             # structured trace

The key point is that objective feedback, such as tests, type checks, static scanning, and builds, is collected and returned by the framework. The model does not have final authority over rollback policy.

This is the real source of “controllability,” not whether the prompt is written well.

2. Context Governance

In the native route, the model decides whether to read another file, compress history, or open a subtask.

In the framework route, the assembly order of the context window, trimming strategy, and retrieval recall are all version-controlled code.

The latter is more friendly to large repositories because “which files should be inspected” can be guaranteed through engineering mechanisms, rather than depending on the model’s self-discipline each time.

3. Tool Exposure and Least Privilege

A key advantage of the framework route is permission narrowing by stage.

During planning, the agent receives only read-related capabilities, such as browsing, searching, and read-only execution.

During execution, write-related capabilities are opened, such as modifying files, generating patches, and running tests.

In the native route, a relatively broad unified toolset is usually exposed, with system prompts used to constrain purpose. This may be sufficient in personal environments, but the risk is significantly higher in multi-tenant or production repositories.

4. Observability

In the framework route, every step produces structured artifacts, such as plans, patches, commands, exit codes, duration, and token usage. These can be sent to log services and monitoring/alerting systems, with cost attribution by team, repository, or model.

In the native route, the reasoning chain is mostly internal state. External observers can only see final actions, which makes troubleshooting difficult when problems occur.

4. Multi-Agent Orchestration: Static Predefinition vs. Dynamic Generation

This is where the two routes show the most visible difference.

4.1 Static Dual-Agent Orchestration: Separating “Thinking” and “Doing”

One common and effective design in the open-source ecosystem is to split planning and execution into two mutually exclusive agents:

• The planning agent has read-only permissions. It reads code, writes plans, and makes architecture decisions, but cannot modify any files.
• The execution agent has execution permissions. It modifies code according to the established plan and runs tests, but cannot change the plan on its own.
• The two agents exchange information through the file system or structured artifacts, such as plan files, patch files, and test reports. Users can interrupt and revise the plan at any point.

The real value of this design is not “nice division of labor.” It is that constraints are enforced by permissions rather than prompts.

The execution agent cannot access the ability to redesign the solution, so it is less likely to drift away from the architecture intent. The planning agent does not have write permissions, so it will not make changes while thinking and leave behind unfinished work.

This “one role, one permission boundary” pattern is a rare but reusable engineering practice in open-source agents.

The limitations are also clear. All roles are predefined and cannot be dynamically generated. If a task exceeds the preset workflow, such as needing data validation, dependency analysis, or documentation synchronization in parallel with code understanding, someone must manually add stages. Flexibility is limited.

Cross-stage handoff can also cause “plan-implementation drift.” Because the execution agent may lose part of the planning agent’s intent, an additional confirmation step is often needed.

4.2 Dynamic Master-Agent Orchestration: Organization Shaped by the Task

Another route allows the master-agent structure to emerge as needed.

Normally, there is an all-capable master agent that plans and executes on its own. When facing a complex task, the master agent can create specialized sub-agents. Each sub-agent has its own independent context and restricted tool permissions.

The master agent then decides how to coordinate them: serial execution, parallel execution, voting, or cross-review.

Recent approaches have gone further by expressing orchestration as executable code, making the sub-agent scheduling logic itself an artifact.

The advantage is extreme flexibility. For structurally unusual tasks that are difficult to classify in advance, such as cross-language migration, legacy-system archaeology, or conflicting multi-party constraints, the system can design the process on the spot instead of requiring humans to define the workflow beforehand.

The risks are also specific:

1. Structural bloat: The master agent may create three layers of sub-agents for a simple task, causing token consumption to become severely mismatched with actual benefit.
2. Non-reproducibility: The organizational structure for the same task may be completely different across two runs, making regression comparison difficult.
3. Error cascade: Sub-agent conclusions are treated as trusted inputs. A single hallucination can be amplified along the orchestration chain.
4. Permission drift: The permission boundaries of dynamically created agents are described by the model. If they are not validated by the framework, the principle of least privilege is effectively handed over to untrusted input.

A pragmatic conclusion is therefore: dynamic orchestration must be wrapped by static guardrails.

The model may propose a structure, but the framework should validate what permissions the sub-agent needs, which paths it can access, and what the budget limit is. Only after validation should the sub-agent be created.

4.3 Orchestration as Code Introduces a New Abstraction

When orchestration itself becomes code, it also becomes a reviewable, testable, and version-controlled asset.

# Illustrative orchestration strategy managed as reviewable code
# Pseudocode
def orchestrate(task, agents):
    if task.risk == "low":
        return agents.build.run(task)                  # single-agent direct path
    if task.needs_independent_review:
        a, b = agents.spawn("analyzer"), agents.spawn("critic")
        draft = a.run(task)
        return b.review(draft) if b.verdict(draft) == "reject" else draft
    return agents.build.run(agents.plan.run(task))     # plan-execution separation

The key governance point is that this code should be reviewed by humans, included in version control, and equipped with resource budgets and timeouts. It should not be improvised by the model at runtime.

5. Measuring the Gap: Build Your Own Evaluation Criteria

When discussing “how much difference is there,” it is risky to draw conclusions from a single-point experience.

A better approach is to build a small evaluation set across six dimensions. Starting with 20 to 50 real tasks is usually enough. These tasks should cover small edits, cross-file refactoring, defect localization, test completion, and documentation or script-related tasks.

The six dimensions are:

1. Task completion rate: Whether the acceptance criteria are met.
2. First-pass rate: The proportion of tasks that can be merged without manual modification.
3. Number of human interventions: The average number of interruptions or corrections per task.
4. Unit cost: Token consumption and wall-clock time required to complete each task, stratified by task difficulty.
5. Reproducibility: Whether repeated runs of the same task produce consistent conclusions.
6. Safety boundary: Whether the agent crosses read-only constraints, touches sensitive paths, or executes unauthorized commands.

Run the same evaluation set on both paradigms and stratify the results by task complexity.

In most cases, simple and clearly defined small edits are more stable and cost-effective under the control-framework route. Open-ended architecture design and complex refactoring are where dynamic orchestration is more likely to create an advantage.

6. Engineering Implementation: Stitch the Two Routes Together

The best production solution is usually not either/or. It is layered: the outer control framework guarantees process, permissions, and observability, while the inner stage allows dynamic capabilities within a single phase.

Practical recommendations include:

• Permission layering: Read permissions should be available by default. Write permissions should be granted temporarily by stage. Command execution should run in sandboxed containers. Network and package-management operations should require approval.
• Context layering: Repository indexes and retrieval results should be stored in object storage or cache. Long-term memory and short-term working context should be managed separately, avoiding full context injection every time.
• Objective feedback first: Judgments about whether output is correct should be delegated as much as possible to compilers, tests, static scanning, and security scanning, rather than asking the model again.
• Gated integration: Patches produced by agents must go through the existing CI pipeline. Failure should trigger rollback. Changes that merely “look correct” should not be merged directly.
• Observability and cost governance: Actions, duration, tokens, and exit codes should be collected into log services and monitoring/alerting systems. Costs should be attributed by project and member. On cloud platforms such as Baidu AI Cloud, these capabilities can reuse common cloud products such as container platforms, log services, and monitoring/alerting services, without building a complete observability stack from scratch.

7. Risk and Governance Checklist

• Prompt injection: Documentation, dependency descriptions, and issue text inside repositories may carry instructions. They must be treated as untrusted data and must not be allowed to trigger privilege escalation.
• Dependencies and supply chain: Automatically added dependencies require version locking and source validation. This helps prevent lookalike or typosquatted package names.
• Hallucinated interfaces: The model may call parameters or methods that do not exist. Type checks and compile-time validation should be used as safeguards.
• Data compliance: Code and secrets should have clear outbound boundaries. For sensitive scenarios, private deployment and local inference should be prioritized.
• Audit trail: All automated changes should retain committer identity, triggering tasks, and review records to meet traceability requirements.

8. Selection Decision Checklist

A few questions can help determine which route is more suitable:

• Can tasks be classified in advance?
• How high is the cost of errors?
• Does every step need to be explainable to an auditor?
• Does the team have the ability to maintain orchestration code?
• Is global consistency across many files required?

If the earlier questions lean toward “yes,” the control-framework-first static dual-agent approach is usually the safer choice.

If the later questions lean toward “yes” and the team already has mature CI guardrails, dynamic orchestration can be introduced. However, budget limits, permission validation, and reproducibility regression must be added first.

The essential difference between the two routes is not model capability level. It is where you place uncontrollability.

Place it inside the model, and you trade controllability for flexibility and a higher ceiling.

Place it outside in the framework, and you trade flexibility for controllability and auditability.

Once this is clear, “how much difference is there” is no longer a benchmark question. It becomes an engineering tradeoff under constraints.