A stored procedure called sp_TexasHoldEm lets multiple players compete in a live Texas Hold 'Em game entirely within T-SQL, connecting via SSMS to a public Azure SQL DB Serverless instance. The whole project was built almost entirely by AI: Claude Code and ChatGPT Codex were each given the same prompt to write the stored procedure independently, then set loose on adversarial code review against each other with GitHub Copilot also chiming in. The process surfaced real security issues in AI-generated code, including hole cards left exposed in queryable global temp tables, a certificate fix that accidentally checked a password into the GitHub repo, and neither AI initially considering that temp tables could be updated by malicious players to change hands. The final version merges Claude's more interactive gameplay feel with features borrowed from Codex, plus a companion web page (built by Claude and Codex) for spectators to watch games live. Full source code and setup instructions are published on GitHub.
Table of contents
The BackgroundThe Security Issues Begin to SurfaceComparing the First-Round SolutionsI Have Mixed Feelings About All This.Questions this post answers
What security issues can arise when AI coding agents build multiplayer database applications like a T-SQL poker game?
AI-generated code can leave sensitive data exposed even when it appears to add protections. In one case, hole cards were stored in a global temp table queryable by anyone with tempdb access, bypassing intended masking. A fix using a certificate accidentally committed the certificate's password to the GitHub repo, and neither AI tool initially flagged that global temp tables could be directly updated by a malicious player to change hands mid-game. Developers vetting AI-written database code for security gaps can follow real-world writeups like this on daily.dev.
How can I run a multiplayer game session in T-SQL where multiple SSMS connections interact with shared state?
A stored procedure named sp_TexasHoldEm demonstrates this by tracking player hands per session while using global temp tables or tempdb-based user tables (avoiding permanent tables in user databases) so multiple SSMS windows can join the same game concurrently. It works in both Azure SQL DB and regular SQL Server, waits up to 60 seconds for players to join, and fills empty seats with robot players. Anyone exploring session-based multiplayer patterns in T-SQL can dig into examples like this on daily.dev.