Case Studies
GDD applied to real work — recent, concrete, and messier than a tutorial. See also the roadmap for potential upcoming arcs serving a specific story.
Three efforts are written up at length:
- Reviewing a contributor's PR — GDD v1.0 — a full session from the week of the 1.0 release: an outside contributor's bug fix reviewed, an engine root cause found underneath it, fixes proposed back, and an issue filed — conducted almost entirely from a phone, one-handed, around childcare. The clearest picture of what the finished system feels like in use.
- A five-year-old disabled test — a deep engine bug: two defects stacked three years apart, the older one hidden behind a test left
@Disabledin the same commit that introduced it. Written as highlights rather than a transcript, and it does not spare the agent — one of its neater explanations turned out to be invented. - Early GDD — the first sessions — condensed transcripts and Thalamus files from GDD's first two sessions ever, back in March: dialogue and decisions as captured, technical detail stubbed. They predate most of today's system, so read them as origin material rather than current mechanics.
The early sessions are GDD being built, the v1.0 study is GDD being used on a different codebase without the human using a desk much, and the deep-bug study is what the pairing looks like when the problem is genuinely hard.
Reviewing a contributor's PR, from a phone
A contributor opened a bug fix on a Terasology module and asked for review. Over a few hours — spent mostly on childcare, with a toddler on lap and later from a phone — the reviewer used an agent to bring a months-old workspace current, checked out the PR, verified the fix against the engine source, ran the game, and found that the bug the PR patched at module level had an engine-level root cause the PR didn't cover. It turned out to be the same root cause as a second, apparently unrelated PR. Fixes went back to both branches as PRs from forks, one leftover finding became an issue, and the contributor merged.
Full writeup: Reviewing a contributor's PR — GDD v1.0.
What it shows: the found-time thesis at full stretch. Also the trust boundaries holding under pressure — the agent's token deliberately lacked push access to the upstream orgs, and the fork-and-PR path was the correct answer rather than an obstacle.
A five-year-old disabled test
Every module integration test in a 15-year-old game engine was failing to attribute classes to their modules. Four rounds across two days found two independent defects stacked on each other — one introduced with a Gestalt upgrade in 2024, one latent since 2021 whose verifying test had been left @Disabled in the very commit that introduced it. That test is now implemented and passing, five years and three months later.
Full writeup: A five-year-old disabled test — GDD on a deep bug.
What it shows: the pairing on a genuinely hard problem, honestly accounted. The agent supplied stamina and made several real mistakes — including confidently explaining a mechanism it had not verified, caught only because writing it up meant checking it. The human supplied three sentences of half-remembered institutional knowledge that redirected the search, and the judgment to ask whether the tidy story was true.
Local political site for a non-technical owner
A local town-council candidate's campaign site was built by a third party as a compiled single-page app, but it had an assortment of bugs, and the owner couldn't change a word of it himself.
Over one GDD session the site was rebuilt fresh as a gh-pages component — the same Jekyll scaffold the Getting Started tutorial uses. Content was recovered faithfully, with several look-and-feel passes reviewed live by a human. The result deployed straight through the standard GDD loop — topic branch, PR, bot review, merge, live — and now carries per-page "edit on GitHub" links plus a maintainer guide, so the owner can keep it current by asking an agent or using the GitHub web editor.
The maintenance loop has since been proven for real: the owner sent a Word document revising his entire policy platform, and the agent read it, applied the restructuring site-wide over several human-reviewed passes, and shipped it to production. As of v1.1 the loop runs over chat — a sandboxed agent takes requests by direct message, images included, and answers with a reviewed pull request carrying a live preview and before/after screenshots, so "ship it" is an informed thing to say from a phone.
What it shows: the tutorial path is a real production path; GDD's independence story (your content, your repo, your agent) applies to people who don't consider themselves technical; and a fresh-machine dogfood run surfaces onboarding friction that flows straight back into the framework as fixes.
Three workspaces, two days
Three parallel GDD workspaces, worked in alternation across two days: a community-feedback site for a local school district (QR codes, online surveys, results — ~5.5k LOC), a work skill helping newer engineers operate releases for services following a specific GitOps pattern (~3k LOC), and an arc on GDD itself (a hook rejecting opaque shell composition, plus related utility and safety work — ~3k LOC). Every piece went through design docs, bot review, and testing; the per-machine Thalamus files and arcs kept each workspace's state recoverable whenever attention rotated back to it.
What it shows: the methodology's answer to context-switching. Arcs and the Thalamus make it cheap to drop a thread mid-flight and pick it up days later, even on a different system — which is exactly the "found snippets of time" reality the framework was designed around.
A greenfield platform component, end to end
A new Backstage-based developer portal component went from idea to merged across a handful of sessions on different machines: brainstorm → design and plan docs (reviewed as their own CRs) → BDD scenarios written before the code → a scaffolded app hardened test-first → live end-to-end validation against a homelab cluster → several rounds of CodeRabbit and Copilot review → merged with the component registered into the community realm. The cross-host arc (same slug in each machine's thalamus) helped visibility on which systems were involved.
What it shows: the full GDD loop on something substantial — plans as reviewable artifacts, tests before implementation, bots plus human judgment on review, and multi-machine continuity through the thalami hoard.
Maintainer attention, horizontally scaled
For the Terasology project started in 2011, a years-old dependency-injection overhaul PR — too large for any human to comfortably hold in their head — was eventually merged as "good enough" after extensive efforts, and then its review findings immediately split via agent into follow-up PRs processed over subsequent days with minimal overhead. GDD's review tooling (ws review, the triage skill) let one maintainer keep pace with a broad set of parallel PRs: processing bot findings, harvesting patterns, and filing issues in the gaps between other responsibilities.
What it shows: GDD isn't only contributor-side. It scales maintainer attention — the scarcest resource in most community projects.
Two agents, one methodology
GDD's own multi-agent groundwork was built by two different agents in two workspaces: Claude Code on one machine and Codex on another, each committing through ws commit with per-session identity so every commit's attribution names the agent that actually made it. The Codex side dogfooded the review cycle on the shared PR and surfaced real cross-harness fixes (token-injected pushes that avoid OS credential prompts, review probes that distinguish "no such PR" from "network blocked") that merged back into the workspace.
What it shows: the ws CLI and the portable layers (AGENTS.md, ws orient, skills-as-markdown) are the agent-neutral core — the roadmap's cross-harness track is an extension of something already exercised, not just a hope.
Another good example is summarized in this GDD PR comment.
Write-ups don't do the process justice when condensed. Try it yourself — Get started here — clone the workspace, turn on mentoring, and see what happens.