This seems like the appropriate first BrentOzar.com blog post in the year 2026, eh?

In the PollGab question queue for Office Hours, MyRobotOverlordAsks asked a question that merited a full blog post answer:

My company announced during some AI training that within the next 12 months we won’t be writing any of our own code. Instead, we’ll be babysitting agents. What’s your opinion on this from a DB dev / DBA POV? MSSQL Dev tends to lag, so I’d personally be surprised.

If this sounds completely alien to you, check out this blog post by developer Armin Ronacher. In it, he discusses how 2025 was the year when he reluctantly shifted his development process to the point where now he spends most of his time doing exactly what MyRobotOverlordAsks’ company is proposing: rather than writing the code directly, he now asks AI tools to build and debug things for him, and he spends his time tweaking what they produce. (Update 2025/01/07: for another example, check out Eugene Meidinger’s post on his uses of AI.)

Inside BrentOzar.com, Richie Rump is the only developer/architect/builder, and he relies heavily on AI day to day. In our company Slack chat room, he’ll frequently describe something he asked AI to build for him, and how it worked out. It’s not a rarity anymore – it’s a regularity.

So, is this going to affect database work?

I think there are 4 major factors that influence my answer.

First, the SQL language is extremely stable and well-documented. This means AI should have a much easier time with database development than it does with application development, which relies on constantly-changing frameworks that don’t have a huge volume of train-worthy articles and samples out online. If this was the only factor involved with AI doing database development, we would see sweeping adoption of AI database tools overnight, game over.

However, second, your existing databases probably aren’t stable or well-documented. The old ones are a hot mess of bad table designs, cryptic column names, and joins across all kinds of disparate systems with completely different histories and naming conventions. The documentation has never kept up with the reality of what’s in the database, and even if it did, the documentation is scattered across all kinds of locations, in different formats. AI can do its best job trying to decipher what the hell is going on, but… it’s not going to be an easy or accurate process.

Third, some database development demands a high grade of security and precision accuracy. If AI builds a to-do list app for you, and the resulting app doesn’t have exactly the layout you want, or doesn’t function quite right on some browsers, or has a few unpredicted side effects where someone can see someone else’s tasks now and then, it’s not the end of the world. Similarly, AI-driven queries often don’t need precision either: after all, your managers were slapping together half-baked NOLOCK queries for decades and calling them a “data warehouse.” That’s fine, and AI stands a great chance of taking over that work. However, some database development requires exacting precision: calculating tax returns, assigning doctors to patients, shipping expensive products to customers, tracking customer balances, etc. Mistakes here are dangerous, and expensive to fix.

Finally, database development tooling is terrible. A lot of for-profit companies compete to build the best development tooling. They make money selling licenses to it, plus use it as a gateway to their cloud services. However, database dev tooling is mostly an afterthought. There’s no one kick-ass IDE that can simply add AI tooling, and revolutionize database work.

There’s an interesting sub-section of the tooling market, though: reporting tools. For-profit companies compete to build the best reporting tools, and those tools usually handle data from lots of different source systems (SQL Server, Oracle, MySQL, Postgres, etc.) The reporting market is cutthroat competitive, and those vendors will be the ones racing to integrate AI first.

What this means for AI in 2026

Because of those factors above, I think that in the year 2026, there’s a pretty good chance that people who work on reporting queries – and preparing data for reports, like data engineers and data warehouse developers – will be the ones at the forefront of AI usage in databases. The reporting and ETL tooling vendors will be the ones who can quickly offer consumers the job of agent steerers rather than query writers.

In addition, people who are building new apps from the ground up in 2026 will likely be using AI right from the start to generate the database schema they’re working with. If they do a good job of that, they’ll keep the relevant context in memory as they work, and it’ll be easy for AI to then generate any necessary queries that an ORM can’t handle by itself. Ground-up new apps built in 2026 won’t yet have the time to build up the complexity that would necessitate a human to get involved in writing a query from scratch, only to steer and make corrections to AI-generated queries.

Those folks who write the reports and build the ground-up apps are also close in proximity to management. Your company’s execs will see the success stories of how their reports get to market faster thanks to AI, and execs will read that as confirmation that AI is the way of the future, even for database jobs.

However, people who are doing mission-critical, secure, accurate database development on large existing databases (and pools of databases) will still struggle in 2026 due to undocumented databases and bad tooling. 2026 won’t be the year that these people can relax back in their chairs, write prompts, and switch to an advisory, steering role rather than a hands-on, typing-furiously role.

In addition, 2026’s newly-built apps will gain complexity and edge cases over time, into 2027 and 2028. The AI tooling used to generate the database schema will change, and the context of the original design will be lost to the sands of time – because even in 2026, people don’t document their databases worth a damn. I would love to see people use extended schema properties to save the context and meaning of each table, column, constraint, relationship, etc, but that hasn’t caught on yet. That means as the new apps age, the humans will gradually have to take the wheel again to write increasingly complex queries and nightly jobs.

I do hope that steering-only future is coming! I would love for everyone’s existing databases to be easy to understand, clearly documented, secure, and to have easily accessible tooling that understood those databases, plus offered AI agents to take control. I have no idea if 2027 will be the year for that, or 2028. But it won’t be 2026.

And I shouldn’t have to mention this, but I feel like I do: none of these words were penned by AI. I do use AI from time to time, like answering Office Hours questions to test AI’s quality back in 2023, and I use AI to write queries. I just draw the line at using it to build content for the blog or training classes, because after all, why would you come here to read something you could generate yourself for free? You come here to get quality human insight (well, at least human insight) that you can’t get from an LLM, so I don’t see the point in using AI to generate content. (On the other hand, LinkedIn is rapidly becoming a cesspool of AI-generated “insight” that people are trying to pass off as their own thought leadership, which is a shame, because for a while there, I was actually enjoying reading LinkedIn content.)