{"slug": "ai-writing-sql-tips-ai-coding-pitfalls-ai-transl", "title": "AI writing SQL tips, AI coding pitfalls, AI transl", "summary": "A developer's production SQL query generated by an LLM caused a performance death spiral, locking tables and spiking CPU to 98% due to a hallucinated index and a Cartesian product from a missing join condition. Benchmarking GPT-4o, Claude 3.5 Sonnet, and DeepSeek Coder on the same dataset showed Claude 3.5 Sonnet was the only model that caught the Cartesian product risk, highlighting that AI coding pitfalls stem from optimizing for plausible-looking code rather than performant execution.", "body_md": "# AI writing SQL tips, AI coding pitfalls, AI transl\n\nI tried to automate a complex reporting query last Wednesday using an LLM because I was too lazy to map out the joins manually. The query was supposed to aggregate user churn across four different shards, involving several nested CTEs and a few window functions.\n\nIt looked perfect. The AI gave me a beautifully indented block of SQL that looked like it was written by a Senior DBA. I ran it in staging. It worked. I pushed it to production.\n\nThen the alerts started screaming.\n\nThe query wasn't just slow; it was locking tables. I checked the execution plan and realized the AI had hallucinated a non-existent index and suggested a `JOIN`\n\nlogic that created a massive Cartesian product under specific edge cases.\n\nThe specific error wasn't a syntax crash, but a performance death spiral. My monitoring tool showed the CPU spiking to 98% with this warning: `Warning: Query execution time exceeded threshold of 30s. Potential Cartesian product detected in JOIN sequence.`\n\n### The \"Looks Right\" Trap\n\nThe real problem with AI writing SQL tips you see all over the internet is that they focus on syntax. \"Just ask the AI to write a JOIN!\" Sure. But AI doesn't know your data distribution. It doesn't know that your `user_id`\n\ncolumn in the legacy table is a `VARCHAR`\n\nwhile the new one is an `INT`\n\n, forcing a type cast that kills any chance of using an index.\n\nI spent three hours digging through the execution plan. The AI had used a `LEFT JOIN`\n\nwhere a `CROSS JOIN`\n\nwas accidentally triggered because of a missing join condition in a deeply nested subquery. It was a classic case of AI coding pitfalls: the model optimizes for \"plausible-looking code\" rather than \"performant execution.\"\n\nI had to manually rewrite the join logic and add a `FORCE INDEX`\n\nhint just to stop the bleeding.\n\n### Comparing the \"SQL Brains\"\n\nAfter the panic subsided, I spent the weekend benchmarking three different models on the same complex dataset to see who actually understands relational algebra versus who is just predicting the next token.\n\n| Model | Syntax Accuracy | Performance Logic | Schema Awareness | Result |\n\n| :--- | :--- | :--- | :--- | :--- |\n\n| GPT-4o | High | Medium | Medium | Great for snippets, dangerous for 100+ line queries |\n\n| [Claude](/en/tags/claude/) 3.5 Sonnet | High | High | High | Best at spotting logical contradictions in JOINs |\n\n| [DeepSeek](/en/tags/deepseek/) Coder | Very High | High | Medium | Blazing fast, but occasionally misses edge-case NULLs |\n\nClaude 3.5 Sonnet was the only one that caught the Cartesian product risk when I fed it the execution plan. It actually told me, \"Wait, if `table_b`\n\nhas multiple entries for `user_id`\n\n, this will explode your result set.\"\n\n### Why \"Prompting\" Isn't Enough\n\nMost people think the fix is a better prompt. It's not. The fix is a better workflow.\n\nIf you're just copy-pasting from a chat window into your IDE, you're playing Russian Roulette with your database. I started integrating my workflow with a community-driven approach, leveraging [Resources](/en/category/resources/) to find better patterns for AI-assisted debugging rather than just generation.\n\nThe shift was simple: I stopped asking the AI to \"Write this query\" and started asking it to \"Review this execution plan for bottlenecks.\"\n\nWhen you flip the script from *generator* to *reviewer*, the hallucination rate drops significantly. You aren't trusting it to build the house; you're asking it to tell you why the walls are leaning.\n\n### The Hidden Cost of AI Translation Tools Compared\n\nWhile fixing the SQL, I also tried to use an AI translation tool to localize the error messages for our international dev team. I tried three different tools—Google Translate AI, DeepL, and a custom LLM prompt.\n\nThe results were a joke.\n\nThe technical nuances of \"deadlock\" or \"race condition\" got translated into literal phrases like \"locked in a stalemate\" or \"running a race\" in some languages. It was practically useless for a developer who needed to know exactly what the system error meant.\n\nPure translation tools fail because they lack context. An LLM with a system prompt like \"You are a Senior Software Engineer translating technical documentation\" performed 40% better in my blind tests, but it still struggled with specific jargon that only exists in the minds of the people who wrote the original codebase.\n\n### Getting Out of the Echo Chamber\n\nThe most frustrating part of this whole experience was realizing I'd been following \"AI Guru\" advice that suggested blindly trusting AI-generated migrations.\n\nThat's why I joined the PromptCube community. It's not a place for \"top 10 prompts\" lists. It's where people actually argue about why a specific version of Claude handles Python decorators differently than GPT-4. It's a space for developers who treat AI as a volatile tool, not a magic wand.\n\nIf you're tired of the surface-level \"AI will replace coders\" noise, you should jump into PromptCube. It's where the actual troubleshooting happens. You join by finding people who are more obsessed with the `EXPLAIN ANALYZE`\n\noutput than the prompt itself.\n\n### My New SQL Checklist\n\nI don't trust AI with my DB anymore without these three steps:\n\n1. **Schema Injection:** I provide the exact DDL (Data Definition Language) for the tables involved. No \"assume there is a users table.\" I give it the actual types and indexes.\n\n2. **The \"Break It\" Prompt:** Once the AI writes the query, I ask: \"Under what data distribution would this query fail or perform poorly?\"\n\n3. **The Plan Check:** I run the query with `EXPLAIN`\n\nand feed the output back to the AI to verify that it's actually using the indexes I think it is.\n\nIt takes an extra five minutes. It saves five hours of production downtime.\n\n[Next KDE Plasma AI Quota HUD: My Arch Linux Setup →](/en/threads/3799/)\n\n## All Replies （0）\n\nNo replies yet — be the first!", "url": "https://wpnews.pro/news/ai-writing-sql-tips-ai-coding-pitfalls-ai-transl", "canonical_source": "https://promptcube3.com/en/threads/3804/", "published_at": "2026-07-26 18:50:20+00:00", "updated_at": "2026-07-26 19:10:51.204638+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-tools", "ai-safety"], "entities": ["GPT-4o", "Claude 3.5 Sonnet", "DeepSeek Coder", "Google Translate AI", "DeepL"], "alternates": {"html": "https://wpnews.pro/news/ai-writing-sql-tips-ai-coding-pitfalls-ai-transl", "markdown": "https://wpnews.pro/news/ai-writing-sql-tips-ai-coding-pitfalls-ai-transl.md", "text": "https://wpnews.pro/news/ai-writing-sql-tips-ai-coding-pitfalls-ai-transl.txt", "jsonld": "https://wpnews.pro/news/ai-writing-sql-tips-ai-coding-pitfalls-ai-transl.jsonld"}}