> ticket in JIRA -> solution in production

We started building that but it quickly turned out to be too narrow. Often we want agents to do task that have no input ticket and often the output is not a code change (Slack bot, incident investigatior, scheduled daily tasks, ...)

▲

vidarh an hour ago | parent | next [-]

I've worked on that as well, and agree with you. You do need the "build this thing" flow, but that just shifts the bottleneck. You also need a whole infrastructure around it, where the jira-to-production pipeline isn't the interesting part.

▲

imtringued an hour ago | parent | prev [-]

Correct and that is why bash coding agents like pi.dev got things completely backwards with their anti-minimalist bloated core tools.

No, giving the agent access to every single command on the system is not minimalist. It is actively detrimental if you want to do more than just attended coding with the agent.

	▲	vidarh 43 minutes ago \| parent \| next [-]
		I don't mind that as long as that system gets regularly wiped. If you don't wipe it, you can't reasonably measure the actual output and it's pets Vs cattle all over again, only with agents.
	▲	oblio 40 minutes ago \| parent \| prev [-]
		I love how I don't even know how many years after they were created mainstream languages haven't yet figured out that the only sandboxing that works is default deny, like Tcl or Lua. Especially with autonomous agents, it's the only way to sanity. We might need new OS abstractions.