Back to Blog

Tidy, Offload, and the Shape of Personal Infrastructure

Notes from building a small pair of terminal tools: one that understands what is taking space on a machine, and one that safely moves the things that do not belong there.

aitoolingterminalinfrastructuremacosgo
Tidy, Offload, and the Shape of Personal Infrastructure

Tidy, Offload, and the Shape of Personal Infrastructure

I had one of those nights where a small utility stopped feeling like a utility and started feeling like a product.

The problem was boring in the way all real infrastructure problems are boring: a development application server was almost full.

Not catastrophically full. Just full enough to be annoying. Full enough that every new build, cache, database file, and log rotation felt like it might be the thing that knocked the machine over.

So we did the normal thing first:

du -sh *

Then the slightly less normal thing:

du -sh ~/Library ~/Pictures ~/.vscode ~/Documents

And then the actual realization arrived:

This machine is a development application server. Why does it have a Photos library on it? Why does it have old backup data from another computer?

That is a different category of problem.

Disk cleanup tools usually answer: where did the bytes go?

The better question is: does this data belong here at all?

The two-tool shape

I have been building two small Go tools that started separately and are now beginning to click together.

The first is tidy.

tidy scans a filesystem, catalogs files into SQLite, classifies them, finds duplicate clusters, and reports what is using space. At first it produced markdown and JSON reports. Then it grew a terminal UI.

The second is offload.

offload is a resumable rsync job manager. It creates named jobs, starts transfers, tracks progress, supports pause/resume/stop, and keeps logs and status under ~/.offload.

Individually, they are useful.

Together, they become something better:

  • tidy decides what might not belong.
  • offload moves it somewhere safer.
  • deletion is not part of the first move.

That last point matters.

If a machine is full, the temptation is to delete first and ask questions later. That is how people lose data. A better workflow is:

  1. scan
  2. understand
  3. stage candidates
  4. copy/offload
  5. verify
  6. only then remove the local source, preferably by moving it to Trash

The goal is not to be clever. The goal is to make the safe thing the natural thing.

DaisyDisk for SSH

The emotional inspiration here is DaisyDisk.

DaisyDisk is great because it turns disk usage from a spreadsheet into a picture. You do not have to read every path. The big things announce themselves visually. You click into the shape of the problem.

But my immediate use case was not a polished Mac GUI. It was a Mac mini on the network, accessed over SSH, acting like a little development server.

So the design target became:

DaisyDisk for SSH.

Not a literal clone. A terminal-native translation.

The current tidy tui is still early, but the shape is already useful:

  • biggest directories first
  • proportional bars
  • keyboard navigation
  • drill-down / parent navigation
  • a header showing the current path
  • a footer that will eventually become a Collector

The first useful screen immediately surfaced the truth:

  • ~/Library was enormous
  • ~/Pictures was several gigabytes
  • ~/.vscode was non-trivial
  • ~/TimeMachine existed at all, which was the real smell

That is the magic moment for tools like this: not “I can see bytes,” but “I can see intent.”

A Pictures folder on a laptop is normal. A Pictures folder on a development application server is suspicious.

A Time Machine backup bundle on an archival disk may be fine. A Time Machine backup bundle sitting in a home directory on a dev box is probably digital sediment.

Tidy finds, Offload moves

Once the terminal browser existed, the next obvious step was candidate detection.

So tidy grew:

tidy candidates

On the server, that produced a ranked list of likely offload targets:

1. ~/Pictures      8.52 GB   Pictures/media folder on a dev server
2. ~/TimeMachine   229 MB    Old backup data does not belong on a dev server
3. ~/Music                  Personal media folder
4. ~/Movies                 Personal media folder
5. ~/Downloads              Downloads often contain installers/archives
6. ~/Documents              Documents may be personal/non-runtime data

The important word there is candidate.

A tool should not assume it knows enough to delete your life. It can make a case. It can rank. It can explain. It can stage. It can automate the boring mechanics after you agree.

So tidy also grew:

tidy offload --start ~/Pictures

That creates an offload job and starts it.

Under the hood, offload handles the boring-but-important parts:

  • rsync flags
  • destination paths
  • logs
  • process state
  • progress parsing
  • pause/resume/stop

This is the division of labor I like:

tidy is the intelligence layer. offload is the transport layer.

One understands the local machine. The other moves bytes reliably.

The Unix thing, but personal

There is an old Unix idea that still feels almost unfairly powerful:

Make small tools that do one thing well, then compose them.

That philosophy has always been beautiful. It has also always required a certain amount of patience. You had to know what tools existed, understand their flags, wire them together, and accept whatever rough edges came with them.

The modern consumer software answer to almost everything is the opposite:

  • find the perfect app
  • hope it exists
  • hope it works the way you think
  • hope it is not bloated
  • hope it does not become a subscription
  • hope it does not trap your data
  • hope it integrates with the other thing you already use

That is a lot of hoping.

The AI-era version feels different. I do not have to go hunting for the perfect disk utility, transfer manager, dashboard, and cleanup workflow. I can build the exact little utilities I want.

Not giant platforms. Not forever-products. Just sharp tools.

In this case, Go is a great language for the job: fast, boring, portable, easy to cross-compile, and happy to produce a single binary. The terminal is a great interface because it works everywhere I care about: locally, over SSH, on a Mac mini, on a server, inside automation.

And the agent loop changes the economics.

I can be sitting on the couch, using WhatsApp, saying things like:

  • “That scan looks dead. Make it show progress.”
  • “I love DaisyDisk. Can this be graphical in the terminal?”
  • “This is a dev server; those files do not belong there.”
  • “Can tidy and offload work together?”

Then the tools improve. Immediately.

That is wild.

It makes the Unix philosophy more accessible, not less. The hard part used to be the mechanical labor of building and wiring the tools. AI agent engineering collapses that cost. Now the scarce part is knowing what you want, where the boundaries should be, and what “safe” means.

Small tools still win. They just get easier to make.

tidy does not need to become offload. offload does not need to become tidy. They can remain separate, legible, boring little programs. But because they speak through the filesystem, command-line arguments, config files, and process state, they can compose beautifully.

That is the sweet spot:

  • personal tools
  • optimal materials
  • no subscription
  • no platform lock-in
  • terminal-native
  • composable
  • built with an AI agent as the accelerant

This is the part that makes me genuinely happy. Not because the tools are perfect yet. Because the distance between “I wish my computer worked this way” and “now it does” is collapsing.

Progress matters more than you think

One of the first sharp edges was progress reporting.

The first version of tidy scan looked dead during long phases. It was working, but it did not breathe. That is bad UX, especially for filesystem tools. If a command might take minutes, silence feels like failure.

So tidy got periodic progress output during walking and hashing.

Then offload had a similar problem. The job was running, rsync was transferring files, but the status output looked wrong because Apple’s older system rsync reports progress differently than newer rsync. It was technically parsing something, but emotionally it was lying.

That got fixed too.

Now offload status can say things like:

Completed transfers  : 31,938 files
Current file progress: 65.77 KB
Files checked        : 31,938 / 77,916
Current speed        : 16.82MB/s
ETA                  : 7m 14s

That is the difference between “I hope this is working” and “I trust this machine.”

Trust is built out of small truthful signals.

The Collector

The next major feature is the one I am most excited about: a DaisyDisk-style Collector.

The Collector should not delete. It should stage intent.

In the tidy TUI, I want to be able to move through the directory tree and press space on things that do not belong. The Collector accumulates them and shows the total:

Collector: 3 items, 9.1 GB staged for offload

Then the action is not “delete.”

The action is:

Create offload plan

After the offload succeeds and verifies, a later cleanup step can offer:

Move local sources to Trash

Not rm -rf. Not silent deletion. Not “trust me bro.” Trash first. Human final say.

This matters because the files that are worth reclaiming are often emotionally or operationally important:

  • photo libraries
  • message attachments
  • archives
  • backup bundles
  • project data
  • old client work

The bigger the win, the more careful the tool should become.

Why this feels like an AI-era tool

The funny part is that none of this is exotic.

SQLite. Go. rsync. SSH. Markdown. Terminal UI. These are boring materials.

The thing that feels new is the development loop.

The tool was not designed in a vacuum. It emerged through conversation:

  • “Why does the scan look dead?”
  • “Can it show progress?”
  • “Can it be graphical in the terminal?”
  • “I love DaisyDisk.”
  • “This is a dev server; those files do not belong here.”
  • “Can tidy and offload talk to each other?”

Each sentence became a design constraint. Each constraint became code. Each run produced new feedback.

That is a different way to build software. It is less like writing a spec and disappearing for two weeks, and more like shaping clay with a very fast apprentice.

The human job is not gone. If anything, the human job becomes clearer:

  • taste
  • judgment
  • safety
  • sequencing
  • naming
  • deciding what the tool should care about

The code is the artifact. The conversation is the workshop.

Public repo readiness

I want these tools to become public, but not recklessly.

Before publishing, I want the repos to satisfy a few rules:

  • no private hostnames or personal NAS paths hardcoded as defaults
  • no generated memory/log artifacts committed
  • no secrets, keys, tokens, or credentials
  • no local-only assumptions that make the tools feel like they only work on my machine
  • clear README files with safe examples
  • dry-run/default-safe cleanup behavior

The current recommendation is: the idea is public-worthy; the repos need a small sanitization pass first.

That is normal. Useful internal tools almost always contain a little local scar tissue. The trick is to preserve the opinionated workflow while removing the private assumptions.

Where this is going

The near-term roadmap is straightforward:

  1. finish the tidy TUI browser
  2. add the Collector
  3. make tidy candidates smarter and more explainable
  4. let tidy offload generate safe offload plans
  5. improve verification before local cleanup
  6. make both repos public-safe

Longer term, I can imagine a small family of tools for personal infrastructure:

  • terminal-first
  • safe by default
  • built for SSH and small servers
  • visually understandable
  • boring underneath

That last part is important.

The best tools often feel magical at the edge and deeply boring in the core.

A pretty terminal UI is nice. A smart candidate list is nice. But underneath, I want files copied by rsync, state stored in plain directories, reports written as markdown, and actions that can be inspected and resumed.

Magic interface. Boring machinery.

That is the sweet spot.

And honestly? I am giddy about it.

Back to all posts