Using LLM Coding Agents: Practical Notes from Models to Agents

1. Clarify the concepts: a model is not an agent

Before sharing usage notes, it is worth separating two ideas that are often mixed up: large language models and model-based coding agents. Many developers who feel “AI coding tools do not work” are treating them as the same thing.

1.1 What a large language model is

A large language model is an inference engine that takes text in and returns text out. Think of it as an expert locked in a room: well-read and strong at reasoning, but unable to see your filesystem, run terminal commands, or use version control. No matter how detailed the chat prompt, the model still only produces suggested text.

1.2 What a coding agent is

A coding agent is a proxy system built on top of the model. The model is the “brain”; the agent adds “hands and feet”:

• File I/O: browse the project, read source, and edit files
• Command execution: run builds, tests, and scripts, then continue reasoning from the output
• Multi-step loops: an observe–think–act–verify cycle, not a one-shot answer
• Tool use: code search, dependency analysis, and similar tools so it can locate issues in a large repo

The difference in experience is simple: the model in a chat window is an advisor; the agent is an intern. One gives advice; the other does work. How well it works depends on how you supervise it.

2. Positive experiences in real use

2.1 Better task understanding and code location

Traditional completion tools generate from the current file and cursor. In agent mode you can give intent-level instructions such as “convert this module from synchronous I/O to async and keep tests passing.” The agent searches related files, traces call chains, edits, runs tests, and iterates. That intent-to-result flow is the main jump in experience.

2.2 Efficiency on refactors and bulk edits

Multi-file, patterned refactors (unified error handling, replacing deprecated APIs) show agents at their best. Example instruction:

Unify all directly thrown custom exceptions into exception classes that carry error codes.
Many files are involved. List the impact first; wait for my confirmation before applying changes.

The useful pattern is plan, then execute: have the agent produce a change list, confirm it, then allow edits. That cuts accidental changes.

2.3 A closed loop for tests and debugging

Agents can cycle through write tests → run tests → read failures → patch code → rerun. That is especially useful for flaky bugs and missing edge cases. Humans mainly review after the loop converges.

3. Limits and common pitfalls

The experience is not uniformly positive. These issues show up often in practice:

1. Context is not infinite memory. Long context helps, but irrelevant code in a huge repo dilutes attention and causes missed or over-eager edits. Use retrieval tools and bound the scope in the instruction.
2. Permissions must be tight. Unrestricted commands risk deleting files or committing bad code. Prefer read-only review or a sandbox in production-like settings, and require human confirmation for destructive actions.
3. Output quality follows instruction quality. Vague prompts such as “optimize this code” tend to be mediocre. Explicit constraints (performance, compatibility, test criteria) produce better results.
4. Cost versus speed. Stronger models fit architecture and hard reasoning; lighter models fit formatting and boilerplate. Mixing tiers is a practical way to control cost.

4. Practical advice for developers

• Tier the work: complex design with a capable model plus deep human review; mechanical edits with a lighter model plus automated tests.
• Keep the repo healthy: clear layout, solid tests, and explicit conventions improve agent results the same way they help human teammates.
• Keep a human in the loop: agents can take on much of the mechanical work; architecture, security review, and final acceptance stay with people.
• Use cloud-side plumbing: combine code hosting, object storage, container runtimes, logs, and alerting so agent output can be landed, verified, and released safely.

5. Summary

The value of intelligent coding tools is not replacing programmers, but removing repetitive labor. Treat the model as the brain and the agent as the hands, and use intent-level prompts, task tiering, and human-in-the-loop review. Tools will keep changing; these methods stay useful.