The Workstation

People ask about this more than almost anything else I write about. Fair enough. It is a reasonable question. If you are running six Rust builds in parallel most days of the week, the hardware underneath that has to actually hold up.

This is not a glamorous post. It is a parts list and the reasoning behind each part.

The Machine

A Mac Mini M4. Onboard storage is 500GB, which sounds generous until you remember what Rust build artifacts actually look like at scale. Target directories grow fast, and six codebases building simultaneously will eat through that in no time.

So the build files do not live there.

External Storage, Two Roles

**Build storage.** An OWC enclosure running a 2TB NVMe SSD over Thunderbolt 5, rated up to 80Gbps. That is where every Rust build actually lives. Six separate codebases, building in parallel, none of them touching the internal drive. The enclosure speed matters here more than people expect. Rust's incremental compilation is already disk-intensive, and running six builds concurrently means the bottleneck moves fast from CPU to I/O if your storage cannot keep up. Thunderbolt 5 keeps it out of the way.

**Long term storage.** A separate OWC enclosure holding two 4TB Western Digital drives in RAID 1. This is backup, archive, and Time Machine, kept completely separate from anything actively building. RAID 1 because the entire point of long term storage is that it cannot be the thing that fails silently.

The split matters. Active build storage and long term backup are different jobs with different failure modes, and conflating them on one drive is how people lose work.

Display and Input

A 34 inch curved widescreen Dell monitor, a holdover from years spent editing video daily at the film studio. It turns out the same wide canvas that worked for timeline editing works equally well for having multiple terminal panes, a browser, and documentation open simultaneously without constantly alt-tabbing.

Keyboard and mouse are both small, wireless, Mac-native. Nothing mechanical, nothing with RGB. The hardware that matters here is the storage and the screen. Everything else is just there to not get in the way.

The Agentic Stack

This is the part people actually want to know about.

I use Codex for the day-to-day agentic engineering work. Deliberately boring, deliberately simple. It does the job without ceremony, and at the volume I am working, predictability matters more than cleverness.

Planning, cross-referencing, bug fixing, and doctrine creation for each repository runs through a combination of Claude Sonnet and ChatGPT. The division is not arbitrary. Different models have different strengths in different conversational modes, and running the same problem past more than one tends to surface gaps that a single model, however capable, will not catch on its own.

Doctrine creation is the part most people skip and it is the part I would defend most strongly. Every repository gets a written record of why it is built the way it is, not just what it does. That document is what makes it possible to step away from a codebase for months and come back without having to reverse-engineer your own past decisions. Given how many parallel builds are usually running at once, that documentation is not optional. It is the only thing standing between organised parallel work and total chaos.

Why It Looks Like This

None of this is exotic. It is a consumer Mac Mini, two external enclosures, a monitor that has outlived its original job, and a deliberately unglamorous software stack on top.

The actual engineering is in how it is used, not what it is. Six parallel builds need fast external storage or they will choke each other on disk I/O. Long term backup needs to be physically and logically separate from anything active. And the agentic tooling needs to produce a paper trail, because the volume of parallel work makes memory an unreliable record keeper.

That is the whole setup. Boring, as promised. But it holds.