Designing a CLI on the premise that an AI will drive it

Mon, 15 Jun 2026 15:00:00 +0900

Part 5 of 5 (finale) — series: Building a publishing tool, and shipping it. Last time was shipping with brew and scoop. See the series index. This time: designing the CLI on the premise that an AI drives it.

crofty is a plain CLI you type at the terminal. But one premise of its design is a little different.

“A person installs crofty and does the first setup; after that, their AI (an agent) runs it.” That’s the usage it assumes. Rather than a person remembering and typing commands every time, an agent drives crofty on their behalf — and the build is meant not to get in the way when it does.

Contract the output — keep changing the inside, even after you ship

Mon, 15 Jun 2026 11:00:00 +0900

Part 2 of 5 — series: Building a publishing tool, and shipping it. Last time I shared the overall picture and premises. Each part stands alone; see the series index. This time: keeping the inside changeable even after you ship.

A tool only you use, you can rebuild however you like. The trouble starts after you publish it and other people begin using it.

Rename a single config key, say, and anyone who wrote settings with the old key suddenly finds their setup broken. Once it’s out, you can’t casually change the parts people lean on. “Whatever is visible from the outside, someone will eventually rely on” — this is the everyday face of what’s known as Hyrum’s Law.

CLI on nsys.dev Tech Blog

Designing a CLI on the premise that an AI will drive it

Contract the output — keep changing the inside, even after you ship