AI Agents That Fix Slow Code Before You Notice

Every engineering team has a Dave.

Dave is the person who wrote — or once touched, or merely survived — the critical section of code that nobody else fully understands. When something slows down in production and the product manager finally escalates past "maybe we can look at that sometime," Dave is the answer to the question of who can even investigate it. And the estimated timeline for Dave's investigation is, famously, somewhere between an hour and three weeks. Nobody knows which until he's done.

May Walter, co-founder and CTO of Hud, opened her recent talk at the AI Engineer conference with exactly this scenario. She knows the room she's in — her background spans runtime internals and adversarial security research — but she's describing something universal enough that any manager or product person who's ever watched a performance ticket languish on a backlog will recognize it immediately.

Her argument, stripped of the technical scaffolding: the investigation phase is the real bottleneck, not the fix itself. Engineers know how long it takes to implement a performance change once they understand what needs changing. The unbounded variable is the archaeological dig through production data required to even know what's wrong. Because that dig is unbounded, it never gets prioritized proactively. Teams wait until something is slow enough to constitute a crisis, then pay for an emergency investigation that could have been routine maintenance months earlier.

"Every time we look," Walter observed, "we actually find things that can be done around performance and stability. But we never stop to proactively look for them, because it doesn't make sense."

That's the structural problem she set out to automate away.

The Loop Hud Is Trying to Break

The failure mode Walter describes has a recognizable shape: ignore the slow thing, wait for it to degrade, escalate in crisis mode, fix it in emergency mode, return immediately to ignoring the next slow thing. Repeat. It's not negligence — it's rational prioritization given incomplete information. You can't justify pulling Dave off feature work for an investigation that might yield nothing.

What Hud built is a weekly automated sweep that does the investigation without Dave. The system examines live production data — the actual requests coming into the application, which functions handle them, how long each step takes — and surfaces only the problems where the math on fixing them is clearly favorable.

To understand why this is harder than it sounds, some plain-English context on a couple of terms Walter uses repeatedly.

When she talks about P90 latency, she means the response time that 90 percent of requests fall below. If your app's P90 is two seconds, nine out of ten users get their response in under two seconds. The tenth person waits longer, sometimes much longer. That tenth person is real, and in a payment flow or a signup form, they represent lost money or a lost customer. Latency metrics like P90 are the standard way production teams measure whether an application is getting faster or slower over time.

When she mentions N+1 queries, she's describing a specific and very common performance trap in database-backed applications. The classic version: your code fetches a list of, say, 100 orders, then loops through them and makes a separate database request for each order's customer information. That's 101 database round-trips to do something that could be done in one. Like making 100 separate trips to the grocery store instead of writing a list — technically achievable, obviously inefficient, and easy to miss when you're writing code that works correctly at small scale and only reveals its cost in production.

These are exactly the kinds of problems — inefficient database patterns, missing indexes that make the database search every record instead of jumping to the right one — that Hud's agent is built to find. They're not exotic bugs. They're maintenance debt that accumulates because nobody is paid to look for them proactively.

What "Agentic" Actually Means Here

The word "agent" has been doing so much heavy lifting in technology coverage lately that it's nearly meaningless. Walter is specific about what her system actually does, which is more useful than the buzzword.

GitHub Actions kicks off a weekly run. The agent — in Hud's current setup, using Claude Code — pulls production context through an MCP connection. MCP, or Model Context Protocol, is essentially a standardized way for AI models to query external data sources; think of it as the agent's ability to ask questions of your production environment rather than just your codebase. The agent can then ask questions like: which endpoints are running slowly, and where, specifically, is the time being spent inside those endpoints?

That last part is the piece Walter calls "prod-to-code," and it's worth dwelling on. Standard monitoring tools tell you that a given API endpoint is slow. They speak in aggregate metrics: CPU usage, memory, response times by endpoint. But a coding agent doesn't reason in those terms — it reasons about functions and files and specific lines of code. The gap between "this endpoint is slow" and "this specific function call on line 247 is executing a separate database query for every item in the loop" is normally bridged by a human engineer doing investigation work. Hud's system bridges it automatically, connecting the high-level performance signal to the function-level cause.

Once the agent identifies a candidate fix, it doesn't stop at suggestion. It implements the fix, reruns the relevant tests, and verifies that the change actually improved the specific flow it was targeting. Only after that verification does a human see it.

"It's not 'hey, I have this idea of something that you can do,'" Walter said. "It's 'here's something that works.'"

That distinction matters enormously. A system that generates suggestions is another inbox to manage. A system that generates verified, tested changes with an explanation of the business impact is something closer to a capable junior engineer leaving a clean handoff.

The Things That Didn't Work

Walter is candid about the failures, which is where the talk gets genuinely instructive.

The first problem she calls "plausible unverified." An AI agent, given a slow endpoint, can generate a plausible-sounding hypothesis about what's causing the slowdown and suggest a fix that addresses that hypothesis. The hypothesis can be technically coherent and still be wrong about what's actually happening in production. Without grounding the diagnosis in real runtime data, you get confident suggestions that don't solve the actual problem — the AI equivalent of a doctor diagnosing a patient without running tests.

The second failure mode is what Walter calls the "lazy fix." When the agent encounters an error, it might suggest wrapping it in a try-catch block — which is a way of hiding the error rather than fixing it. Catching an exception so the application doesn't crash is not the same as understanding why the exception is being thrown. Building a playbook that explicitly requires the agent to trace problems to their root cause, rather than paper over the symptoms, was necessary to prevent this.

The third issue was context quality. Production systems generate enormous volumes of monitoring data, most of it low-signal noise. The agent needs enough context to reason accurately, but drowning it in irrelevant data degrades its performance just as surely as giving it too little. Walter's team had to build query tools and pre-packaged analytical "skills" — essentially specialized queries for common investigation patterns, like finding what was running on a specific server during a memory spike — to make the agent's reasoning reliable and consistent.

The structure-first approach shows up here in practical form: the agent isn't clever on its own, it's effective because of the guardrails and methodology built around it.

The Human Interface Problem

One of the more interesting design decisions Walter describes is what the system doesn't do.

The obvious endpoint of this workflow would be automated pull requests — the agent finds a problem, fixes it, and opens a code review. Walter built toward that and then pulled back. The reason is behavioral, not technical. Flooding engineers with a large volume of automated PRs, however small and correct each one might be, creates a review burden that people will simply stop engaging with. Trust collapses. The automation becomes noise.

Instead, Hud generates a human-readable report — something closer to a briefing than a task queue. The format Walter describes is almost conversational: this endpoint usually responds quickly, but occasionally takes much longer; here's the specific cause; here's the fix; here's the evidence it works. The engineer can then decide whether to open a ticket, review the generated PR, or simply note the issue for later.

"We're still living in this hybrid world where humans are in the loop," Walter said, "and we want to respect our place in people's lives."

The phrasing is a little diplomatic, but the underlying point is sound. Automation that engineers don't trust doesn't get used. The measure of success isn't how many fixes the system generates — it's how many the team actually deploys. Starting with a single high-confidence, well-documented recommendation per cycle builds the habit. Credibility compounds.

This is the part of the developer productivity story that rarely makes it into the pitch decks: AI tools that skip the trust-building phase tend to generate individual excitement and team-level friction in equal measure.

Walter's sharpest observation in the talk isn't about the technology. It's about the category of work being automated. She points out that Hud's system isn't accelerating something engineers already do — it's doing something engineers effectively never do. Nobody holds a weekly performance review meeting to look for low-hanging optimization opportunities. It doesn't happen because the expected cost of investigation makes it irrational to schedule.

Automate the investigation, and the calculation changes. The thing that was never worth doing becomes something that happens automatically in the background and delivers verified results to your Slack channel on Monday morning.

Whether the category of automated investigation that Walter describes becomes infrastructure for every engineering team, or remains a specialized product for organizations with mature enough production observability to make it work, is still an open question. The prerequisite list is real: you need production tracing, function-level instrumentation, a codebase that someone has taken the time to monitor carefully. Not every team has that foundation.

But the problem she's addressing is genuinely universal. Every team has a Dave. Most of them are waiting for a crisis before they let him look.

Bob Reynolds is Senior Technology Correspondent at Buzzrag.