BuildNot yet confirmed elsewhere1 publisher3 min readPublished
Bundle archaeology beats "make it faster": 2.1 MB to 890 KB, one change per measurement
A dev.to write-up puts numbers on what coding agents are actually for. The 4 KB library swap the agent proposed cold was worth 0.3 percent of the eventual cut.
The Engineer · Build desk

What happened
- A developer reports cutting a dashboard's initial JavaScript from 2,148 KB to 890 KB in about four working sessions with Claude Code.
- Asked flatly to reduce bundle size, the agent recommended work already done, including tree-shaking that was already enabled.
- The unlock was a build step that emits a machine-readable map of package to bytes from the output and source maps, which the agent read before proposing anything.
- Applying five optimisations in one pass removed 300 KB and silently broke two charts, with no way to attribute the failure.
Why it matters
- capability The import-site reading nobody ever schedules becomes cheap to do, which moves the constraint from finding fixes to proving each one, and proving is the part that still costs a build and a test run.
- decision Batching agent edits now has a stated price: one broken render inside five changes cost the whole batch, so throughput has to be traded against attributability up front.
- cost The entry fee is human engineering time on a reporting harness and a production build that still emits source maps, all paid before the agent contributes a single byte.
- precedent A byte budget in CI becomes the acceptance criterion for agent-assisted performance work, because the diff is diffuse and one dependency bump can quietly undo a session's output.
Before it had read a byte of build output, the agent proposed swapping a library that accounted for 4 KB [3]. Set that against the 1,258 KB that eventually came off [25] and the suggestion was worth about 0.3 percent of the job [20]. The rest of the cold advice was worse: lazy-loading three components that were already lazy-loaded, and considering tree-shaking that was already on [2]. That is what an agent returns when the only input is source code, and it is the strongest argument in the post for building a reporting step first.
The more expensive lesson was the batch. Five optimisations applied together took 300 KB off and silently stopped two charts rendering, with no way to identify the culprit short of unwinding all five [4]. Roughly a quarter of the eventual win [21] arrived in a shape that had to be discarded. After that the author wrote the loop into CLAUDE.md as a hard rule: record the size, change exactly one thing, re-run size and tests, commit with before and after in the message or revert on the spot [14][13].
This is one practitioner's self-report on dev.to [18], and it is worth being precise about what the numbers say. The starting figure is given twice, 2,148 KB raw and 612 KB gzipped; the finishing figure is given once, as 890 KB, with no compression state attached [19]. Raw against raw, that is a 58.6 percent cut [26]. If the original 28.5 percent ratio [23] still held at the end, 890 KB is roughly 254 KB over the wire [24], but the post does not supply that number and no reader of a bundle-size result should have to infer it.
The transferable artifact is not the percentage. It is the report script: a walk over the dist output and the generated source maps that emits a flat map of package to bytes contributed [10]. That is what turned a vague brief into a checkable one. The follow-up prompt shows the delta, since asking for every import site of the top ten packages returned file paths and line numbers, plus three packages imported at app root but reachable only from /reports [11][12]. The precondition is a production build that emits source maps for something to read.
Four sessions for 1,258 KB is about 315 KB a session [22], on a dashboard that had accumulated for three years and carried 214 direct dependencies [17][8]. The reading was the cheap part. What got the work funded was 11 percent of mobile sessions bouncing before first interaction [9], not the Lighthouse score of 41 [6] and not the 8.4 second time to interactive on a throttled Moto G4 profile [7]. Lint rules and a CI budget are credited with keeping the result from rotting [15], though the protocol text available here breaks off before either is shown.
What to watch
- A follow-up naming the byte threshold that fails CI, and what the team does the first time a dependency bump breaches it.
- A gzipped after-figure, or re-measured Lighthouse and time-to-interactive numbers at 890 KB, which would tie the 58.6 percent claim to user-visible latency.
- Whether the source-map reporting trick holds up on builds that do not ship source maps, or in bundlers other than Vite.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence34
- Adoption14
- Hype gap+22
- Incentives55
- Confidence41
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The author reports getting the bundle down to 890 KB in about four working sessions using Claude Code v2.x on Node.js 22.x.
- [2]
The open-ended prompt "Analyze this project and reduce the JavaScript bundle size" returned suggestions to lazy-load three components that were already lazy-loaded and to consider tree-shaking, which was already enabled.
- [3]
The same unguided response proposed swapping a library that accounted for 4 KB.
- [4]
Letting the agent batch five optimisations dropped the bundle 300 KB and silently broke two charts, and the author could not tell which change caused it without unwinding all five.
- [5]
At the start of the work the app shipped 2,148 KB of initial JavaScript, 612 KB gzipped.
- [9]
Analytics showed 11% of mobile sessions bounced before first interaction, which is what got bundle work prioritised.
- [10]
The author added a build:stats script and a bundle-report.mjs report that walks the build output plus generated source maps and emits a flat JSON file of module to bytes contributed, collapsed to package granularity.
- [11]
The revised prompt told the agent to read bundle-report.json, find every import site in src/ for the top 10 packages by bytes, state whether each was needed on first paint or reachable only from a specific route, answer in a table, and change no code.
- [12]
The response was a table with file paths and line numbers, including three entries flagged as imported at app root but used only on /reports.
- [13]
The written loop was: measure with build:stats, pick one candidate, apply it, re-measure and run tests, commit with before/after in the message if smaller and green, revert immediately if regressed or red.
- [14]
CLAUDE.md carried the rule as non-negotiable: run npm run size and record the number before touching anything, change exactly one thing, then run npm run size and npm test.
- [15]
The author credits lint rules and a CI budget with locking in the wins so they could not rot.
- [16]
The author describes bundle bloat as archaeology rather than engineering: the fixes are usually trivial one-liners, and the work is finding which ones across hundreds of import sites and a dependency tree six levels deep, high-volume low-creativity reading.
- [17]
The app was a dashboard that had grown for three years, with weight accumulating rather than being deliberately added.
- [18]
The account is a single first-person write-up published on dev.to.
- [19]
The post states the starting size as both raw (2,148 KB) and gzipped (612 KB), and states the finishing size only as 890 KB without a stated compression state.
- [20]
The 4 KB library swap proposed before the agent had any build data was worth about 0.3 percent of the eventual reduction.
- [21]
The 300 KB drop from the five batched changes was about 24 percent of the eventual total reduction.
- [22]
Averaged over about four sessions, the cut ran at roughly 315 KB per session.
- [23]
The starting bundle's gzipped-to-raw ratio was 28.5 percent.
- [24]
If that compression ratio held, 890 KB would be roughly 254 KB gzipped, a figure the post does not report.
- [25]
The total reduction was 1,258 KB.
- [26]
That is a 58.6 percent cut, raw against raw.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toHow I Cut a 2.1 MB JavaScript Bundle to 890 KB With Claude Code
1 article · August 24, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.