The Difference Between a "Script" and a "Tool"
Think of the difference between a sticky note and a printed manual. A sticky note is written for yourself, in the moment, with no expectation that anyone else will read it. A printed manual is written for an audience — it has structure, clear instructions, and handles the case where the reader doesn't already know what you know. Scripts are sticky notes. CLI tools are manuals.
As an Operations Engineer, you write scripts constantly. A quick Bash one-liner here, a ten-line Python script there to glue two APIs together. These scripts work fine when you're the only one running them, in the exact environment you wrote them in, with the exact inputs you had in mind.
But what happens when your team grows? What happens when that quick script becomes critical to a deployment pipeline? Suddenly, your "quick script" is infrastructure. If it breaks silently, deployments fail. If a new team member can't figure out how to run it, they wake you up at 3 AM. If it exits with code 0 after failing, your CI/CD pipeline happily continues and breaks production.
CLI Engineering is the discipline of taking an ad-hoc script and turning it into a robust, reliable, and usable command-line tool. It means moving beyond just making the code work and thinking about the user interface of the terminal — the contract your tool makes with its users and with the systems that call it.
A well-engineered CLI tool:
- Tells you how to use it (help generation).
- Tells you accurately if it succeeded or failed (exit codes).
- Can be read by humans AND other programs (output formatting).
- Handles unexpected inputs and interruptions gracefully.
- Behaves predictably according to standard Unix conventions.
The gap between a script and a tool is not about lines of code. A 20-line Python script that handles errors correctly, exits with the right codes, and prints structured output is a better tool than a 500-line script that doesn't. This lesson covers the specific, concrete practices that close that gap.