exe.dev | full time member of technical staff | sf bay area only
competitive salary, meaningful early equity, 2 days a week in the downtown sf office
come build a cloud. we are doing everything from custom hardware to custom ssh servers to our own global load balancer. very senior small high-trust team looking for someone we can rely on to get done whatever is most important in the stack for the business. some days that means patch the vmm. other days it means figure out passkey quirks.
more about what we are building here: https://crawshaw.io/blog/building-a-cloud email me at david@exe.dev.
exe.dev | SF Bay Area | full time | $200k+, meaningful equity
Come build a new cloud. The entire engineering team has been in the industry 20+ years. Lots of hard problems. The freedom and responsibility to do what you think matters, push it to prod and deal with support when it breaks.
I would also love to hire an engineer with a background in design who wants to build UIs that are both functional and beautiful. You would get to own UI.
Hi, author here. FWIW, the only people I coordinated with are my colleagues at exe.dev. Philip wrote a blog post a week ago on the topic too: https://blog.exe.dev/customizing-shelley. In retrospect, I should have sent drafts of this to other people I know thinking about new dev tooling to get their feedback! A bit more private discussion could have let me polish this more.
We are all busy discovering the shape of new tools and norms as our profession has been overturned by LLMs. It is not too surprising similar ideas are floating about. Though I have not seen anything that captured how I now go about personalizing programs, and how I expect it to change our industry. So I wrote this.
(Author here.) Open models are really quite good now. I still use oai as my daily but I have been very impressed by qwen/glm/k3/etc when I try them. They are clearly my future.
FWIW the first version of meat was based on anthropic models, I switched to Oai models because they are faster and just as good right now. This is an astonishing thing to say, but the switch was a single shot prompt using a frontier model. I’m happy to add some selector there, but that is also the point of this article: do you really need me to make it configurable when you can switch the tool over to Anthropic with a single prompt? It’s a strange new world we live in.
On the website: you’re right. I have some side-by-side diff examples I want to turn into a website. I am just short on hours in the day. My real goal is to make the tool compelling enough that I can convince my colleagues that we should build it into Shelley. :)
Website not even needed! Janky terminal screenshot in the repo would have been good enough for me lol.
On another note, the reason I was perusing the blog was because I was curious about more of how exe handles review/quality/testing because you mentioned there being no code review in another post about stripe billings (maybe a different author). So consider this a casual request for more content on reducing delivery bottlenecks :)
(exe.dev co-founder here) The platform is designed make it easy for you to share if you like, but we are not typically in the business of pointing directly at products users make. Maybe we should change that! It would be fun to have a "best of exe.dev" on our site.
Ask creators before featuring them, but medium and substack and YouTube are popular platforms because of their discovery mechanisms, not because hosting text or video is especially hard these days.
Interestingly, it's the .xyz on our VM domain that causes problems. It's apparently far more of a problematic gTLD than I realized. E.g. it appears Southwest Airlines blocks the entire thing, as do some enterprise networks are working with.
For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand.
This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.
Checkout https://shellbox.dev for exactly thisnusecase: boxes can be stopped, they are snapshotted to disk then cost just $0.5/month. They wakeup with the same state (memory and processes too) on ssh connections, or web endpoint activity, or just just a cron schedule. When you dont need the box... Just delete it and stop paying. No subscription, managed via ssh
I'm a relatively basic claude code user, basically just running a few instances in different terminal tabs and monitoring them pretty closely, but I could definitely see value in being able to dump a bunch of code and tools into a workspace where there's no credentials present and just set an agent some goals to research or try a bunch of things in a mostly unsupervised manner.
I think it’s worth trying. There’s a lot of value in having the agent in the box. You can give it root so it can do something like tcpdump unsupervised. And if you happen to build a new server, you can keep it serving indefinitely. That’s the whole motivation behind exe.dev.
Yeah I have some stuff which is supposed to be “there” for months with the agents continually moving it forward. Not to mention the need to run different software. Running local VMs for now.
If you have a good local VM flow that’s great. I couldn’t make it work for me. I ended up needing it to run when my laptop was shut, both as an agent and the servers I am building.
It’s a real tension, working with a remote dev env has never been my first choice. But agents seem to tip the balance enough in favor of remote that I have switched.
Hopefully this helps mathematicians. It seems very clear to me that it will help software engineers apply formal methods to more of our software.