Building tools for two kinds of users
What changes when your developer tool is used by engineers and AI agents at the same time.
For most of the history of software, a developer tool had one kind of user: a person in front of a screen. The trace tool I built now has two. Engineers use it every day. So do AI agents. Designing for both turned out to make it better for each.
Where it started
The tool began as a fix for my own frustration. Our systems write very large binary traces, and the viewer we had was slow to load and slower to filter. It had no colour, no real keyboard navigation and no command line. Every investigation started with waiting, and the waiting added up to hours.
So I wrote a new one in Go, built around large files from the first line. Traces that took hours now open in seconds, and whole batches can be processed in one run. Engineers who care about their tools picked it up quickly: people who live on the keyboard and hate waiting.
Lesson 1: build the engine first, the screens second
The most important decision was one I made for people, not for AI. I kept all the real work in one core engine and treated every way of using it as a thin front-end: command line, terminal UI, web, VS Code and desktop.
That paid off twice. Each new front-end was cheap, because it reused everything. And when agents arrived, they already had what they needed most: a command line with predictable output. An agent can’t click through a GUI, but it is very good at running a command and reading the answer.
Lesson 2: give an agent a map, not the whole territory
The first instinct is to hand a model everything: the full trace, every log format, all the context you have. It works badly. The model drowns, and you pay for every token of it.
What works is progressive disclosure. The agent starts with a small map of what exists and how to ask for it. When it needs the detail for one part of the system, it asks for that part and nothing else. Teams can add knowledge about their own area without making every request heavier.
Lesson 3: speed matters more for agents than for people
A person opens a trace once and reads it. An agent opens it, filters, checks a theory, filters again, and repeats that dozens of times. If each step takes minutes, the agent is useless. If it takes a second, the agent can reason its way to an answer while you make a coffee. The performance work I did for impatient engineers is what makes AI analysis practical at all.
Lesson 4: people deserve AI too
Agents driving the tool is only half the story. The other half is engineers asking for what they want in plain language, by typing or by voice: show me every error from the card reader after the last restart. The tool turns that into the filter they would have written by hand. Experts still write filters. Everyone else no longer has to learn how.
What I’d tell myself at the start
Treat the command line as the real interface and design its output to be boring and stable. Everything else is a skin. If a tool is pleasant for a keyboard-first engineer, it is already most of the way to being usable by an agent.