“Vibe coding” is the latest term making the rounds in the world of application development. The basic idea is simple enough: Instead of painstakingly writing every line of code manually, developers describe what they want to an AI coding assistant, review what it produces, adjust, and keep going. Development becomes more conversational, iterative, and, at least theoretically, faster.
There is a lot to like about vibe coding. But somewhere between asking it to “build me an application that does this,” and deploying that application into production sits something that database professionals should be paying very close attention to: the SQL.
AI can generate SQL quickly. It can frequently generate SQL that produces the correct answer. But as every experienced DBA knows, SQL that returns the correct answer is not necessarily good SQL.
And “good enough” SQL can become very expensive when it reaches production.
Functionally Correct Is Not the Same as Efficient
One of the fundamental problems with AI-generated SQL is the same problem we have dealt with for decades with inexperienced developers: The focus tends to be on getting the right result. We check to see if the query returns the requested rows and, if so, great.
Move on to the next task. And yes, we need to make sure that the results are correct, but DBAs know there is more that needs to be done. How many rows were examined to return those rows? Which indexes, if any, were used? Were there any unnecessary table scans? Did the query introduce a sort? Are predicates indexable? Did the joins occur efficiently? Was a Cartesian product accidentally introduced? What happens when the table grows from 100,000 rows to 100 million?
AI-generated SQL can look perfectly reasonable while also containing subtle performance problems. A coding assistant may construct an unnecessarily complicated query, use a function on an indexed column that inhibits efficient access, generate redundant subqueries, or fail to take advantage of an existing index.
The SQL works well until scale arrives.
The Multiplication Effect
This is where database engineering differs significantly from simply generating application code. An inefficient piece of application logic executed once a day may be annoying. An inefficient SQL statement executed 10 million times per day can become an operational nightmare.
Suppose an AI-generated query consumes only a few additional milliseconds of CPU. During development, nobody notices.
The test database is small, response time looks fine, and the application passes functional testing.
Now, multiply those milliseconds by millions of executions. Suddenly, that innocent-looking SQL statement is consuming substantial CPU, increasing I/O, interfering with other workloads, and potentially contributing to higher infrastructure or software costs. This is particularly important for high-volume transactional systems such as Db2 for z/OS, where small inefficiencies multiplied across enormous workloads can become very expensive.
The problem isn’t that AI generated the SQL. Humans have been writing bad SQL since SQL was invented. The difference is velocity. AI enables developers to produce code (including SQL) much faster than ever before. If our ability to review and validate SQL does not increase at the same pace, we simply create technical debt faster.
Don’t Wait for Production
Historically, many times, database performance analysis does not happen until after deployment. An application goes into production. Response time deteriorates. CPU increases. Users complain. Then somebody calls the DBA.
That model was already inefficient. In the era of AI-assisted development, it becomes increasingly untenable. Database performance testing needs to shift left.
SQL should be analyzed as part of the development lifecycle, not after the application reaches production. Developers should receive feedback about problematic SQL while they are still writing and testing the application. That means examining access paths, indexing requirements, predicate construction, estimated costs, cardinality, sorting, joins, and other performance characteristics before deployment. This is because the earlier you discover inefficient SQL, the cheaper it is to correct.
Guardrails for AI-Generated SQL
Organizations adopting AI coding assistants should establish database guardrails alongside their application development guardrails. Automated SQL analysis should become part of the CI/CD pipeline.
Organizations can establish standards that flag potentially problematic SQL automatically. For example, queries might be flagged for review when they perform large table scans, contain Cartesian joins, use questionable predicates, generate excessive sorting, exhibit unexpectedly high estimated costs, or violate established SQL coding standards.
The objective is not to prevent developers from using AI. It is to use AI to accelerate development that is paired with automated controls capable of keeping pace.
And remember that automated analysis does not eliminate the DBA. It makes the DBA more valuable by allowing experienced database professionals to concentrate on exceptions, architectural issues, workload interactions, and difficult performance problems instead of manually inspecting every statement.
AI Needs Database Engineering
For years, some have predicted that automation and AI would reduce the need for DBAs. Instead, AI-assisted development may demonstrate precisely why human-led database expertise remains necessary.
Someone still needs to understand the difference between SQL that works and SQL that scales. Someone needs to understand the workload. Someone needs to recognize when adding an index helps one query, but damages overall insert and update performance.
And someone must understand that optimizing an individual SQL statement is not necessarily the same thing as optimizing the system. Those decisions require someone with context, judgment, and experience. And that “someone” is a DBA.
Vibe coding can dramatically improve developer productivity. But increased development velocity without corresponding engineering discipline can simply deliver problems to production faster.
So, by all means, let developers vibe. Let AI generate code. Let it suggest SQL. Let it accelerate development. But before that SQL reaches a high-volume production database, make sure somebody (or, better yet, an automated process backed by somebody) who understands database engineering asks the question that has always mattered: Yes, it works. But will it perform?