Hacker News Reader

Comment by bitwize | Hacker News Reader

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.

View on HN

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.

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

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.

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.

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.

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.

Reply on news.ycombinator.com