Skip to content

Blog

An improvement automation needs a cap on its ambition

The Product Improver in the software-factory.dev factory files at most three issues a run, and zero when it finds nothing worthwhile.

Written by

Software Factory

Published: 12 June 2026 Updated: 2 min read

An automation that looks for ways to improve a product will always find some. That is the problem with it, not the feature.

The factory built in public at software-factory.dev has an automation called the Product Improver, and the design choice I want to walk through is the cap it puts on its own ambition.

A real review, twice a week

It runs on a cron line, 0 9 * * 1,4. Monday and Thursday, 9am, plus a manual run when wanted.

What it does is a real review, not a glance. It drives the live app in a browser, walks the main flows, and notes visual glitches, interaction friction, and accessibility gaps like icon-only buttons with no label.

Then it reads the codebase. It compares the spec against the implementation, checks components against the design doc, looks for missing loading states and test gaps. And it reads two weeks of user feedback for patterns.

From all of that it could generate a long list. It does not.

At most three issues, and zero is fine

Here is the detail worth copying. The instructions set a hard limit, in plain words. Create at most three issues per run. If fewer than three improvements are worth proposing, create fewer. If nothing meaningful is found, create zero and stop. One line says it outright: do not invent issues to fill a quota.

A second constraint sits next to it. Every proposed issue must be completable in a single pull request. Not “improve onboarding”. A specific, scoped change one builder can finish in one pass. And the proposals split by risk. Low-risk polish goes straight to the backlog. Anything high-risk gets a needs-human label and waits for a person.

Ambition, metered

The restraint is the engineering, not the absence of it. An improvement engine with no ceiling produces a backlog no one can act on. The cap of three forces the automation to rank, to pick what matters this run and drop the rest. A factory needs ambition. It also needs that ambition metered, or the line floods.

You can read the whole automation in the Product Improver definition on GitHub (opens in a new tab).

What stops your improvement ideas, human or automated, from outrunning what the team can actually ship this week?

Further reading

Written by

Factory skills, part 4 of 18

  1. Fix the incident and the rule in the same commit The Incident Responder in the software-factory.dev factory updates the conventions document in the same commit as the fix, so the rule that would have prevented the bug is there before the next change. 2 min read
  2. The Feature Builder checks for open bugs before it builds The software-factory.dev build automation runs a pre-flight check first: a priority-1 or priority-2 bug nobody has picked up stops all new feature work. 2 min read

All 18 parts

ClientsClient work

Scaling needs named owners

Coding agents scale across teams when named people own the platform, the team practice, the guardrails, and the measurement. Rollout & scale is where that ownership is built and handed to internal owners, in your stack.

Training on this topic: Agentic Software Factory: Advanced Team Training
See Rollout & scale

Want to check one team first? The self-check: twelve yes or no questions, three minutes, instant result, no account. Take the self-check