Challenge
A replacement the team would choose
We were paying more than $40,000 a year for Sessionboard while using only part of it. The challenge asked whether builders could produce an open-source replacement our conference team would actually choose to run. A deployed app and independent operator review gave the exercise a concrete customer and a practical finish line.
Supporting source · Pair with motivation
Challenge
One speaker, six connected workflows
A speaker submits a proposal, gets reviewed, joins the right portal, supplies deliverables, receives reminders and appears on a schedule. Each screen can look plausible while the handoffs fail. A useful evaluation follows the same person through those transitions and includes invited and sponsor speakers who never submitted a CFP.
Supporting source · Pair with scope
Trackstage
Make the repo carry project memory
Trackstage separated standing rules, design decisions and the build log into different files. Its specification and prompt archive gave later agents a way to recover the project’s context. This is a concrete practice to borrow for long builds: record what the product needs, what the team chose, and what actually happened, so the next session can resume useful work.
Supporting source · Pair with M02
Trackstage
More agents required isolated test state
Marko’s process account describes workers resetting a shared development deployment every 30–60 seconds and invalidating one another’s tests. The repo added an independently seeded local Convex backend in CI; later changes split the flow suite across four isolated backends. Parallel implementation made environment design part of the coding problem.
Supporting source · Pair with M02
Trackstage
The bug appeared after recipient 25
Trackstage could send the first batch of 25 emails and leave the rest waiting until an unrelated send restarted delivery. The repair schedules another delivery whenever the batch reaches its cap. A demo with a handful of recipients could miss this. The reusable test idea is simple: exercise the transition just beyond a batch limit.
Supporting source · Pair with V05
Trackstage
A passing check compared the wrong thing
The production API reference pointed its interactive client at a development server. Marko’s process account explains that the drift check compared the URL against itself. The review fix illustrates a trap for agent-built verification: a green check is only useful if its comparison can distinguish the correct behavior from the incorrect behavior.
Supporting source · Pair with M04
OpenRostrum
Give shared files an integration owner
OpenRostrum assigned schema, migrations, dependencies and shared UI primitives to an integration owner. A hook prevented ordinary feature worktrees from committing those files without an override. Workers also had separate D1/R2 state. This makes concurrent work more concrete than asking agents to coordinate: the repo defines who can change common foundations.
Supporting source · Pair with V03
OpenRostrum
A feature can exist and still miss the job
OpenRostrum’s scenario register describes a rule system that could use custom fields but could not express built-in triggers such as Track or Format. Its account says the design survived three review rounds. Walking through actual scenarios exposed the missing representation. A feature checklist should be followed by specific examples of the decisions users need to express.
Supporting source · Pair with V05
OpenRostrum
Save each review finding as it arrives
Reviewers originally returned all findings in one final JSON response. If that response was truncated, the whole review could become unusable. OpenRostrum changed the protocol to store each validated finding through submit_finding, then signal completion separately. A failed run can retain useful work without pretending that the required review finished.
Supporting source · Pair with V06
OpenRostrum
Reviewers also need a way to stop
A later change reports four of five reviewers exhausting their turn budgets on a 25-file PR after storing findings. The harness restricted closing turns to the completion tool and logged a forced close distinctly. This is a useful agent-system design detail: stopping the process and completing the review are different events.
Supporting source · Pair with V06
OpenRostrum
Reuse the guardrails across projects
Valentin confirmed that Thytu/agent-rules is the template discussed in his interview. His Harness Engineering 101 article organizes the work into Prepare, Do and Review: give agents product context, enforce checkable rules, verify smaller chunks and review the result. The confirmation identifies the template; it does not prove that every current file existed during the competition build.
Supporting source · Pair with V06
Conferencer
Crawl the help site before writing the spec
Yazin describes converting the brief to Markdown, using Firecrawl to gather help material and related product information, and turning that research into a feature list and specification. The useful tip is to look beyond the landing page. Help articles explain the states, exceptions and vocabulary that a convincing screenshot does not reveal.
Supporting source · Pair with Y02
Conferencer
The first build was followed by a 45-page UX sweep
Conferencer’s August 11 history records a 45-page UX sweep using a screenshot harness and critic/implementer agents. A shared design document specified tokens, layout families and component conventions. The repo adds an important second act to the self-reported 4.5-hour implementation run: deliberate review and product editing followed the first build.
Supporting source · Pair with Y03
Conferencer
Product polish had observable failure modes
Conferencer’s fixes include a menu hidden behind sticky navigation, a status selector snapping back, nested forms breaking hydration and sign-out redirecting to an internal host. These are small interactions with large consequences for usability. They are stronger examples of product editing than an abstract instruction to improve the UI.
Supporting source · Pair with Y03
Conferencer
Put outstanding deliverables on one page
Kelsey singled out the ability to see deliverable statuses together, without opening each individual form. That is a useful way to explain product taste: understand the comparison an organizer keeps making, then arrange the information so they can make it in one place. The current app capture illustrates the matrix; the interview describes the reviewed experience.
Supporting source · Pair with Y04
Wider applicants
Turn screenshots into testable specifications
Bodo’s submission describes turning 42 screenshots into screen-by-screen specifications covering controls, labels, defaults and acceptance criteria. That is a practical middle step between collecting reference images and starting implementation. It turns visual inspiration into specific expectations that another worker or reviewer can inspect.
Supporting source · Pair with V03
Wider applicants
Research the domain before splitting features
Sessionbored’s account describes four research spikes and a 29-table data model before feature work. It then split work into three worktree lanes after establishing the shared foundation. This is a useful organizer question for future challenges: what did the builder decide centrally before allowing agents to work independently?
Supporting source · Pair with V03
Wider applicants
A worker needs more than a Git branch
Opensesh assigned each worker a branch, database, port and environment file, with one agent merging the results. Its account also describes walking the deployed app and dictating findings in batches. The build combined parallel coding with integration and operator feedback; the independent environment was part of the worker assignment.
Supporting source · Pair with Y03
Numbers
Most builders mixed tools
Among the other 66 reviewed records, 48 selected more than one coding tool and 40 selected both Claude Code and Codex. Fifty-nine selected more than one model family. These are overlapping reports of use. They describe how participants assembled their workflows, but cannot establish market share by spend, tokens, time or effectiveness.
Supporting source · Pair with tools
Numbers
Billions of tokens often meant rereading context
Three detailed heavy-build reports attribute roughly 97–98.5% of processed token volume to cached context reads. Programflow reports 14.8 billion processed tokens with about 19.2 million output tokens. The scale is striking, but the accounting matters: a cached input token and a newly generated output token are different kinds of work and can have very different prices.
Supporting source · Pair with M02
Numbers
Keep subscription bills separate from API-equivalent value
Trackstage reports $600 in nominal subscription charges and roughly $4,000 in API-equivalent usage. Those are two accounting views, not two interchangeable spending totals. OpenRostrum reports more than two billion tokens without a usable cash figure; Conferencer’s response gives 750 without an explicit unit. A useful comparison preserves those gaps.
Supporting source · Pair with M02
Numbers
Large codebases do not establish product quality
The snapshot count covered 53 public repositories and 55 of the 72 raw records, totaling 6.26 million source lines with a median of 91,427. Counts include recognized scripts, markup, styles and tests, with standard dependency/build exclusions. This illustrates project scale. Current default-branch snapshots can include later work, and line counts cannot rank the products.
Supporting source · Pair with M06
OpenRostrum
Use five minutes as a concrete user journey
Valentin describes putting himself in the organizer’s shoes for a short product walkthrough, then tracing rough spots back to missing context or insufficient research. His onboarding example asks what makes a good path before rerunning the build process. The method includes human inspection, even when the intended repair is an improvement to the agent workflow.
Supporting source · Pair with V05