4 ms·

The goal is "ticket in JIRA -> solution in production" without human intervention. Right now agentic frameworks are multiplying to bring us closer to that solut

The goal is "ticket in JIRA -> solution in production" without human intervention. Right now agentic frameworks are multiplying to bring us closer to that solution like JavaScript frameworks did ~10y ago. We still haven't uncovered the "React" of this space yet, the one that business decides is good enough to standardize on.

ngruhn 5d ago
> 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, ...)
- imtringued 5d ago
  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 5d ago
    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 5d ago
    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.
- vidarh 5d ago
  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.
internet101010 5d ago
What do you mean by the "React" of this space? The overall base layer has more or less converged on Kubernetes + MicroVM, which makes total sense. But if you mean how to interact with it as well as how permissions should work, yeah I agree.

ngruhn 5d ago

> 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, ...)

imtringued 5d ago
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 5d ago
  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 5d ago
  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.
vidarh 5d ago
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.

internet101010 5d ago

What do you mean by the "React" of this space? The overall base layer has more or less converged on Kubernetes + MicroVM, which makes total sense. But if you mean how to interact with it as well as how permissions should work, yeah I agree.