GoKawiil2026-07-30T14:16:04.000Z
Solving Poker with Custom WebGPU
Have coding agents gotten good enough that we don’t need libraries anymore? This post recounts one case in which the answer is “we don’t”: I needed a tensor library to run my poker model in WebGPU. The library I wanted did not exist. It turned out I did not need it.
Background
For the past year, I’ve been interested in the state of solvers for poker. For those unfamiliar: a solver finds an approximate Nash equilibrium strategy for any game situation in poker. In practice, they take a “spot”, a set of public cards and betting history, and produce an output strategy. Because the strategy approximates an equilibrium, it is provably (up to epsilon) non-exploitable: if a player plays a different strategy than your equilibrium, they can’t beat you in expectation.
Commercial solvers have existed for years, but they tend to be quite expensive. I wanted to make an open source, in-browser solver that I could offer for free. Given the compute requirements, I needed to find a way to run the neural net and algorithm in the browser. There are good ways to evaluate models using WebGL or WebGPU, but there is no general tensor-library equivalent of PyTorch1. I spent months building and testing different models in PyTorch. Even when I was satisfied with the final output running on my computer, there was no way to achieve my goal of serving it in the browser.
Reference Implementations
But this is 2026. All I needed was code that produced the same output, quickly, in WebGPU (same function; different platform). I’ve learned to spot the reference-implementation pattern anywhere: PyTorch is a correctness oracle. So I instructed Codex to build me a set of WebGPU kernels that allowed evaluation of the model and the core algorithm, and to confirm parity with the PyTorch reference. It passed the parity tests after a single prompt, so I left it running in a loop overnight to optimize the kernels. With that simple approach, Codex got a greater than 10x speedup over its own naive implementation on its first attempt—and it also flagged that I needed to switch the models’ activation function for performance.
To first order, libraries exist because writing correct, fast, well-architected code is expensive, so we amortize that cost across thousands of users and accept the abstraction penalties that come with generality. If generation is cheap and verifiable, that tradeoff can flip: in this case, a custom kernel that does exactly my computation can beat a general library. As others have noted, a test suite you trust to exercise all relevant behavior can be better than a specification in the LLM era.
This does not work everywhere. The computation has to be well defined, the reference implementation has to be trustworthy, and the tests have to capture the behavior that matters.
... continue reading