← Back to Blog

From 8 Steps to 5: How We Replaced Our Build Pipeline

The Uno to CC Worker migration story

Last week our build pipeline had 8 moving parts across 4 services. Today it has 5 steps and one service. Here's how we got there.

The Old Way

Our original pipeline used Uno (a Slack bot) to receive build requests, Viva (a Kubernetes worker) to execute code generation with OpenCode CLI, and Gemini to architect the prompts. It worked. Apps got built. But the chain was fragile.

The Gemini architect would sometimes corrupt git URLs into gitpython. The sanitizer would sometimes strip valid dependencies. The verifier would flag false positives. Each layer added ~30 seconds and a 5% failure rate.

Multiply that across 8 steps and your end-to-end success rate drops to ~66%.

The New Way

We built CC Worker — a lightweight agent that runs on a VM, picks up tasks from a queue, and executes them with Claude.

The entire pipeline:

  1. API call creates a task with an instruction
  2. CC Worker picks it up, clones the golden template
  3. Claude reads the CLAUDE.md rules and transforms the app
  4. Git push to GitHub
  5. Coolify auto-deploys

No architect. No sanitizer. No verifier. No watchdog. Claude follows the rules file and gets it right the first time.

The Results

We ran three experiments:

  • Fresh scaffold: 2 minutes 45 seconds. Zero bugs. All rules followed.
  • Fork-transform: 13 files modified. Auth and billing preserved perfectly.
  • Full pipeline (API to live URL): 15 files. Deployed to production. Working.

The success rate went from ~66% to effectively 100% across our test runs.

Why It Worked

The key insight: a good rules file (CLAUDE.md) replaces multiple validation layers. Instead of building systems to catch and fix AI mistakes, we wrote clear instructions that prevent the mistakes in the first place.

Less code. Fewer services. Better results.

Ready to build?

$25K fixed. One week. You own the code.

Get Started →