Build1 publisher3 min readPublished
In one worked example, a coding agent waits 93 percent of its cycle on CI
A dev.to design essay argues CI was sized for human review speed and proposes tiering checks by cost and failure probability. Its figures are examples, so the case rests on the failure modes it names.
The Engineer · Build desk
What happened
- A dev.to post, originally published on tamiz.pro, argues that LLM-assisted coding has outrun validation speed and produced a CI bottleneck of backlogs, developer fatigue and unreviewed automated changes.
- Its worked example has an agent writing 5,000 lines and 50 unit tests in under a minute, then sitting idle for 14 of the 15 minutes the CI system takes to validate the result.
- The post's starting premise is that CI was designed around human cognitive limits, running the suite on push as a backstop while human review speed set the bottleneck.
- It names three failure modes particular to LLM output: duplicated logic that ignores existing abstractions, over-generated boundary tests, and imports referencing libraries absent from the lockfile.
- In autonomous loops, the post says, an agent keeps generating code incompatible with its previous output, producing merge conflicts that are semantic conflicts in the dependency graph.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Validation wall clock caps how much agent output reaches main. A faster generator only lengthens the queue in front of the runners.
- decision Platform teams have to rank their checks by rejection probability, because gate order decides how much runner time a rejected change burns before anyone learns it was rejected.
- exposure Test flakiness stops being an annoyance and starts producing commits, because an agent that reads red as a defect signal will change code that already works.
Run the example forward. The agent waits 14 of every 15 minutes, which is 93 percent of the cycle [1]. One serialized 15-minute pipeline clears four runs an hour, whatever the model on the other end can produce [2].
The post is a design essay: it analyzes why linear pipelines fail under AI-generated load and proposes fixes, and its numbers are illustrative [17]. The 15-to-1 ratio describes your repository only if your suite really takes about 15 minutes, your agent really emits work in 5,000-line units, and your runs queue behind one another [3][4]. If validation takes four minutes and you fan out across runners, generation speed is not what is hurting you.
The concrete proposal breaks the monolithic job into tiers ordered by cost and failure probability [13]. Tier one runs at agent-local speed: lint and format with Prettier, ESLint or Pylint, plus a dependency graph check that verifies every import exists in package.json or requirements.txt without running install [14]. Parsing a manifest is a local text operation. install is network-bound, can take minutes, and blocks the entire pipeline when it fails [11]. CI runners are often ephemeral and disk-constrained, so the I/O overhead of larger AI-authored working directories is itself a performance penalty [6].
A manifest parse catches an import that was never declared but does not check whether the declared version is current or safe. The post files outdated, vulnerable and conflicting package suggestions separately, with two agents importing lodash in one file and underscore in another [10].
Ordering matters for security scans too. How much it gains depends on your reject rate. The post's case is that a scan running after a 10-minute build wastes 10 minutes on code that was rejected in the first 30 seconds [12]. Measured against a pipeline that already runs the scan alongside the build, gating adds 30 seconds to every change that passes and saves 10 minutes on every change that fails, so it pays above roughly a 5 percent rejection rate [3].
Flakiness is the failure mode that changes character. Code that passes 90 percent of the time and fails 10 percent because of race conditions or unhandled async edge cases is an annoyance under human review [7]. The post calls it "a catastrophic feedback loop" when the agent uses the CI result as a signal to fix the code [8]. Take ten independent iterations at that pass rate and the chance of at least one spurious red is 65 percent [4]. Each one invites the agent to edit code that works, which the post names reward hacking in reinforcement learning terms [9]. The agent that over-generates boundary tests is also part of why the suite is slow enough to make the wait expensive [5].
The post says the pipeline has to separate a genuine logic error from a transient failure [9]. The available text breaks off inside tier one, before it gets to how [14].
What to watch
- Whether any team publishes measured commit rates and CI queue times from an agent-heavy repository, which is what the 15-to-1 example currently stands in for.
- Whether CI vendors ship dependency graph verification as a first-class step that runs before install, or leave it to a custom script.
- Whether flaky-test quarantine gets wired into agent retry loops, so a transient red stops producing a fix commit.