dregitsky
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.
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.
There are also a bunch of newer startups in this space. I'm building one myself, https://boxes.dev -- we're very early but building for this exact use case. Some other ones worth a look are Factory Droid and Amp Orbs. Those two build their own agent harness (like Cursor), whereas with boxes.dev we run the native codex and claude code harnesses directly.
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.
- 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.
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.
100% agree on "clone X and tell me how it works". I'd also add: "clone X and see how it does Y; use that as design reference for building feature Z" if licenses permit.
On modifying software... I forked codex in ~Dec and had my own lightweight "plan mode" and a few other things. It was fun and satisfying, but it ended up being a bit of a pain to keep updated. The models were less good then, and maybe I should have learned some rust first. But it was close. For a less fast-moving codebase it'd have worked, and that was 8mo ago.
On the other hand as someone building in devtools for the first time, I struggle with how to think about this. We're building a cloud agent + sandbox platform, https://boxes.dev - same problem space as the author's product exe.dev. We could open source our client or the whole stack (we've been thinking about it), but we're adding stuff so quickly that anyone customizing would have a hard time with updates. There's also a lot on the hosted side that users couldn't modify unless they self-host.
But I like this vision of a world where software is some fluid thing, and everyone is writing personal mods and building off of others' - basically OSS with forks but where every user (or their agent at least) is engaged with the code.
I'm working this with https://boxes.dev - a workspace for launching and managing claude + codex sessions, each running in its own cloud devbox.
We launched with a desktop app but have gotten a lot of pull for terminal-driven workflows, so have a TUI as well. It's interesting - when the Codex desktop app launched I was so sure that GUI is the future for coding agents (it's just a chat!). But turns out there's no killing the CLI
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.
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.
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!
And thank you!
These can go for many hours from all the manual testing and debugging. Quality really depends on how much you spec things out beforehand, and how you define the test plan / "success" gates. If the agent can't even run the app to test it then things can definitely go off the rails!
Re: web searches -- we're running a full linux kernel and the agent runs on the machine itself, so we can't sleep mid run. But conceptually, moving the agent off-box and sleeping during web searches etc would be interesting, but in our experience coding agents are running enough stuff on the machine itself (rg, bash, playwright, etc) that there wouldn't be much savings.
It's a fully client-side, Tableau-inspired data visualization & exploration tool for CSV / tabular data. I built it around 7 years ago with just ES6 and d3.js (no React etc) but never really finished or "launched" it - perfectionism led to a neverending todo list, and with a target market of only myself I didn't have a strong pull toward solving a real-world use case. I even took some time between jobs thinking I'd build it into a real product, but only managed to burn myself out instead (quite a surprise to learn that could happen on a passion project!)
But it does work - drag in a CSV file (ideally <100MB) and you can make some cool charts and quickly explore a dataset, all without the data leaving your machine. The features aren't very discoverable, but it has stuff like adding derived columns, various fancy charts, row/column sorting, custom colors, etc. I'm sure there are far better tools around these days, but I've still come back to this thing a surprising amount in my day job when I want to whip up a quick histogram or investigate some trend in a medium-size dataset.
Cash works well when everyone has it, but from what I've seen that doesn't happen all that often. Also, you get a lot of restaurants that refuse to itemize the bill (maybe their point of sale system doesn't support it), and sometimes they'll only take 1 credit card. Integration with payment apps is great for that. It goes beyond saving time...an app can help make sure people pay up and the IOUs don't become permanent.
Disclosure: I recently released Grouptuity (https://play.google.com/store/apps/details?id=com.grouptuity), which tries to solve these problems and integrates with Venmo.