AI Agent Coding & Development Case Hub: Verified-Source Records on Docs, Migrations, Builds, and Parallel Agents

Data basis and how to read this page. This domain holds 345 published cases (site statistics, 2026-11-09). This page draws only on 10 of them that we read line by line and re-checked for source accessibility (10/10 reachable, verified 2026-11-09). Every figure here is source-reported; this site has independently re-tested none of them. Re-check the original source before citing any number.

Who this page is for, and what it promises. For engineers and technical leads evaluating whether to hand development work to AI agents. After this page you can state: which development task types have publicly traceable records, where humans stand in each (the five-bucket model: setup / preparation / oversight / review / exception handling), who vouches for each disclosed number, and under what conditions these attempts fail.

Task map

Six task types with verified examples (each with its boundary):

1. Documentation generation & upkeep — engineering discussions → doc drafts → human review of every page. Boundary: conceptual errors need a domain expert as the safety net; line-count metrics are the easiest to inflate.
   • Examples: Fern writer workflow (~20k new doc lines/mo across ~500 pages, self-reported, not single-tool attributable); Aspire cross-repo docs PRs (396 runs, 82 merged PRs in a rolling 30-day window, vendor-reported).
   • Deep dive: our task guide How AI assists technical documentation — a single-workflow read with evidence boundaries; this hub does not repeat it.
2. Large-scale migration & upgrades — legacy stacks, framework/language/database moves across batches of services. Boundary: "zero bugs" is usually a handoff-time state, not a production conclusion; total time and cost often go undisclosed.
   • Examples: Solo legacy migration (95%+ API coverage at QA handoff, self-reported); Brex 180 microservices (~90% lower cost per service, company engineering blog).
3. Small-scope fixes & PRs — well-defined single defects. Boundary: complex full-stack tasks were still rewritten by humans; don't extrapolate "5 minutes per small task" to all tasks.
   • Example: RunLLM delegating minor fixes to Devin (~5 min human testing per small task; complex tasks failed and were rewritten).
4. Greenfield builds & scaffolding — new services, full-stack project setup. Boundary: environment/dependency setup is the most common stall; vague prompts cause irreversible deletions.
   • Examples: Copilot agent mode full-stack (all models initially failed on React/Tailwind v4/ShadCN setup); Cursor scaffolding Terraform/k8s/CI (spec-compliant, but a vague "cleanup" prompt deleted 14 files).
5. Parallel agents & long runs — multi-session/multi-container division of labor. Boundary: coordination cost is underestimated; research prototypes are not production designs.
   • Examples: 16 agents building a C compiler (2,000 sessions, $20k API, 100k lines; author is an Anthropic researcher); [10 parallel Claude sessions](/cases/bcce5845-b8c2-81ce-4273-dbcbb536bb20/en) (index-transcribed, unverified).
6. Low-level & kernel patches — performance-sensitive system code. Boundary: press coverage ≠ merged fact; a branch-only patch is not production-validated.
   • Example: Claude Code drafting a Linux kernel patch (branch only; merge into the window unconfirmed).

For all 345 records (mostly not line-checked by us), browse the full catalog by category.

Comparison table

Cross-case conclusions

1. Every quantified result is source-reported; we have re-run none of them. 10/10. Check the original before citing a number.
2. Human involvement concentrates in setup and review; zero hands-off success stories in this sample. Even the closest case (Aspire) makes per-PR human approval mandatory.
3. The same specific failure patterns recur: environment/dependency setup stalls, vague prompts causing deletions, concept errors needing domain experts.
4. Demo ≠ production. The kernel patch is branch-only; the C compiler's author calls it a research prototype; "zero bugs at QA handoff" is a point-in-time state.
5. Numbers don't attribute cleanly to tools. Fern's ~20k lines can't be credited to one tool; team gains usually change process and tools at once.

Verify it yourself

1. Open any case in the table and click its original source: confirm it is reachable, note the measurement window (e.g., May 3 – June 2, 2026), and check who the author is.
2. Read the evidence label on the case page: treat "vendor self-report" as promotional, and for "index-transcribed" entries, re-check against the original.
3. Compare each case-page figure against the original source, watching the units — a "44.8-hour median time-to-merge" is not generation time; "~20k lines a month" is not one tool's output.
4. Run the case page's "try it" prompt in your own environment for two weeks and record your own error rates and human hours instead of quoting someone else's savings.
5. Revisit this table as a reminder: this site has re-tested no numbers; replace every figure with your own pilot data before deciding.

Next steps

• Start small: pick small-scope fixes or docs-PR automation (clear boundaries, cheap rollback), run a two-week pilot with the case page's "try it," and log your own error rates.
• Go deeper on documentation: read the task guide How AI assists technical documentation (a Fern-based, single-workflow deep dive).
• Keep exploring: browse the full catalog under "Software & development" for all 345 records (mostly not line-checked by us).
• After you try: share your practice and numbers via the submission form on the homepage, noting the source and how humans stayed involved.