NetBSD themselves have a no AI policy (fair; at some point lawyers are going to make a mint), but I just wanted to have a play about and since I run NetBSD, perhaps for too long, I just assumed I was out of luck with most AI tooling (most things do just target macOS, Windows and Linux). But it turns out things are mostly ok thanks to all the CLI tooling being node/npm:
- Gemini just works* (and requires nothing more than a Google account; Which I have again since switching to Android)
- Codex throws an unsupported platform (I wonder if this could be worked around?)
- Claude runs (but there is no free tier)
- Qwen code works (requires a free account; Looks like a Gemini clone)
(Don’t use global installs)
I started with Gemini - I thought I’d jump in the deep end and ask it to do something useful and something fairly complex so I asked it to build me a Chrome Cast receiver in python - I’d love to be able to cast from my Pixel to my NetBSD laptop. It “worked” in that it built something that looked sensible and did run although didn’t actually work when it came to being a Chrome Cast receiver. So then I thought I’d step back a bit and ask it to migrate simplenote.py (long neglected by me) from Travis to Github Actions; Because this is the kind of thing I’ve been meaning to do for a few years and just haven’t found the time for; I.e. this seems like the kind of “chore” task we should be using AI for instead of all the terrible things we are using AI for.
Comparing Gemini with Qwen
For both I gave a prompt like this (apart from the branch name being different):
Create a branch of this repository called gemini-github-actions and migrate the Travis CI setup to Github Actions
And then also gave both permissions for whatever it asked for for the session.
Both gave me additional instructions. Gemini:
To verify the migration, you should push this branch and ensure the GitHub Actions runner can successfully execute the tests and build the package. If you want to proceed with a commit, please let me know.
Qwen:
Next steps:
- Add PyPI credentials to GitHub repository secrets (PYPI_USERNAME and PYPI_PASSWORD)
- The deploy job triggers on release publication (modern approach vs. Travis’s tag-based deployment)
Personally I find it dumb that neither of them committed automatically (why would I be telling you to create a branch?) so I told both:
Please commit your changes including the summary of the changes you’ve just provided in the commit message.
Qwen had just created the .github/workflows/ci.yml file whereas Gemini also removed the .travis.yml and updated the README badges (nice); However, I LOVE that Qwen co-authored the commit by default.
I told Qwen:
Please also delete the .travis.yml and update the README badges to suit Github Actions
to get it in the same state.
(Interesting aside… I had to update my PAT to allow creation and updates of workflows before I could push)
Here’s the final results (final at the time of publishing is one commit on the gemini branch and two on the qwen one):
There are some subtle differences. Gemini includes many more python versions, Qwen just two, matching exactly what I had for Travis.
Of these two, only the Gemini branch automatically triggered a Github Actions run because it sensibly included its own branch - it failed though on every single job. Don’t actually know why. Github just tells me all the jobs exceeded the maximum execution times whilst waiting for runners.
In an effort to actually publish this post this year I am going to leave the AI efforts there for now - I might continue with both branches and get Gemini and Qwen to make further tweaks or I might continue by hand, but that could take me days, or weeks. Or months. So this will do for now. There’s no conclusions to this post, just observations - literally just me documenting my playing about.
This post has taken me months to write. I’m just too busy. I’ve been wanting to play with AI CLI tooling because up until just the last day or so I’ve not been allowed to use any such tooling at work (believe it or not). At least my tinkering on NetBSD did give me a little bit of a headstart and familiarisation.
* - Worked until this change since that it now gives env: unknown option -- S on NetBSD. Reverting that makes it work again. For me that was these files:
/home/me/node_modules/.bin/gemini/home/me/node_modules/@google/gemini-cli/dist/index.d.ts