CI is too slow and too expensive. We're fixing it.
Kaizen CI finds what makes your pipeline slow and costly, fixes it as a pull request, and proves nothing else broke. Then it does it again, every cycle.
CI costs more every month, and gets no better.
Every provider sells the same thing: minutes. Faster minutes, pricier minutes, more of them. Nobody sells you a pipeline that needs fewer.
a month, on CI alone.
That's what we were paying Blacksmith. Not for a better pipeline: for running the same slow, wasteful one on faster machines.
Every PR waits.
Runs take long enough that engineers context-switch and agents sit idle. Coding agents open more PRs than people ever did, so the queue only grows.
The waste stays.
Flaky tests, duplicate tests, red builds nobody owns, steps that rebuild what didn't change. You pay for all of it, on every run, forever.
A one-time fix fades. A habit compounds.
Faster hardware is a single step down, and CI creeps back up as the codebase grows. The pipeline itself never gets better, because nobody's job is to keep making it better.
Faster runners
Same pipeline on quicker, pricier machines.
- Quicker jobs on day one
- Doesn't fix flaky tests or red builds
- Waste grows back with the code, and so does the bill
Kaizen CI
The pipeline itself gets better, cycle after cycle.
- Root-causes red builds and flaky tests
- Removes redundant work and tests
- Verifies every change, so gains stay
Not either-or: Kaizen works on whatever runs your jobs. Charts are illustrations, not measurements.
CI that keeps iterating with you.
Kaizen CI watches your runs, finds the bottleneck that costs the most, and sends the fix as a pull request. You review it like any other PR. Then it finds the next one.
Finds the bottleneck
Measures every run: where time and money go, which jobs fail, which tests flake, what reruns cost you.
Opens the fix as a PR
One focused change at a time: a cache, a de-flaked test, a trimmed suite, a parallelised job. Small enough to review in minutes.
Proves it, keeps it
Re-runs the affected jobs and refuses any change that makes something else slower or flakier. Gains become the new baseline.
Never stops
Runs on a schedule, on every red main, or when you ask. It modernises your stack when the numbers say it's worth it.
One cycle, one improvement.
Each cycle is small enough to review and safe enough to run on a schedule. When it ends, the next one starts from fresh numbers.
Measure
Read recent runs: pass and fail per job, step durations, jobs that failed and passed on the same commit.
Pick one
Rank candidates by engineer time and money wasted per week and take the top one.
Improve
Hand it to the matching skill: triage a failure, fix a flaky test, speed up a step, trim the tests.
Verify
Re-run the affected jobs. Nothing else may get slower or less reliable.
Record
Write down what changed and what it saved, so the gain becomes the new baseline.
What kaizen means.
Kaizen is Japanese for improvement. In practice it means continuous improvement: many small changes, made every day, that add up.
Small steps
Many small improvements over rare big overhauls. In CI: one change per cycle, small enough to review.
Measure first
Improvements start from what actually happens. In CI: every cycle starts from real run data, not a hunch.
Every day
Improvement is a habit, not a project. In CI: the loop runs on a schedule and never finishes.
Hold the gain
A better process becomes the new standard. In CI: verified changes stay, and nothing may regress.
The practice is best known from Toyota's production system, and was popularised outside Japan by Masaaki Imai's 1986 book Kaizen: The Key to Japan's Competitive Success.
Seven skills, one loop.
Open Agent Skills: markdown procedures plus deterministic scripts. Any coding agent can run them, on any model.
- 01kaizen-loopRuns one improvement cycle: measures, picks the single highest-value fix, hands it to the right skill, verifies, records.→
- 02audit-ci-runsFinds where CI time and money go across many runs: waste, red streaks, flaky jobs, queueing, hygiene. Scores CI health 0–100.→
- 03assess-build-cachingScores how well a codebase fits task-level build caching (moon, Turborepo, Nx, Bazel), estimates the speedup and plans the rollout.→
- 04triage-ci-failureTakes a failing run down to a root cause, then fixes it or files a precise report.→
- 05fix-flaky-testFinds why a test passes and fails on the same commit, and makes it deterministic.→
- 06speed-up-pipelineMakes the pipeline faster without reducing what it checks: critical path, caching, parallelism, skipping unchanged work.→
- 07reduce-test-bloatCuts redundant tests with per-test coverage, timings, test impact analysis and mutation testing.→
Imagine CI that's fast and cheap.
Today you pick one. We don't think you should have to. Read the vision →
CI that finishes in under a minute.
Every PR, every time. Fast enough that nobody, human or agent, waits on it.
CI at half the price.
Not by squeezing machines, but by not running the work that never needed to run.
Both. Under a minute, for less than you pay today.
A pipeline that gets faster and cheaper every cycle is how we get there.
Start today. Just ask your agent.
The skills work now, in any coding agent, on any repo. Point it at your CI.
- Run kaizen-loop on this repo's CI
- Audit our CI runs from the last week
- Why is this test flaky?
- Would moon make our CI faster?