Ioannis Loutsis

Vibe coding works because we stop reviewing every step. We describe what we want, the agent gets on with it, and we look at the result. That speed is the whole point, and I don't think anyone wants to go back to approving every command.

But it means the agent is running commands, reading files, installing packages and calling tools with our own permissions, mostly unwatched. When something goes wrong, the transcript doesn't help much: it's a conversation, not a record of what actually happened on the machine.

For a long time that felt fine to me. Then I started recording every action my own agents took, and looked at a few days of it.

What surprised me wasn't any single command. It was the combinations. Reading a file with credentials in it is normal. Calling a cloud API is normal. The same session doing one and then the other, without me asking for either, is the kind of thing I want to at least notice. Some of what got flagged I could explain right away. A few I'm still going through, which is exactly the point: without the record, I wouldn't even know there was something to look at.

Coding agents now run commands, read files and call tools with our own permissions, and most of us review the final diff rather than every step. For a while that felt fine to me.

Then I started recording every tool call my own agents made. Some of what it flagged in my own sessions was things I hadn't noticed at all, like a credential read followed by a call to a cloud API in the same session. Each turned out to have a reason, but I only knew because I looked. The transcript alone wouldn't have told me.

I'm curious how others approach this:

- Do you review what your agent ran, or only the result? Why?

Today I launched Agentmetry, an open-source tool I've been building alone: it records what AI coding agents like Claude Code, Cursor and Codex actually do on your machine (every command, file read and tool call) into a tamper-evident local log.

A few things I didn't expect, which might be useful to anyone building developer tools:

1. The first real feature request wasn't about security. A developer asked to see time and token usage broken down by task and tool, because they'd found by hand that one browser tool was burning most of their time and tokens. Same data, completely different value. I'd been pitching the wrong benefit to half my audience.

2. Saying what the tool can't do helped more than the features. It only sees agents whose hooks are installed, and it can't see cloud agents at all. Every time I said that up front, the conversation got more serious, not less.