--- title: We don't need no stinkin' tensor library | daily.dev description: A developer built a browser-based poker solver using custom WebGPU kernels instead of a general tensor library, using Codex (an AI coding agent) to generate... canonical: https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: We don't need no stinkin' tensor library | daily.dev og:description: A developer built a browser-based poker solver using custom WebGPU kernels instead of a general tensor library, using Codex (an AI coding agent) to generate... og:url: https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x og:image: https://api.daily.dev/og/posts/JU38wIN9X.png og:image:alt: We don't need no stinkin' tensor library og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # We don't need no stinkin' tensor library **[Hacker News](https://daily.dev/sources/hn)** · 6 min read · 0 upvotes · 0 comments ## Summary A developer built a browser-based poker solver using custom WebGPU kernels instead of a general tensor library, using Codex (an AI coding agent) to generate and optimize the kernels against a PyTorch reference implementation. The agent achieved a 10x speedup over its naive implementation and passed parity tests after a single prompt. The post reflects on how AI coding agents have matured to the point where custom, task-specific code can outperform general libraries when the computation is well-defined and verifiable tests exist. The author notes that while agents now write essentially all the code, human judgment and planning remain essential for deciding what to build. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 28 comments across hackernews (as of 2026-07-31). **TL;DR:** The HN thread is mostly a tangent into poker strategy and solver theory, with only a few comments directly engaging the post's technical claims about WebGPU and AI-generated code; those who do engage are generally positive or curious. **Sentiment:** 55% positive · 35% mixed · 10% skeptical **The case for** - A commenter surfaced jax-js.com as a browser-native JAX-parity library, validating the space the author is working in. - The author's solver apparently passed informal 'test spot' checks from an experienced player, suggesting real correctness. - The project sparked interest from others wanting to build their own solvers given high commercial prices. **The pushback** - The post's characterization of PioSOLVER as using abstractions/cutoff functions was called out as factually incorrect by a knowledgeable commenter. - One commenter expressed disappointment that the post leaned more toward AI/engineering hype than substantive poker-CS content. **By community** - hackernews (mixed): Discussion largely drifted into poker strategy and GTO theory rather than the WebGPU/AI-agent technical angle, with mild positivity toward the project itself but a factual correction and some disappointment about the post's depth. **Hottest debate:** Whether the post's description of PioSOLVER as using approximations is accurate, with one commenter firmly asserting it solves the full game tree without simplifications. **Open questions** - How do re-solve approaches with neural network cutoffs enable preflop solves without requiring a massive game tree? - How does the browser-based solver's performance compare to established commercial solvers like PioSOLVER or GTOWizard? **Highlights** > You should check out https://jax-js.com/. It has parity with quite a large surface area of Jax, and compiles natively in the browser to wasm and webGPU, entirely written in JS. > — [mncalc7 on hackernews · 1 comments](https://news.ycombinator.com/item?id=49115738) > >>A more modern approach instead “re-solves” each spot to a limited search depth and uses a neural network as an approximation function at the depth cutoff. Both tabular (e.g. Piosolver) and neural (e.g. GTOWizard) commercial solvers are available. PioSOLVER doesn't use any abstractions or cutoff functions. It just solves the whole game without any simplifications other than allowed bet sizes. The cost is rather large RAM requirements. The advantages is that it's very precise and produces exact results for every hand (it doesn't bundle them). > — [bluecalm on hackernews](https://news.ycombinator.com/item?id=49115335) > >QQ for all the pro players out there, for 6 or 9-ring poker, can solvers really solve every scenario - or there is simply too many permutations. Solvers can only solve using restricted game trees. Generally only heads-up pots, for one--multiway solvers exist but they are cumbersome and there's no guarantee that their algorithms converge to any kind of optimal play. And within the heads-up game tree, you still need to restrict the size of the game tree with a limited number of bet sizes. Not really a big deal, but in theory a perfect poker player would have a continuous range of bet sizes available for them to use (eg 1bb, 1.5bb, 2bb, 2.5bb, etc), not just a few discrete ones. >The other question I have is how do human players adapt to GTO play now? Like in other games, humans have adapted to novel strategies - I'm curious for poker whether there's ways to exploit GTO solvers (ie, if you put your opponent bot on the GTO range and chase the fat tails). You can't really exploit GTO solvers. But a human player can't play a GTO strategy, it's simply impossible. People can get reasonably good at playing a few of the most common nodes in a low-exploitability way, but beyond that, nobody is placing a perfectly balanced strategy. It's just impossible. The strategies are way too complicated. >And is the poker community's fair play detection algorithm good enough to catch players who use solvers like chess community - or it's easy to evade by making a few deviations. The strongest fair play detector right now, at least at high stakes, is the players themselves. Precisely because playing a GTO strategy is impossible, if someone starts playing too perfectly, other regs will notice. And the high stakes community is pretty small too so everyone knows everyone else, or at least knows who knows them or whatever. Those two things combined mean that there's a lot of self-policing. Also, playing a GTO strategy isn't necessarily always desirable. Equilibrium strategies are fundamentally defensive. A solver will defend at the perfect frequency against a river bet: folding just enough to make you indifferent when bluffing, so that "always bluffing" and "never bluffing" have the same EV (this is technically oversimplified but whatever). But this approach doesn't make the maximum amount of money. To win the maximum, you want to just always fold if your opponent isn't bluffing enough and always call if they're bluffing too much. Of course this opens the door for you to be counter-exploited (if you always fold, they can start bluffing all the time, and vice versa) which is why the solver lands on the goldilocks equilibrium. In other words, a GTO strategy does not punish frequency mistakes, and Hold 'em is a game of frequencies. Of course a GTO strategy will still win money, because people don't just make frequency mistakes, they also make just straight EV mistakes. So there is certainly some risk of being cheated, sure. Another thing that disincentivizes cheating a bit is that you have to be extremely consistent with it. In chess, using an engine in just one or two critical spots could be enough to swing a game completely. In poker, because of the imperfect information & randomness, the wins and losses are distributed far more evenly across time. It's not enough to just check a solver a couple times a session if you're bleeding money in the other hands. Anyway, all of these are real issues, but the bigger issues facing online poker are all just related to game availability and quality: poker sites charging way too much rake, fewer recreational players willing to lose a lot of money online over time, a gazillion legal/regulatory issues that make it hard for people (both professionals and recreational players) to even play online in many places in the world. > — [bugufu8f83 on hackernews](https://news.ycombinator.com/item?id=49117263) > Wow, this is amazing, great read too. I have a few "test spots" I like to use with solvers and yours nailed them. >A more modern approach instead “re-solves” each spot to a limited search depth and uses a neural network as an approximation function at the depth cutoff. This sounds very interesting, I'd love to hear more about it. A few years ago a wrote a solver that worked by reducing the entire game tree. It was slow, and couldn't do preflop. It sounds like these re-solves allow preflop solves with needing a massive tree? > — [ryanto on hackernews](https://news.ycombinator.com/item?id=49115923) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49111523) · 52 points · 28 comments ## Similar posts on daily.dev - [Custom Kernels for All from Codex and Claude](https://daily.dev/posts/custom-kernels-for-all-from-codex-and-claude-78oornvdz) · Hugging Face · 21 upvotes · 2 comments - [How to Build AI Apps in the Browser with TensorFlow.js and WebGPU](https://daily.dev/posts/how-to-build-ai-apps-in-the-browser-with-tensorflow-js-and-webgpu-dpdzsemp2) · freeCodeCamp · 2 upvotes · 0 comments --- Tags: [#ai-coding](https://daily.dev/tags/ai-coding), [#neural-networks](https://daily.dev/tags/neural-networks), [#pytorch](https://daily.dev/tags/pytorch), [#codex](https://daily.dev/tags/codex), [#webgpu](https://daily.dev/tags/webgpu) [View this post on daily.dev](https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"We don't need no stinkin' tensor library","url":"https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x"},"datePublished":"2026-07-30T22:21:15.329Z","dateModified":"2026-07-31T18:09:34.555Z","description":"A developer built a browser-based poker solver using custom WebGPU kernels instead of a general tensor library, using Codex (an AI coding agent) to generate...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/73fb3558e2b0e46c6a2bd9a155a69719?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/73fb3558e2b0e46c6a2bd9a155a69719?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/we-don-t-need-no-stinkin-tensor-library-ju38win9x","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"ai-coding,neural-networks,pytorch,codex,webgpu","timeRequired":"PT6M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"We don't need no stinkin' tensor library"}]} ```