I sometimes joke that I’m a Junior Developer and a Principal Database Administrator, which is why I have a Staff level title. I’m not sure it’s a joke anymore, though.

I’m still an OLTP database specialist, but increasingly I’m also a programmer who commits code in multiple languages. I own pull requests that I ship in a release process, following all the same rules and patterns as other developers. My PRs feature unit tests, integration tests, feature flags, the whole shebang.

Tech roles, including DBA roles, are changing rapidly due to AI coding advances. Don’t use AI to write production SQL code without incredibly heavy review and revisions, but do use it to accelerate shipping your improvements to SQL code.

A Pivotal Hackathon

This shift happened pretty suddenly for me. We had a hackathon at work where some members of our platform team helped everyone who didn’t have a working local dev environment get one running – people managers, Product Managers, everyone. I got things working in just over an hour with the help of the team and a couple of AI agents. I was shocked at how much I could suddenly do, see, and learn in my local environment.

This experience made me realize there was nothing standing in the way of me owning all my code changes completely, even the portions that aren’t SQL code. In that hour, I could see the full stack, understand how my SQL changes connected to the application layer, and make changes across both. It was a revelation.

Before the hackathon, I would identify a problem, identify a change in code or an index, then work with a developer on the application code changes, testing, and feature flag work to get the change shipped. This was always a partnership, which was good. This built relationships with developers. But it was often slow: teams have lots of priorities to manage.

In some ways I worried that owning my own changes fully would mean more separation from dev teams. But actually, shifting things to own my own changes and participating more actively in the code review process on both sides has increased the amount of collaborative time I spend with software engineers.

After the hackathon, I realized I can own nearly all of the performance tuning changes I work on end-to-end. I am increasingly proficient at reading and analyzing C# and understanding the common patterns we use in our codebase, and I learn more with every PR both from AI agent feedback as well as from teammates in code review.

Help from Teammates

For the first couple of PRs that I managed on my own, it was helpful to have a partner on the app dev side to help provide feedback early about my code changes. I was overcomplicating some things, and feedback helped me learn to prompt AI agents better to follow our patterns and practices more simply.

Honestly, the hardest part was getting over my own worries that I was going to mess something up. But practices such as feature flagging and testing, along with my teammates’ code reviews and careful testing both in my local dev environment and load testing environments, helped me gain more confidence in my ability to ship more significant changes and refactor more complex code.

In the past I’ve largely focused on making the most impactful changes I can while taking on the smallest amount of risk where possible. This is still a very useful approach, but sometimes you need to take on a larger problem where there is a high amount of risk that you need to minimize as much as possible: I’m now much better equipped to do that on my own.

Benefits of Owning Changes End to End

I really like shipping my own changes. When I own the code changes, I can iterate faster. I can identify the issue, write the fix, test it, and ship it without waiting for someone else’s schedule to align with mine. This speed matters when you’re dealing with performance problems that are impacting customers.

I have increased understanding of the user experience and how slow or failing code impacts customers. I’m learning more about the developer experience of writing features with SQL code, and what’s easy to do versus hard to do. I can see the full picture, from the database query to the application code to how it impacts the user.

The partnership with developers was valuable, and I still have that. But now I can move faster when I need to, and the collaboration happens more through code review on both sides rather than through handoffs.

AI for App Code: Following Patterns Works Extremely Well

This is where AI really shines for database professionals who are expanding their development skills. AI is quite well trained at generating code with languages like C# and Python, which makes owning all my code changes practical.

I’ve found a few things that work well when using AI with app code. Instruct the AI to look at patterns in the repo. Provide example pull requests for reference on patterns to follow. Work with teammates to continuously improve instructions for agents to help developers with common workflows.

AI also helps me considerably in managing and using development environments. Dev environments are increasingly complex with Kubernetes and lots of orchestration. AI helps me understand each environment, troubleshoot failures, and learn how to effectively test with it. It helps me identify how to click-test or script-test code changes, which helps me identify where SQL is called from on the application side and ensure that testing coverage reaches them all.

Where AI is Terrible for SQL Code

There are some problems with having AI generate SQL code and shipping it without heavy review and testing.

Syntax often doesn’t work. AI tooling typically doesn’t have a sandbox environment to validate the specific dialect of SQL code you’re using. It might mix in some PostgreSQL syntax when you are working with SQL Server, or it might use features that don’t exist in your version. It still often hallucinates syntax that doesn’t exist in any database I can find.

You’ll often get incorrect results. AI will generate queries that look reasonable but return wrong data, or that look unreasonable and also return the wrong data. (To be fair, the same thing can be said about my queries.)

Performance will be terrible. Even if AI has the database schema you’re working with, unless you’ve set it up with a test environment with a realistic production dataset, it will not know how a query will be optimized. How could it? I’ve been working with SQL Server for 20 years and I can’t do this either. Query optimizers are complex, and the rules they apply to a query vary based on many factors, including data sizes, data distribution, and the resources assigned to the production instance.

Where AI is Fantastic for SQL Code

Even with its flaws, AI is a huge help at those “heavy review and testing” tasks when it comes to SQL code, whether you generated that code or wrote it yourself. This is simply a matter of having a helper to generate fairly basic procedural scripts following your instructions.

I frequently use AI to:

• Generate simple tests that prove the code does what it needs to do
• Generate complex tests that compare output of different versions of code to verify the output is correct
• Compare the performance of different versions of code to confirm a tuned version is actually faster with realistic data
• Ensure parameter sniffing-safe code by generating scripts or engineering a test harness to run code in different orders and cache plans at different points
• Research production data distribution by generating queries that help understand why queries perform differently in some environments rather than others

All of these things can be done without AI tooling, of course. AI tooling makes it much more efficient to do this on a regular basis, and to think about ways to write tooling to build this functionality into the developer workflow itself.

Code Review Makes You Better and Builds Collaboration

I should mention that humans are reviewing all my code. While AI can be quite good at application languages, especially when it’s following common patterns, human review is still critical.

Asking others for code reviews also helps remind me that I should be making time on a daily basis for doing code reviews. Code review is a skill that improves with practice. The more PRs I write, the better I get at reviewing other people’s code. I learn what to look for, what questions to ask, and how to provide helpful feedback.

This bidirectional code review process has actually increased the amount of collaborative time I spend with software engineers. Instead of collaborating through handoffs and explanations, we collaborate through code review, which happens more frequently and on a more equal footing.

App Code Projects I’m Thinking About

The hackathon realization that I could own all my code changes opened up possibilities I hadn’t considered before. Now that I’m owning code changes completely, I have several code projects I’m thinking about that would help with database work and observability. These are projects that would have been much harder to pursue when I had to coordinate with developers for every application code change.

Query tagging for observability. I want to tag queries for better observability and improved analysis by code region. I want to automatically inject comments into code, including ORM code, to make it easier to tie queries back to the user experience and build analytics on that. I particularly want to use this to increase the visibility of “clusters” of ORM code that are related, but where queries have unique syntax. Owning both the SQL and application code means I can implement this tagging consistently across the stack.

Flexible load-testing datasets. I’m interested in identifying characteristics of different dataset “flavors” that tend to generate different styles of query plans for customers, and building out flexible load-testing style datasets from them for improved load testing and code validation. One of the historical problems with keeping safe, sanitized or generated performance testing datasets up to date has always been the time and effort it requires. AI offers options for new workflows where it takes on a lot of the toil. Being able to write the scripts and tooling myself means I can iterate on this more quickly.

Multiple query plan paths. I’m thinking about forcing multiple query plan “paths” for very frequent app queries by injecting a static comment value into some of the query strings. SQL Server’s ability to cache plans across sessions conserves memory and CPU, which is great, but for queries that execute at a very high frequency I don’t necessarily want a single query plan in production. If that plan regresses, it impacts everything calling it. I’m thinking about using comments injected into the SQL string at the app layer to help manage this in some scenarios so that I can still get a lot of query plan reuse without having all eggs in one basket. I like the idea of being able to specify having N different query plans per application server, but need to do more research to find the right design to test.

What This Means for Your Career

Database roles are changing. The days of being purely a DBA who only touches SQL Server Management Studio are fading, even for stubborn creatures like me who are most comfortable when curled up snugly inside a complex query execution plan. I don’t have any regrets about the past or not having started out doing more application development – there has been plenty to keep me busy with databases. But, at this point, the barriers are low enough that it doesn’t make sense to NOT become more of a developer.

The hackathon experience showed me that the barrier to owning all your code changes isn’t technical skill. It’s having a working dev environment where it’s safe for you to make mistakes and realizing that nothing is actually stopping you. AI agents make it practical to write application code even if you’re not an expert in C# or Python.

Embracing development skills makes you more valuable. You can ship improvements faster. You can own problems completely. You can understand the full stack, from the database to the application to the user experience.

This doesn’t mean you need to become a full-stack developer. It means you should be comfortable with these skills:

The bad news is that we’re all developers now. The good news is that it doesn’t suck.