Recently, Loren got back from a ten-day silent meditation retreat with a fire under him about changing his relationship with the internet. A big piece of that was wanting to break the default habit of opening news sites or Reddit in the thirty seconds between finishing one task and starting another. The retreat made him realize he wanted to be more intentional about the media and information he was consuming, rather than doing it on autopilot.
There are already some tools for this, like Freedom and Cold Turkey, and Brick for your phone. But all the desktop ones had unnecessary features like cross-device sync, scheduling, browser extensions, and dashboards. We only wanted one thing: block a list of websites for a set amount of time, with no way to undo it until the time runs out. This was simple enough that we thought we should just build it ourselves.
The app is called Retreat. It’s free, open source, and works on macOS 15 or later. You can download it at retreat.computer.
Diving into loop engineering
Building Retreat was also an experiment. We’ve been thinking about loop engineering, where you give an agent a high-level goal, let it generate its own subtasks, execute them, and iterate until the goal is achieved. Ideally, the process is largely unattended and you come back to finished software.
We’ve seen loop engineering work in a few specific contexts. There’s a much-discussed case of the JavaScript runtime Bun migrating an enormous codebase from Zig to Rust largely through autonomous agent loops. That’s the kind of task loop engineering is probably suited for: a clear input, a clear output, a test suite that can verify correctness without human eyes.
We wanted to see how it would hold up for building a new native app from scratch. The short answer is that it didn’t, really.
Agentic tech bureaucracy
We let the agents run for around twenty-four hours, using frontier models and a setup where they’d generate tasks for themselves, execute them, and loop. The agents wrote code and features, and something resembling Retreat took shape.
But when we came back to it, the agents had created a system of elaborate and incomprehensible internal tickets, an agentic tech bureaucracy. Reading through what the agents had decided mattered and why, was like reading meeting notes from a company that didn’t exist (for good reason).
Also, a lot of the code didn’t work.
The core problem is that loop engineering needs verifiable success criteria that the agent can check without a human in the loop. For a library or framework with unit tests, that works pretty well. For a native macOS app that blocks network requests, the agent doesn’t have a good enough way to verify that the blocking actually works. Computer use has gotten better, but isn’t fully solved yet.
On top of that, building any product involves hundreds of small decisions. Every time the agent made one differently than we would have, the gap between what the agents were creating and the result we wanted would grow. After enough of these branching decisions, the product goes in an entirely different direction.
Eventually we ended up doing what we always do: sitting down with the agents, being hands-on, guiding the code, testing manually, and fixing things. And now, the app is what we want it to be, but it definitely wasn’t loop engineering that got it there.
The future of loop engineering?
Loop engineering is probably the right choice, in the right conditions. If you have clear success criteria, verifiable outputs, and well-defined scope like migrating a codebase, running a batch job, or transforming data in a predictable way, loop engineering could save you a lot of work.
But new product development isn’t the right fit yet. Products involve taste and nuanced decisions, and often, involve you changing your mind about the result. The agents can handle a lot, but they can’t handle all that.
The tooling also isn’t there yet for native app development specifically. Agents can more or less run the app with computer use, but it’s still flawed and burns tons of tokens, which leaves a huge gap in development. You still need to do the most important part yourself.
We’ll keep experimenting, but for now, Retreat was built the old new way: we had an idea, some agents helped write the code, and we did a lot of manual iteration.
Download it at retreat.computer. Source is on GitHub. Time to break out of bad habits!