AI Coding Agents Slow? Four Hidden Bottlenecks and Optimization Strategies

Introduction: Why Your AI Coding Agent Is Getting Slower

Many developers have found that even after switching to faster models, the overall efficiency of their AI coding agent hasn't improved noticeably. The problem often isn't model inference speed—it's the tool calls the agent makes during execution. Based on an in-depth discussion from the YouTube channel "Superlinear" combined with developer Brandon's hands-on experience, this article breaks down the speed bottlenecks of AI coding agents and offers four actionable categories of optimization.

The Core Bottleneck: Tool Call Time Gets Overlooked

Amdahl's Law in the Context of AI Agents

The episode presents a key chart that breaks down agent working time into three parts—model inference, tool calls, and human intervention. As verification steps (like end-to-end tests) increase, the share of time spent on tool calls rises sharply, while human intervention time decreases thanks to growing trust. Model inference time is hard to control (unless you switch to a dumber model), but tool call time is exactly the lever you can optimize.

"If you can't change inference time, and human time has already been compressed, then tool call time is the problem." — quote from the episode

Amdahl's Law, proposed by computer architect Gene Amdahl in 1967, originally described the theoretical upper limit of speedup in parallel computing: if a portion of a program has proportion p and cannot be sped up, the overall speedup is at most 1/(p+(1-p)/s), where s is the speedup factor achievable for that portion. The key corollary is that when optimizing overall performance, you should prioritize the largest portion of the work, since extreme optimization of a small fraction yields little benefit. In the AI coding agent scenario, when tool calls grow from 20% to 60% or more of total time, even a multi-fold increase in model inference speed barely improves end-to-end time. This is exactly why the article stresses diagnosing the time distribution before optimizing: only once tool calls are confirmed to be the dominant factor do cleanup, parallelization, and offloading become worthwhile.

Why Tool Calls Keep Getting Slower

• Build processes: Project complexity grows in compiled languages like Rust, and compile times rise linearly.
• Test suite bloat: Agents tend to generate tests for every new feature and default to running all historical tests, causing test time to spiral. Brandon's Electron project once hit the painful situation of "a few minutes to build a feature, an hour waiting for tests."
• Verification tool calls: Having the agent make judgments by clicking through a UI is the slowest operation of all.

Four-Step Optimization Strategy: From Simple to Advanced

Step 1: Diagnose Tool Call Time

Before optimizing, have the agent analyze recent session logs. You can ask: "Which parts of my tool calls take the longest?" The agent will point you in a general direction (tests, builds, code review), and you can then use instrumentation to pinpoint the specific slow test cases.

Step 2: Clean Up Low-Quality Tests

Tests generated by LLMs often include a lot of "junk tests": test function names, redundant coverage, tests for deleted features, and so on. Just talk to the agent to identify and delete them. Brandon emphasizes: "Don't leave tests in your codebase when you don't understand why they exist."

Step 3: Parallelize Test Execution

By default, agents run tests sequentially (unit tests → integration tests → end-to-end tests). You can instruct the agent to "run tests in parallel where possible." Brandon shares a case where an 8-minute test suite was cut down to 1 minute through cleanup and parallelization.

Test parallelization typically relies on two layers. The first is concurrency at the test runner level, such as Jest's --maxWorkers, pytest's -n (pytest-xdist), or Go's t.Parallel(), which distribute independent test cases across multiple processes or threads. The second is parallelism at the task orchestration level, i.e., launching unit tests, integration tests, lint, type checking, and other independent commands simultaneously. Note that parallelization has boundary conditions: tests sharing the same database or filesystem may produce flaky failures due to contention, end-to-end tests often depend on serial state, and excessive concurrency on insufficient CPU cores can actually slow things down through context switching. In practice, then, do test isolation first (independent data and environment per test) and then set concurrency according to resource constraints—otherwise parallelization just trades serial waiting for random debugging costs.

Step 4: Run Tests On Demand (Use with Caution)

When the test suite is still large, you can filter tests based on code changes. Methods include:

• Using dependency-tracking tools like Bazel or Nix.
• Matching file paths to tests with regular expressions.
• Having a decision model (like Jev) predict the relevance of each test based on the diff, then setting a probability threshold to skip low-relevance tests.

Risk warning: End-to-end tests have weak correlation with code changes, and skipping them can introduce hidden risks. Only use this when the test suite is out of control (e.g., over several minutes) and other optimizations have been exhausted.

Advanced Approaches: Offloading Tool Calls and Swapping in Faster Tools

Offloading Tool Calls with Crabbox

Crabbox is an open-source tool developed by Peter Steinberger and the OpenClaw^Ad team. It pushes resource-heavy tool calls (like tests and builds) to remote machines for execution, then syncs state back locally. The agent itself still runs locally, keeping your development environment familiar.

• Any machine works: Old laptops, cloud servers, DGX Sparks, and more can all join the cluster.
• Automatic load balancing: Crabbox handles queuing and resource scheduling.
• Cross-team sharing: You can build machine pools for multiple people to use.

In his Electron project, Brandon used Crabbox to offload tests to a DGX Spark at home, solving the problems of maxed-out RAM and a frozen computer.

Remote execution has mature precedents in the build systems world: Google's Bazel supports the Remote Execution API, distributing compilation actions to a cluster and caching results by content address; Nix achieves cross-machine build reuse through content-addressed derivations. Crabbox follows the same line of thinking but targets general tool calls for AI agents—not just compilation, but also tests, lint, code review scripts, and more. Its technical prerequisite is environment consistency: remote machines must be able to reproduce local dependencies, environment variables, and toolchain versions, or you'll get "works locally, fails remotely" drift. In addition, state synchronization is the main source of overhead in such schemes—transferring large build artifacts and test logs can offset part of the gains, so in practice you should aim to have the remote end return structured summaries rather than raw files.

Replacing with Faster Toolchains

In web development, ESLint can be replaced by OxLint (about 100x faster), Node.js by Bun, and there are faster options for React bundlers too. Some have even rewritten the TypeScript compiler in Rust for a 2–5x speed boost.

Brandon also shares his experience building a fast Swift linter with an agent: a traditional Swift linter takes 5–10 seconds, while his version takes just 100 milliseconds. This proves that with agent assistance, building fast tools for a specific language ecosystem is no longer out of reach.

Action Guide: Optimization Order and Mindset

The recommended order of optimization:

1. Diagnose the time distribution.
2. Clean up bad tests.
3. Parallelize tests.
4. Use fast tools (like OxLint).
5. Offload tool calls (Crabbox).
6. Build your own fast tools (only when other options fall short).

At the end of the episode, Brandon offers this take: "Over-engineering is dead." With tokens plentiful today, it's worth boldly trying crazy ideas—about one in five homegrown tools succeeds, but when it does, the payoff is huge.

Conclusion

The speed bottleneck of AI coding agents often isn't the model—it's the engineering feedback loop. By diagnosing, cleaning up, parallelizing, offloading, and replacing tools, you can significantly cut waiting time and turn your agent into a truly efficient productivity tool. Next time your agent stalls, first look at what it's waiting for—the answer may surprise you.

One-line Summary

AI coding agents are bottlenecked by tool calls, not model inference—systematically optimize via cleanup, parallelization, offloading, and toolchain replacement.

Paragraph Summary

Based on a discussion from the YouTube channel "Superlinear" and developer Brandon's hands-on experience, this article argues that the end-to-end speed bottleneck of AI coding agents often lies not in model inference but in tool calls such as tests and builds. As verification steps multiply, tool call time dominates. The author proposes a four-step strategy: diagnose the time distribution from session logs, clean up low-quality LLM-generated tests, parallelize test execution, and filter tests by code changes when necessary. Advanced approaches include offloading heavy tool calls to remote machines with Crabbox and replacing existing tools with faster toolchains like OxLint and Bun. It closes with an optimization order and a mindset of "over-engineering is dead."