7 Vibe performance engineering: when assumptions mislead

In this chapter, the author shows how performance work can fail when it is driven by guesswork instead of evidence. Two recurring mistakes are highlighted: optimizing code too early without knowing traffic or latency requirements, and ignoring the hot-path, the part of the system that accounts for most real work. The chapter argues that LLM-assisted development does not automatically protect engineers from these mistakes; in fact, if prompted badly, it can amplify them by confidently generating over-engineered solutions and hidden complexity.

Using an account lookup example, the text compares a human-style optimization attempt with an LLM-generated one. Both initially assume that multithreading will help, but benchmarks show that parallel execution adds overhead without improving performance for the realistic workload. When the prompt is revised to include the expected data size, the model switches to a better algorithmic solution: a map-based lookup that is much faster than the thread-heavy variants. The lesson is that LLMs can produce strong results, but only when given concrete constraints about traffic, scale, and acceptable trade-offs.

The chapter then moves to hot-path analysis in a word service, where load testing and internal metrics reveal that the most frequently executed endpoint dominates overall system cost even if it is not the slowest in absolute terms. The human approach uses targeted metrics and a cache to improve the word-exists path while keeping tracing lightweight and focused. The LLM approach also identifies the bottleneck, but it tends to add too much custom instrumentation, blur the diagnostic signal, and make implicit assumptions about memory, startup time, and caching strategy. Overall, the chapter concludes that LLMs are useful performance helpers, but they work best when engineers supply traffic expectations, measure actual behavior, and keep the optimization scope tightly aligned with the hot-path.

AccountFinder JMH Plot.

AccountFinder JMH Plot with HashMap is much faster than the other approaches.

Endpoints with different request frequencies.

The 80/20 rule, as presented by the Pareto principle.

The architecture of a word service with two functionalities.

Viewing the word-of-the-day initial performance results that looks good enough.

Viewing the word-exists initial performance results - higher percentiles looks problematic.

Eager initialization and computation.

The word-exists performance results after applied optimization.

The LLM-caching solution is faster than the human-based solution, but at the cost of increased memory consumption.

• LLMs are also prone to mistakes in optimizing code based on a lack of or false assumptions. Providing sufficient context allows LLMs to implement solutions that match those created by experienced performance engineers.
• Knowing the expected SLA and traffic for your system is even more critical in the context of Vibe Performance Engineering, as it can help you guide the LLM towards more efficient solutions.
• The trade-off between tracing and measuring too much vs too little is essential in the context of hot-path detection. Measuring too much increases the cognitive load; measuring too little doesn’t allow you to detect the hot-path at a proper granularity level.
• Be careful when using the LLM to generate performance improvement code, as it may shift the performance problems from one place (runtime) to another (application startup with eager init). Again, providing the boundaries (RAM needed, write vs read requests per second, etc) guides LLM into the proper direction and reduces the risk of introducing bottlenecks in different places

FAQ