But seriously this is such a big problem you should install my fdu skill for it.

More

Feel free to DM me if you’re interested in attending.

fdu is self-installing as a skill so just tell your agent: > Run `uvx fdu@latest` and follow the help instructions to install it as a skill I'll use this chance to share more technical notes, since I found building fdu was a great exercise in several agentic engineering techniques. [100% human text here so pardon the roughness:] 1. This began with a complete research pass, first analyzing every previous implementation of a tool like this. Before settling on the current design. These are checked in so every agent has access to all reasearch. 2. I used github.com/jlevy/tbd to streamline these research reports, spec-based planning, and high-quality Rust CLI design. A lot of work here was around customizing which system calls to use for file watching and the best API design for streaming that wouldn't adversely affect performance or memory use. 3. The actual implementation process was tracked with beads in tbd. By mapping the design to beads, it could run more reliably for 12-24 hours at a pass to do clean spec-driven implementation. Also tbd has baked into it lots of agent guidelines for things like setting up the repo and CI, release engineering, Rust best practices, etc. 4. Another key design element is distributing prebuilt Rust wheels through PyPI. I find cargo installs clumsy as it assumes a full Rust toolchain and source build. Many agents and developers developers already have uv available but don't want the size and complexity of a Rust build. By using PyO3+maturin for build and packaging, we make the native CLI installable via `uv tool install fdu` or `uvx fdu@latest` with no local compilation. In short, it's a little counter-intuitive, but I recommend using this approach of uv+PyPI to distribute Rust CLIs you want agents and humans to try easily. 5. Getting high performance is another big process, and probably the most interesting technical challenge. I set up an auto research loop powered by github.com/jlevy/softchema that systematically enumerate different hypotheses about better performance so there's a creative listing of all the different processes. Softschema is a convention for structuring the records as Markdown+YAML. Then there's an auto research loop that iterates through every hypothesis, implements the performance change, benchmarks, and then decides whether to keep or abandon that particular improvement. I ran this for a few days of agent time on both Mac and Linux, which produced a bunch of charts showing performance improvements (these are in the repo too). This was dozens of improvements with a total gain of 2-3X. 6. Another really important trick when building complex apps is to use golden testing. I have tbd guidelines on this (install tbd and ask about it!) but the core idea here is to use Tryscript, a simple session-based testing framework that makes testing serialization fast and easy, by using Markdown docs that document their actual behavior as the test framework. This is a big improvement over most agent-written, verbose unit and integration tests: github.com/jlevy/tryscript 7. There's also subtlety on how to use native APIs for Mac and Linux. The fast Mac-only dumac uses macOS-specific system calls to better batch file stats. That's a key reason it is so much faster than built-in du. We use the same approach as dumac but are cross platform and offer more features. Another nuance is the fact that for tallying only, caching results does not save you any time because the cost is mainly the stat (and on most filesystems, you have to stat every file to see which are modified). But if you're reading the files to count lines of code, disk caching (so you don't recompute unless a file is modified) is a massive speedup. This means you can rerun it on a giant codebase and get document and LOC tallies right away. 8. The fdu repo also has a little tool to generate a clean terminal video of using the CLI with real time outputs and realistic input typing (based on modeling human typing patterns). I could pull this out as a new tool if there is interest. 9. If you are as much of a terminal and design nerd as I am, you might enjoy checking out Planetaire, a new monospace font I use here. It is a modernized version of the legendary B612 and in my humble opinion now the most beautifully yet extremely legible font you can use in a terminal: github.com/jlevy/planetaire