Tool as CLI
An agent that cannot act on the real tools is a sophisticated chat window. It writes the code, and then I open the browser, go into GitLab, click create merge request, fill in the form the way the house requires, wait for the pipeline, open another tab to see the log, open the database client to check a piece of data. The work came back to me whole, and the gain stayed in the cheapest stretch of all.
The turning point is making each tool addressable from the command line. In some cases that is adopting the tool’s official CLI; in others, it was writing my own, because the official one does not exist or does not speak the vocabulary of the landscape.
The commands go to the whole of engineering together with the rest of the tooling, and are not configuration of my machine.
What is automated
GitLab: opening a merge request already in the house ritual, reading pipeline status, triggering and re-running jobs, pulling the diff for review. It is the surface I use the most, because every delivery goes through it.
Database and logs: opening a session without an exposed password, running a parameterized query, and reading the services’ logs knowing which queries return empty silently. That last part is operational knowledge you only acquire by getting burned, and it is now encoded instead of living in my head.
Service desk: reading what the business reported in a ticket, downloading the attachment that came with it, opening a ticket for another team, commenting and moving state. It is where demand comes in, and it was the surface with the most manual clicking per unit of work.
Change management. The ticket that precedes every production release has its own ritual: a mandatory form, an order between team and owner that cancels itself if inverted, fields that block closing if filled in wrong. It became a command precisely because it is the procedure where a mistake costs a lost release window.
Identity. The central provider that cuts across practically every service I maintain: creating a client for a new application, role, scope, token audience, test user. Only the staging environment is reachable, on purpose.
Standards and versions: checking code against the house’s written rules, and finding out which version an application is on.
What changes when the tool is a command
Three things, and the third is the one I had not foreseen.
The agent executes the whole task, not the textual piece of it. The unit of work stops being “write this function” and becomes “solve this and open the MR”.
The house ritual stops depending on memory. The merge request format, what needs to be described, which checks run before: all of that was in agreed convention, which each person followed with varying fidelity. It became a command, and a command does not forget.
Operational knowledge leaves the head and becomes a tool. Each CLI I wrote encodes something that cost me to discover, including the traps that return a wrong answer with no error at all, which are the expensive ones. That has value even if I never use an agent again, and it is the argument that convinced me to do it: the artifact outlives the tool that motivated it.
And it stopped being mine: with the tooling distributed, whoever joins engineering receives these commands ready to use. The trap that cost someone three hours became a line nobody pays for again.
The limit
Automating a tool is giving the power to act to something that makes mistakes with confidence. The answer is not to distrust everything, which cancels the gain, but to separate what is reversible from what is not: reading, querying and diagnosing are free; writing to a third-party system goes through me. A merge request is opened, never approved; the reachable identity environment is staging, and production is not reachable by design, not by configuration, which someone changes without thinking.