At 9:30 on Saturday, October 31, I started merging. Eleven PRs for GSD Task Manager went in over the first two minutes. By 11:38, I'd merged 64 across three repos: 27 for the web app, 22 for the iPhone, iPad, and Mac app, and 15 for Android. The sprint plan on the board said November 2 to 13.
By lunch, none of those changes had reached a user.
I didn't write any of the sprint's code. A tech lead agent planned the work, wrote the briefs, assigned engineers to their own terminal panes, reviewed their PRs, and kept the board. My job was to approve the plan, answer the decisions it escalated, and merge. The morning looked great from my chair.
GSD is my free task manager apps built around the Eisenhower matrix, with tasks stored on your device by default and optional sync. It runs on the web, iPhone, iPad, and Mac; the native Android app is in Google Play testing. This sprint was about making the three implementations agree. The landing page has the product details, and the web, Apple, and Android codebases are public.
Eleven worker agents ran in two waves, with a lead coordinating them. My Mac mini's load average hit 275 on 14 cores. Questions went to the lead, which pulled me in when it needed a decision or confirmation.
Then the lead's closing report listed what the morning hadn't done. The Android 0.10.1 release build still needed a real-device sign-in and sync test. Manual checks, from deleting a throwaway account to signing out during a sync, remained unrun. The sprint's iOS 27 simulators wouldn't boot under Xcode 27.2 on my machine, so its simulator checks ran on iOS 26.5.
Writing down my judgment had helped the agents produce and integrate a substantial batch of work. Now I had to decide whether the evidence was good enough to release it. The PR count couldn't answer that.
I'll happily delegate the typing. I won't delegate accountability.
I wrote that line in Two Gates and a Night Shift about a three-agent pipeline. This sprint tested it with a dozen.
Write the kickoff the way you'd onboard a tech lead
The idea started with a post from Miguel Rios that my friend Dan sent me. I turned it into a kickoff document beside the three app repos and asked Claude Code to begin with planning, then stop at the checkpoint. The document reads like the onboarding notes I'd hand a new tech lead on day one.
It names roles first. The lead plans, briefs, staffs, answers escalations, reviews PRs, and keeps the board. Engineers commit, push their branches, and open PRs. For this sprint, nobody merged except me. An engineer here is a Claude Code session with a brief and a ticket. One of the eleven workers only summarized the sprint's records.
Then it sets the mechanics for parallel work. The rule was a separate git worktree and branch for each coding engineer. A file-ownership map said which engineer could change each shared file. Questions about contracts, data safety, or ownership went into a question file for the lead, while the engineer moved to independent work or waited. I ran the panes in herdr, which marks a waiting agent as blocked.
If I could keep one line from the kickoff, it's this: every blank you leave empty becomes a guess. Each engineer starts without the lead's conversation history. It can read the repository and its instructions, but it cannot recover the decisions I never recorded. An agent can fill that gap with a plausible answer and keep going. That's why a brief needs the goal as user-visible behavior, testable acceptance criteria, and exact verification commands. It also needs the files the engineer owns, the files it must not touch, and when to ask for help.
Staff by the cost of a mistake
The kickoff maps three levels to three models. Staff agents on Opus 5.5 take contracts, sync, data migrations, architecture, hard bugs, and reviews. Senior agents on Sonnet 5.5 build features against an approved contract. Junior agents on Haiku 5.5 take mechanical work with a clear check, plus reporting.
Those titles are routing shorthand. They tell the lead what work to assign and what review it needs; they don't establish that a model has the judgment of a human staff engineer.
The rule for junior coding agents was especially narrow: no schema, sync, or auth changes, and no implementation task whose result we couldn't check deterministically. For work where a mistake could lose someone's tasks, I used the more capable model and another reviewer. The price of the model follows the price of being wrong.
I didn't track token usage or cost, so I can't tell you what the morning cost or whether this was the most economical staffing. Sprint 2 will measure both.
Read the morning like a benchmark score
In The Frame Is the Bottleneck, I borrowed Dan Shipper's term “smuggled intelligence”: the human judgment packed into the task before the model begins. It's easy to credit the resulting score entirely to the model and overlook that preparation.
My morning deserves the same scrutiny. I wrote the kickoff with Claude. Claude did most of the mechanical drafting; I guided what went in and what each rule said. I estimate three to four hours of my time went into the kickoff, plan review, and escalated decisions.
The agents also started with mature repositories, existing tests, and an earlier parity review. The Android Saved branch already had 17 commits waiting to be integrated. Those changes are part of the 64 merged PRs. The planned two-week window wasn't a measured human baseline, and the first-PR-to-last-merge clock leaves out preparation.
This was a productive morning. It doesn't tell me how much of the result came from the models versus the structure around them. It does leave a record of that structure that I can inspect and improve. In the earlier post, I called the versioned specification that carries judgment with the work a Context Spine. The kickoff serves a similar purpose for coordination: who owns a decision, what evidence they need, and where uncertainty goes.
Pin the contract before anyone builds against it
Parity work across three codebases has a familiar failure mode. Each platform implements its own reading of a rule, and a task synced from the web behaves differently on Android. Shared contracts and fixtures give each implementation the same examples and expected results.
The sprint ended with 352 corpus cases. Of those, 155 were exercised by all three clients: 117 for due time of day and 38 for escalation by due date. The remaining 197 cover the top-three view and weekly sweep planned for sprint 2. The lead's check of 74 fixture copies across repos and worktrees found no mismatches.
The sequencing was less clean than the principle. The merge order said the due-time corpus had to land first, and I merged the web implementation a minute ahead of it. Some work also used stacked branches. Those dependencies can be legitimate, but each engineer still needs to know which contract version governs the work. “Contracts first” needs an explicit dependency and verification plan when the PRs land in a different order.
The line counts need the same care. Of 25,882 added lines, the lead classified 13,714 as corpus and fixture data, including copies across repos, and 3,817 as app code. Another 7,166 were tests. That explains the size of the diff; it doesn't establish the value or correctness of the work. The evening review would find bugs those tests missed.
Coordination ran through the lead. In The Agent Team Tax, I found that peer discussion earned its cost when the work needed real disagreement. Here, much of the implementation could proceed independently against shared rules. Review was where I wanted those rules challenged, especially when one platform was being treated as the reference for another.
Parity work finds bugs no single platform shows you
I expected a feature sprint. Classified by PR title, the mix came back even: 24 features, 24 fixes, eight tests, and eight docs or chores. On iOS, fixes outnumbered features 14 to seven.
The worst discovery was in Android 0.10.0. A task created between two database reads could be deleted with no copy in Trash. The lead reproduced it against a fake store, and the fix was included in 0.10.1. On iOS and the web, a rejected sign-in token could make a task listing look like every remote task had been deleted. The fixes confirm the session before deletion reconciliation removes local tasks. On the web, quiet hours had been dropping timed reminders instead of deferring them.
The kickoff's rule for a suspect reference implementation mattered here: if it looks like a bug, escalate it before porting it.
Engineers sent the lead 20 questions, and every question got an answer. The iOS staff agent challenged a brief that would have removed a protection iOS already had. The same note identified the missing identity check that became iOS #45. The Android staff agent stopped before changing the spec, calling it “a data-integrity call.” That question led to the saved_at investigation that opens sprint 2.
The useful behavior was the willingness to challenge the assignment. I had made room for that in the instructions, and the record shows agents using it. Helping an agent succeed includes giving it a way to tell me the brief is wrong.
The lead made mistakes, and the record shows them
The closing report has a section called “Where the sprint slipped.” The web main branch went red twice. Two sync PRs interacted badly in a test, and a follow-up fixed the mock. Later, the edit-drawer snooze PR broke an end-to-end selector. The lead acknowledged missing it in review. I merged the changes, so the miss belongs to me too.
One iOS commit landed on a branch after its parent PR merged and had no PR until the lead found it while closing out. The lead also recorded five calls it later reversed. One told the iOS engineer to match the web on every path, when native queued writes needed different treatment.
The setup itself had an exception I needed to account for. The plan said coding engineers should work in separate worktrees, but the launcher explicitly put the Android staff agent in the main checkout on the existing Saved branch. The written rule and the mechanism starting the agent disagreed.
The board, decision log, and closing report made these problems visible. A sprint without that record would have looked cleaner and deserved less trust.
The constraint moved to my side of the merge
Two hours and eight minutes separate my first merge from my last. The lead's report starts with the first PR opened, at 8:40, making its window two hours and 58 minutes. I merged mostly in batches as reviews finished.
On the web repo, SonarQube Cloud runs a quality gate and Codex provides code and security reviews. The iOS and Android repos had no CI at all, so their evidence was each author's local test runs. PR #650, which adds Android share-sheet support to the installed web app, shows why their results still need a decision.
SonarQube passed it with 96.6 percent coverage on new code. Codex flagged a P2: when a share carried both a title and a plain-text body, the body was dropped. The lead's review cleared the PR after a documentation change, and another automated review reported no issues. I merged it in a batch anyway. The review layer caught it, and I merged past it.
The coverage number was accurate. So was the finding. Executing the code in a test hadn't established that it preserved the information a user shared.
In Two Gates and a Night Shift, I put human judgment at plan approval and release approval. This sprint also had a contract checkpoint and my manual merge decisions. By lunch, the release decision was still ahead of me.
That evening, I had an agent review deployment readiness against all three main branches, with a separate adversarial code review. The reported automated suites passed: 4,059 web tests, 312 Swift package tests, and 466 Android JVM tests plus 339 emulator tests. The verdict was still “not ready to deploy as a whole.”
On iOS, the new Complete and Snooze reminder actions failed while the app's database was suspended. A partially failed account deletion could also let the next sync remove local tasks, a bug older than the sprint. On the web, snooze presets could lose reminders. Android received a conditional go, pending my real-device smoke test. Fixes for the three bugs later merged as web #662 and iOS #62. Those merges still weren't releases.
Merged PRs are output. The outcomes that matter start when a user's task survives a sync on someone's phone.
The sprint had explicitly excluded deployment and store uploads. At its close, the remaining work included a real Android sign-in, a throwaway account, a Mac trackpad, a real notification, an iPad keyboard, and four owner decisions. Completing the implementation had made that work the critical path.
In a larger organization, those responsibilities may sit with device labs, release engineering, product owners, and the people accountable for a sync change. Some of that work can be automated too. The lesson I take from this run is to plan verification and release capacity alongside implementation capacity. Otherwise, a faster build can leave a larger queue waiting for acceptance.
I'd written before about judgment moving upstream into the frame. This sprint made the other end just as visible: deciding what evidence is enough to accept the result. Both decisions need an owner, even when an agent makes the call.
What the next kickoff needs
For sprint 2, I'm giving agents broader discretion over merges. They will weigh the reviews and make the merge decisions. I'll still approve the release, and accountability stays with me.
That's an experiment whose result I still have to measure. I merged past a useful finding; the lead and another automated reviewer failed to act on it too. An agent making the merge decision can repeat that mistake.
I want the next record to show what happened to meaningful findings: fixed, rejected with a reason, or escalated. PR #650 is a concrete case to evaluate. A warning that shared text will disappear deserves a resolution before the change lands. I expect review to take more time, and I'll judge the result by unresolved findings, rework, and readiness for release as well as throughput.
One more fix is mine to make. The lead posted its reviews from my GitHub account, so its comments show my name over an agent's judgment. That's the problem I wrote about in The Agent Is Wearing Your Badge, and I'm addressing it in sprint 2.
The records point to three other changes: account for every branch with unmerged commits, stop subsequent merge batches while main is red, and give the lead a readable copy of the backlog. This time, the backlog lived in a Claude Project the sprint couldn't access, so the lead worked from the plan and PR descriptions. The worktree exception and contract sequencing need the same attention: the tools should carry out the rules I write down.
Sprint 2 starts with a bug this one found. On the web and iOS, an upgrade can clear a task's saved_at timestamp and lose its Saved placement, while leaving its content intact. The lead reproduced that against a fake server; exposure in real use remains unmeasured. The share bug from #650 is on the backlog too.
First, though, the Android build in Google Play testing needs time on real phones.
