Building Trust with Software, One Visible Action at a Time

Here's the specific moment it happens: you ask an AI tool to do something, it says it's done, and you realize you have no idea what actually changed.

Not because it lied. The task is probably complete. But nothing was shown to you. No diff. No list of edits. No way to verify. And now you're in the uncomfortable position of either trusting that everything went correctly, or digging through your files trying to reconstruct what the system touched. Most people open the file, scan for a few seconds, close it, and tell themselves it's fine. But something has shifted. You trusted the tool a little less than you did a minute ago.

This is how trust in software erodes. Not through dramatic failures. Through small, invisible moments that accumulate.

Trust isn't a feature you ship

The software industry tends to treat trust as a credibility problem. Publish a security whitepaper. Add a SOC 2 badge. Write a blog post explaining your safety model. These aren't useless — but they're not what makes a specific person trust a specific tool in their daily work.

That kind of trust is built through something more granular: repeated observation. A 2024 study in Frontiers in Psychology on human-automation trust found that people calibrate their confidence in a system based on what they actually see it do, not what the system claims about itself. When the observable behavior matches their expectations, trust grows. When something happens they can't explain, trust drops, often sharply and permanently.

The catch is that most AI tools actively work against this. They optimize for fluency and speed. They complete tasks without narration. They move fast and don't leave visible traces. All of which feel like quality until something goes wrong and you can't figure out what.

What visibility actually does

There's a specific design decision that separates tools that build trust from tools that merely seem trustworthy at first: whether the tool shows its work.

Git is the clearest example. Version control became indispensable not because it prevented mistakes — you can still write terrible code in a carefully versioned repository — but because it made the history visible. Every commit is a record of what changed, when, and why. You can go back. You can compare. You can see exactly what another developer did. Over time, this visibility doesn't just help you recover from mistakes. It changes your relationship to the tool. You trust it more because you understand what it's doing, and you know you can undo it.

The same logic applies to AI writes. When an AI proposes a change and shows you a diff before applying it — additions in green, deletions in red — something shifts. You're not just accepting a result. You're reviewing a decision. And that moment of review, even if it takes three seconds, does something important: it keeps you in the loop. It means the next time the tool does something, you have a context for it. A track record. A pattern you've observed and verified.

Visibility is the mechanism through which trust accumulates. Not earned once, but built across hundreds of small interactions.

Reversibility changes the math

There's a concept in AI agent design called earned autonomy: the idea that a system shouldn't start with full decision-making authority, but should earn greater latitude as it demonstrates reliable behavior. The most trustworthy AI tools work this way. They ask first. They show the diff. They record what they did. And they let you undo it.

This doesn't mean every action needs approval — that would be exhausting and would undo most of the value. The interesting design question is which actions need to be visible, and which can run quietly. Low-stakes, easily reversible operations can happen in the background. Writes to things you care about — your notes, your contacts, your preferences — should be legible.

What reversibility does is change the cost of trust. If you know you can undo something, you're willing to watch the tool try. The stakes of any single action are lower. You can observe it work without fully committing to its output. And across many of these low-stakes moments, something accumulates: a sense of how the tool behaves, what it tends to get right, where it needs correction.

That's trust. Not the word, the actual thing.

The tools that ask for the most

There's a pattern worth noticing. The AI tools that ask for the most trust upfront — "just let me handle it," no audit log, no diff, no history — are often the ones that erode trust fastest. Not necessarily because they make more mistakes. But because when they do make a mistake, you can't see it. And when you can't see it, you can't correct it. And when you can't correct it, you stop relying on the tool for anything that matters.

The tools that ask for less trust upfront tend to accumulate more of it over time. They show their work. They record what they did. They let you push back. And slowly, across dozens of small observable moments, the relationship changes. You stop watching every output so carefully. You start delegating more. Not because you decided to trust the tool, but because you watched it earn it.

That's the difference between a tool you use occasionally and a tool you rely on.

---

Asgeir Albretsen is the founder of Harbor.