Journal · Developer story

Why we split Stitchu into four work lanes

On 17 October 2026, Stitchu's pattern engine, its website, a new account service and the site's own pages were worked on at the same time, each in its own lane, with one integrator merging the results. This is the record of that day, written from the lanes' status files, messages and test receipts: who did what, where we waited for each other, which problems got past green tests, and what is still open. None of the dresses has been sewn yet.

1. Before: one dress and one writer at a time
2. Who did what
3. Why in parallel
4. Where we waited for each other
5. Problems that got past green tests
6. What we learned
7. What is still unsolved

Before: one dress and one writer at a time

Until mid-October the work ran as a single queue. From 27 September the rule was to finish one dress completely before starting another, and only one agent wrote code at a time. The two AI coding tools we use took turns: a run orchestrated by Claude from 10 to 13 October, then Codex on 14 and 15 October, with no Claude run. The hand-off notes of 13 October replaced the one-dress lock and the one-writer rule with lanes split by file ownership.

On 17 October both tools worked in the same run. Root, the integrator, and the reader thread were Codex threads. The engine, web, account and marketing lanes were Claude sessions. The Claude sessions could not message the Codex threads directly, so every lane wrote to two files that the others read: a status file (what it owns, what it is doing, what is open) and an outbox of numbered messages.

Who did what

Everything below is on the lanes' own branches. When this was written, none of it was on the live site yet.

• Root (Codex), the integrator. It owns the integration branch, the native engine build, the shared service files and the hosting configuration. It merges a lane's commits only after checking the file hashes in the lane's receipt, then rebuilds and reruns the tests. For independent checks it starts its own child agents: one read the first real pattern package against the request, one checked the shared header, loading states and consistency across pages, and one audited the service's repair loop.
• Reader (Codex). It turns a written description or a photo into a structured reading of the dress. These are the paid model calls. On the public site this step is not open yet; the workshop there builds one example design.
• Engine (Claude). The C++ pattern engine, built natively and as WebAssembly for the browser, plus the drawings and the sewing guide text. It had delivered 15 receipts by the time of writing, among them: a zip opening that must end strictly below the hip when the request says so, a straight silhouette that stays straight on every body size, a length check against the knee of the selected body, and error messages that say which seam or height is at fault. It also reviewed real packages.
• Web (Claude). The workshop and the wardrobe. A failed or interrupted request now survives a browser restart. A saved design can be rebuilt in another size in the browser from its saved reading, without a new model call, and versions can be compared side by side. The wardrobe can save to an account and shows the account's state when the service is slow or down. Later in the day the lane took over the shared header, footer and skip link.
• Account (Claude). Stitchu had no accounts: there was no sign-in code at all. The lane built a separate Cloudflare Worker, with D1 for users, sessions and design versions and R2 for files. An independent security review found six issues: four were fixed, one became a cost decision (password hashing needs more CPU than the free Workers plan gives) and one can only be checked once the site routes to the service (the hosting platform's request size limit). The deployed service passed 11 of 11 tests, including a 6 MB photo upload. It is not connected to the site yet.
• Marketing (Claude). The copy, guides, journal, patch notes, search titles and share cards. It removed claims of features that do not work yet, wrote five guides for the steps before cutting, and checked whether the free samples could be sold on Etsy; they do not meet its rule that digital items be designed by the seller, so no shop was opened.

Why in parallel

The engine work was tied to the reader: every fix had to be tried on real model output, and each model call took minutes. The website, the account service and the site's pages did not depend on those results. Holding them until the engine was done would have left three lanes idle for most of the day, so they ran at the same time and met at Root's merges.

Where we waited for each other

• Live model calls froze integration. A first reading took 289 to 309 seconds; repair calls took 73 to 142 seconds. A result only counts if it can be traced to the exact source and engine binaries it ran on, so Root froze the integration branch while calls were running, and the lanes kept working on their own branches. The marketing lane's first round was reviewed during a freeze and merged only after it ended.
• One writer per file. Each lane listed its files in its status file, and a file had one writer. Shared files needed a grant. The home page needed both copy and layout, so the marketing and web lanes agreed by message: marketing writes the markup, copy, images and search tags; web writes the shared stylesheet, components, loading and accessibility. Until web's stylesheet existed, marketing kept its styles inline in the page. The hosting configuration belongs to Root; each lane could add exactly one line to it, turning off preview deployments for its own branch, because a pushed branch otherwise gets a preview build, and early pushes that day did.
• Root's merge queue. Lanes push commits with a receipt: commit hashes, file hashes, the tests that ran and where the evidence is. Root checks, merges, rebuilds the engine and reruns tests. At 14:50 UTC it merged the account, marketing and web lanes and its own consistency fixes into one integration commit. When this was written that evening, 77 lane commits pushed after that merge were still waiting, and the account service was running in the cloud but waited for Root to route the site to it.
• One laptop with 8 GB of memory. All lanes shared one machine. The web lane ran its browser tests through two machine-wide slots so that Chrome and the local Workers runtime would not pile up; the marketing lane ran its browser checks one at a time under a lock. In one web test run the local account worker could not start because another session's worker held the same debugger port (9229); the account lane then gave each worker its own port.

Problems that got past green tests

Each of these passed the checks of the lane that made it. They were found by a reviewer that had not done the work, by another lane, or by reading the real output (the PDF text, the screen) instead of the test result.

1. Share cards promised a feature we do not have. About 20 pages used a link preview that said: “Photograph a dress. Get a real sewing pattern. A hand-built C++ engine drafts it to your exact body.” The public workshop does not read your photo or draft to your body. The page checks were green; an independent reviewer marked the card critical. It now shows three drawn dresses, free EU36 PDFs and “not yet sewn”, and the story pages have their own cards.
2. A phone header hid the dresses. On a 390 × 844 phone screen the shared header took 177 px, so the home page showed no dress in its first screen. Overflow was 0 and page errors were 0. The web lane's one-row header is 57 px; it waits for the next merge.
3. The first real package failed review after passing its checks. From a short written description of a straight, sleeveless dress ending above the knee, with a zip at the centre back, the pipeline produced all six files; browser tests passed and Root matched the file hashes. A reviewer reading the PDFs found that the pattern was shaped to the waist (finished bust, waist and hip 90, 77 and 96 cm), the hem sat at the knee, and the neck binding instructions closed the zip opening into a ring. After engine and reader fixes, the next fresh package cleared all three: a straight side line, the hem 40 mm above the knee, the binding open at the zip. This was an internal test; the public workshop does not take descriptions yet.
4. An account error stayed on “loading”. When the account service answered 404, the account page kept its loading state and said the service had refused. Root's consistency agent found it in a browser run. The account branch now shows an “unavailable” state with a retry; it waits for merge.
5. The workshop example builds an unpublished dress. The example design in the workshop is the pink pinstripe back-bow mini with four PDFs in sizes EU34 to EU44, while the journal said that dress's PDF package was not published. Both pages passed their own checks. The story now says what the workshop builds and why the dress is not with the free patterns; whether the example should be a published dress instead is Root's decision.
6. PDF titles did not match the site. The keyhole mini's PDFs are titled “Bow Cap-Sleeve Mini Dress”, and both wrap minis are “Draped Mini Dress”. Downloads now save under the dress's site name, and the marketing lane proposed one names file for both the site and the PDF covers; the engine lane has not answered yet.
7. The marketing lane stopped another lane's Chrome. During a browser check it stopped a headless Chrome it took for its own hung browser. The browser's parent process was not the marketing lane's, so it may have been another lane's test. It told every lane to rerun any browser test that failed at that time. Since then it stops only processes it started and checks the parent process first.

It went the other way once. A browser test reported that the engine's WebAssembly bundle failed to start in Chrome. Root traced it to the test server, which sent the files without a UTF-8 charset; the bundle was fine and was not rebuilt. The correction went out as its own message to every lane that had read the first one.

What we learned

None of this is a new method. Branches, code owners, a merge queue and independent review are ordinary software practice. The day showed where they mattered when AI agents did most of the work.

• Context. A lane knows only what is in its status file and in the messages sent to it. Messages that carried commit hashes and evidence paths let the receiver check a claim instead of trusting it, as Root did with the lanes' receipts. When a fact changed, as with the WebAssembly charset, the correction had to reach everyone who had read the first message. In the afternoon the engine, web and marketing lanes each ran as a coordinator with implementer agents in separate scratch copies of the repository: the implementers held the details of one change, and the coordinator held the merge, the checks and the messages.
• Division of work. Splitting by files worked where a file had an obvious owner. It was slowest where nobody clearly did: the shared header, navigation and footer. The 177 px header was reported at 15:40 UTC. Root's consistency agent owned that area then; the web lane took it over at 16:32 and delivered the fix at 18:12, on a branch that is still waiting for merge.
• Integration. Each lane's tests were green on its own branch. The problems above sat between lanes, or between a page and a file: a share card and the workshop, the workshop and the journal, the site and the PDF covers. Two independent reviews of the same package can also disagree: Root's reviewer cleared the next fresh package for a printer test and a tailor's toile, while the engine's reviewer, checking other things, found the finished neck 316 mm round against a 360 mm body neck, so the zipped neckline cannot sit at the base of the neck. And the merge was the bottleneck: four lanes produced work faster than one integrator merged it, and every merge also meant an engine rebuild and a test rerun.