That's close to my workflow as well... keeping planned areas in TODO.md, done changes in DONE.md, and a non-committed WORKING.md for the current work being done, as well as coordination with sub-agents, so I can view/monitor... have to direct the latter each time to have it done that way.
I spent part of last week, and the weekend, in Claude (Fable) on a documentation project... maybe a waste to use Fable, but been a little obsessed with trying to get the technical details right. I know, from personal history, more than some of the available info easily found on the subject. I let a lot of it just go, and swing for the fences, but in the end, did hand review all the output at each stem.
In my specific case, implementing modern documentation for Remote Imaging Protocol (and old graphics protocol for terminal/bbs usage), and in particular trying to gather what exists of the later version released. The company itself folded, and there wasn't a lot of broad use of the later versions, and only partial information was ever released as a documentation. Claude was able to interrogate the apps, and some available open source, in progress work, and establish a lot of things.
I've still got to direct some edits... I guided a re-flow of the order the documentation was written in, particularly to be consistent between the versions... but it obsessively added verbose summaries to every page/file. All markdown, meant to build a website from, and eventually some compatibility tests, guidelines and a green/open implementation.
Beyond the early MacOS UI/UX, I would look at pre-smartphone devices as well. Palm pilot, phones, etc. These will give you ideas on what you can accomplish with lower resolution UI screens.
For that matter, look at good TUI applications... (not the render path, but the result as a whole) ... blocking/spacing and clear controls, etc... though you'll be more touch, less tab/enter, etc. A TUI App renders by characters, but you can still learn from the overall layouts. Simplified menu lists with fewer items in a hierarchy, etc.
If you can and have physical buttons, think long and hard about their functions, especially if you have a limited number... these should do your most important things.
Early monochrome devices were largely liquid crystal rather than electrophoretic displays.
The key differences:
- LCD was far lower resolution, often element-based rather than pixel-based displays (though the latter also existed).
- Screen response is far faster, with no ghosting. Electropheretic refreshes tend to take time, particularly at higher-quality or colour settings. Modern LCDs are used in high-performance displays at 60--120 Hz refresh or greater. By comparison, a fast EP/e-ink display might reach a few herz, and many require a substantial fraction, if not more than a second, to fully paint.
- Contrast was low. LCD relies on polarisation filters which greatly reduces foreground/background distinction.
That's not to say that some lessons cannot be learned, but the media do differ.
Yeah, I can't even run AI on work hardware... I have been able to use it for writing small utils/libraries that I then pull into the work... but the divide is clear and I review all the code myself.
For a couple examples, working through an animated loader for html/js/css with an svg for the org. Another was working through a library implementation to work against an interface that was designed for Mongo, but the org is using SQL Server. Latest was a quick util to extract a zip file of pdfs into a 1bit(b/w), zopfli compressed png file per page.
Generally stuff I could do, but would take me a few days for research and experimentation vs an hour or two with AI.
Hard for me to even imagine being in that kind of work environment. I know that I don't always like the output for AI, and even will argue with it at times (often into submission), then ask it to restate.
For code gen and review, it's been pretty good since recent Opus versions, and I really like Fable's outputs (though a bit costly in terms of use). Fable is much closer to my own style for the couple things I've done with it.
I have yet to even consider replying to emails/messages with AI. I sometimes write a wall of text on my own, but it's entirely me.
IIRC, it was a decision based around not porting to 64bit in the newer versions of Windows. I agree it's a shame it didn't move forward... same for a lot of things that were in earlier versions that didn't make the cut.
FWIW, in a lot of cases you aren't expecting even thousands of simultaneous users, so SQLite is a perfectly valid option. Not to mention services like Cloudflare D2 and Turso which build on SQLite as a core with different features for scale/concurrency.
A lot of people manage to run several containerized applications on a single VPS behind a reverse proxy for personal or small groups. Managing a full rdbms takes work supporting multiple applications, or spinning up multiple instances per app in said containerized flows takes up excess resources, where SQLite would do the job just fine.
Not everything is going to be running 5+ nines of operation with distributed workloads. Plenty of real things run on a decent server with a good enough backup system in place.
This is actually very similar to some ideas I've been having for a while... that having a smaller entry model that knows enough about "expert" models that themselves are smaller to hand work over to could be better/faster/lighter in terms of working through real problems vs the megalith ones we currently use. Highly distilled experts and coordination with a fallback mode to a larger model option.
afaik there is some research at this area.
Also the new apple foundation model uses related idea. they process the whole prompt and based on prompt load required experts and use only these experts for generation. It doesn't require fitting full model into memory or per token ssd streaming
The only possible legit argument for blocking Chinese models is to force US orgs to use US based providers/models. And despite the fact that I and a lot of others cannot or should not use Chinese based models, they should be generally available as much as anyone in any other nation has access.
It's a lot like the guards against dealing with security issues.. I'd rather they be found and fixed then to try to stop people from being able to discover in the first place. I mean, where does that stop, do we let AI security scanners not tell you you have a SQL injection for fear someone might exploit it? They already can and they might use something else that tells them as much.
