The first build plan for Tabwar estimated work in developer-days. Foundation work: two to three days. The daily workflow: four to six. Hardening and beta: another four to six. The workspace engine needed more investigation before it could be estimated.
Then I asked for a different kind of sprint plan: only AI agents would build Tabwar, and a sprint would be the work one Claude or Codex session could finish within a five-hour usage window.
That changes the questions the plan needs to answer. What can an agent finish and verify in one session? What context does the next session need? Which parts must wait for me?
A smaller unit of planning
For this experiment, a sprint is one bounded agent session. It does not mean five hours of uninterrupted coding. Investigation, tests, failed attempts, documentation and review preparation all have to fit around the implementation.
The assistant proposed ten sequential sprints for the remaining candidate work. Persistence and recoverable switching come first, followed by autosave, recovery, workspace controls, search, tab operations, accessibility and beta preparation.
Those ten windows are an estimate to test. They do not establish a delivery date. Even the earlier developer-day estimate had already needed correction when I rejected separate browser windows and required workspace switching inside the same window. Changing the planning unit does not remove uncertainty about the work itself.
There is one early calibration point: the builder recorded roughly an hour and a half to investigate and fix the first tab-loss bug and a related redirect problem, including tests and documentation. That is useful evidence about one session. It is too little evidence to predict every remaining feature.
The proposed plan calls for re-estimating after the first two sprints. That gives the estimates somewhere concrete to meet the results.
One agent at a time
I chose to run one agent at a time. The assistant recommended this because much of the remaining work touches the same workspace engine and interface files. Parallel sessions could spend their time reconciling changes to those shared files.
The sequence still needs continuity. Each proposed sprint includes a factual journal entry and an updated project state, so the next agent can read what changed, what passed and what remains uncertain.
The assistant also proposed a branch and pull request for each sprint. The alpha had been committed directly to the main branch. A reviewable change per sprint would give me a concrete point to inspect the result before the next slice begins. That process is still a proposal in the plan.
My part appears in the dependencies
The plan identifies three checkpoints that require me.
First, I need to confirm the tab-loss fix in my own Chrome. Automated regression tests are recorded as passing, but that does not establish that my original browsing session was recovered or that I have verified the updated extension.
Second, I need to decide unresolved product behavior: how workspaces belong to windows, how new tabs are adopted, which tabs are protected, and where a restored snapshot should go. The layout question from my first use also remains open. The proposed first sprint includes a decision brief to put those choices in front of me.
Third, the beta needs manual checks in stable Chrome on macOS and Windows.
These checkpoints make my work visible beside the implementation work. Another agent session can produce options, code or test evidence. It cannot supply my confirmation that the behavior fits what I want to build.
Requests do not automatically become scope
After trying the alpha, I asked for favicons, a visible theme switch, a way to move individual tabs, and selection for bulk actions.
When asked what the sprint plan should cover, I chose the open issues already marked as first-version candidates. The newly recorded enhancement issues stayed outside that plan pending a scope decision. Some underlying tab operations already overlap the existing backlog; that does not make every detail of the new requests approved.
The proposed completion criteria also include tests, passing CI, documentation and a reviewable result. Producing a screen or finishing a coding prompt would not, by itself, complete a sprint under those rules.
There is now a plan written around the sessions I intend to use, with explicit places where I need to review, decide and test. The next evidence will come from running it: what fits, what carries over, and whether the handoff leaves the next session able to continue.
