Skip to main content

Enterprise demo: Claude plans, AIFactory builds

One developer + Claude → a multi-issue epic shipped end-to-end while you watch.

This page captures the enterprise pitch for AIFactory in one continuous run. There are no cuts and no edits — the asciinema and browser recordings below were taken in a single take against the public olafkfreund/aifactory-demo repo.

The pitch in 30 seconds​

In a traditional workflow a senior engineer would spend their morning:

  1. Designing an epic
  2. Breaking it into actionable GitHub issues
  3. Writing the code for each one
  4. Reviewing the result

In the AIFactory workflow that same engineer:

  1. Opens Claude Code in their terminal: "Draft an epic for X with 3 sub-issues against the repo"
  2. AIFactory's Auto-Fix toggle picks up the new issues from GitHub automatically (every 5 minutes, or one-click)
  3. A planner / coder / QA agent runs on each issue in its own isolated git worktree
  4. Three PRs land while the engineer is in their next meeting
  5. They review the PRs at the end of the day

What you're watching​

The two recordings below run in parallel — same demo, two angles.

The terminal side​

The developer asks Claude to draft 3 issues. Claude calls gh issue create × 3. The AIFactory poll endpoint picks them up; the script then polls task status until all three agents finish.

Loading recording…

The portal side​

A walkthrough of the same lifecycle from the operator's seat: the kanban with the three canonical demo tasks in Human Review, creating a new task via + Task (description filled, mode selected, submitted) and watching the card land in Backlog, then jumping into the completed task to tour Subtasks (3 of 3 green ✓) and Logs — the artifacts every autonomous run leaves behind for review.

How the auto-takeover works​

The "AIFactory takes over automatically" beat is the Auto-Fix toggle in each project's GitHub Issues view (or any provider — it also works with GitLab and Azure DevOps). When enabled:

  • The frontend polls POST /api/projects/{id}/auto-fix/check-new every 5 minutes
  • The backend calls the project's configured provider, fetches open issues, diffs against existing .aifactory/specs/ directories
  • Each new issue → spec dir → agent run in an isolated worktree
  • A WebSocket event broadcasts so the UI updates live

In production, the same flow is also exposed as a webhook receiver (POST /api/webhooks/{provider}) so polling isn't required. For the demo we use the polling path because it doesn't need the portal to be reachable from the internet.

Reproduce these recordings​

The two recordings on this page are produced by independent scripts so each can be re-shot without affecting the other.

Prerequisites:

  • The portal running locally (apps/web-server + apps/frontend-web per the Getting Started guide)
  • A Claude OAuth token in apps/backend/.env
  • asciinema + ffmpeg on PATH
  • git clone https://github.com/olafkfreund/aifactory-demo /tmp/aifactory-demo and the repo registered as an AIFactory project
  • An existing completed run for the demo task (the narrator script reads its real artifacts — spec.md, implementation_plan.json, build-progress.txt, qa_report.md)
# Terminal cast — narrates over the completed task's real artifacts.
asciinema rec --overwrite --idle-time-limit 2 \
  --command "bash $(pwd)/scripts/record-handover-demo.sh" \
  docs/static/recordings/handover-workflow.cast

# Browser walkthrough — drives the live portal via Playwright.
node_modules/.bin/tsx scripts/record-portal-walkthrough.ts
# (then ffmpeg-trim/crop the resulting webm into the .mp4 under docs/static/recordings/)

Honest caveats​

  • The agents take real time — typically 5-15 minutes per issue with Claude Sonnet for the coding phase. Asciinema's --idle-time-limit=2 compresses the wait in playback to roughly 3-5 minutes total.
  • The recording captures real LLM output. The code in the resulting PRs is what Claude actually produced on the day of recording — not curated. If you watch closely you can see the planner asking clarifying questions in requirements.json before writing the spec.
  • The demo repo is intentionally tiny so each agent run is bounded. For real enterprise use, the same flow scales to repos of any size; the planner's complexity assessor adapts the pipeline length per task.