Yes but no. I don't doubt whether the code will work, it most likely will with a probability of failure compared to a human. The actual issue I have with the entire topic is not the LLM but the way it's handled and applied. There are multiple issues I see, all connected to maintainability.

• There is currently a lot of work going on that seems unfocused to the actual goal of getting the new qr to prod and each of these changes introduces additional risks of bugs
• Most of the code is self-merged with only one person (I hope) ever seeing that code and no additional person knowing any of the details without clicking through the 100 commits that have happened since the qr. Which is getting less reasonable with the current pace of new commits and PRs. Also, there is no actual rush for most of these changes. What matters right now is getting the qr to prod so we can have take a look at regressions and fix them after such a huge change
• There have been surprising changes where I would have expected the entire team to be consulted like introducing a toml formatter that is in my perspective very subpar
• We have very limited human resources in the project. Before me there was only graham (and someone else, sorry I forgot the name) and I don't see how permanent the current amount of people is. I think (don't pin me on this statement) I have been the longest maintainer of the software and I assume that after right now, it will be back to me again (if I decide this works for me) and the others following different projects (which is fair, there is no lifetime requirement) - leaving me with a codebase I have no idea how it works (like back when I started) in a state only a LLM can understand and which I am not willing to spend my own money on the amount of tokens it requires. Unfortunately, there has to be someone maintaing this software and both my past experience and what I think people I have worked with expect of me gets me into the situation where I will be doing the required work

Hello, I am not sure if this is the right place to ask, but I set up a hydra instance on my server and it all works so far but I am a bit confused by the architecture. I used the newer hydra-queue-builder and runner that came from helsinki-systems and when garbage collection ran on the builder, the next time it builds something, it tries to build everything starting from bootsrap stage 1. I enabled substitutions and the hydra-queue-runner says something like this:

hydra-queue-runner[84836]: 2026-05-11T19:17:16.161281Z  INFO queue_monitor_loop:get_queued_builds:process_new_builds:create_build:create_step:create_step: hydra_queue_runner::state: create_step: llw11xba2z4kfiyka62yhfjc75fys75x-bash-5.3p3.drv already finished (outputs in store), skipping build_id=1 build_id=1 drv_path=a97x63dkns7qsza17rbpgkmn6k9f65sf-rp4-image-hydra.drv build_id=1 build_id=1 drv_path=a97x63dkns7qsza17rbpgkmn6k9f65sf-rp4-image-hydra.drv build_id=1 drv_path=llw11xba2z4kfiyka62yhfjc75fys75x-bash-5.3p3.drv

so it already is in the s3 cache (it got build by the builder earlier) and the queue runner knows that. the queue-builder has the cache enabled as a subsituter but doesnt use it, is this intended?

This is the process running right now

hydra-q+   84985  0.0  0.2 595328 34872 ?        Sl   21:17   0:00 nix --extra-experimental-features nix-command build --json --no-pretty --print-build-logs --log-format raw-with-logs --no-link --max-silent-time 7200 --timeout 36000 --option max-build-log-size 67108864 --option fallback true --option substitute false --option builders  /nix/store/bx33y6dvsb44avnjah0hsh25hj0axa0f-users-groups.json.drv^*

So it picked the first drv that is not in the cache and tries to build it but --option substitute false is set