Exploring the age of continuous work.

A few weeks ago, I was swimming laps after work, reflecting on my day. This eventually led to a spark of inspiration for a potential project, and I spent the rest of my workout mulling over this idea. As I biked home, I opened up my voice notes app and proceeded to do a verbal dump of my brainstorming session at the pool. When I got home, I copied a cleaned up version of my voice note transcript into a Google Doc and refined the vision. I spun up Codex, set a goal, pasted in my vision, and Codex has been working to build out this vision ever since.

This blog post explores a weird but powerful new way of building software that I've started to refer to as continuous work. The premise is straightforward: establish an ambitious goal with a clear vision and task a coding agent to work nonstop, around the clock, building towards that goal. I'll share how I've adapted my development process to explore this new mode of working, and peek into a future where this becomes the predominant way that people collaborate on ambitious projects.

The core principle

Rule #1 of continuous work is that your main agent thread should never be idle; this means that we need to create the conditions for the agent to work without stopping. It starts with an ambitious goal; if the goal is too simple, agents will simply complete the task and then stop and wait for further instruction (which breaks rule #1).

This also means that you are no longer in the driver's seat; you need to reorient your development process to allow the agent to work autonomously. The agent will work relentlessly while you sleep, eat dinner with your family, go to the gym, and generally live your life. In order to keep the agent on a productive path, I have settled into a pattern where I'll periodically check in, see what work it's recently completed, notice when it may be heading in the wrong direction, and provide periodic nudges to steer the agent towards the path that better aligns with my vision. Humans become the guide, not the gatekeeper.

Keeping a pulse on progress

Figuring out the right way to check in on the work has been an interesting challenge, given that it's not practical to read every line of code the agent added to or deleted from the repo. I've settled into a pattern where I instruct the agent to maintain documentation that represents a higher-level vantage point for me to inspect. Some of these documents include:

• a roadmap to document what work has been completed and what the agent is planning to work on next
• the shared vision for what we're working towards
• a technical specification for how the overall system works alongside some architecture diagrams
• an experiment log for targeted explorations (e.g. working on performance improvements)

These documents serve as an effective entrypoint for me to understand the state of the system and allow me to prioritize which parts of the codebase I should more closely inspect.

Steering the agent

When I do want to take a closer look, I'll usually open up a side thread where I can ask the agent questions, understand the context behind certain technical decisions, and share my input on the direction I'd like to go. Doing this in a side thread allows the main agent thread to stay focused on relentless execution, adhering to the core principle we previously established.

As I gain a better understanding of the current state of things and the reasoning behind the decisions that got us here, I will sometimes want to redirect the agent to explore a new direction. To do this, I'll share my feedback and ask the side thread agent to write a concise "design nudge" to share in the main thread and steer the main agent. This can involve multiple iterations of back and forth as we work to crisply define the guidance to share with the main agent.

I've learned that the most useful feedback isn't just about the specific thing the agent is working on, it's about the principles behind it. When I share feedback with the agent, I try to explain my thinking in terms of durable principles that the agent can reuse when making future decisions. It's incredibly satisfying to give some feedback and share the principled reasoning and see the agent using that same line of reasoning when solving a problem two days later.

While principles are useful for teaching the agent how I want it to think, guardrails help catch the ways it tends to go wrong. I'm not going to be monitoring each and every line of code the agent writes, so it's important to expose signals it can use to detect issues and correct course on its own. I've found Rust to be a great language for coding agents: the compiler is strict enough that whole classes of bugs become precise compile errors, giving the agent fast, automatic feedback it can act on before anything reaches me. On top of that, I've set up a set of "quality gates" the agent runs after completing each unit of work:

• standard unit and integration tests help prevent behavioral regressions,
• cargo-crap helps fight against untested complexity,
• differential tests are useful in comparing output against a known reference (e.g. comparing a slow but trusted method against a performance-optimized method),
• and I've also had the agent write its own linting tools to enforce feedback I've given around areas like code organization.

Building out this kind of environment is a big part of what makes continuous work sustainable: the richer the signals around the agent, the more it can catch and correct on its own — and the longer it keeps making real progress while I'm off doing something else.

The shifting nature of work

With this new style of continuous work, I feel like one of the most important things humans can do is spend more time thinking and learning. Let the agents build and prototype and experiment with new ideas; our role shifts to building a deeper connection to the problem, continuing to learn about the world, and figuring out the right questions to ask.

That kind of thinking starts with the goal itself. For this project, I thought hard about the problem and the general shape of the solution I wanted to see. Then I handed the agent a clearly specified goal to build toward. I sometimes see people recommend having an agent write their goal, but I think there's real value in humans thinking deeply about what we want the agents to build.

To me, this presents an optimistic view of the future. I love learning! Having more time for it is a gift. And you don't need to be tied to a desk to think deeply; it doesn't matter where your body is, it matters where your mind is. The idea behind this whole project came to me while I was swimming laps at the pool. You can work through a hard problem on a walk in the forest or in your favorite cozy spot, and I think that's a delightful thing.

Leaning in

Suppose we lean into this new style of work and push the frontier. What could this look like? One emerging pattern shifts the main agent from executor to orchestrator: instead of writing all the code itself, it breaks the goal into bounded tasks, hands them to subagents, and stitches the results back together.

There have been times when I've taken on the orchestrator role myself, and it can be incredibly taxing. Handing that coordination to a main agent lets us scale the system's productivity without over-saturating our mental bandwidth. From there, the system scales as a function of the main agent's capabilities and speed.

Collaboration in the age of continuous work

Scaling up the system's output is one interesting dimension to explore, but I think an equally interesting one is scaling up the team steering the agentic system. The same main thread that one person watches and nudges can become something a whole team watches, discusses, and shapes together.

When humans collaborate, they share ideas and diverse perspectives, ask questions to seek clarity, and push back to refine a design. The vision comes out stronger and clearer for it. Perhaps, as the nature of our work shifts, we'll place an even higher value on collaboration with other humans.

Right now the coding agents are largely designed for personal interactions, but I can envision a future where an entire team can observe the main thread as it works continuously towards a shared vision; different people can dig into different areas, discuss amongst the team, and shape nudges to share with the main agent.

Closing thoughts

This style of working is new and weird and it can feel uncomfortable to hand control over to the agents. I don't think we're at a point where this works well for every problem, but for a certain shape of problem it can be very powerful.

I've been running this experiment alongside my normal day-to-day work, where I use coding agents on bounded tasks that end in a pull request. In that mode, I'll go back and forth with the agent on exactly the right approach, shaping the code until it's how I want it. In continuous work, I let that go and trust the agent to find its own way, even when it isn't exactly what I'd have chosen. Moving between the two creates real cognitive dissonance. How do we best leverage something that is extremely powerful, but not perfect?

In The Art of Doing Science and Engineering, Richard Hamming wrote about the shift from analog to digital computing; he observed that the people who helped drive progress were the ones who recognized the new thing as new and studied it on its own terms. Continuous work feels like one of those moments, and I think it's worth exploring.

Acknowledgements

Thank you to Kalpesh Sutaria for showing me what's possible when you task agents with ambitious goals and set up the right oversight to keep them on track. Thank you to Ian (伊恩) for creating and sharing the ian-xiaohei-illustrations skill that I used to make the illustrations in this blog post.