N+1, No Pagination, SQL Injection: AI Didn't Fix Any of Them

The post that named the thing everyone is feeling

On 28 September, a DEV.to post titled "Dear Coder: Open This If You're Feeling AI FOMO" made a small, unfashionable argument: the author skips most of the weekly tutorials on MCP, agents and loop engineering, and is instead spending the time on two problems — how to adopt AI without losing existing skills, and how to identify the problems AI brings. The supporting evidence was three bugs, not three frameworks. Plenty of codebases, the author writes, still suffer from N+1 problems, missing pagination and SQL injection. Most of that code was written before the AI hype. "Now imagine the chaos inside vibe-coded codebases."

Four commenters piled on in agreement, from a university lecturer in Spain who has taught programming since 1998 to a front-end engineer in Accra and a self-taught developer in Virginia. That consensus is the interesting part, because the four of them do not agree about AI at all — only about what happens underneath it.

What the three bugs actually are

These are not exotic failures. They are the boring ones that survive every technology cycle.

An N+1 problem is a database access pattern: your code runs one query to fetch a list of a hundred records, then runs one more query per record to fill in the details. A hundred rows becomes a hundred and one round trips to the database. It works fine on a developer's laptop with ten test rows and falls over in production.

Missing pagination is the same failure of scale at the API layer: an endpoint returns the entire table instead of a page of it. Fast with a thousand rows, fatal with a million.

SQL injection is the oldest of the three. User input gets pasted directly into a database query instead of being passed as a parameter, so anyone who types the right characters into a form field can run their own commands against your data. It has been a solved problem, in the sense that the fix is well known and takes one line, for longer than most working developers have had careers.

Why generated code reproduces them rather than removing them

The commenter from the University of Vigo put the mechanism plainly: if AI is mixing what everyone has written in the past, the output can only be messy until training sources are curated. Models learn from the corpus that exists, and that corpus is the same body of code that contains every unparameterised query and every unpaginated endpoint ever shipped. Nothing in the generation step distinguishes the common pattern from the correct one.

The second half of the mechanism is throughput. As Mika Flowers put it in the comments, AI can generate an implementation incredibly quickly — but a human still has to understand the architecture, recognise when something is wrong, test it, debug it, and decide whether the solution makes sense at all. Generation got faster. Review did not. "Vibe-coded" is the term for what happens when the second step is skipped: code accepted because it ran, not because anyone read it.

That is why the commenters converge on the same posture from different directions. Blaise Akpalu argues fundamentals matter more with AI in the loop, precisely because you have to evaluate and verify what it produces, while still pushing for an agentic workflow where the model handles execution and the developer keeps architecture, context and verification. The original post's ordering is blunter: build real skills first, then leverage AI — in that order.

Questions You Should Be Asking

• Of your own team: when generated code is merged, who read it line by line, and can they name the failure mode it would hit at ten times current load?
• Of any vendor selling an agent: what does the tool do about the three boring bugs — does it detect them, or does it only produce code that runs?
• Of your hiring pipeline: if fundamentals matter more now, what in your interview process actually tests them rather than testing prompt fluency?
• Of the FOMO itself: which of this month's acronyms changed a decision you made, and which ones did you read about and then never use again?
• Of your codebase: do you know how many unpaginated endpoints you currently ship, or are you guessing?

What To Watch Next

Watch whether review capacity becomes the thing teams measure. The argument in this post only holds if unreviewed generated code produces incidents at a rate people notice — the signal will be the first widely-reported outage or breach traced not to a novel AI failure but to an N+1 query or a concatenated SQL string that nobody read before merging. Until then, "pick your battles" remains the cheapest advice on offer.