> There are actions AI tools shouldn't perform autonomously (I certainly wouldn't let one run a Terraform apply), but there are plenty of actions where it doesn't make sense to stop them.

I'm curious as to where you would draw the line. Assuming you've adhered to DevOps best practices, most--if not all--changes would require some sort of code commit and promotion through successive environments to reach production. This isn't just application code, of course; it's also your infrastructure. In such a situation, what would you permit an agent to autonomously perform in the course of incident resolution?

▲

tptacek 21 hours ago | parent [-]

During incident resolution, most of the actions an operator takes are diagnostic commands, not changes.

▲

otterley 20 hours ago | parent [-]

The number one cause of incidents is change, and the number one response to them is to initiate a rollback. Maybe you’re right about investigation, which requires no changes, but resolution requires action, which does.

In any event, you said:

> What Weakly seems to be doing is laying out a bright line between advising engineers and actually performing actions --- any kind of action, other than suggestions (and only those suggestions the human driver would want, and wouldn't prefer to learn and upskill on their own). That's not the right line.

So what’s your quibble exactly? Those suggestions would come from autonomous analyses, would they not? What is the right line, in your view?

	▲	tptacek 19 hours ago \| parent [-]
		I would not in 2025 during an incident response have an agent do speculative changes, or really any changes at all. I would have an agent perform diagnostic steps: dumping devicemapper tables, iproute2 configurations, nftables rules, BGP advertisements, Consul data, and, especially, logs and oTel telemetry. Weakly's article is in large part about not allowing agents to do the things in the second category there.