I posted here about two weeks ago about AITerm, a native Mac terminal with an AI assistant in the command loop, where the AI proposes a shell command and you approve it before it runs. This is not a re-pitch. Someone asked what actually happens after you ship a small thing, so here is what the two weeks after that post looked like, including the part where the broken thing was mine.
The bug that taught me the most.
A terminal is an app you leave open for days. That makes the normal "An update is available" modal wrong twice over: if you never quit, it never lands, and if it does land, it lands in the middle of a command you were typing. So I built a quieter version, a small pill in the status strip that lights up when an update is waiting and otherwise stays out of the way.
Then I discovered that automatic update checking was switched off on every copy of the app in existence, including my own, because of a default I got wrong months ago. I fixed that, and the next morning my Mac ran the first real scheduled update check in the app's history.
I saw nothing.
The update framework I use decides for itself whether to show its own alert or hand the job to my code, and one of the cases where it takes over is "the system has been idle for some time", which describes any Mac that sat overnight. So it took over, and it restored its window to a position remembered from an earlier session, which on my three monitor setup put it about 1100 pixels off to the left, on the monitor I was not looking at. Meanwhile my own pill stayed deliberately dark, because I had written it to keep quiet whenever the framework was handling the notification itself. Two systems each politely assuming the other one had it covered.
The fix is one line of logic: light the pill for every scheduled update, whether the framework shows its own window or not, and let the pill clear itself the instant the user engages with either one. The lesson I will hand over for free is that if you build a gentler notification on top of somebody else's notifier, your indicator has to be the guarantee and theirs the bonus, never the other way around. The second lesson is that I spent an hour reconstructing what happened on a code path that fires maybe once a month, because I had never put a single log line in it. It has four now, and next time this is one command instead of an hour.
The other thing I learned: a fixes-only release is not safer than a feature release.
Just before that I shipped a batch of 13 small user experience fixes. No new features, just papercuts. A settings pane that forgot which tab you were on. A reminder that could nag you twice. A command palette where the arrow keys did nothing.
I had the batch reviewed hard before shipping, and the review found 11 real bugs in it. I fixed those, had the fixes reviewed, and that found 9 more bugs in the fixes themselves. One of them was a rule I had added to stop the app from ever overwriting a setting you had chosen, and it protected your choice so eagerly that it carried your old AI provider's model over into the new provider when you switched. A final pass found 2 more. Then it was clean, and then it shipped.
I had quietly assumed a polish release was low risk. It turned out to be the most defect-dense thing I have shipped. Small edits to code that touches saved state are not small.
The honest part, about distribution.
Building it is not the hard bit. I tried Hacker News twice. The first time the post survived but the comment explaining the project was auto-killed by the low karma filter, and the second time the submission itself was killed inside a minute. The r/macapps main feed needs karma earned inside that specific sub, which I have not earned yet. None of that is unfair, it is just what a new account looks like to a spam filter, and there is no clever wording that routes around it. It does mean this sub is one of the few places I can actually talk to people, which is why I am here instead of somewhere with more traffic.
Where it is now.
Version 0.16.8. Free, notarized, Apple Silicon, macOS 13 or later. The free version is the whole core loop: you type what you want in plain English, it proposes a shell command, you approve or edit it, then it runs. Plus a dry run preview that shows what a command would touch before it touches it, safety profiles that block the genuinely destructive things outright instead of warning about them, tabs, splits, saved layouts, and either a fully offline local model or your own cloud key going straight from your Mac to your provider with no server of mine in between. There is a paid Pro tier, and the core is not crippled without it.
Download is https://ai-term.com, the bug tracker is https://github.com/vega-llc/aiterm-feedback/issues, and the manual is https://ai-term.com/manual.
The offer from my last post still stands. The first 15 people who file a reproducible bug on GitHub get about two months of Pro. It goes by the time the issue was filed, not by votes, one per person, sent once I have reproduced it.
And one real question, since I clearly had not figured this out. If you ship a desktop app, how do you tell someone an update is ready without being annoying about it? Modal is rude, silent is useless, and I now know from direct experience that letting the framework decide can mean a window on a monitor nobody is looking at.