How to Build a Slow Product in the Fast AI Era

It has been a little over two months since I wrote the previous post, From Mole CLI to Mole for Mac: What I Learned. In that time Mole went from 1.13 all the way to 1.18, added AI tool cleanup and System Data cleanup, the Windows version shipped on the evening of October 14, and the GitHub repository quietly passed 72.9K stars.

Looking back, most of my time did not go into new features. It went into things that look like a poor trade to an engineer: installing 850 Mac apps from China and abroad one by one, using each a little, then uninstalling it; resending more than 400 unactivated license emails one at a time; redrawing dozens of icons over three rounds; and rewriting the interface copy line by line until someone opening Mole for the first time could follow it.

Programmers naturally like work that scales. Whatever the task, we look for a way to turn it into a tool, a script or an AI call so we can be lazy. These two months left me feeling a bit differently. Code keeps getting cheaper and anyone can quickly build something that runs, so what sets products apart is more and more the details you only learn by doing the work yourself. The good news is that with AI, these chores that used to take a lot of people can now be finished by one.

I am a bit obsessive and keep my own Mac at around 30 apps. To make Mole’s uninstall more thorough and its leftover cleanup stronger, the first round collected more than 300 Mac apps from China and abroad, about 100 GB of downloads, split into 30 groups of 10. An agent used computer use to download each from its official site, install it on my Mac, check its folders, update bundles and login items, uninstall it, look for what was left behind, and add the missing rules to Mole.

At first I thought 100 mainstream apps would be plenty. When those were done I thought, why not another 100, and at 200 I thought the same again. Later I added App Store versions and extensions, and the count went to 549, 709, 824, and now 850. My Mac suddenly turned into the very messy desktop below. Have a look.

The process looks extremely boring. Many apps start popping up permission requests the moment they are installed, nudge you to buy a membership, and some insist on an administrator password. The agent handled most of it on its own and I stepped in for the rest. What surprised me most was that the AI wrote its own scripts to automate installing, uninstalling and checking leftovers, to make its job easier. Quite clever. I was mostly its assistant.

It also changed some of my assumptions. I thought software engineering was orderly and followed conventions, and that after 100 apps there would be few rules left to add, since the conventions of mainstream apps should be enumerable. The further I went, the clearer it became that this was wrong. Many leftovers cannot be found by any general rule, and some bundle IDs are not even reverse domain names. A convention that looks tidy may just be what some programmer typed years ago, with no theory behind it, so the only way is to install one and check one.

That first round of more than 300 apps gave Mole 13 kinds of reusable general rules and more than 90 precise cleanup paths. Along the way it also fixed more than 30 places I had thought should be cleaned but should actually be left alone, and added more than 100 unit tests. Those places to leave alone were as valuable to me as the new leftovers: a cache can be rebuilt, the user’s own files cannot, and data several apps share should never go just because one of them was uninstalled.

I also wrote up the leftover paths and uninstall steps for every app as guides in Chinese and English on the site. All 850 are free to read, so even without any tools you can follow them by hand. See whether the apps on your Mac are in this list.

Before Mole had AI cleanup, many people had asked to clean up the data AI tools leave behind. I used to see AI coding session history as a valuable asset, so Mole only cleaned real caches and old versions there.

But using AI every day, I had piled up plenty of old artifacts, old sessions and worktrees I no longer needed, and one user’s single opencode.db had grown to 62 GB and they urgently asked how to clean it. So I tested more than 30 AI tools one by one: 13 desktop apps, 13 command line tools, plus the folders OpenClaw, Hermes and Pi leave behind after uninstall.

Unlike the earlier install-and-uninstall rounds, this time I signed in to every tool I could and really used it once in a real project: asking questions, running agents, building code indexes, setting scheduled tasks. A lot of the data only appears after real use, and an app you install but never open will not show it.

For each tool, the AI compared against the state before install, measured what it wrote into the home folder, ~/Library, /usr/local/bin and the shell configuration, and recorded it in a ledger. Then it checked how many processes and how much memory the tool used, uninstalled it with Mole, and scanned the whole home folder by name for anything unlisted. Whatever was missing went into the code that night and was tested again.

This round was more surprising than ordinary apps. The most visible part was memory: the 13 desktop apps open together took about 23 GB, and one tool from a big Chinese company started 41 processes and 4.49 GB of memory on launch. Most of these tools are built on VS Code or Electron, so each window brings a string of helpers. That is why, when I built status monitoring, I gave each app one row and added up all of its child processes; in Activity Monitor alone it is hard to see who is actually eating the memory.

Then there were the small changes they made to the system. Some tools, on first launch, put a root-owned command link in /usr/local/bin, which becomes a dead link once the app is deleted. One put a python3.12 into ~/.local/bin, so typing python3.12 in the terminal afterwards ran its bundled copy. The worst was a Chinese command line tool: I ran it once, it told me it was no longer maintained, and then, without asking, downloaded and installed its new version, edited .zshrc, and renamed the old command to legacy.

The sizes were wild too. One desktop app downloaded a roughly 1 GB toolkit the first time I used its Work mode, 3.1 GB unpacked, carrying its own LibreOffice, FFmpeg and OpenJDK. My own ~/.codex, which I use every day, was already 24 GB, 17 GB of it sessions, and 12 GB of the Claude desktop app’s 14 GB was the Cowork virtual machine. Many skill installers also write a skills/ folder into every agent’s directory whether or not you have that agent, so I had config folders for Qwen Code, iFlow and Droid without ever using them. Mole’s first version even treated them as 2.4 MB of tool leftovers and nearly cleaned out my installed skills as junk.

Something else I did not expect was processes. The morning after an uninstall, two command line tools had their folders deleted and grown back. The terminal sessions from the night before were still alive: the program files were already in the Trash, but the background processes kept writing logs into the folders. A command line tool has no window, and closing the terminal tab does not necessarily end it.

I also saw plenty of mess. Some installers quietly write something to your clipboard while downloading, to track the install channel. Some pop up endless prompts to join campaigns and claim tokens, ads plastered everywhere, the kind of tool you hold your nose to use. By comparison, Claude, Codex and Cursor stayed fairly restrained, and in China the one that pleasantly surprised me was Qoder: a clean interface, good taste, nothing pushy.

All this changed one of my earlier judgments. Sessions really are valuable, but old sessions and worktrees you are done with really do take space. Today’s AI cleanup lists sessions by the retention period you choose, 15, 30, 90 or 120 days, each with its title and time, and keeps a recovery copy before deleting. A worktree only shows up when git can prove it has no uncommitted changes. opencode.db gets database compaction, which only returns the freed pages to the disk and never deletes the user’s conversations.

A while ago I was browsing Reddit and saw many people complaining that System Data in macOS settings often reaches one or two hundred GB, asking what it is and whether it can be deleted. That number is only the result of a classification. Apple’s own explanation also counts every file the other categories did not take, so it is not a list you can delete from. Mole’s System Data group therefore only states how much it measured and can handle, and does not try to match the total in System Settings.

The hard part is that you cannot install one thing and check one thing on your own machine here. Every Mac’s System Data is different, and many cases can only wait for a user report and then be traced layer by layer.

Take purgeable space. The number the system reports mixes iCloud files that can be reclaimed with caches the system will release on its own. Even a Mac with no local snapshots shows around 142 GB. Early Mole used that number to estimate how much snapshots could free, estimated 50.7 GB, and after cleaning the free space only grew by a few GB. Now the snapshot row no longer shows an estimated size; after cleaning, Mole measures how much free space actually changed, and since APFS does not return space all at once after a delete, it waits until the number stops growing. Along the way I caught a bug: reading free space always returned a stale cached value, so cleaning always showed 0 freed.

Another user’s System Data held 179.53 GB of wallpaper render cache, 6644 files in all, an uncompressed BMP for every wallpaper at every screen size, never deleted by the system. The first version could find it but could not delete a single byte, because the wallpaper process is always running in the background, and the command that checks whether a file is in use reported errors on single files, which were treated as uncertain. In the end it only lists the ones older than a week that are not currently on screen, for the user to confirm, and this shipped in 1.17.

As for things like the 119 GB iPhone backup and the 79.5 GB Parallels virtual machine on my own Mac, they are big but should never sit behind a select-all delete button. Mole only shows their size and where to manage them, they cannot be ticked, and they do not count toward the space that can be cleaned, so people go back to the right place and make sure before doing anything.

Over the National Day holiday I spent a day on something I had put off for a long time. I went through every Mole order from the May launch to the end of September that was bought but never activated, about 400, had AI write a simple local script to list the emails and keys, and resent them one by one, grouped by purchase month, country and language. Not a promotion, and not a push to activate, more like sending a message to a friend: a reminder not to forget it, and no rush if they are not using it yet.

Interestingly, replies kept coming in from users in many countries, and they meant much more than I expected. Some said they bought it just to support the development and actually preferred the Terminal version, and some had forgotten about the GUI and had been using the CLI all along. One user had bought two, one for themselves and one for family as a Christmas present, so it was still unactivated, the key already saved in their password manager. It made the world feel like a lovely place.

One user could use it on a work computer at first, until the company banned software outside its approved list, and was waiting for a new Mac of their own to start using it. Another bought during a discount and still had no MacBook, planning to activate as soon as the new machine arrived. Someone replied with just “Prefect!”, and someone else said during the holiday that it was time to slack off properly, a pun on mole that o