"Projects" is a new harness pattern, and it is effective

Claude and Cursor now offer a "Projects" feature in which a coordinator thread manages worker threads that each run on their own cloud machines, share a mounted filesystem for notes and rules, and can message one another, according to a practitioner account of the pattern. The author reports that after about 2-3 days of correcting mistakes and process in a Project, a stable workflow emerges, with a typical setup having an implementor thread spawn review and test threads, and larger tasks adding a TPM thread that breaks work into focused PRs. The pattern matters because threads can read each other's history and update shared guidance, letting a coordinator run retros that fix process failures without direct user involvement.

"Projects" is a new harness pattern, and it is very effective. Claude and Cursor now have a "Projects" feature, with a few key attributes: - You primarily talk to one coordinator thread, which manages other threads to do the actual work. - The coordinator and all the worker threads run on their own cloud machines - There is a shared filesystem mounted on every machine, where notes, rules, status, etc. can be shared between threads. - Any thread can message any other thread - You can directly message any thread if you want - A project has its own "rules", like an AGENTS.local.md for that repo, but shared by all the cloud machines. Having a coordinator managing separate threads is a great improvement. You get some resilience because the coordinator can keep threads on track, and you get some parallelism without having to jump between threads. There are some other emergent behaviours though that make this much more powerful: - Multiple threads can collaborate on one task, even just separating the reviewer and tester from the implementor catches a lot of slop. - Threads can read other project threads, so when something goes awry a new thread can read the history and figure out what happened. - Those introspection threads can see the multi-thread collaboration too. - The shared workspace can hold learnings, rules, and processes, so threads can improve the process as you work. This means that any time something goes wrong, you can tell the coordinator "make sure this never happens again" and it can have a thread do a retro on what happened and update the right guidance to fix it. In my experience, after about 2-3 days of working in a "Project" correcting mistakes and process, I will have a stable workflow that ships exactly the way I want. After that, I can guide the process just by prompting the coordinator when I want updates, and do occasional retros when things go wrong. I have seen an implementor make a bad scope decision, and another thread send a corrective guidance note before I could chime in. It is very cool when it starts working. The process that all my projects end up on is roughly: The coordinator creates an implementor thread, and the implementor spawns a review thread and a test thread. They all argue through the implementation, and I only give notes to the coordinator. In bigger projects, or for bigger tasks I might have the implementor spawn a TPM thread which breaks down the work into small increments, and has implementors build it 1 focused PR at a time. I will also have PR writer threads which just focus on writing really good PR descriptions to save reviewer time me . I always start the project with roughly this workflow, but it will veer off course sometimes and some retros will be required to make sure the process is robust. It is all a bit slower than being directly involved in the build, so I will usually have 3 separate streams of work going at once, so that there is always something for me to review.