nsys.dev Tech Blog

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.

Shipping a CLI with brew and scoop — all at once via GoReleaser

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

Part 4 of 5 — series: Building a publishing tool, and shipping it. Last time was designing a multilingual site. See the series index. This time: the practical side of shipping with brew and scoop.

Once the CLI exists, the next question is “how do I ship it?” go install works, but being installable with Homebrew or Scoop is much easier on the people using it.

That said, building by hand for mac, Windows, and Linux, then hand-writing a Homebrew formula and a Scoop manifest… isn’t something you keep doing every release. So I had GoReleaser do it all in one go — including the one place macOS tripped me up (signing).

Designing a multilingual site — holding text in three kinds

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

Part 3 of 5 — series: Building a publishing tool, and shipping it. Last time was contracting the output. See the series index. This time: how to design multilingual support.

When you hear “make the site multilingual,” translating the body comes to mind first. But once you actually do it, the body isn’t the only text that needs translating. Nav labels, a profile, config values — each has a different nature, and forcing them into one container strains.

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.

Keeping what you write in your own hands — a small publishing tool

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

Part 1 of 5 — series: Building a publishing tool, and shipping it. Each part stands on its own; to follow the whole thing, see the series index. This part is the groundwork — what I wanted, and how the pieces fit. The individual design decisions come in later parts.

Where does what you write end up?

Most of the places we write are on someone else’s platform. They’re easy to be read on, but the post’s address (its URL), its look, and your connection to readers all live by that platform’s rules. If the service changes course or shuts down, your writing goes with it.

Stopping distributed scraping with country-level CIDR, on stock nginx

Fri, 12 Jun 2026 00:00:00 +0000

On a certain website, I noticed traffic from a particular country’s IPs had grown noticeably. Looking closer, it wasn’t the usual “one server hammering you” type — it was scraping spread across a great many IPs, each at a modest pace.

This is a record of how I read its nature, chose how to block it by “blast radius” (the range of damage if something breaks), and rolled it out without stopping the running servers. I hope it offers a clue to anyone troubled by similar distributed access.

Adding a blog

Tue, 09 Jun 2026 00:00:00 +0000

I’ve set up a place to jot down, little by little, the things I work on in day-to-day development — as a notebook. Nothing formal; partly a way to look back on my own work, written at an easy pace.

How it’s built

The homepage at https://nsys.dev prioritizes loading speed, keeping a perfect 100 on every PageSpeed Insights metric. I designed the blog on the premise that adding it would not break that.