One of the patterns I’ve seen with people using Claude for programming is: A programmer in the past looked at a tradeoff space and decided to make a common operation fast and an uncommon operation slow. Claude lacks proper context of the use of the software but spots a pattern that looks like things it’s training set has flagged as slow and so points to the slow path as a bottleneck. The user asks for a test case and Claude provides a simple microbenchmark that triggers the slow path. Now that it’s confirmed as slow, the user asks a ‘agentic’ harness to explore the design space and optimise for the benchmark. The swarm of Claude instances makes plausible changes to the code and reports back with a modified version that passes the test suite and improves the microbenchmark. The test suite doesn’t exhaustively cover all possible race conditions and so the new version may include subtle concurrency bugs. It also probably makes the common case slower and so is a regression overall. I don’t know if other LLMs encourage this flow, but I’ve seen it several times from people using Claude. I suspect Linus’ recent embarrassing interaction with his kernel’s virtual memory code may have been an example of this pattern. It’s very easy to do with an LLM because each step appears to be a demonstrable improvement. It comes with an objective benchmark, it passes all of the tests. Unfortunately, software often depends on a load of extrinsic knowledge that the LLM is trying to infer from a load of likely misleading data points.