Comment by nico
5 days ago
> Don't
Do you mean "Don't give it more autonomy", or "Don't use it to access servers/dbs" ?
I definitely want to be cautious, but I don't think I can go back to doing everything manually either
5 days ago
> Don't
Do you mean "Don't give it more autonomy", or "Don't use it to access servers/dbs" ?
I definitely want to be cautious, but I don't think I can go back to doing everything manually either
Why aren't you using the tools we already have: ansible, salt, chef, puppet, bcfg2, cfengine... every one of which was designed to do systems administration at scale.
"Why would you use a new tool when other tools already exist?".
Agents are here. Maybe a fad, maybe a mainstay. Doesn't hurt to play around with them and understand where you can (and can't) use them
Play and production need to be separate domains. Otherwise, you don't have production, you only have play.
1 reply →
You have to choose between laziness or having systems that the LLM can't screw up. You can't have both.
You can have it write code that you review (with whatever level of caution you wish) and then run that on real data/infrastructure.
You get a lot of leverage that way, but it's still better than letting AI use your keys and act with full autonomy on stuff of consequence.
I mean, both, but in this case I'm saying "don't use it to access any kind of production resource", with a side order of "don't rely on simple sandboxing (e.g. command patterns) to prevent things like database deletions".