I was reading about GitButler recently, and one idea really stood out to me: making version control easier for coding agents by giving them higher-level commands.
Git is powerful, but it is also a collection of relatively low-level operations. An agent might need to inspect the working tree, work out which files belong to a change, stage them, create or amend a commit, and potentially recover when something goes wrong.
Humans have learned how to navigate those steps. Agents can too, but that does not mean it is the best interface for them.
GitButler's approach got me thinking about a broader question:
What if an agent could build its own higher-level tools by watching how it works?
The Repetitive Bits of Agentic Coding
When I use Codex, I often notice chains of tool calls that look familiar.
The agent searches for files, reads a few of them, checks Git status, runs a command, inspects the output, then runs another. Sometimes that is exactly what the task requires. Other times it looks like a sequence the agent has probably performed dozens of times before.
Imagine a recurring validation workflow:
git diff --name-only
git status --short
npx tsc --noEmit
npm run lint
npm run testNot every project needs these exact commands, and not every change needs every check. But the intent is recognisable: understand what changed and validate it.
If that sequence appears regularly, why should Codex have to rediscover the procedure each time?
What if it could eventually call:
agentcli validate --changedA purpose-built command could handle the mechanical steps, apply project-specific rules, and return structured results instead of pages of terminal output.
That is the part of GitButler's approach I find interesting. The agent does not necessarily need a better way to type commands. It needs a better interface for expressing intent.
A CLI That Evolves Through Use
My idea is a small local tool that observes coding-agent activity and gradually builds a catalogue of useful commands.
The loop would be something like:
- Observe: Collect tool calls, arguments, outcomes and timing from Codex sessions.
- Discover: Find recurring sequences and group them by what the agent was trying to achieve.
- Propose: Ask an agent to design a reusable command that performs the same job.
- Validate: Test the proposed command against representative examples.
- Reuse: Make approved commands available to future sessions, then measure whether they actually help.
Over time, the CLI would become tailored to the projects I work on and the workflows I repeat.
I like the idea that its feature set would not be planned in advance. It would emerge from real usage.
Finding Patterns Is the Interesting Problem
Generating a shell script is relatively easy. Knowing which shell script to generate is much harder.
A simple frequency counter might tell me that Codex runs rg, git status and cat all the time. That is not particularly useful. Those commands serve lots of different purposes.
The more interesting signal is a repeated workflow.
For example, perhaps Codex often searches for an API endpoint, follows the route to its handler, locates the associated types and tests, and then reads the relevant configuration.
The exact filenames and search terms will change, but the underlying task is similar.
That might become:
agentcli inspect-endpoint --route /usersThe command would be more than an alias. It would encode a repeatable process and return a concise result that another agent can work with.
This also raises an interesting question: how much should the system infer from adjacent tool calls, and how much context does it need from the conversation to understand the agent's goal?
Two commands happening next to each other does not necessarily mean they belong together.
We Already Have Some of the Raw Material
Codex records local session activity, and its tool integrations provide opportunities to observe operations as they happen.
That suggests a fairly simple starting point: analyse existing session logs before building a live telemetry collector.
I'd want to know:
- Which multi-step workflows recur most often?
- How many calls and how much elapsed time do they consume?
- Which sequences have stable inputs and predictable outputs?
- How many can be compressed without losing useful flexibility?
From there, Codex could propose a small number of commands, each with a defined input schema, implementation and tests.
The first version would be deliberately boring. A local database, a command-line interface, and a folder of generated command modules would be enough to test the concept.
No dashboard required. No autonomous installation of arbitrary scripts.
Does Fewer Calls Actually Mean Faster?
There is an important distinction here.
Replacing five shell commands with one does not magically make the underlying checks faster. The same compiler and test runner still need to execute.
The potential savings come from reducing the decisions between operations, avoiding repeated tool round trips, and returning less irrelevant output to the model.
But there is a danger of optimising the wrong thing. A command that wraps five operations might be less useful if the agent normally needs to stop after the second one and react to the result.
So I would want to benchmark the original workflow against the generated command, looking at elapsed time, tool calls, tokens, errors and task success.
And if the new command does not improve anything, it should not be kept merely because it looks neat.
Tools That Can Improve Themselves
This is where the idea starts to feel more interesting than a personal productivity script.
Imagine that every few weeks the agent reviews its own tool usage and proposes changes to its toolkit.
It might identify a new command worth adding. It might notice an old command is never used. Or it might discover that three existing commands could be combined into something more useful.
There would need to be boundaries. Generated commands are executable code, so I would want review, tests, permissions and a straightforward rollback mechanism. An agent should not silently promote untested scripts into its own environment.
But within those boundaries, it is a compelling feedback loop:
Agent works
↓
Telemetry reveals repeated workflows
↓
Agent proposes better tools
↓
Tools are tested and approved
↓
Agent uses the improved tools
↓
RepeatThe agent is not just getting better at using the tools it has. The tools themselves are adapting to the agent.
Where I'd Start
I'd probably make this a small side project rather than a full platform.
First, inspect a month of local Codex sessions and see whether there are any genuinely useful recurring patterns. Then generate a handful of candidate commands and compare them against the original workflows.
If the results are interesting, the next step would be live collection, automatic suggestions and a lightweight command registry that Codex can discover.
GitButler made me think about the benefits of designing tools specifically for agents instead of expecting them to operate human-oriented interfaces.
My extension of that idea is simple: rather than designing every higher-level command ourselves, could we let agents discover which commands they need?
I don't know yet whether the savings would be meaningful. But I really like the possibility of a development environment that gradually learns how to make its own repetitive work easier.