The number one power move I have is Nix integration. The availability of tooling, secrets, environment and the ability for the agent to modify its own environment is... well, I don't know how people live without it. I guess you guys still install things using commands and hope everything you need is present on the next machine? Developer machine, CI environment, deployment environment: They're all derived from a single source, and compiling and running always works on every machine.
In Claude I use /branch and /rename a lot (context checkpoints, fork, go back)
I use sandboxing almost exclusively: https://github.com/nix-tools/bubblebox -- it's a generalisation of Numtide's claudebox with a few fixes and some feature additions (more coming). This is best compared to always running your Claude in Docker containers, except there's no Docker runtime. Works fine in WSL and nix-darwin, too.
+100. I also dig fnox (encrypted-secrets-in-git) and hk (pre-hooks manager that is actually fast and stays out of the way) by the same author, pretty much default for any project I start nowadays.
Flake parts modules means that it’s an abstraction on top of an abstraction, flakes, on top of Nix. Then to need to throw unflake or trix at the problem is more layers & woven dependencies—same for ‘Dendridic’ patterns. If you invert that paradigm, & just import or callPackage Nix files from the flakes, then accessing say a package.nix or module.nix or overlay.nix is trivial for anyone not taking part in your specific design pattern—be it flakes, nilla, whatever. I feel this is another of these situations where engineers want to engineer their way out of messes by adding more code. Rather than a “how do I do X-PROBLEM in flakes?” if the question is “how to do X-PROBLEM is bog standard Nix?” you end up at design that tends to be a lot simpler since the the simpler bits are now decoupled from the framework (which flakes behaves more like); instead, flakes now own its complexity only in its file instead of its patterns ‘infecting’ simple parts (case in point, 2 weeks ago I helped a project get the overlays be compositionally sound by removing a coupling of inputs as a first argument & a self threaded into the package via callPackage). This is why ‘package normal form’ exists for packages in Nixpkgs so any setup can callPackage it… or how overlays already offer more powerful/flexible composition than input.follows which adds to flakes composition problems. With exceptions, Nix itself was already good enough for most cases… it just needed some design guidelines everyone could start reasonably follow (which the experiment post points out is “the good part” (good post btw… hadn’t seen)), except the state of flakes being as the are means they are stuck in limbo as too many projects now rely on it; which I guess that limbo itself means they are stable since all changes insight in-fighting—& all of these forks now have incompatible changes making it non-standard. I say best to just skip flakes since most projects don’t need anything more than pinned input starting point to produce: a package, an overlay, & a module (if relevant).
(for context, you're replying to the author of an alternative nix input pinning mechanism, which means... they're probably aware of all that and yet they chose their wording like this anyway)
I do the same. Codex manages a per project flake.nix and uses `nix develop` for all testing. nix-direnv for my own convenience. I generally have it generate dockerfiles or other deployment assets at some point.
I also prefer giving it a VPS over a Docker container.
On my own machine I just give it a Linux User Namespace, i.e. soft virtualisation via "bubblewrap."
What Docker Compose and Linux User Namespaces provide that a VPS doesn't: You can easily mount extra directories from your developer host machine in read or read+write mode. With the VPS you (most likely) need it to clone all of your resources separately, which requires SSH keys, and now you're slowly building towards an independent agentic environment, which is definitely very nice, but time-consuming, compared to piggybacking on your developer environment. Definitely the direction I'm going.
nix develop ensures your dev env is the same as your build/test/prod env. At least with Python everything is a flurry of requirements.txt, Python versions, poetry, pyproject.toml, perhaps automated with direnvs, a hefty Dockerfile/docker-compose, and perhaps conda (ugh) along the way; lots of moving parts.
I have a project that's mostly Rust sprinkled with C++ libs and Python helpers and it's easier to manage than the average virtualenv. Everything builds with nix build, everything runs with nix run, profiler/debugger works, IDE detects everything on any of my computers, builds and links with CUDA on x86, aarch64, NixOS, MacOS, Ubuntu or Amazon Linux. nix build can even build a Docker image for the odd need of Docker, and I haven't tried but I'm convinced that if I import the flake on my nix-config it will be built into the SD card for my Raspberry Pi just fine.
It's even replaced Ansible for me, colmena all the way.
Pythonistas have mostly moved to uv, which solves much of the "flurry" you describe. Tools like Mise add more of the benefits ascribed to nix. And smolmachines' smolvms can provide better isolation than Docker. Just saying, TIMTOWTDI. Not hating on nix, just pointing out it's not the only game in town.
Nix is like Borg of Star Trek: It assimilates everything.
I'm not a Python developer, but I follow the news, and I agree that uv is the future of Python package management.
So if you're a Nix user and you want Nix to be opt-in, and you love uv, you use uv2nix, declare the uv lock file the source of truth and build your Nix derivations on that. When the hashpins live in the uv lock file, uv works just fine, but uv2nix produces derivations that are cached and can be embedded in CI or deployment strategies.
So... running CI on your uv-based project means your Nix tooling can cache both tooling and dependencies.
And... deploying your uv-based project you can build an OCI image with the same source of truth as the dev/CI environments.
This matters more for toolchains that YOLO more wrt. dependency pinning: Does that CLI call in your Dockerfile really pull the same thing down just because it's still v6.6.6? Some package managers provide a lot of sane choices, and I'd bet uv is one of them. But your Dockerfile is always a second-grade citizen unless you re-use the same base as a devcontainer.
In Claude I use /branch and /rename a lot (context checkpoints, fork, go back)
I use sandboxing almost exclusively: https://github.com/nix-tools/bubblebox -- it's a generalisation of Numtide's claudebox with a few fixes and some feature additions (more coming). This is best compared to always running your Claude in Docker containers, except there's no Docker runtime. Works fine in WSL and nix-darwin, too.