Recurse Center

Recursers built an arcade cabinet that you can ship games to by pushing to GitHub. It has a real CRT with a custom display adapter, and over 50 new games made by the RC community. Watch the full talk on how the RCade was built from the hardware up: https://lnkd.in/eMuWKpnN

We're accepting applications for the Fall 1 Batch, which begins on August 10! Spend 6 or 12 weeks programming with other curious peers in Brooklyn or online. 🌱 The (soft) deadline to apply to Fall 1 is tomorrow, July 30, but we'll still review applications sent later. 👉 https://lnkd.in/eFYprfPZ

We sponsored a podcast! Listen via the link in Nick's post.

After 15 years, it felt like it was about time to make a video.

I finally found a good way to run agents unmonitored. A shocking number of people run `claude code` or similar without a sandbox. They either `--dangerously-skip-permissions` or tediously approve each request, which quickly becomes mindless and almost as bad as YOLOing. This opens you up to mistakes (e.g., `rm -rf`), prompt injection, and supply chain attacks. The right way is to run agents in their own VMs, but that's annoying to set up correctly, so most people don't do it and just hope nothing goes wrong. Enter: exe.dev. Just `ssh exe.dev` and you can have a VM running in 30 seconds. And it makes all the stuff that's normally hard or annoying (secure web access, auth, API secrets, sending/receiving email, etc) super easy. (This is not an ad! I'm just a paying customer, who came across exe.dev because it was founded by David Crawshaw, an Recurse Center alum.)

❤️

writing tip: say something surprising permalink: https://lnkd.in/eh8rxPDe

Robots, unease, agents for everything, and everything for agents. I'm at SFO, about to fly home after 36 hours in SF. I came back for the Y Combinator Alumni Demo Day, and to meet up with Recurse Center alums. Some quick thoughts after watching 50+ YC pitches, and speaking with dozens of current and past YC founders and investors, as well as half a dozen OpenAI and Anthropic employees: - Unsurprisingly, every single startup I saw was an AI startup. - Of those, the most common was "agents for X" -- agents for property management, agents for payroll, agents for hiring, etc. - But almost as many companies were "building X for agents:" E.g., phone numbers for agents, marketing for agents (so agents find your product more easily), developer experience for agents (so they can use your APIs more easily), and even insurance for agents (insurance for if they go off the rails...) - There were also plenty of companies training their own models, either for cost (e.g., for cheaper video avatars for CS agents) or for specialized tasks with proprietary data (e.g., hiring people to pickup groceries and training on motion capture data). - That leads to the last big trend I saw: lots of hard tech, mostly robots: Robots for scanning and sorting packages, robots for bio labs, robots that could prepare drinks, underwater defense robots, and many more. The energy at YC was positive and infectious: so many people earnestly building new stuff. That stood in contrast to what I heard in more private chats with software engineers and employees at the big AI labs. For them, the mood was all uncertainty. But I don't think the two groups actually disagree. They're just looking at different timelines. The founders are optimistic because they're focused on today, and today is a great time to build. The lab folks are worried because they're focused on the future, and what happens if AI really does just keep getting better.

Alums: RC meetups in SF tonight and tomorrow afternoon! Check the RC calendar or DM Nick for details.

I've deleted more code with AI than I've written with it. I help maintain a 15-year-old Rails codebase for the Recurse Center. It's ~250,000 lines of code, mostly Ruby and JavaScript. Over the years we've run dozens of failed experiments and built countless internal tools and dashboards that we later abandoned. Sometimes we removed all the related code afterwards, but usually we didn't; it rarely felt worth the time of doing so or the risk of breaking something in the process. But now? Every time there's a new model, my first instinct is to test it out by firing off a prompt to remove some deprecated feature I've recently spotted in our codebase. The previous generation of models were ok at this, but still needed a fair amount of guidance from me, requiring lots of back and forth to get them to realize that deleted dead code frequently creates more dead code. This week, I gave Fable a curt request to remove a feature we stopped using three years ago. It cranked for about 10 minutes, and came back with a PR touching 47 files and only one small bug. (For the curious: The bug was a minor visual regression from failing to remove a spacer div that made some tabular data line up; Fable didn't catch it because it couldn't run our system tests because I'd just updated Chrome but not my chromedriver, so the versions didn't match. Fable flagged this and gave me the command to upgrade via brew. Once I did, Fable found and fixed the bug!) Less dead code is the opposite of introducing AI slop: It makes your codebase easier to understand, and it makes it less likely agents follow bad patterns or write senseless code.