This kind of project totally shows that Claude Code is nothing special, if anything it lacks a lot of features. I hope every company develops a model agnostic coding agent rather than using a one tightly controlled by one company.
Why we built our own background agent
21–29 of 29 posts
Re: Why we built our own background agent
#22This kind of project totally shows that Claude Code is nothing special, if anything it lacks a lot of features. I hope every company develops a model agnostic coding agent rather than using a one tightly controlled by one company.
Yes. I don't think that one-size-fits-all is the future of coding agents. Different companies have different requirements. I would like to build specialised test harnesses that internal coding agents could use to iterate rapidly.
Also, inevitably these AI companies will start selling out data and become part of the surveillance state, if they're not already.
Re: Why we built our own background agent
#23This kind of project totally shows that Claude Code is nothing special, if anything it lacks a lot of features. I hope every company develops a model agnostic coding agent rather than using a one tightly controlled by one company.
It's really a shame because anthropic had a lot of opportunity to show good will by open sourcing claude code.
Re: Why we built our own background agent
#24I work at Ramp and have always been on the “luddite” side of AI code tools. I use them but usually I’m not that impressed and a curmudgeon when I see folks ask Claude to debug something instead of just reading the code. I’m just an old(er) neckbeard at heart. But. This tool is scarily good. I’m seeing it “1-shot” features in a fairly sizable code base and fixes with better code and accuracy than me.
These Xmas there have been a lot of converted programmers after having some free time and playing with things like Codex, Claude Code, AMP...
Re: Why we built our own background agent
#25Reading this article and discovering how Ramp team use Modal for sandboxed dev environment just saved us weeks of custom infra development and potentially months of headache, thanks you !
Re: Why we built our own background agent
#26Fun marketing experiment, but you basically implemented ralph wiggum in the cloud.
Claude code locally in a vm and/or with work trees will 1 shot far better without burning cloud infra cash.
I’d bet this ends up wasting more money and time than it’s worth in practice.
Re: Why we built our own background agent
#27Definitely impressive. How many engineering hours did you need to build an MVP?
Re: Why we built our own background agent
#28This is a great writeup! Could you share more about the sandbox client communication architecture? e.g., is the agent emitting events to a queue/topic, writing artifacts to object storage, and the client subscribes; or is it more direct (websocket/gRPC) from the sandbox? I’ve mostly leaned on sandbox.exec() patterns in Modal, and I’m curious what you found works best at scale.
After reading the article, I built a tool like that with sprites.dev. There's a websocket to communicate stdout and stderr to the client.
Web app submits the prompt, a sandbox starts on sprites.dev and any Claude output in the sandbox gets piped to the web app for display.
Not sure I can open source it as it's something I built for a client, but ask if you have any questions.
Re: Why we built our own background agent
#29Definitely impressive. How many engineering hours did you need to build an MVP?
I built something similar after reading the blog post, based on sprites.dev.
A day of work to get the prototype working and a few hours the next day to allow multiple users to authenticate.
It's surprisingly simple.