To use an analogy, to add to everybody else: it's like rings on a tree stump. The innermost part of the stump is the oldest; the outer the youngest. Earth is on one of those in-between rings, neither the oldest nor the newest - doesn't matter which of the in-betweens, to be honest.
Suppose now that you're an ant on the middle ring of that tree stump. No matter which way you're looking from Earth's middle-ring, either the rings will get gradually older and then younger with increasing distance (if you're looking towards the center-ish), or the rings will get strictly younger (if you're looking away from the center-ish).
This analogy obviously breaks down if you delve into details but that should give a better intuition to what's going on.
> Would love feedback from people working on long-running agents, training loops, eval harnesses, or similar workflows.
I have not required a service for this kind of optimization at work. Though work gives me unbounded access to Claude 4.x-1m (substitute x with whatever is available). So I often ask it to do this kind of task.
I found that when I just specify, sometimes the AI will optimize to the point that it breaks other existing functional requirements in the same codebase. So I have to steer it with invariants. This is where the bulk of my effort is - monitoring to make sure that the agent didn't suddenly scramble the infra or delete valid usecases.
1. How do you address that [paperclip problem](https://en.wikipedia.org/wiki/Instrumental_convergence) in Remoroo? Can we define invariants?
2. Why is there a whole orchestration system? Was there some limitation that prompted this architecture, e.g. did workers die frequently? Looks like Temporal/AWS SWF with the brain/worker/control architecture. The existence of `q (quit): Kills the Worker, aborts the run. The run is marked FAILED.` makes me think there's only one worker...so why...? It'd make more sense if the brain wanted to dispatch multiple hypotheses to multiple workers to test in parallel (e.g. if optimizing SQL, try these different joins all at once, discard queries running for X minutes after the first complete one).
When I saw the title, I actually didn't have much emotion beyond curiosity. But then after checking thus comment, it piqued my interest, made me step back and really consider the ramifications of how we got here. And then yes I became depressed also.
Anyway, I got value out of it, comments dont have to increase net factual information to be meaningful, because we are all capable of reflection.
- Could you explain what you mean by "security through obscurity"? The mechanism is well explained in the blog.yossarian.net posts linked within. It is simply adding a time filter on a client.
- Also, I'm not sure if package registries (e.g. server) and package managers (e.g. client) are being conflated here regarding "attacks on package managers", this seems to be more of a mitigation a client could do when the upstream content in a registry is compromised.
- Lastly, I agree with the sentiment that this is not a full solution. But I think it can be useful nevertheless, a la Swiss Cheese Safety Model. [1]
This conversation thread reminds me of the very interesting and insightful talk here: Klaus Iglberger “Free Your Functions!” [video] https://www.youtube.com/watch?v=WLDT1lDOsb4.
reply