dregitsky

> The code IS the documentation

I liked this advice when humans wrote code. Though even then I'd urge people to write meaningful commit messages that capture the "why" of what they did, so no one tramples their intent by mistake.

But not sure it works in an age where most code is LLM-generated. Especially if that code is not even reviewed by humans (irresponsible or not, it's happening), and commit messages are also generated by AI. I think something is needed to separate "what did the human operator intend" from what the agent went and built.

I do agree that this gets way overengineered. My approach has been more or less what you stopped doing though - committing all our timestamped "plan/implementation docs" and "investigation docs" that document what the user wanted + empirical findings, and making all prior session transcripts searchable. It's seemed mostly helpful? For whatever reason I haven't run into many staleness problems so far.

This is inaccurate - natural monopolies are a thing.

Monopolies happen due to barriers to entry, and not all barriers to entry are government-created or illegal: network effects, big upfront costs, economies of scale, control of a scarce resource, etc.

Regulation can produce a monopoly, but lots of regulations also exist to keep natural monopolies in check.

> The only difference is to what degree they wield the tariff hammer, and in which direction it is swung.

I mean that's the point, no? Swing the hammer carefully at a nail or with maximum force at your own leg?

Or to drop the metaphor - much of the difference between good and bad policy is a difference in degree. So your counterargument here is valid against "all tariffs are bad" but I believe the point most are making is "the current admin's use of tariffs is bad" which makes your counter appear as a bad-faith mischaracterization.

Yeah, it's kinda scary. I don't know if you even need open weight self hosted models for this sort of "AI worm" (though they def make it harder to kill). Like for example:

- AI agent finds and uses API keys or AI subscriptions to propagate itself. OpenAI/Anthropic/etc could revoke creds, and their current safeguards might block a lot, but if something like this got started and there were lots of instances creatively looking for creds and workarounds, containment might be hard.

- prompt injection version: huggingface incident had multiple agents discovering other agents' messages and jumping on the bandwagon to help with the hacking task. If there were some self-replicating instruction that models could accidentally stumble upon that gets them to drop what they're doing and try to propagate it instead, you could wind up with a version of this too, with just the inference people are already running.

Yep fair point. In my case I don't think codex team was really considering outside contributor PRs except bugfixes, plus my idea of "plan mode" was prob not what they wanted to ship in their product. But maybe I should have tried!

For boxes.dev we use E2B - they had everything we needed at the time. I'd love a standardized API / marketplace, but more just to try out new providers with differentiated features or pricing - we probably wouldn't be switching often / using multiple (unless customers asked us for more options). There are so many sandbox providers popping up!

Our use case is pretty specific though - one persistent machine that you set up your full developer environment on, then ability to very quickly spin off full copies of that machine (filesystem + memory) as separate VMs to run agents on. Firecracker VMs + support for "forking" the box were our key requirements. Another provider that could do this was Modal, but they use gVisor and not Firecracker, which means it's harder for users to run docker inside the box.

Thanks! We aggressively spin down idle boxes. We'll put any box to sleep where the agent has finished its turn and you're not connected, and then we'll wake it again if you connect (firecracker VMs can sleep/wake very quickly). We don't charge for sleeping boxes (neither does our infra provider) so this keeps costs down for everyone.

Thanks! Longer term it's hard to say if everything 100% moves to the cloud. I'd guess that some things stay local (e.g. if you need your local hardware or are very are hands-on iterating with the code). But at the moment the average developer coding with AI seems way too local-bound, so we're focused on making remote development more convenient. At some point down the road we may add local as an option too.

Yes it definitely sped up development! The main wins were around parallelization and autonomy:

1) full isolation (filesystem + compute per thread) 2) agents having a working dev environment that runs our app 3) being able to close our laptops and check in from mobile

The combo of these meant we could fire and forget lot of parallel threads like "root cause and fix this bug: add logging, run app, get a repro, write fix, validate live" or "build this feature, test new workflows live, send screenshots" -- and then come back later to review & iterate.

You can get to a reasonable level of this with locally with git worktrees and the right project setup, but in the cloud you can really fly.

Nice! We love hearing about personal setups to solve these same problems. One difference between boxes.dev and your setup is that we spawn an exact copy of the main box for each agent thread, so it's totally isolated. But doing parallel agents on one box can definitely work too, it's just more work to configure a project for it.

Our bet is that a lot of people will want something prebuilt, and that the last-mile UX for making a good coding workspace (including code review, etc) is actually nontrivial, especially at companies.

Thanks! We were also excited about Sprites when it launched but it didn't quite work for us either. And Cursor Cloud Agents is definitely pretty similar -- one area where we differ is that Cursor only uses their custom harness, and we liked using the actual Codex/CC harnesses directly (and wanted to benefit from any improvements big LLM cos are making to their models+harnesses)

> What kind of cpu/memory do the vms get?

Default is 4 vCPU / 8 GB memory but it's configurable at the team/project level (can go higher).

> Is there a way to define the template that's used, so I can say to a new team member, log in to boxes.dev and all the repos and tools are already there for you?

Yes we're moving in this direction! For the current public version each person sets up their box and then agent threads start on a snapshot of that box. But for companies, what you laid out is 100% the vision and coming soon. No more eng onboarding, and maybe even give non-technical folks a default dev environment where they can spawn agents and prototype.

> And where do you get the machines, can we bring our own?

Right now we're using MicroVMs with E2B as our infra provider, but for companies we're exploring how to support bringing your own. Happy to chat if interested!