AI has made writing code cheaper, but the hardware doesn’t get any cheaper.
I build React apps used worldwide, many running inside WebViews on affordable Android phones. These devices often represent the slowest 10% of user experiences. Even when all CI checks pass, performance issues can still slip through review.
AI has also made another part of this process harder. We can release more code, but reviewers still have the same time. With more changes in each PR, reviews get crowded, and it’s easier to miss performance problems.
To help with this, I built a loop around a coding agent. It reads runtime traces, runs the same benchmark every time, and compares the results with what we see from real devices in the field.
I find this setup is useful, but it’s not all about success; it brings new ways to make mistakes in different forms: the benchmark gives better numbers, but the user experience gets worse. LLMs say the changeset is a win, but the trace shows the opposite. While LLMs are working on performance improvements, I’m working on guardrails and more deterministic tools for LLMs to make this loop more successful.
In this talk, I’ll walk you through the setup I landed on: runtime traces, benchmarking, and the guardrails I put around the agent. I’ll also share a few places where my first assumptions turned out to be wrong.
Twenty minutes is not enough to cover everything about performance engineering, but it is enough to share questions that helped me build this loop. I hope this gives you a helpful starting point for your own projects.
