I've had similar thoughts lately while using agents for coding. It seems like if I give the agents external tools and sources of truth they perform really well. In my case it was a lot of standards, extensive use of Rust language features (e.g. traits), formal methods tools, large-scale architecture and specification documents (accessed via a special tool I also wrote), and using the beads_rust tool for tracking session state and giving the agent a list of issues to work. I hadn't thought of this as 'backpressure' but I really like that framing. It gives the agents guardrails and context and external validity that it can't make up.
This is pretty much my approach. I started with some spec files for a project I'm working on right now, based on some academic papers I've written. I ended up going back and forth with Claude, building plans, pushing info back into the specs, expanding that out and I ended up with multiple spec/architecture/module documents. I got to the point where I ended up building my own system (using claude) to capture and generate artifacts, in more of a systems engineering style (e.g. following IEEE standards for conops, requirement documents, software definitions, test plans...). I don't use that for session-level planning; Claude's tools work fine for that. (I like superpowers, so far. It hasn't seemed too much)
I have found it to work very well with Claude by giving it context and guardrails. Basically I just tell it "follow the guidance docs" and it does. Couple that with intense testing and self-feedback mechanisms and you can easily keep Claude on track.
I have had the same experience with Codex and Claude as you in terms of token usage. But I haven't been happy with my Codex usage; Claude just feels like it's doing more of what I want in the way I want.
People interested in similar experiences should check out this podcast/series of videos where two Windows/Mac users try desktop Linux and report out on their experiences.
I also use gonic over navidrome (and formerly airsonic) because Navidrome doesn't support folder view (and apparently never will). As nice as Navidrome is, that's a dealbreaker for me. Gonic works great though.
That's wild, I was in LA recently for work and drove by that area and wondered what was up with the street grid. I figured it must be something like this given the airport.
I just want to pour one out for CalSky, that was a great page for setting up custom trackers for lots of astronomical things. It was very old school web too (for better or worse).
Yes; APL is a University Affiliated Research Center (UARC) and while we sometimes do work with industry, our whole purpose is to support the US Government. That doesn't necessarily mean you need a clearance, but much of our work is national security related.
Echoing others, thank you for writing this (as someone doing an applied math masters and digging into ML - I have used ESL for a class but not the others you mention)
Of course it can, 486s were common in Linux's early heyday. During my senior year of high school and freshman year of college ('97-'99) I ran Debian Slink on an IBM 486SX. X ran a little slow on it so I used it in console only mode. I mostly used it to do compsci homework. Before I settled on Debian full-time (still using it to this day) I used Red Hat, I think v5 (the original numbering, before RHEL). And before that probably Slackware on floppies. I eventually got an AMD K6-2 which ran a lot faster...
Of course, this article is about running modern Linux, but Debian Slink is still there to download and install and I'm sure it works just peachy.
The section on configuring the kernel really gives me nostalgia as I used to build my own kernels back then, something I haven't done in years.
