I feel so sorry for you and the kind of life you're building for yourself... I really hope this is a joke
I spend about 90% of at-computer time in a herdr-like tool.
It feels like playing factorio: whatever is manual needs to be automated away.
LLM writes the test. The test is crap. Update the skill. Ask an LLM to review your feedback on the last 5 PRs and write a skill for a review bot to look for similar problems and post. Now you only see PRs after they've gone through a few rounds of review.
The LLM has stopped picking up new issues. Ask an LLM to diagnose why. Ask an LLM to write a cron to regularly check if the LLM PR pipeline has halted and ping you. Get an LLM to try to diagnose it first.
I'm using a lot of LLMs! Ask an LLM to diagnose why. Write a tool to audit your usage, and produce a weekly report. Have it raise issue to reduce spending.
And like a base building game there are many competing facets, coming all at once.
In factory building games, the systems in play can be understood and are fully deterministic. You're given a set of tools and a problem, and then craft together a solution. Your reward isn't just seeing the item you want on a conveyor belt, but looking at the factory you built ticking like clockwork.
What you're describing is beating out endless nondeterministic fires. It's like you were forced to play Factorio exclusively through an algorithm that designs incomprehensible factories that don't work sometimes, but designs them much faster than you ever could. So you click the magic button and see a mass of buildings appear in front of you. They may work perfectly fine, but if they don't, you need to use the same statistical factory estimator to build an in-game factory fixer mechanism and factory tester mechanism. And then a few updates later the factory fixer breaks so you need to deploy a factory fixer fixer, and a belt clean-up machine, and so on ad infinitum. To me this doesn't seem satisfying in the slightest.
I think we (software engineers) are suffering from partial blindness to this aspect of engineering given that software has always been so extremely deterministic. We've trained ourselves that solving a problem means composing small fully deterministic parts into deterministic systems, and the prospect of having to work more with statistical confidence and managing failure modes feels scary and wrong.
But beside that, I don't think that LLM non-determinism is really the same thing as what you see in engineering. Engineering has things like tolerances and redundancy, and while they accommodate random events, they're known, estimated and expected. They also deal with external factors, not the potential of shoddy engineering in the same system they're working on. The best way I can compare it is building a bridge that can withstand twice the normal expected full load and with enough structural redundancy to not collapse even after a prolonged lack of maintenance. These things account for many types of natural degradation and edge cases that are expected. And then there's building a bridge that you know will collapse in the next 10 years at a completely random moment, and instead of engineering a more robust solution, tacking on more gadgets to make the collapse less bad - automatic gates that close the entrances to the bridge, lake drainage system that will suck out the debris, a drone system that drops a brand new randomized bridge on the same spot, and so on. It doesn't feel very much like engineering.
If that doesn't sound convincing to you, consider one other thing. If you gave an engineer a non-deterministic solution and a deterministic solution to the exact same problem, which do you think they would prefer? Would they willingly remove determinism from a system? Maybe it's not the chaos of the real world that scares software developers so much - lots of them have to work on systems that directly interact with the real world. What if it's the fact that there is now a fight to take away their nice, understandable, satisfying deterministic solutions and inject probabilistic chaos into things that never had to have it in the first place - into absolutely everything?
I didn't mention determinism or predictability.
I said "It feels like playing factorio: whatever is manual needs to be automated away.".
I'm sure you can find many differences between Factorio and what I'm doing.
> If you gave an engineer a non-deterministic solution and a deterministic solution to the exact same problem, which do you think they would prefer? Would they willingly remove determinism from a system?
We choose non-determinism in our systems a lot, because we get better outcomes in other aspects.
* Non-deterministic network latency: Packet switching rather than circuit switching.
* Multi-tasking operating contending for the same resources.
* Multi process programs whose interleaving/execution is non-deterministic.
* Profile guided optimisation, depends on the profile.
* The entire field of randomised algorithms.
I prefer deterministic processes, but if the benefits of non-deterministic processes are significant enough, I pick non-deterministic.