Is 5x real?

The idea in one line: A decision model alone makes distro work about 1.2-2x faster, because judgement is a minority of the work. 5x, in maintainer-attention hours, needs a decision model, a coding agent and a fast build oracle working as one loop, and only a derivative, image-based distro gets there.

The operator asked: can a Jev-like model help someone build a new Linux distro 5x faster? A yes would be a great pitch. But you can only spend this answer once: build on a wrong yes and you waste months, and an investor or a researcher will check the arithmetic. So this lesson does the arithmetic out loud, with every assumption labelled.

The short version: no, not from a decision model alone. Yes, plausibly, for one kind of distro, in one unit (attention hours, not wall-clock), with two other pieces in the loop. The biggest lever turns out not to be a model at all. It’s how fast the build tells you whether you were right.

Start with a commute. Your trip takes 60 minutes: 40 on the motorway and 20 through town. Buy a car that’s twice as fast on the motorway. The motorway part drops to 20 minutes, but town still takes 20, so the trip is 40 minutes. That’s 1.5x faster, not 2x. The part you didn’t speed up sets the limit.

That’s Amdahl’s law, named after the computer scientist Gene Amdahl, who presented it in 1967 at the AFIPS Spring Joint Computer Conference (Wikipedia: Amdahl’s law, last edited 2026-08-13). In symbols:

speedup = 1 / ((1 - p) + p / s)

p = the share of the time spent in the part you speed up
s = how many times faster that part gets

In words: the new time is the untouched share (1 - p) plus the sped-up share shrunk by s. The speedup is the old time (1) divided by the new time.

Worked example. Diagnosis takes 30% of your week, and a model makes it 10 times faster:

p = 0.3, s = 10
speedup = 1 / (0.7 + 0.3 / 10)
        = 1 / (0.7 + 0.03)
        = 1 / 0.73
        = 1.37x

A 10x faster step gave a 1.37x faster week. The untouched 70% dominates.

What 5x demands. 5x means the new time is one fifth, 0.2, of the old:

need:  (1 - p) + p / s  <=  0.2

s = infinity  (the step takes no time at all):
       1 - p <= 0.2               so  p >= 0.80
s = 10:
       1 - p + 0.1p <= 0.2        so  p >= 0.89

So even an infinitely fast model gets you to 5x only if 80% or more of your time is in steps it fully absorbs. A decision model speeds up judgement. It doesn’t write code or patches, it doesn’t make builds finish sooner, and it doesn’t plug in hardware. So the whole question becomes: what share of distro work is judgement?

The week splits into six kinds of work: waiting on builds and boots, diagnosing failures, deciding (selection, approvals, bumps, CVEs), writing (Containerfiles, specs, patches, docs), hardware QA, and support.

Look at the first row as a picture, one # per hour of a 100-hour month:

Derivative image, first build (estimated, 100 hours)

wait         #########################   25
diagnose     ####################        20   <- decision model
decide       ####################        20   <- decision model
write        ####################        20   <- coding agent
hardware QA  ##########                  10
support      #####                        5   <- decision model

Only 45 of the 100 hours are judgement a decision model can touch. By the formula, even an infinitely fast model would leave 55 hours, so the ceiling is 100 / 55 = 1.8x.

The speedup each tool gives is also an estimate:

• A decision model makes diagnosis 4x faster, and deciding and support 3x faster.
• A coding agent makes writing 2x faster. That isn’t guaranteed: the one randomized trial found experienced developers slower with AI (more below). Config-heavy greenfield work like a new image may be a friendlier case.
• A faster oracle makes waiting 3x faster for image distros. The oracle is the build system that gives the true answer. “Faster” means caching, prebuilt kernel-module images, automatic retries and speculative parallel builds. For a from-scratch distro, whose compiles are compute-bound, waiting only gets 1.5x faster.

Here is the first profile worked line by line. “All three” means the decision model, the coding agent and the faster oracle together:

Derivative image, first build: 100 hours (estimated shares)

              today   model only         all three
wait             25   25                 25 / 3 =  8.3
diagnose         20   20 / 4 =  5.0      20 / 4 =  5.0
decide           20   20 / 3 =  6.7      20 / 3 =  6.7
write            20   20                 20 / 2 = 10.0
hardware QA      10   10                 10
support           5    5 / 3 =  1.7       5 / 3 =  1.7
total           100   68.3               41.7

speedup, model only:  100 / 68.3 = 1.46x
speedup, all three:   100 / 41.7 = 2.40x

The same function runs every scenario. Change the dictionaries to test your own week:

# Amdahl's law over a week's time budget. The shares and speedups are
# the researcher's estimates, not measurements.
def speedup(shares, factors):
    """shares: hours per activity; factors: how much faster each gets."""
    new_hours = sum(h / factors.get(k, 1) for k, h in shares.items())
    return sum(shares.values()) / new_hours


first_build = {"wait": 25, "diagnose": 20, "decide": 20,
               "write": 20, "hw_qa": 10, "support": 5}
model_only = {"diagnose": 4, "decide": 3, "support": 3}
all_three = {**model_only, "write": 2, "wait": 3}
stretch = {"wait": 10, "diagnose": 10, "decide": 5,
           "write": 5, "hw_qa": 2, "support": 10}

for name, f in [("model only", model_only), ("all three", all_three),
                ("stretch", stretch)]:
    print(f"{name:10} {speedup(first_build, f):.2f}x")
# model only 1.46x, all three 2.40x, stretch 5.56x

All three profiles and four scenarios:

A disagreement to keep visible. The research report gives 2.50x, 2.86x and 1.92x for the “all three” row. Those figures come out exactly if hardware QA also gets 1.2x faster, for example because the model sorts incoming user reports, but the report doesn’t list that assumption. With hardware QA left untouched, as stated, you get 2.40x, 2.79x and 1.89x. Either way the conclusion holds: about 2.5-3x for a derivative, and under 2x from scratch.

The stretch row assumes waiting ÷10, diagnosis ÷10, deciding ÷5, writing ÷5, hardware QA ÷2 and support ÷10. For from scratch it keeps waiting at ÷1.5 and writing at ÷3, because compiles can’t be wished away. Check the first column: 2.5 + 2 + 4 + 4 + 5 + 0.5 = 18 hours, and 100 / 18 = 5.56x. The from-scratch stretch comes to 41.0 hours, or 2.44x. The report’s 2.39x would need hardware QA at ÷1.5, so call it about 2.4x.

Read the stretch row carefully. It means the human almost never waits for a build or reads a log, because the loop runs unattended and only escalates the hard tail. The 5x is in maintainer-attention hours. Wall-clock time and CPU hours don’t shrink 5x; builds still take as long as builds take.

So, the verdict:

• A decision model alone: about 1.2-2x.
• A derivative image distro with a coding agent and a fast build oracle: 2.5-3x realistically, 5-6x at a stretch, in attention hours.
• A from-scratch distro: near 2x, and about 2.4x even at a stretch.

The names come from Kahneman’s two modes of thought. System 1 is fast and intuitive; System 2 is slow and deliberate. TypeSafe calls Jev a “System One” model for exactly this reason: one fast pass, a probability out, no writing (TypeSafe docs: System One, read 2026-10-28).

In the co-pilot, each part gets the job it’s good at:

• The decision model is System 1. It triages each event, routes the work, and verifies what comes back.
• The coding agent is System 2. It writes the diffs: Containerfile changes, spec fixes, patches.
• The build system is the ground truth. Nothing ships because a model believed it; it ships because the oracle passed it.

C4 · L2 Container · Distro co-pilot loop

....................... Distro co-pilot [system] .......................
:                                                                      :
:  +---------------------+              +-------------------------+    :
:  | [Container: Python] |    events    | [Container: ONNX]       |    :
:  | Event intake        |------------->| Decision server         |--+ :
:  | CI, Koji, issues    |    (JSON)    | System 1: typed odds    |  | :
:  +---------------------+              +-------------------------+  | :
:                                         |     |           ^        | :
:              +--------------------------+     |           |        | :
:              | retries, re-checks             | routes    | verify | :
:              v                                v (JSON)    | (JSON) | :
:  +---------------------+              +-------------------------+  | :
:  | [Container: podman] | diffs, build | [Container: agent CLI]  |  | :
:  | Build oracle        |<-------------| Coding agent            |  | :
:  | build, lint, boot   |------------->| System 2: writes diffs  |  | :
:  +---------------------+ pass or fail +-------------------------+  | :
:         |                                                          | :
:         | outcomes (SQL)                                           | :
:         v                                                          | :
:  +---------------------+                                           | :
:  | [Database: SQLite]  |                                           | :
:  | Outcome store       |                               escalations | :
:  | results = labels    |                               (web inbox) | :
:  +---------------------+                                           | :
:                                                                    | :
:....................................................................|.:
                                                                     v
                                                 +---------------------+
                                                 | [Person]            |
                                                 | Maintainer          |
                                                 | the uncertain tail  |
                                                 +---------------------+

Events reach the decision server, which scores the typed questions (how to read the diagrams). Confident easy cases go straight to the build oracle as a retry or a re-check. Real work is routed to the coding agent, whose diffs come back to System 1 for checking and go through the oracle before anything ships. Every outcome becomes a training label, and only the uncertain tail reaches the maintainer.

The routing rule is selective prediction: act only when the probability clears a threshold set from the cost of being wrong, and abstain otherwise (from probability to automation).

• A wrong retry costs one CI run, so the retry threshold can be loose, say P ≥ 0.7.
• A wrong “safe to auto-merge” can ship a broken image, though bootc lets users roll back. That threshold must be strict, around P ≥ 0.98, and Fedora’s policy wants a human to stay accountable anyway.
• Verification is a decision too: “is this agent’s change inside the requested scope?” The operator’s own agent rules open with “Only what I ask for” (tsaqib/mycachy/CLAUDE.md:9), which is exactly the question a fast verifier can answer on every diff.

Why do you need both halves? Look back at the table. A coding agent alone gives 1.05-1.21x, and a decision model alone 1.2-2x. They multiply each other’s reach. The decision model keeps easy cases away from the expensive agent and checks its output. The agent does the writing the decision model can’t. And the oracle makes the whole thing trustworthy. The thresholds only mean something if the probabilities are honest, which is why calibration has to be fitted on distro data.

What won’t speed up:

• physical hardware QA: MOK screens, NVIDIA laptops, suspend and resume;
• taste, since the 25 rejected features in terra-fedora’s ledger are the product;
• key custody and Secure Boot trust: who holds the signing key;
• upstream social processes such as package review, policy votes and sponsors;
• licence judgement;
• first-time compiles;
• genuinely new code, such as the planned Stack Shell plugin layer, which is generation, not decision.

Here’s the number that reframes everything. A decision API answers in about 0.1-0.65 seconds per request, by independent measurement (Vals AI, 2026-10-06). A terra-fedora CI lap can take up to 180 minutes.

one lap = decide (0.5 s) + build and test (60 min)

make the decision 10x faster:   0.05 s + 60 min   = still 60 min
make the build 10x faster:      0.5 s  +  6 min   = about 6 min

The decision is under 0.02% of the lap. Making it faster changes nothing you’d notice. Making the lap faster changes everything, because the operator’s first week was a sequence of laps, each teaching one Fedora 44 fact. So the 10x moves are structural:

1. Delete decisions before you predict them. CachyOS ships a prebuilt open NVIDIA module for each kernel, which mycachy installs in one line (tsaqib/mycachy/modules/nvidia/mod.just:7-8). Universal Blue publishes signed kernel-module images, rebuilt daily (ublue-os/akmods). Either one removes the akmods-signing pipeline terra-fedora maintains by hand. Each such change removes weeks; a better classifier removes minutes.
2. Auto-retry transients. If 85% of re-runs pass, a loose retry policy removes most human wake-ups before any clever model is involved.
3. Cache. terra-fedora already mounts a package cache into its build (--mount=type=cache,target=/var/cache/libdnf5, Containerfile:31). Caching image layers goes further.
4. Run laps in parallel. Speculative builds test several candidate fixes at once and keep the one the oracle passes.
5. Build where the oracle is fast. The x86_64 ISO can’t be built through Rosetta on the operator’s Mac, so that lap has to run on a Linux host.

Use the oracle; don’t imitate it. A model belongs only where the oracle is slow (a 20-180-minute CI run), missing (hardware) or expensive (human review). Everywhere else, the fastest correct answer is to run the tool.

What would it cost to triage every failed build Fedora had in a year? At Jev’s list price as of October 2026 ($0.042 per million input tokens, output free):

284,204 failed Koji tasks in 12 months
x 2,000 tokens per log snippet        = 568.4 million tokens
x $0.042 per million tokens           = $23.87, about $24 a year

The task count is from Koji’s public hub, counted on 2026-10-28; the 2,000-token snippet size is the plan’s own cap. Self-hosting a small encoder is cheaper still: the reference design estimates about $1-3 per million 1,000-token decisions, which puts a year of Fedora’s failures at a few dollars at most. That’s an estimate, not a measurement.

So the scarce things are not model calls. They are labels, plumbing and evals: the label miners, the outcome store and the gold sets from building the co-pilot. For a founder, that’s where the moat is, as wedges, moats and proof argues.

Keep these in view whenever someone quotes a big multiple:

• Log Detective has published no accuracy since it went public in early 2024, even for its explanations, and Fedora Magazine says it likely offers little to experienced packagers (2026-05-13).
• Jev is mid-tier, not frontier. It scores 67.8% on TypeSafe’s own four workflows, tied with Sonnet 5 and below GPT “sol” (74.1%) and Opus 5 (73.1%); those are the vendor’s own numbers. Its calibration varies by task: an ECE (expected calibration error) of 0.011 on one benchmark and 0.108 on another (Vals AI). So the thresholds above must be fitted on distro data.
• AI tools slowed experienced developers in the one randomized trial. METR’s study of 16 experienced open-source developers across 246 tasks found early-2025 AI tools increased completion time by 19%, while the developers believed they’d been 20% faster (METR, arXiv 2507.09089, 2025-07-12). It’s a single study.
• Merged isn’t correct. r-ryantm’s 91.8% merge rate and Universal Blue’s 97-99% bot merge rate leave few negatives, so “safe to merge” needs revert and CI signals too.

Where the frontier is. The architecture here, a fast verifier and router wrapped around a slow generator with an exact oracle as judge, is the general pattern behind the System 1 versus System 2 argument in the big debates. Distro work is a clean test bed for it, because the oracle is real and cheap to call.

Open problems:

• The time shares are estimates. The single most useful next step is to log every maintainer touch for a month on terra-fedora. That would turn this verdict from reasoned into measured.
• Generative speedups are untested here. METR found a slowdown in mature repositories. Whether config-heavy distro work behaves differently is unknown.
• Hardware truth has no data. No public dataset links image versions to boot success on specific GPUs and firmware. Opt-in stack doctor reports could start one, with consent and privacy questions to solve.
• The report’s own arithmetic has a gap. Its “all three” row carries an unstated hardware assumption (see above). Small, but it’s the kind of thing to check in any multiple you’re handed.

• Wikipedia: Amdahl’s law: the formula, worked examples and its 1967 origin.
• METR’s randomized trial, arXiv 2507.09089: 16 experienced developers, 246 tasks, and the evidence behind the caution on coding agents.
• Vals AI: independent evaluation of Jev: the latency and calibration numbers behind this page.
• ublue-os/akmods: the “delete the decision” lever in practice, prebuilt and signed kernel modules.
• Fedora AI-assisted contributions policy: why the loop keeps a human as the final arbiter.