The overeager pull request

I’ve started exploring OpenShell as an interesting way to sandbox workloads, agentic and not, and impose network-level constraints. Once I got my feet wet a bit, I decided to see if I could get Fabro running on it as a good example of a harness that I understand reasonably well, and one that’s particularly structured to receive new sandbox backends. Claude and I discussed it a bit and decided to divide the work into two phases: first, run Fabro in a single OpenShell sandbox to get the basic config and network policy sorted; then do the work to add OpenShell as a Fabro Sandbox Provider.

Anthropic was able to bring Fable back last week, so this felt like a meaty enough chunk of work to see how working with it felt. We dove in, and in a largely unsupervised afternoon, Phase 1 was complete and I had Fabro up and running, making sandboxes for its workflows inside an OpenShell sandbox.

While it was doing the work, Fable noted some timing issues that might suggest that a configuration issue was causing unneeded relay latency, so while I was high on the unsupervised success of the first run I YOLO’d a “Claude, benchmark that so we can dig into it a bit.” Yeah, that wasn’t as successful and I shouldn’t have expected it to be; I’ve done enough performance testing and benchmarking to know these things are fiddly and take a fair amount of work to get right … or at least right enough to be useful and indicative for the thing you’re looking at. No big deal; v2 was a lot better and found a real bug with an easy socket configuration fix.

So I put Fable back to work tackling the issue and writing the code to fix it, and then I went to bed. And woke up to our first PR in the OpenShell project, which I really hadn’t expected. Fable was pretty happy with the work it had done, though, so up it went.

Problem is, I’d expected to review the work first and be sure it was well structured, concise, and genuinely fixed the bug in a way that made a meaningful improvement in latency. When I dug in, I quickly saw improvements I’d direct, so I killed the PR and settled in with Fable for a morning of revisions. Once the dust settled, we’d:

• Pulled the original separate set_nodelay(true)? calls into a set_nodelay_best_effort() helper to prevent a failed syscall from killing the connection, logging the failure instead.
  • This is the preferred behavior since the issue we’re fixing is purely a latency cost, so continuing just means things are a bit slower than they could be.
  • The first pass on this helper dropped it into the supervisor_session crate, which would have inappropriately coupled a number of other parts of the code to it.
• Found another path the first pass missed
• Ran before and after benchmarks and included their stats in the PR
• Published a separate branch with the tools, data, and analysis
• Put the PR up as a draft so we could see if the corresponding issue generated any conversation before asking for review.

Throughout this, Fable did an excellent job at achieving the goal, and the original explanation and summaries of its Phase 1 work hinted in the right direction for me to follow up on and help us find a subtle bug. Part of the fun for me¹ in this was the learning, both about OpenShell and its codebase as well as Nagle’s Algorithm and what happens when it intersects with TCP’s Delayed Ack. I really enjoyed the collaboration, even if Fable was a little overeager to ship and move on.

Where things went awry was that Fable and I didn’t have a shared understanding of what “ready for PR” meant and what we needed to do to get there. I wanted more rigor and to show up with more evidence before I brought a PR that touched quite so many things, some of them serving security critical functions, as well as more confidence that we’d done it well. Fable was following the rules as written, no doubt, but I knew we could (and should) do better on our first outing in a new-to-us community. Those are the unwritten rules of how communities work, or at least how they worked before the robots arrived.

In the end, working together we proved out the fix and found another couple of improvements worth making as well as avoiding a few pitfalls. I’m happy with the PR we put up and I’m looking forward to learning if this community of humans and robots working together has norms that are similar enough to the other open source spaces I’ve worked in that I can trust my intuition on how to engage and the level of rigor to bring. However it goes, I’ve learned a lot, including that a strong shared understanding still matters whether your teammate’s a coding agent or a person, and we’re not even started on Phase 2 yet!

Footnotes

1. Why yes, I do have a warped sense of fun. Why do you ask? ↩