Large Language Model Capability Boundaries and a Practical Guide to Coding Agents

1. First, Draw the Line: What LLMs Can and Cannot Do

Before discussing AI coding, you need a realistic baseline of capability — one that neither inflates nor dismisses what the models actually do. The practical ceiling of today’s top-tier models is this: they can complete a closed loop on tasks of medium complexity — understand a requirement stated in natural language, read existing code, produce an implementation, and self-correct based on compile or test feedback. What they cannot do is equally clear:

• No persistent memory. The model itself holds no state across sessions. An architecture decision you discussed with it last week is invisible this week unless that information re-enters the context.
• No autonomous intent. It will not decide on its own that “this module needs a refactor.” Every action starts from a human instruction.
• Context is the world. The model’s entire understanding equals the text supplied in the current request. Files in the repo that were never read, constraints in a design doc that were never retrieved, do not exist as far as it is concerned.

The first practical implication follows directly: anything the model would need to “remember on its own” must be injected explicitly at the engineering layer. Team conventions, directory layout, dependency versions, and records of past pitfalls should all be turned into retrievable context assets, not left to the model’s memory.

2. The Capability Gap Is a Cliff: How to Measure It and How to Read It

2.1 Human Blind Evaluation and Rating Mechanics

The most credible way to measure model capability is still blind human evaluation: present two anonymous answers to the same prompt to reviewers in randomized order, have them pick the better one, then use Elo-style pairwise ratings to convert large volumes of head-to-head votes into comparable scores. Public leaderboards of this kind now accumulate millions of votes across hundreds of model versions. Three caveats matter when reading them: the score is a relative quantity, not an absolute capability value; the confidence interval is tied directly to vote volume; and the gap between the top few models often falls inside the noise band.

2.2 Strong on a Single Turn Is Not the Same as Stable Over Many

The multi-turn dimension deserves separate attention. The real working shape of a coding agent is a long chain: read files → think → edit code → run verification → read errors → edit again. Any intent drift, forgotten instruction, or compounding error in a single turn pushes the final artifact away from the goal. This produces a familiar pattern: a model that ranks at the top of single-turn Q&A can drop more than ten places on multi-turn stability. The two capabilities do not share a source. Single-turn evaluation tests point knowledge and expression; multi-turn evaluation tests the ability to hold goal consistency and self-correct across a long context — and that is the hard metric for agent scenarios. Selecting on single-turn leaderboards alone is like predicting a marathon placing from a 100-meter time.

2.3 What the Tier Difference Really Means: The Probability of Getting It Right the First Time

Put the same requirement in front of different tiers and the felt difference is immediate. Take “add a paginated query endpoint with caching to a layered backend service”:

Tier	Typical behavior
T0	Generates the full path in one pass (endpoint, service layer, cache key design, invalidation strategy) and proactively handles edge cases such as empty results and concurrent cache stampede
T1	Reaches a comparable result after one or two rounds of additional prompting
T1.5	Basically usable, but prone to missing boundary conditions and error branches
T2	Produces a skeleton that needs substantial human adjustment and completion

The gap is not “can it write the code” but the probability of getting it right in one attempt. A simple model makes this quantifiable: if a single sub-step has a correctness rate of $p$, and a task requires $n$ consecutive correct steps, the probability of completing it with no human intervention is $p^n$.

p = 0.95, n = 20  →  0.95^20 ≈ 0.36
p = 0.99, n = 20  →  0.99^20 ≈ 0.82

A four-percentage-point difference in per-step correctness more than doubles the end-to-end success rate. That is why a task a top tier finishes “in three rounds” can leave a lower tier “still wrong after fifteen” — every round it introduces deviation that later rounds must repair, and each repair is itself another probabilistic event. Conclusion: the model is the foundation, methodology is the structure built on top. If the foundation cannot bear the load, no amount of refinement above it will keep the building standing.

3. From Q&A Function to Agent: One Loop Is Enough

A bare model is just a stateless function: context in, text out. The entire mechanism for making it “act” can be summarized as:

Agent = main loop + tool calls + tool executor

Using “add caching to a service method” as the example, the full trace looks like this:

[Instruction] Add caching to the getById method in the user service
  ↓
[Recon] Call "read file" → fetch target source, sibling implementations, config classes
  ↓
[Think] Locate the injection point, decide cache key convention, null handling, invalidation timing
  ↓
[Act] Call "write file" → insert the caching logic
  ↓
[Verify] Call "terminal" → run compilation and unit tests
  ↓
[Self-heal] Read the error output → fix the implementation → verify again
  ↓
[Done] Verification passes, emit a summary of changes

The illustrative implementation is only a dozen lines or so:

messages = [system_prompt, user_task]
while not done and step < MAX_STEPS:
    reply = model(messages, tools=TOOL_SCHEMAS)   # the model decides the next step
    if reply.tool_calls:
        for call in reply.tool_calls:
            result = executor.run(call)           # real side effects happen here
            messages.append(tool_result(result))  # observations fed back into context
    else:
        done = True                               # the model declares the task finished

Keep the ownership of the three elements straight: “intelligence” comes from the model, “capability” comes from the tools, “autonomy” comes from the loop. Two engineering rules follow:

1. The tool boundary is the capability boundary. Grant read/write access to files and it can change code; withhold network tools and it cannot reach the internet; withhold database credentials and it cannot query production data. Do not expect the model to “figure a way around the limits,” but do not rely on its self-restraint either.
2. Safety comes from framework constraints, not model discipline. Least privilege, path allowlists, command blocklists, human approval for destructive operations, and sandboxed execution environments must all be implemented in the executor and framework layer.

Additional loop engineering details to fill in include: termination conditions (max steps, token budget, timeout); loop detection (abort when the same tool is called repeatedly with unchanged arguments); context compression (summarization and pruning strategy for long tasks); and failure classification (retryable errors vs. errors requiring human intervention). The common shapes of coding agents in industry — IDE plugins, CLI agents, standalone workbenches — are essentially different wrappers around this same loop. The differences come down to which tools are provided, where it runs, and which model it talks to.

4. Six Criteria for Judging an AI Coding Solution

• Task pass rate. Build an evaluation set on your own private codebase (30–100 real tickets with acceptance tests) and measure first-attempt pass rate and pass rate within k attempts. Public leaderboards carry a data contamination risk; the private set is the actual basis for decisions.
• Cost to convergence. Average number of rounds, token consumption, and wall-clock time needed to finish a task. At equal pass rates, half the rounds means half the cost and half the latency.
• Human intervention rate. The proportion of work that developers have to rewrite, heavily correct, or abandon outright. This is the metric closest to real-world experience.
• Artifact quality. Whether changes follow team conventions, whether they introduce duplicated code or unused dependencies, whether test coverage is updated alongside.
• Security. Interception rate for out-of-scope file access, dangerous command execution, and prompt injection (whether the agent is hijacked after reading a file or web page containing malicious instructions).
• Observability and reproducibility. Whether every tool call and context snapshot can be replayed in full. An agent you cannot reconstruct after the fact cannot be governed in production.

For teams consuming large-model capability from a model service platform such as Baidu AI Cloud, these metrics can be wired directly into the existing monitoring, alerting, and logging stack — turning call volume, success rate, average rounds, and per-task cost into dashboards so that model and prompt iteration is driven by data rather than by feel.

5. A Practical Adoption Path

1. Tier by model selection. Use low-cost, fast models for simple completion and single-file edits; route cross-module refactors and hard debugging to higher-tier models.
2. Context engineering first. Build repository retrieval, accumulate team convention files and notes on common patterns, and turn “implicit knowledge” into explicit context that can be injected.
3. Test-driven closed loop. Give the agent tool access to run tests and compile. Letting “verify → self-heal” actually run is the single highest-impact investment in accuracy.
4. Graduated permissions and sandboxing. Default to read-only; authorize write operations and command execution by repository, directory, and command category; isolate production environments entirely.
5. Move in small steps. Establish a baseline and an evaluation set on one module and one class of task first, then widen scope, and let measurements set the pace of rollout.

6. Conclusion

Understanding AI coding comes down to seeing three things clearly at once: models have well-defined capability boundaries, and the differences between them show up in long-chain stability rather than single-point performance; an agent’s autonomy comes from the plain “loop plus tools” architecture, with both capability and safety defined at the tool layer; and the merits of a solution must be settled jointly by pass rate, cost to convergence, and security on a private evaluation set. Select models carefully, treating them as the foundation, and keep investing in methodology as the structure above it — only then does AI coding move from demo to dependable productivity.