I got pi to write me a very basic sandbox based on an example from the pi github. Added hooks for read/write/edit/bash, some prompts to temp/perm override. Have a look, copy-paste what you like.
The people pushing oh-my-pi seem to have missed the point of pi... Downloading 200k+ lines of additional code seems completely against the philosophy of building up your harness, letting your agent self-improve, relying on code that you control.
If you want bags of features, rather clone oh-my-pi somewhere, and get your agent to bring in bits of it a time, checking, reviewing, customising as you go.
Probably, Roy was born agentic as a part of a package which included an disregard for intellectual growth.
This doesn't mean that being agentic cannot be cultivated by regular people.
In 2026, yes, agency matters more than skill/wisdom/intelligence to get VC funds.
But what's the point of agency alone if you are leading such a life?
What gives me hope is that in 2026, skillful people can delegate a lot of their work to LLMs, which gives them time to learn the "agentic" part which is basically marketing and talking with people.
This is super interesting framing. I’m definitely a completer, not that I like much about Slack. Probably useful to have this kind of discussion before/while making knowledge management decisions in startups.
A surprising number of solutions can be realized in ways that don't actually need much of a control plane if you introduce a few design constraints.
But if you do need one, I guess Kubernetes is perhaps the safe bet. Not so much because I think it is better/worse than anything else, but because you can easily find people who know it and it has a big ecosystem around it. I'd probably recommend Kubernetes if I were forced to make a general recommendation.
That being said, this has been something that I've been playing with a bit over the years. I've been exploring both ends of the spectrum. What I realized is that we tend to waste a lot of time on this with very little to show for it in terms of improved service reliability.
On one extreme we built a system that has most of the control plane as a layer in the server application. Then external to that we monitored performance and essentially had one lever: add or remove capacity. The coordination layer in the service figured out what to do with additional resources. Or how to deal with resources disappearing. There was only one binary and the service would configure itself to take on one of several roles as needed. All the way down to all of the roles if you are the last process running. (Almost nobody cares about the ability to scale all the way down, but it is nice when you can demo your entire system on a portable rack of RPis - and then just turn them off one by one without the service going down)
On the other extreme is having a critical look at what you really need and realize that if the worst case means a couple of hours of downtime a couple of times per year, you can make do with very little. Just systemd deb packages and SSH access is sufficient for an awful lot of more forgiving cases.
I also dabbled a bit in running systems by having a smallish piece of Go code remote-manage a bunch of servers running Docker. People tend to laugh about this, but it was easy to set up, it is easy to understand and it took care of everything that the service needed. The kubernetes setup that replaced it has had 4-5 times the amount of downtime. But to be fair, the person who took over the project went a bit overboard and probably wasn't the best qualified to manage kubernetes to begin with.
It seems silly to not take advantage of Docker having an API that works perfectly well. (I'd research Podman if I were to do this again).
I don't understand why more people don't try the simple stuff first when the demands they have to meet easily allow for it.
I did something similar once for a mining technique called “core logging”. It’s a single photo about 1000 pixels wide and several million “deep”: what the earth looks like for a few km down.
Existing solutions are all complicated and clunky, I put something together with S3 and bastardised CoGeoTIFF, instant view of any part of the image.
I'm curious about the "core logging" photo. Where can I find one? Do you have an implementation of your solution? I would be curious to have a look at it.
I don't know enough about the science side to take it any further on my own.
The "tech" part of what I started building is really quite simple: convert the images to Cloud-optimised GeoTIFF, then do range requests to S3 from the browser.
Might not be possible to find any, they’re expensive and niche. If you reach out (email in profile) I can show/share how it works (nothing currently public).
I would have given the OOP the effort and due respect is formulating my response if it was phrased in the way you're describing. It's only fair that comments that strongly violate the norms of substantive discourse don't get a well-crafted response back.
I’m just a casual observer of this thread, but I think you’d find it worthwhile to read up a bit on zero-copy stuff.
It’s ~impossible in Python (because you don’t control memory) and hard in C/similar (because of use-after-free).
Rust’s borrow checker makes it easier, but it’s still tricky (for non-trivial applications). You have to do all your transformations and data movements while only referencing the original data.
If you do both (use flipped parentheses around the operators), it makes even more sense, and makes the parsing trivial to boot: just surround the entire expression with parentheses and parse normally. For instance:
1 + 2 )( 3
Becomes
(1 + 2 )( 3)
Which is actually just what the author wants. You might even want multiple, or an arbitrary numbers of external parentheses. Say we want to give the divide the least precedence, the multiply the middle, and the add the most. We could do that like:
1 + 2 )/( 3 ))(( 4
Surround it with two sets of parens and you have:
((1 + 2 )/( 3 ))(( 4))
I haven't just proved to myself this always does what you expect, though...
Wait, no. It makes no sense to use the same characters! An "inverted" opening parens is visually identical to a "normal" closing parens. IMHO the entire proposition is inane.
https://github.com/carderne/pi-sandbox
reply