What Makes a Coding Agent Trustworthy? A Look at SolonCode's Design Choices

An engineer laid out a five-point trust checklist for coding agents — source readability, data locality, vendor independence, user-controlled autonomy, and reversibility — using SolonCode, an MIT-licensed open-source coding agent built in Java on Solon AI, as the reference implementation. The agent runs locally via CLI, Web UI, or desktop IDE, is provider-agnostic through a Settings → LLM configuration, and exposes explicit work modes so users choose the autonomy level per task.

Every week there's a new coding agent, and every week someone asks the same question in a slightly different tone: can I actually trust this thing with my codebase? It's a fair question. A coding agent reads your source, runs commands in your shell, and — increasingly — edits files and opens pull requests on its own. That's a lot of access to hand to a black box. So instead of arguing about which agent is "smartest," I want to talk about a less glamorous property: trust . What does it actually take for a coding agent to earn it? I'll use SolonCode https://github.com/opensolon/soloncode — an open-source coding agent built in Java on top of Solon AI https://github.com/opensolon/solon-ai — as a concrete reference, not because it's the only good answer, but because its design happens to line up with a checklist I think is worth having. Take the checklist with you and hold any agent to it, including this one. Here are the five questions I ask before I let an agent near a real repo. | Question | Why it matters | |---|---| | Can I read the source? | You can't trust what you can't inspect. | | Where does my code go? | Every network hop is a place your code can leak. | | Am I locked into one vendor? | Lock-in quietly removes your ability to walk away. | | Can I control what it does? | An agent that acts without review is a liability, not a tool. | | Can I undo a mistake? | Autonomy is only safe when it's reversible. | Let's go through them. The strongest form of trust is the kind you don't have to take on faith. If the agent is open source, you or your security team can read exactly how it builds prompts, what it sends over the wire, and where it stores things. SolonCode is MIT-licensed and fully open source — the CLI, the Web UI, and the desktop client are all in the open. That means the interesting questions "what exactly gets sent to the model?", "does it phone home?" are answerable by reading code, not by trusting a marketing page. This is the part that "purity" really comes down to for me: not a vibe, but the fact that there's nothing you can't look at. A coding agent has to send something to a model to be useful. The question is what else happens along the way — telemetry, analytics, background uploads. SolonCode runs locally. You start it from your own machine in whichever form you like: terminal CLI soloncode cli browser Web UI soloncode web 0 or the desktop IDE The agent process lives on your box, works in your workspace, and talks directly to the model endpoint you configured. There's no mandatory middle-tier service that your code has to pass through first. For teams with source that legally cannot leave the building, that distinction is the whole ballgame. A lot of agents are welded to a single model provider. That's convenient right up until pricing changes, a better model ships elsewhere, or your employer mandates a specific vendor. SolonCode is provider-agnostic. You configure models yourself — through Settings → LLM in the Web UI — and point it at whatever you're allowed to use: a hosted API, an OpenAI-compatible endpoint, or a local model. Because it's built on Solon AI, swapping the underlying model is a configuration change, not a migration. The practical value: the day a cheaper or smarter model shows up, you switch a setting instead of switching tools. This is the one people underestimate until an agent runs a command they didn't expect. Trust isn't "the agent is always right" — it's "I decide how much rope it gets." SolonCode makes the autonomy level an explicit choice. Its work modes include: The point isn't that one mode is "correct." It's that you pick the risk level per task, instead of the tool picking for you. Reviewing a hairy migration? Read-only planning. Renaming a variable across ten files? Let it run. Even a careful agent will occasionally do the wrong thing. What matters is whether that's a shrug or a disaster. SolonCode keeps persistent session history with rewind and redo , recoverable workspace checkpoints, and safe deletion. If a run goes sideways, you roll back to a known-good checkpoint instead of reconstructing your working tree from memory. Autonomy and reversibility are two sides of the same coin: the more freedom you give an agent, the more you want a clean undo. None of these five points are about which agent writes the cleverest code. They're about whether you can verify how it behaves — read its source, see where your code goes, keep your model options open, control its autonomy, and undo its mistakes. That's a better lens than "which one is smartest," because smart-but-opaque is exactly the combination that gets you into trouble. An agent you can inspect, run locally, point at any model, gate with approvals, and roll back is one you can reason about — and reasoning about your tools is the whole job. SolonCode is one implementation that scores well on this checklist, and it's open source, so you can confirm every claim above by reading the code: Run the checklist against whatever agent you use. The goal isn't loyalty to a tool — it's keeping the power to check, choose, and undo in your own hands.