100% agree that the more deterministic code the better up to the limit where you need the LLM's ability to be non-deterministic to kick in.
There is this ACM blog post called "Manual Work is a Bug" [0] that was originally written to help humans automate processes using code. I find it just as applicable today as when it was written. You and the LLM look at what has to be done and then figure out the scripts/tools to make it happen. You then tie those tools into a system.
The more I use the above the more it makes sense and the worse the whole "just commit the prompt" seems like nonsense.
I was unsuccessful in area of automation because of different issue.
By trade I am a .Net software developer so as a lot of people would imagine — I was not able to accept a script that wouldn’t be reusable and flexible, basically over engineered.
I do quite some devops so I finally had to accept the fact that I can write simple script with hardcoded values that will live on a server (where I can copy paste and change values to meet other server) and most likely I will not have to look at that script for years as it will be running with cron doing its job without an issue.
Over engineered scripts designed from get go always required debugging from time to time so lots of time I was just doing stuff manually to make it quicker.
So I started winning when I accepted first script can be really simple and when needed I can move it to be parametrized but if not it will just keep doing it's job there on the server.
There is an idea I have been enjoying called WET, Write Everything Twice. Basic idea is you should only make things more general and parameterized if you need to write it a third time.
The upshot of this is you actually have a much better understanding of the different way your script needs to work if you're adapting it for a third use instance.
i believe committing the prompt comes about from people who have near unlimited access to the models coupled with the models routinely getting better and an assumption that tasks using AI could always be done better
i dont think that really holds for a large amount, if not nearly all, of the use-cases for AI where it is either failing and shouldnt be in the loop at all or it is capable of developing some code to fix the problem permanently and its okay if that code is not perfect as long as it works.
refactoring with AI can always be a future use-case when the AI improves
This is an interesting share, thanks. Yes, that is my mental model. Use coding agents to generate more "programs" (scripts) to automate everything. Have edge case handlers - and these handlers can develop/update the original scripts.
You could even have a decision tree in code where the leaf nodes are primarily "run this script with these params" but some of the leaves are "ask the LLM"