I have been building the draft and portfolio builder side of a stock draft game using Cline, running on Sonnet through a Claude Console API key. Most of the writing about AI coding tools focuses on whether the code is good. That matters, but two other things ended up mattering just as much day to day: how much control I actually had over what the tool could do, and whether I could tell what it had just done. Here is a concrete look at both, pulled directly from this project.
Permissions: a settings menu, not a guessing game
Every agentic coding tool has to answer the same question. How much should it be allowed to do without asking first. Too restrictive and you spend your day approving trivial actions. Too permissive and one bad command becomes a real problem.
Cline handles this with a straightforward auto-approve menu rather than anything hidden or inferred from a conversation. Here is the exact configuration used throughout this project.
Cline's auto-approve settings menu.
Breaking down what each toggle actually does:
- Read project files / Read all files, both on. The first scopes reads to files inside the current project. The second extends that to anywhere on disk. With this on, Cline never had to ask before opening a file for context.
- Edit project files, on. Edit all files, off. Cline could freely modify anything inside the project without asking, but editing something outside the project's boundaries required explicit approval each time. This is the one I would flag as the most important default. It gives an agent real freedom inside the sandbox of your repo while keeping a hard stop at the edge of it.
- Execute safe commands, on. Execute all commands, off. Cline distinguishes between commands it considers safe, things like running a linter or test suite, and anything it cannot classify that way. Safe commands ran without interruption. Anything else needed a manual yes.
- Use the browser, off. Cline never had a reason to browse during this project, so this stayed off by default rather than being something to remember to disable.
- Use MCP servers, on. This project used MCP tooling, so it was left enabled.
The practical effect: Cline moved quickly on everything that mattered for iteration speed, reading context, running lint and test commands, while the higher risk categories, editing arbitrary files outside the project, running arbitrary shell commands, browsing, stayed off unless deliberately turned on. None of this required trusting an opaque memory system or hoping a written instruction got remembered three sessions later. It was a set of checkboxes, visible at any time, adjustable in seconds.
If you are evaluating a coding agent for a real project, this is worth checking early. Can you see, in one place, exactly what it is allowed to do, or do you have to infer it from behavior?
Clarity: a diff explanation you actually get, not one you have to ask for twice
After Cline finishes a task, it shows two buttons next to its summary: View Changes and Explain Changes. View Changes is the raw diff. Explain Changes, when clicked, generates a plain-language explanation placed directly under the relevant code, file by file, with a reply box so you can ask a follow-up question right there, the same way you would comment on a pull request.
Here is a real example from this project. A review pass caught that four tickers in the shared sector data list had no matching historical price file, meaning a user could draft one and have it silently vanish from their results. The fix was a small, scoped helper function rather than editing the shared data file directly:
// lib/available-stocks.ts
import { STOCKS_BY_SECTOR } from "@/data/sectors";
import type { Sector, Stock } from "@/lib/types";
// A handful of tickers in the shared sector lists (data/sectors.ts) don't have
// a matching file in data/historical/, so picking them would silently show
// "No data" on the results page. Filtered out here, scoped to the draft flow,
// rather than editing the shared sectors list.
const TICKERS_WITHOUT_HISTORICAL_DATA = new Set(["HES", "PXD", "EMR", "ETN"]);
export function getAvailableStocks(sector: Sector): Stock[] {
return STOCKS_BY_SECTOR[sector].filter(
(stock) => !TICKERS_WITHOUT_HISTORICAL_DATA.has(stock.ticker),
);
}
Clicking Explain Changes on the commit that wired this helper into the draft page produced this, directly under the diff:
Cline explaining why the getAvailableStocks wiring change mattered.
That explanation is not a changelog entry someone wrote after the fact. It is generated at the point of the change, describing not just what moved but why the one-line wiring change was the part that actually made the fix take effect in the running app. The reply box underneath means if that explanation is not enough, you do not have to open a new conversation and re-explain your own codebase to ask a follow-up. You ask it right there, with the diff still on screen.
The same pattern showed up when a review pass flagged that the homepage was still 100% unmodified create-next-app boilerplate, with zero link into the actual feature:
Cline explaining the homepage rewrite.
Across a project where a dozen or more files can change in a single task, this is the difference between being able to explain your own code to a teammate afterward and quietly hoping they do not ask too many questions about a diff you half remember.
Why both of these matter together
Permissions and clarity solve different problems, but they compound. A tool that moves fast without asking permission for every action is only comfortable to use if you also know, clearly and immediately, what it just did and why. Cline's auto-approve menu gives you control over the blast radius. Explain Changes gives you visibility into what happened inside that radius. Neither one alone would have been enough to make me comfortable handing over a real feature build. Together, they made it a normal part of the workflow rather than something to babysit.
Top comments (0)