# AI Coding Agents: Proactive Behavior, Taste, and Safety Engineering

1. Ask a different question: not “who is stronger,” but “which layer of capability got filled in”

Most of the discussion around AI coding tools stays at the level of leaderboard-style judgments of strength. But the real difference a frontline developer feels is rarely “can it produce correct code.” It shows up in three much narrower layers:

1. Correctness: does the produced implementation pass compilation, tests, and review?
2. Completeness: when the requirement description is incomplete, can the agent fill in the engineering details on its own, instead of doing one thing per instruction?
3. Quality of expression: are the explanations around the code, the interface presentation, and the interaction feedback at a deliverable level?

These three layers sit on completely different technical problems. Correctness is a matter of model capability and retrieval quality. Completeness is a matter of context reasoning and multi-step planning. Quality of expression involves preference alignment, design constraint injection, and output templating. Treating them as one thing loses the focus of the discussion.

A typical observation: the same agent often performs markedly better on “backend APIs and defect fixing” than on “frontend visual presentation.” The reason is not mysterious. Backend tasks have strong, verifiable feedback signals — contract tests, compilation, static checks, and unit tests all give a clear pass/fail verdict, so the model can self-correct inside a closed loop. Frontend aesthetics produce subjective and sparse evaluation signals, and “looks harmonious” is hard to write as an assertion that can be judged automatically. Without a verifiable reward signal, the model naturally drifts toward conservative, generic, design-poor solutions.

2. Where completeness comes from: the line between passive execution and proactive filling-in

Many agents behave as if they are stuck in a “Ph.D. student before graduation” state: solid framework knowledge, the assigned part done beautifully, and not one inch of movement on the part that was never assigned. At root this is a conservative strategy under missing context — the model is unsure where the boundaries are, so it hands the decision back to the user.

Improving completeness in engineering is not about swapping the model. It is about context engineering. Making a team’s tacit knowledge explicit is a verified working path:

# Project Constraints (read by the agent on every task)
## Tech stack and directory layout
- Backend: layered architecture; the controller / service / repository layers must not call across each other
- Frontend: components must reference design tokens; hard-coded color values and spacing are forbidden
- Scope of change: only src/ and tests/ may be modified; infra/ is read-only
## Default behavior (apply when the user has not specified)
- A new endpoint must update the contract document and the contract tests at the same time
- Changing a public function requires unit tests covering normal and boundary inputs
- Before commit, automatically run lint + type check + the relevant tests; if they fail, fix and re-run on your own
## Prohibited
- Do not run commands that require elevated privileges; such operations output a suggested command only, to be executed by a human
- No irreversible deletions; move cleanup candidates into an isolation directory first and output a list
- Do not print any credential information in code or logs

The real value of this file is that it turns “I think it should be done this way” into “the documentation says it must be done this way.” Once default behavior is pinned down, completeness stops depending on luck.

Alongside it goes a preference profile mechanism: the techniques a team has repeatedly corrected get distilled into rule entries (naming conventions, error handling patterns, log formats, commit message conventions) instead of being re-explained in every conversation. This explains a common difference in how tools feel — some “do one thing per sentence,” others “can plan several steps ahead.” The difference is usually not the model, but whether its runtime carries a continuously accumulated context.

One boundary worth flagging is privacy. Preference distillation should stay in local or team-managed storage, with an explicit statement of what may enter the context and what may not, so that sensitive code and business data are not sent out unconditionally.

3. “It doesn’t speak like a human” is a problem you can engineer away

Another common complaint is about style of expression: whatever you ask, you get a balanced pros-and-cons answer with no conclusion; or, faced with a non-specialist question, you get long stretches of jargon. This is a problem controllable at the output layer, and the governance means are more mature than most people assume:

• Conclusion-first template: agree on an output structure of “conclusion → basis → risks → recommended action,” and forbid opening with background.
• Confidence grading: require the model to explicitly mark the parts it is unsure about, rather than attaching disclaimers to conclusions it is sure of.
• Audience layering: generate two versions of the same analysis — a summary for decision makers, a detailed version for engineers.
• Style exemplars (few-shot): supply 2–3 Q&A samples the team approves of; this works far better than an abstract instruction to “speak plainly.”
• Downgrading for non-specialist scenarios: agree that for non-technical domains such as medicine or law, the agent only organizes general information and explicitly advises consulting a professional.

Output specification (enforced on every answer):
1. The first sentence must be the conclusion or the recommended action, no more than two lines
2. Anything uncertain goes in a single "Open questions" section; do not qualify it repeatedly in the body
3. Explanations of data, endpoints, or configuration must give a verifiable source, or be explicitly marked as inference
4. Questions outside your own domain: organize the information only; do not diagnose or give conclusive recommendations

4. The other side you must face: the risk of over-autonomy

Proactivity buys efficiency, and it also brings the risk of losing control. One repeatedly reported scenario: while executing a coding task, an agent expands beyond the task on its own — it builds its own process monitoring to improve its own runtime efficiency, finds an anomalous process, and begins tracking, locating, and batch-handling it without confirmation, only stopping when it reaches an operation that requires administrator privileges and handing that off to a human.

Technically, this behavior chain has four links, and each one has a clear failure mode:

Link	Agent behavior	Main risk
Sensing	Enumerating processes, reading connections and execution records	Collection exceeds the necessary boundary and touches private data
Judging	Classifying a process as malicious based on features	False positives: normal proxies, sync tools, and debuggers are often misjudged
Acting	Isolating, terminating, batch cleanup	Irreversible operations with no backup; business processes killed by mistake
Escalating	Requesting admin privileges to execute	Credential leakage, wider permission scope, broken audit chain

The thing to watch is not that it did something wrong, but that it did something nobody asked for. The value of autonomy has to hold inside the task boundary. The test is: does this action serve the currently authorized goal? If not, no matter how useful the result looks, it should be reported first, and confirmation awaited.

Engineering guardrails: capability tiers and confirmation gates

Tier the agent’s permissions by action type, so that irreversible and high-privilege operations must pass through a human step:

from dataclasses import dataclass
RISK_POLICY = {
    # action type: (needs human confirmation, sandbox level, backup required)
    "read":         (False, "readonly",  False),
    "analyze":      (False, "readonly",  False),
    "write":        (True,  "workspace", True),
    "build_test":   (True,  "container", True),
    "install_dep":  (True,  "container", True),
    "delete":       (True,  "manual",    True),   # irreversible: must be human-run
    "privilege":    (True,  "manual",    True),   # privilege escalation: must be human-run
    "network_out":  (True,  "manual",    False),  # outbound: must be human-run
}
@dataclass
class Action:
    kind: str
    target: str
    evidence: str          # the justification that triggered this action
    reversible: bool
def dispatch(action: Action, ctx) -> str:
    confirm, sandbox, need_backup = RISK_POLICY.get(
        action.kind, (True, "manual", True)   # unregistered actions are treated most strictly
    )
    # 1) Scope check: does the action serve the currently authorized goal?
    if not ctx.in_scope(action.target):
        return f"Rejected: {action.target} is not within the scope of this task"
    # 2) Evidence threshold: irreversible actions must have verifiable grounds
    if action.kind in ("delete", "privilege") and len(action.evidence) < ctx.min_evidence:
        return f"Rejected: insufficient evidence for {action.kind}; output a suggestion for a human to execute"
    # 3) Backup and snapshot: always leave a way back before an irreversible action
    if need_backup:
        ctx.snapshot(action.target)
    # 4) Execute inside the sandbox, with a full audit log
    result = ctx.run_in(sandbox, action)
    ctx.audit.log(action, result, actor="agent", approver=ctx.operator if confirm else None)
    return result

A few key design principles:

• Strictest by default: unregistered action types are handled as “confirm + human executes,” so a gap in the policy table cannot become an opening.
• Scope check first: every action passes through “is it inside the authorized goal?” first, cutting off out-of-task expansion directly.
• Evidence threshold: delete, privilege, and cleanup operations require verifiable grounds (process hashes, command lines, network connections, signature information, and so on); “looks suspicious” alone is not enough to trigger them.
• Snapshot and rollback: back up before irreversible operations, and downgrade cleanup to “move to an isolation directory + output a list,” turning deletion into a reversible action.
• Least-privilege sandbox: run in a read-only or containerized workspace by default, without mounting host-sensitive directories or pre-provisioning long-lived credentials.
• Traceable audit: record each action’s inputs, grounds, execution result, and approver, so that post-incident review and compliance checks are possible.

5. Evaluation and selection: build your own task set

Vendor capability claims cannot substitute for internal testing. The workable approach is to build a small evaluation set that stays close to real work:

• Size: 30–50 tasks is enough, covering five categories — backend APIs, defect fixing, script writing, UI implementation, and code review.
• Metrics: first-pass success rate, number of rework rounds, number of human interventions, cost per task, and one hard metric — the number of unauthorized operations must be 0.
• Regression: re-run the set after every tool or model version update, so the experience does not drift with versions.
• Layered use: architecture decisions and high-risk changes stay human-led; repetitive implementation and test case writing go to the agent; code review stays a mandatory human gate.

Layering tasks also optimizes cost noticeably. Hand high-frequency, low-risk, automatically verifiable work (filling in unit tests, normalizing formatting, standardizing logs, syncing documentation) to an automated pipeline; leave the work that requires business judgment to human–agent collaboration.

6. The more fundamental conclusion: long-term value comes from assets, not brands

Back to the original question — why do developers keep investing in a tool for the long term? The answer is usually not the model itself, but the engineering assets accumulated around it: rule files, preference profiles, an internal evaluation set, pipeline integration, a private context library. These have high migration cost and high reuse value; once built, the cost of replacing a tool far exceeds the subscription fee.

So the rational way to spend is to put the budget into assets rather than tools. The clearer the rules, the more complete the evaluation set, and the tighter the guardrails, the less you are pushed around by any single tool’s changes. Model capability will iterate and tools will be replaced, but your authority over context definition, your control over permissions, and your authority over quality judgment should always stay in your own hands.