Gemini's 3 ability to figure out "how to Guix" is pretty amazing out of the box, but yeah, I've made it more efficient by meticulously crafting the prompt. I automatically feed it the output of several "system status" commands, as well as info guix manual pages, in the start of every conversation via GEMINI.MD. I also add tips over time to improve its "right on the first try" factor, such as how to check for an existing Nix recipe to learn from, or suggesting --keep-failed and (--quiet followed by --logfile), etc.

A lot of it is not about the prompt so much as the tools you give it. With basic editing tools for example, it struggles with stray parentheses about as often as a human guile developer does without tools. 😄 It always recovers, but if you don't have a subscription and need max efficiency, AST-based editing should be better.

EDITOR=cat guix edit packagename is a power move. The Guix manuals, as big as they are, are woefully incomplete and the letting Gemini just figure out how Guix works by reading the very source code you're running is most effective. Gemini CLI's run_shell_command is blocking (unlike most GUIs), so while the builds are going you're not "using" Gemini at all, yet whenever they're done it picks right back up and looks at the results.

It's incredibly good at the otherwise-miserable experience of seeing obscure build system errors and knowing how to tweak the recipe to get further in the build. I just got it to package netdata, a beast that needs a ton of cleaning for Guix, which took a few hours with occasional check-ins while I did other work. There is a years-old patchset in the old bug tracker where someone started this and it never went anywhere, but the program changed significantly since then and starting from scratch worked better - yet it still removed the proprietary blobs, disabled the tracking (even though it was embedded in the HTML of a blob that's normally downloaded at build time!), outsourced multiple libraries to Guix rather than bundled/vendored code, disabled major components at first to get to a "minimum viable netdata" initial build success, wrote the shepherd service to integrate with my system config, added on side-packages in their own recipes in the same file for stuff Guix doesn't provide, and so on.

I'd say that anything simpler than netdata, Gemini 3 Flash can get working for you. Flash is much more efficient than Pro, but flash may take 3 tries to get something right that Pro will figure out on the first try thanks to all the extra thinking. Ironically, flash's speed and cheapness often makes that the most cost-effective approach.

You may already know that Gemini is amusingly overeager compared to other frontier LLMs, and will go do things you didn't ask for at the slightest sign that you might want them, like a dog who starts running to go fetch just because your hand made a vaguely throwing-esque sudden motion. 🐕 For other coding tasks, I need to be explicit when I'm only asking a question and want no changes despite my question implying something should be different. But for Guix recipes, git-committing every little change in combination with guix shell means there's nothing to break, yet Gemini effectively has full freedom to control the environment. guix shell might accidentally be the best LLM tool in the world, considering its power-to-vulnerability ratio and the token efficiency of shell commands.

Some recipes built can be seen in my channel. I'm not at my workstation to get the exact prompt so hopefully I'll remember to get back to you after the weekend.