Rust in the Loop: Why Fast Tooling Makes Coding Agents Up to 68% Faster

A new generation of native developer tools has replaced much of the Python and JavaScript toolchain. In the standalone benchmarks below, on real open-source repositories, Ruff lints Python 22 times faster than Flake8 and formats it 88 times faster than Black. uv installs a 58-package lockfile 11.5 times faster than pip from a cold cache. Pyrefly and ty check types 12 to 52 times faster than Pyright and 2.5 to 6 times faster than mypy (though mypy’s warm cache still wins on a rerun with no changes). On the TypeScript side, oxlint and oxfmt check VS Code 67 and 99 times faster than ESLint and Prettier, and Microsoft’s TypeScript 7 (tsgo) type-checks it 4 to 6 times faster than tsc 6. All of these tools are written in Rust except tsgo, which is written in Go.

When someone proposes swapping those tools into a codebase to speed up AI coding agents, the skeptical response is almost always the same: Why bother? The model takes 45 to 90 seconds to think and stream tokens anyway. Saving eight seconds on a linter is noise.

On a back-of-the-envelope spreadsheet, that objection looks reasonable. If an agent runs a verification gate twice during a 70-second task, cutting the gate from 12 seconds to 2 seconds should save about 20 seconds of CPU time—helpful, perhaps, but hardly transformative.

Measured across 120 end-to-end coding agent sessions and 60 standalone hyperfine benchmark groups, the spreadsheet math turns out to be wrong. Swapping legacy Python and Node checkers for Rust and native binaries—while keeping the codebase, task prompt, model and test suite identical—won 23 of 26 non-tied task pairs (p = 8.80 × 10⁻⁵) and cut median task completion time by 13% to 68% in four of the six model-and-language pairs. The other two pairs were a near tie and a pair where too few sessions passed to compare (details below).

Two mechanisms explain why slow tools hurt coding agents much more than a one-shot spreadsheet predicts.

Why slow gates cost more than their wall time

When a human runs eslint && prettier --check && tsc --noEmit in a terminal and it takes 12 seconds, the human waits 12 seconds once before committing. Coding agents pay that tax differently for two reasons:

1. Agents verify inside the edit loop, not just at the end. Across the 120 sessions, models ran full or partial verification checks 1 to 4 times per task—after an initial edit, after fixing a type or lint diagnostic, and before committing. Even in sessions that never spent a turn polling a background task (every Gemini 4 Argon session, and 80% of Gemini 3.8 Flash Python runs), a faster gate saved time on every edit-check-fix cycle: 21 to 26 seconds off the median Gemini 4 Argon TypeScript and Gemini 3.8 Flash Python tasks (161 s → 140 s and 96 s → 70 s), and 60 to 98 seconds on some multi-file refactors and API migrations.
2. Slow commands trigger asynchronous background spillover. Agent harnesses cannot block a conversation forever if a command hangs or starts a server, so they enforce synchronous command timeouts. The exact threshold depends on the harness:
   • Short synchronous windows (about 10 seconds): The agent runner used in this study waits at most 10 seconds for a command to finish. A 2-second Rust gate finishes inside that window and returns its output in the same turn. A 12-second legacy TypeScript gate is still running when the window closes, so the runner turns it into a background task. What happens next depends on the model. Gemini 3.8 Flash and Gemini 3.5 Flash-Lite usually spent extra turns polling the task for its result, and each of those turns sends the whole conversation back through the model. Gemini 4 Argon never polled: its gate was backgrounded just as often, but it waited for the runner’s completion notice instead. It still paid for the slow gate in time, as its tool time nearly doubled (17 s → 31 s).
   • Longer synchronous windows (120 seconds): Claude Code, for example, waits up to 2 minutes by default before timing out a synchronous Bash call (unless run_in_background is set). On a small repository, a 12-second check stays under that ceiling. On a large repository—like Django (47.3 seconds incremental with Pyright) or VS Code (100.6 seconds incremental and 483.9 seconds cold with ESLint + tsc 6 + Prettier)—legacy gates either consume most of the 2-minute window on every turn or blow straight past it, whereas the Rust and native stack finishes in 1.94 seconds on Django and 9.96 seconds on VS Code.

In the 120-session benchmark, none of the 60 sessions using the Rust and native gate had a command backgrounded. Under the legacy gates, the gate was backgrounded in all 30 TypeScript sessions and 21 of 30 Python sessions (in Python, usually the first run, which builds the environment). Whether that cost extra turns depended on the model: 10 of 10 Gemini 3.8 Flash and 9 of 10 Gemini 3.5 Flash-Lite TypeScript sessions polled for the result, while Gemini 4 Argon waited for the completion notice every time.

Study 1: 60 standalone tool benchmarks on real repositories

Before full agent loops, the tools themselves were measured with hyperfine: 10 timed runs per command, pinned repository commits and tool versions, and 8 threads pinned to 8 cores of an AMD Ryzen 9 5900X. Four real open-source repositories span two orders of magnitude in size:

• Python: Rich (45,800 lines of Python) and Django (460,700 lines of Python).
• TypeScript: Hono (74,800 lines of TypeScript) and VS Code (3,640,000 lines of TypeScript).

In an agent loop, the number that matters most is the composite per-turn gate: running the linter, type checker and format check together after the agent edits a single file.

Notice where each stack lands relative to those synchronous command windows. On a 461,000-line Python repository like Django, a legacy incremental check takes 17.4 seconds with mypy or 47.3 seconds with pyright—long enough to background on every turn in a 10-second runner and stall multi-step edits in any harness. Replacing those three tools with ruff, pyrefly and ruff format --check brings the entire gate down to 1.94 seconds, comfortably inside a single synchronous tool call. Even on VS Code’s 3.64 million lines of TypeScript, an incremental gate drops from 100.6 seconds to 9.96 seconds (oxlint + tsgo + oxfmt).

Breaking the gate into its individual tools shows where the time goes. The last two rows, package install and code search, sit outside the per-turn gate but run often in agent sessions:

These speedups don’t come from checking less. The lint comparisons use matched rule sets (Flake8’s E4,E7,E9,F rules, and 68 rules shared between ESLint and oxlint), and the tools flag comparable volumes of findings: 12,767 for oxlint against 16,122 for ESLint on VS Code. Searches exclude .git on both sides. Two caveats apply. Package install over the network is noisy (one pip run hit a retry spike), so the median is reported. And the benchmarks ran on a shared host while agent sessions were also running; legacy and native commands ran back to back in the same hyperfine invocation, so both saw the same background load.

Study 2: 120 end-to-end coding agent sessions

To see how much of that standalone speedup survives inside a real agent loop, the second study uses two multi-domain application repositories—an 83,000-line Python codebase and a 100,000-line TypeScript codebase—along with five multi-file engineering tasks per language:

1. bug_fix: Diagnose and repair a cross-module state bug.
2. feature: Implement a new domain feature across service and repository layers.
3. refactor: Restructure shared records and call sites across modules while preserving behavior.
4. error_paths: Add structured error handling across a multi-step pipeline.
5. api_change: Migrate paginated service methods and callers across the codebase.

Every session received the exact same repository, task prompt and visible test suite, and was graded against a hidden held-out test suite after committing to main. The only difference between the two arms was what sh scripts/gate.sh executed:

• Python — Rust gate (py-rust, 3.1 s cold / 1.6 s warm): uv + ruff format --check + pyrefly + ruff check + pytest.
• Python — Legacy gate (py-legacy, 12.0 s cold / 2.9 s warm): pip + black --check + mypy + flake8 + pytest.
• TypeScript — Rust / native gate (ts-rust, 2.2 s cold / 2.0 s warm): oxfmt + tsgo (TypeScript 7 native) + oxlint + node --test.
• TypeScript — Legacy gate (ts-legacy, 12.4 s cold / 12.7 s warm): prettier --check + tsc 6 + eslint + node --test.

The first Python gate run in a session builds the environment with uv or pip; later runs only check it, which is why the warm Python times are much lower than the cold ones. tsgo is the one tool here that isn’t written in Rust: it’s Microsoft’s Go port of the TypeScript compiler.

The study ran three Gemini model tiers spanning frontier reasoning to lightweight execution—Gemini 4 Argon, Gemini 3.8 Flash, and Gemini 3.5 Flash-Lite—for 10 sessions per language-and-gate cell (5 tasks × 2 repetitions = 40 sessions per model, 120 sessions in total).

Across all 30 paired model × language × task cells, the Rust and native gate was faster in 23 cells, the legacy gate was faster in 3 cells, and 4 cells tied (tasks where Gemini 3.5 Flash-Lite did not reach a passing solution in either arm). A two-sided exact sign test gives p = 8.80 × 10⁻⁵, with a median finite time-to-correct reduction of 21.7 seconds per task.

Five of the six model-and-language pairs reached a median time-to-correct in both arms. Four of them finished 13–68% faster with the Rust and native gate. The fifth, Gemini 4 Argon on Python, was a near tie: 174 s with the Rust gate against 171 s with the legacy gate. The Rust gate won three of its five tasks, but the median moved slightly the other way. For that pair the gate was a small share of the session: the faster gate saved about 9 seconds of gate time, while model time ran 13 seconds longer in the Rust arm (156 s against 143 s). In the sixth pair, Gemini 3.5 Flash-Lite on Python, fewer than half the sessions passed in either arm (5 of 10 and 4 of 10), so neither arm has a median time-to-correct. The pass-only medians in the table (30 s and 38 s) count only the sessions that succeeded.

Three details in this table explain why developers feel the difference immediately when they switch toolchains:

1. Slow gates multiply tool wait time across every edit cycle

Look at Gemini 4 Argon and Gemini 3.8 Flash. Both solve all 20 Python and TypeScript tasks in both arms. On Gemini 4 Argon TypeScript, swapping the legacy gate (prettier + tsc 6 + eslint, 12.1 s of gate time per session) for the Rust and native gate (oxfmt + tsgo + oxlint, 2.0 s) cuts total tool time nearly in half (31 s → 17 s), drops median turns from 15.5 to 13.0, and cuts median completion time from 161 s to 140 s.

On Gemini 3.8 Flash, which runs the full gate 3 to 4 times per session, the legacy TypeScript stack spends nearly five times as long in the gate (36.8 s against 7.6 s) and spills into a background task in 10 of 10 TypeScript sessions. Switching to the Rust and native gate cuts median completion time from 96 s to 70 s in Python and from 104 s to 81 s in TypeScript.

Output tokens moved less consistently. They fell in four of the six pairs, by 20% to 54%, and rose by 9% to 12% in the other two (Gemini 3.8 Flash TypeScript and Gemini 3.5 Flash-Lite Python).

2. The smallest model lost the most time to slow gates

Look at Gemini 3.5 Flash-Lite on TypeScript. Under the legacy gate, every session had its gate backgrounded and 9 of 10 spent turns polling it, median turns rose to 25.0, output tokens more than doubled (5,411 against 2,470 with the Rust gate), and median time-to-correct reached 97 seconds. With the 2-second Rust and native gate, it never had a command backgrounded and finished in 16.5 turns and 31 seconds, a 68% reduction.

Correctness barely moved. Both arms produced working code in all 10 sessions. Under strict grading, which also fails a session that edits files outside the task’s scope or skips the required commit, the Rust arm passed 8 of 10 against 6 of 10. With ten sessions per arm, that gap is too small to read as a real difference (two-sided Fisher’s exact test, p ≈ 0.63).

3. On multi-step refactors and API migrations, the savings compound

When a task only requires one gate run at the very end, a fast gate saves 10 to 20 seconds. When a task requires iterative verification across several modules—such as refactor, error_paths and api_change—the gap widens dramatically:

• On Gemini 4 Argon (TypeScript), refactor dropped from 175 s to 115 s (−60 s) and api_change dropped from 439 s to 341 s (−98 s); on Gemini 4 Argon (Python), feature dropped from 177 s to 137 s (−40 s) and refactor dropped from 130 s to 114 s (−16 s).
• On Gemini 3.8 Flash (Python), error_paths dropped from 125 s to 75 s (−50 s) and api_change dropped from 208 s to 119 s (−88 s).

These measurements are one half of a broader shift. Coding agents made slow inner-loop tools expensive, and over the same period they made Rust itself much cheaper to write and migrate to. The companion post, Why the AI Era Flipped the Economics of Rust, covers that second half and the agent-driven Rust migrations behind it.

The practical rule: budget 3 seconds for your agent gate

You do not need to rewrite your Python or TypeScript application in Rust to capture this speedup. Put Rust and native tools inside the verification gate your coding agent runs on every turn:

• In Python: Replace pip + black + flake8/pylint + mypy/pyright with uv + ruff format --check + ruff check + pyrefly (or ty). On a 460k-line repo, that drops an incremental gate from 17–47 seconds to under 2 seconds.
• In TypeScript: Replace prettier + eslint + tsc 6 with oxfmt + oxlint + tsgo (TypeScript 7 native). On a 75k–100k-line repo, that drops the gate from 6–12 seconds to 0.3–2.0 seconds; even at 3.6 million lines, an incremental gate stays right at 10 seconds instead of 100.

Keep the entire pre-commit or verification gate under 3 seconds warm. Below that line, every check returns synchronously inside the turn that called it, and your coding agent spends its tokens writing code instead of polling background tasks.