Pre-launch — Gluecron is in final validation. Public signups and git hosting for non-owner users open after launch review.

We shipped 30 features in one session

AI-parallel development: how we used multi-agent Claude to ship workflow cache SAVE, OCI registry, Redis SSE fan-out, pack-content ruleset enforcement, and 25 other features simultaneously. Here's the architecture.

The standard model of software development is sequential: one engineer, one feature, one PR at a time. Even with a full team, coordination overhead keeps the actual work from flowing freely. On June 1, 2026, we ran an experiment — a single Claude Code session, multiple agents, 30 features in parallel.

The setup

We used Claude Code's multi-agent mode: one orchestrator agent that decomposed the feature list into independent work trees, and one agent per feature that executed inside a dedicated git worktree. Each worktree shared the same Neon database schema but had its own branch, so merge conflicts were impossible at the file level.

The orchestrator scheduled agents by dependency order — features that touched schema.ts ran first in isolation, then all independent features ran in parallel across 28 worktrees simultaneously. Total wall-clock time: 47 minutes.

What shipped

The headline features from that session were:

  • Workflow cache SAVE / RESTORE — .gluecron/workflows/ YAML now accepts a cache: key that persists node_modules or any directory across runs. Average CI time dropped 62% on our own repo.
  • OCI container registry — docker push gluecron.com/owner/repo:tag now works. Blobs stored on the same Fly volume as git objects. Auth via PAT with registry scope.
  • Redis SSE fan-out — live-events now fan out through Redis Pub/Sub so horizontal scale works without sticky sessions. Every SSE topic (platform:deploys, pr:live, etc.) propagates across all instances.
  • Pack-content ruleset enforcement — rulesets now include a max_file_size rule enforced at the pack-objects layer, not just at commit time. A 400 MB model checkpoint can't land even in a force-push.

The other 26 features were smaller — bug fixes, missing API fields, UI polish — but they shipped atomically alongside the big four in a single batch merge.

What we learned

The hardest part wasn't the agents — it was the review. Thirty PRs landed simultaneously. We needed a merge queue that could serialize them safely, and our own GateTest gate to catch the handful of integration bugs that individual worktrees couldn't see. Both held up perfectly.

The conclusion: the bottleneck in software is no longer writing code. It's reviewing code, and deciding which features are worth building. Everything else is execution, and execution is now parallelizable.