This isn’t an affiliate page, and I’m not claiming that this is the correct stack for everybody. It is simply the stuff I tend to reach for when I start a project.
Systems and infrastructure
Debian and Linux are my defaults. I like boring service management, explicit configuration and native mechanisms such as systemd units and timers when they fit the job.
I use Ansible and containers for the repeatable parts of deployments. PostgreSQL, Redis and Prometheus turn up frequently because I usually need durable state, events and some way to see what the system is doing.
For networking, that means BGP, DNS, DNSSEC, VPN and overlay systems, plus packet captures, route inspection and the usual small tools needed to answer “what is this machine actually doing?”
Code
Python is still the fastest route from an experiment to useful automation, and most of SkyeEngine’s model and data work uses it.
I increasingly use Rust for long-running network services and components where strong types and predictable deployment are worth the extra work. C++ remains part of the toolbox, especially around systems and hardware projects.
I don’t have a particularly interesting editor opinion. Tests close to the behaviour and documentation beside the code matter much more to me.
AI workbench
The workstation is where I write orchestration, inspect data and run cheap smoke tests; it is not where most of the model compute happens. Its RTX 5080 gets quick GGUF checks and smaller experiments, and probably sees less sustained use than any of the datacenter GPUs. At 120B scale, inference normally starts with an H200-class accelerator. Full-weight training uses four H200s at minimum, with B200s used when available. The sustained judging passes—including the 120B, Gemma 4 and safeguard runs—use rented datacenter capacity too. A NAS holds the datasets, private model weights and old artifacts which are still worth keeping.
SkyeEngine ties together the inference backends, corpus generation, evaluation, repair and training preparation. Ollama and native Transformers loading are useful for the model checks which fit on the workstation; the same workflow can move the serious inference and training jobs onto H200 or B200 systems without pretending the desktop is the centre of it.
The part I’ve become increasingly fussy about is provenance. If I can’t explain which input, prompt, code version and transformation produced a file, I don’t consider it finished.
Workshop
The physical side involves CAD, 3D printing, PCB design, soldering, measurement and printing the same part again after moving one hole by two millimetres.
OctoPrint has been part of my printer setup for years. Arduino-class controllers are still useful for quick instrumentation and machine interfaces. Calipers, a multimeter and a logic analyzer routinely settle arguments faster than another hour of staring at code.
The Builds page has the less tidy version of this list: the actual machines, boards and half-finished projects.
The General Rule
I prefer tools which show me what they are doing, keep useful intermediate files and can be replaced without rebuilding the whole project around them. That probably explains the list above better than the brand names do.