Root cause in 33 seconds: How Kiro CLI saved 4 years of build time

33 seconds. That’s all it took Kiro CLI to investigate a gnarly performance bottleneck, identify the root cause buried deep in a legacy codebase, and implement a fix which ended up saving about 4 years of compute time per month across 381 packages that are built 550,000 times every month.

The problem: build times that eat your day

If you’ve ever stared at a build that’s been running for 30 minutes and wondered whether something went wrong, you know the feeling. That was the reality for a suite of internal configuration build packages our team maintained. P99 build times had crept past 25 minutes — sometimes exceeding 30. With hundreds of packages being built hundreds of thousands of times per month, those minutes were adding up fast.

We needed to figure out why. The usual approach of manually reading through profiling data, cross-referencing it with an unfamiliar codebase, forming a hypothesis, and then implementing a fix could easily take days. We decided to try something different.

Why Kiro CLI?

We’d been using Kiro CLI for a while, and this felt like the kind of task it was built for. This wasn’t a simple code generation job but a complex, open-ended investigation. We needed an agent that could reason across multiple files, interpret profiling output, and connect the dots between runtime behavior and source code.

Tools purpose-built for code generation are great at what they do, but for root cause analysis across an unfamiliar codebase, we wanted a more generalist agent. Kiro CLI was the right call.

Kiro in action: from profiling data to fix in 33 seconds

We started by capturing performance data using perf and reformatting it into a clear, structured format. (More on that in the lessons section — this step matters.) Then we gave Kiro a single prompt:

What followed was a fully autonomous investigation.

The profiling data told a clear story once you knew how to read it. The call tree showed that the config file parser was consuming a massive share of CPU time — nearly 80% of the execution path traced back through the parser’s core routines:

Kiro read this output, mapped it against the configuration build tool’s source code, and identified the culprit: the config parser was being re-initialized on every single function call across multiple subroutines. Each call spun up a brand new parser instance, re-reading and re-parsing the same config files from disk every time.

The fix was elegant: introduce a shared cache keyed on the relevant config parameters. Parse once, reuse everywhere.

The tools that made it possible

The investigation relied on a few key capabilities:

• Code intelligence tools (generate_codebase_overview, search_codebase_map) for understanding unfamiliar codebases quickly

• File system tools (fs_read, fs_write, glob) for reading profiling data, inspecting source code, and implementing changes

• Subagent delegation (use_subagent) for offloading focused analysis tasks without polluting the main context

Under the hood: how Kiro investigated the problem

To understand what made this investigation so fast, it’s worth looking at how Kiro actually worked through the problem. Over the course of 10 autonomous turns, Kiro used a combination of code intelligence and file system tools to navigate an unfamiliar codebase, correlate profiling data with source code, and implement a fix.

Understanding the codebase structure

Kiro started by getting oriented. It used generate_codebase_overview to build a high-level map of the repository structure, followed by search_codebase_map to identify key directories and packages. These tools gave Kiro a mental model of the project layout without having to read every file.

Then it used fs_read in Directory mode to list the contents of the target directory, confirming the presence of the performance report file.

Why this matters: Before diving into profiling data, Kiro needed to understand what it was working with. These reconnaissance tools let it build context efficiently, the same way an engineer would skim a README and browse the file tree before digging into code.

Reading and interpreting the profiling data

Next, Kiro read the profiling report file using fs_read in Line mode.

The profiling data showed that 79.41% of CPU time was spent in the parser’s core function, with significant overhead in token parsing and I/O operations. This was the smoking gun, but Kiro still needed to figure out why the parser was consuming so much time.

Why this matters: Profiling data is dense and hard to interpret. Kiro didn’t just read the file but the entire call tree, identified the hottest code paths, and connected them to specific function names. This is where a generalist agent shines: it can reason about structured data formats like perf output without needing a specialized parser.

Delegating code analysis to a specialized subagent

At this point, Kiro had identified the bottleneck (the config parser) but needed to locate where in the codebase the parser was being instantiated. Kiro delegated this task to a specialized code-analyzer agent using use_subagent.

The subagent was given a focused query: "Identify build tool package locations where we can implement performance optimizations based on perf data analysis."

Why this matters: This is one of Kiro’s most powerful features. By delegating to a specialized subagent, Kiro kept its own context clean while offloading a focused subtask to an agent optimized for code analysis. The subagent ran in parallel, analyzed the codebase, and returned results — all without cluttering the main conversation.

Locating the problematic code

Armed with the subagent’s findings, Kiro used glob to find all files in the build tool package, then used fs_read to inspect the relevant source modules.

It read the plugin and configuration modules, scanning for where the parser was being instantiated. The pattern became clear: every function in the configuration module was creating a new parser instance with identical parameters.

Why this matters: Kiro didn’t just grep for the parser class and call it a day. It read the actual code, analyzed the control flow, and identified the repeated instantiation pattern. This required reasoning about the codes behavior, not just pattern matching.

Turn 10: Implementing the fix

Finally, Kiro implemented the solution. It used fs_write with the str_replace command to modify the configuration module, introducing a caching mechanism:

• Added a cache hash to store parser instances

• Created a helper function that checks the cache before instantiating a new parser

• Refactored all existing functions to use the cached parser

The fix was surgical: it preserved all existing behavior while eliminating the redundant re-initialization.

Why this matters: Kiro didn’t just suggest a fix, it wrote the code and implemented it. The str_replace operation required understanding the existing code structure, identifying the exact lines to change, and generating syntactically correct code that integrated seamlessly with the existing codebase.

Kiro implemented 80–90% of the required code changes directly. We reviewed, validated, and ran a build to confirm the hypothesis. The results were immediate: P99 build times dropped from over 30 minutes to under 1 minute.

What we Learned

Use a generalist agent for investigation tasks. When the problem is open-ended — "why is this slow?" rather than "write me a function that does X" — a generalist agent that can reason across files, tools, and data formats is the right choice. Kiro CLI’s ability to chain tool calls autonomously made it well-suited for this kind of exploratory work.

Trust the agent to go deep, but verify the output. Kiro implemented the majority of the fix autonomously, but we still built the package and validated the results before shipping. AI-assisted development accelerates the investigation and implementation phases dramatically but shouldn’t replace the engineer’s judgment on correctness and safety.

The ROI compounds at scale. A 30-minute build feels like a personal inconvenience. Multiply it across hundreds of thousands of builds per month, and it becomes an infrastructure cost problem. Kiro helped surface and fix an issue of a scale that only becomes visible in aggregate.

What made this work wasn’t any single tool, it was Kiro’s ability to chain them together autonomously. Kiro built context, formed a hypothesis, validated it against the code, and implemented a fix, all without human intervention beyond the initial prompt.