Let Me Tell You What I Actually Needed

I wasn’t trying to do anything particularly impressive when I started this. I just needed to see what was happening inside a SQL Server, right now, without the usual drama of setting up a full monitoring stack.

I didn’t want Grafana or Datadog. I didn’t want agents to install, a new license to justify, or a whole weekend to sacrifice just to get some visibility. I just wanted a clean look at my wait stats in a browser. That was the whole requirement.

So I described it in plain English. Twelve lines of text. I gave those lines to Claude Code and this dashboard is what came back. It is dark-themed, auto-refreshing, and reads live from sys.dm_os_wait_stats and sys.dm_exec_requests. The best part is that it’s built entirely in HTML and JavaScript with no external tools or middleware sitting behind it.

What It Does

The dashboard connects directly to two DMVs. sys.dm_os_wait_stats gives the cumulative picture since the last server restart. sys.dm_exec_requests shows what is actively waiting right now. No middleware. No agent. Just those two views and some JavaScript doing the work.

Here is what it covers:

• Categorises every wait type into CPU, I/O, Memory, or Other
• Shows cumulative wait time since the last server restart
• Lists top wait types by total wait time
• Shows average wait time per task
• Shows active waits happening at this exact moment
• Charts for wait distribution across all categories
• Breaks down signal wait versus resource wait
• Recommendations panel based on what the server is actually doing
• Auto-refreshes every few seconds
• Highlights CPU pressure when signal wait crosses 25%

The signal wait versus resource wait split is honestly the most important thing here. Signal wait is how long a thread sat waiting just to get back on the CPU after it was already ready to run. That has nothing to do with your disk. Nothing to do with memory. That is purely CPU pressure. When that crosses 25% of total wait time, you have a specific problem, and this dashboard will tell you clearly.

The recommendations panel at the bottom is not generic. It reads what is actually happening and gives you something practical. The kind of thing a DBA would say after looking at the numbers, not after reading a checklist.

The Exact Prompt

I want to be honest about this. I did not write clever prompt engineering. I just wrote what I wanted.

Create a SQL Server wait statistics analysis dashboard.
Use sys.dm_os_wait_stats and sys.dm_exec_requests.

Requirements:
- Categorize waits into CPU, I/O, Memory and Other
- Show cumulative wait time since last restart
- Display top wait types
- Show average wait time per task
- Show active waits
- Charts for wait distribution
- Signal vs resource waits
- Recommendations based on patterns
- Modern dark themed dashboard
- Auto refresh every few seconds
- Highlight CPU pressure if signal wait exceeds 25%

That is it. Claude Code took that, figured out the right DMVs, categorised the wait types correctly, filtered out the benign ones, wrote the delta logic for the refresh, built the charts, wired the recommendation engine, and produced the full CSS. One pass. The screenshot above is what came out.

Why I Was Building This

This isn’t just a hobby project; I am actually building this as a Proof of Concept for an organization I am helping. I will deliver this first version, and then their internal team will take it over and adapt it for their own environment. My role eventually shifts into mentoring and guiding them as they build it out further.

Interestingly, this is the second time in the last month that a project has followed this exact pattern. An expert comes in, uses AI to compress weeks of work into a few days, delivers a working foundation, and then moves into a teaching role. It is starting to feel like a new standard for how technical consulting is going to work from now on.

Some honest reflections

I want to be honest about this part as well.

I have been doing this work for more than twenty years, so I know very well what it normally takes to build what you see in that screenshot. Just the query part alone is a heavy lift. You have to get the categorization right, decide which waits to ignore, and make sure the refresh is actually showing rates instead of just raw totals. That alone is a solid afternoon of work for someone who really knows these DMVs. This isn’t a task for a junior person; it is for someone who has lived inside this data for years.

Then you have to add the UI. You need a refresh loop that does not abuse the server, the threshold logic for alerting, and a recommendation engine that actually says something useful instead of something obvious. That is easily another half day of effort.

I have built different versions of this many times across many different projects. So when I watched something like this come out of just twelve lines of plain English, I did not feel proud. I did not feel excited in the usual way. I felt something I still have not fully named. It was something quiet and a little unsettling.

The bottleneck was never just the code. It was always knowing what to ask for. That gap has now become very small.

And here is what keeps coming back to me. I knew what to ask for because I have spent years doing this the hard way. I know what signal wait means because I have watched it climb during real incidents, at night, when the pressure was on. I knew what it meant before I even finished reading the number.

I know why 25% is the right threshold because I have seen both sides of it enough times that it stopped being a number and became a feeling.

The prompt was twelve lines. What was behind the prompt was twenty years.

The Thing Nobody Wants to Say Directly

There is a comfortable version of this story where AI just helps people build faster, barriers come down, and more people can create useful things. All of that is true. But sit with this for a moment.

The junior developer who spent three years building things slowly and getting them badly wrong was not wasting time. Every execution plan that left them confused, every dashboard they built that answered the wrong question, and every 4 AM incident where they guessed wrong three times before finally getting it right was depositing something into them. It is something very difficult to name but very easy to feel when you are in a room with someone who has it and someone who does not.

That slow, painful, and sometimes humiliating process is now being compressed.

The honest question, the one that nobody at a conference will ask out loud, is whether compressed experience produces the same thing as slow experience. We have to wonder if it produces something that looks exactly the same until the moment everything is on fire and it suddenly does not.

I am not saying one is better than the other, but they are certainly different. That difference will show up at the worst possible time: when the dashboard looks fine, the query looks correct, the wait stats look normal, and yet the system is still struggling. That moment is coming for everyone, and the person you want in the room at that moment is very specific.

What This Actually Means If You Are a SQL Server Professional

If you are a junior or mid-level data pro, the “grunt work” of the job is basically changing overnight. The hours spent writing standard monitoring queries, building routine dashboards, or setting up basic alerting are going to be compressed into minutes. That part is moving faster now, and there is no going back.

But there is a core part of this job that isn’t going anywhere: the intuition. AI can build the instrument, but you still need someone in the room who actually knows how to read the gauges. Knowing which DMV to point at for a specific symptom is one thing, but understanding that CXPACKET by itself tells you nothing without checking your MAXDOP settings and the actual query plans is another. It is that split-second judgment to look at an automated recommendation and know if it actually fits your workload or if it is just generic advice that might actually tank your server performance.

That kind of “knowing” does not come from generating tools quickly. It comes from years of watching those tools give you the wrong readings and learning exactly when to trust the dashboard and when to ignore it and dig deeper.

The dashboard came together in minutes. What it takes to understand what the dashboard is actually telling you, that still takes years.

The one thing that has not changed in all of this is that your server is waiting on something right this second. There is critical information sitting inside sys.dm_os_wait_stats right now that you probably have not looked at this week, or maybe even this month, mostly because setting up that kind of visibility always felt like a massive chore.

Well, that excuse is officially gone. The prompt is in the blog post. Go run it, get the dashboard up, and then actually take the time to sit with what the numbers are telling you. That is the one part of the job I cannot put into a prompt for you.

Reference: Pinal Dave (https://blog.sqlauthority.com/), X

First appeared on AI Built SQL Server Wait Statistics Dashboard in Minutes

So after the session, one of the senior DBAs, let us call him Ramesh, asked me if we could grab a chai. I said sure. I thought he wanted to discuss query performance or maybe an Always On Availability Group issue. But the moment we sat down at the cafeteria, he said something that hit me hard.

“Pinal, I have been a DBA for 17 years. My entire career I have tuned queries, managed backups, handled disaster recovery. Last month my manager showed me a demo where an AI tool automatically identified slow queries, suggested index changes, and even predicted storage issues before they happened. He was very excited. I was smiling during the demo. But inside, I could not breathe.”

He paused. Then he said the thing I have been hearing from so many people these days.

“Who will pay my home loan if this AI does my job?”

Friends, I have been writing on this blog for nearly two decades now. I have written about deadlocks, about execution plans, about career advice. But today I want to write about something that is not technical at all. It is deeply personal. And I am writing this because in the last six months, I have had this exact conversation with at least thirty to forty data professionals. In airports, at conferences, over Zoom calls, and over too many cups of chai to count.

The fear is real. And it is not the kind of fear you can fix with a certification.

The 2 AM Math That Nobody Posts on LinkedIn

Here is what happens when a data professional starts worrying about AI replacing their job. They do not immediately go and update their resume. No. First, they lie in bed at night and do mental arithmetic.

Home loan EMI. INR 47,000 per month. Car loan. INR 12,000. Credit card outstanding from last month because the washing machine broke down and the kid needed new school uniforms at the same time. School fees due in April. The insurance premium they keep forgetting about until the reminder SMS (text) comes. The SIP they started last year and are now wondering if they should stop.

I know this because Ramesh told me this. And Suresh from Hyderabad told me the same thing two weeks later. And a woman named Anitha who works as a data analyst in Chennai told me almost the exact same numbers, just with different amounts. The specifics change. The fear is identical.

Nobody talks about this on LinkedIn. On LinkedIn, everyone is “excited about AI” and “embracing the future” and posting about how they built a RAG pipeline over the weekend. Good for them. But behind those posts, a very large number of people are quietly terrified. And they feel like they cannot say it out loud because it will make them look weak or outdated or, worst of all, replaceable.

Well, I am going to say it out loud. If you are scared, you are not weak. You are paying attention.

The Story of the DBA Who Got “Optimized”

Let me tell you about someone I will call Vikram. He reached out to me through email about four months back. He had been working as a Database Administrator at a mid-size IT services company for about eleven years. Solid guy. Knew his SQL Server inside out. The kind of DBA who could look at an execution plan and tell you the problem in thirty seconds. Old school. Reliable. The person everyone called when production went down at 3 AM.

His company started using an AI-powered database management platform. At first, it was positioned as a “helper tool.” Vikram was even asked to evaluate it. He gave honest feedback. He said it was good for basic monitoring but could not handle complex performance issues. His manager nodded.

Three months later, his team of six DBAs was reduced to two. Vikram was one of the four who were let go. The official reason was “restructuring and automation efficiency.” The AI tool that he himself evaluated had, in a way, written his own termination letter.

When he called me, he was not angry. That is what surprised me. He was just… lost.

He said, “Pinal, I gave them eleven years. I missed my son’s annual day function twice because of production issues. I worked on Diwali. And now I am sitting at home and my wife is asking me what happened and I do not even know what to tell her.”

He had an EMI of 52,000 rupees per month for a flat he bought in 2019. His wife was not working because they had decided she would stay home until the younger child started school. He had about four months of savings. Four months. That is the distance between “we are fine” and “we are in trouble.”

I did not have a perfect answer for Vikram. Nobody does. But we talked for a long time, and I will share what I shared with him later in this post.

The Business Owner Who Cannot Sleep

It is not just employees, friends. Let me tell you about another conversation.

I was doing a consulting engagement for a small analytics company. About 80 employees. The founder, I will call him Mehul, built this company from scratch about eight years ago. Started with three people and a shared office space. Now they have a proper office, a decent client list, and a team that genuinely likes working there.

Mehul is the kind of boss who orders biryani for the entire office on Fridays. He gives Diwali bonuses even in bad years because he says “people work hard, they should feel valued, they should know it matters.” He personally calls every employee on their birthday. That is the kind of person he is.

After the consulting session, Mehul asked me to stay back. He closed the door and I could see his face change. The confident business owner was gone. In front of me was a tired, worried man.

He told me that three of his biggest clients had already started cutting scope. One of them had directly told him,

“Mehul, we like your team, but our management is asking why we are paying for analysts when we can use AI tools for half this work.”

Another client had not renewed their contract and just gone silent. You know what that silence means in business. It means they are already gone, they just have not told you yet.

Mehul pulled out his laptop and showed me his monthly expense sheet. Payroll alone was almost 38 lakhs a month. Office rent, meals, software licenses, insurance, everything added up to nearly 50 lakhs monthly. His revenue pipeline for the next quarter had dropped by 40%.

He looked at me and said,

“Pinal, I have 80 families depending on me. I am not sleeping. My wife thinks I am fine because I crack jokes at dinner but I am doing calculations in my head 24 hours a day. Do I cut people now and save the company? Do I wait and hope clients come back? If I shut down, what happens to Rajesh who just took a home loan last month because I told him the company is doing well?”

That last sentence. Read it again. “Rajesh took a home loan because I told him the company is doing well.” The guilt in Mehul’s voice when he said that, I cannot describe it to you in words.

The Data Analyst Who Stopped Going to the Office Canteen

One more story. Small one, but it stayed with me.

I was at a SQL Server community event. During the break, a young data analyst, maybe 28 or 29, came up to me. She said she loves reading my blog and then she asked me a question that caught me off guard.

“Sir, I have stopped eating in the office canteen. I bring food from home now. I cancelled my Netflix. I returned a kurta I bought online. Am I overreacting?”

I asked her why. She said her entire team of data analysts was told that the company is evaluating AI tools that can generate reports and dashboards automatically. Her team lead had said it casually in a meeting, like it was no big deal. But she went home and could not sleep for three nights.

She said, “I have a credit card bill of 23,000 rupees that I was planning to pay in two installments. Now I am paying it in full this month because what if I do not have a job next month? My parents think I am settled. I send them money every month. How do I tell my father who brags about his daughter’s IT job to his friends in the village that AI might take away my job?”

She was not crying. She was very composed. But her hands were shaking slightly while she held her tea cup. That image has not left my mind.

Friends, this is the reality on the ground. Not the shiny AI demos on YouTube. Not the fancy keynotes at tech conferences. A young woman returning a kurta because she is scared about her future. A DBA staring at his home loan statement. A business owner doing mental math during Friday biryani.

OK, But What Do We Actually Do? The Employee Side.

I am not going to give you advice that sounds good on a slide but means nothing in real life. Let me share what I have actually been telling people in my conversations.

Number one, and I cannot stress this enough, learn the AI tools that are threatening your job. I know this sounds counterintuitive. The thing you are scared of, go and learn it. When I told Vikram this, he said, “Pinal, why would I learn the thing that replaced me?” And I said, “Because the companies that are adopting AI still need people who understand the domain AND the AI. The AI can suggest index changes but it does not understand the business logic behind the database design. You do. The combination of your 11 years of database knowledge and AI skills makes you incredibly valuable. Either of those things alone, not so much.”

Vikram started learning AI and ML basics, started understanding how these automated DBA tools work under the hood, and last month he got a new role as a Senior Database Reliability Engineer at a company that specifically wanted someone who understood both traditional database management and AI-driven operations. His salary is actually 20% more than his previous job. I am not making this up to give you a feel-good ending. This actually happened. But it happened because he did the hard thing when he was scared, not after he felt ready.

Number two, move toward the messy, complex, human problems. AI is fantastic at clean, repeatable, well-defined tasks. Writing a standard SQL query. Generating a dashboard from clean data. Creating a summary report. You know what AI is terrible at? Sitting in a meeting where the sales team says the data is wrong and the finance team says the data is right and the CEO is frustrated and someone needs to figure out that the actual problem is that two departments are using different definitions of “active customer.” That is a human job. That requires empathy, politics, communication, and domain knowledge. Move toward those problems. Be the person who solves the problems that require understanding people, not just data.

Number three, get your money situation under control, and I mean right now. Pay off that credit card. Not next month. Now. Build an emergency fund. Even if it is 5,000 rupees a month, start. Reduce your EMI burden if you can by prepaying loans. I know this is not exciting advice. Nobody wants to hear “budget better” when they are scared about their career. But I have seen the difference between someone who loses their job with six months of savings and someone who loses their job with zero savings. The first person is stressed but functional. The second person is in panic mode and makes terrible decisions.

Number four, start building something that is yours. A blog, a YouTube channel, a small consulting practice, a training course, something. I started SQLAuthority many years ago not because I was a genius but because I wanted to share what I knew. That blog has opened more doors for me than any single job ever could. You have knowledge. You have experience. Start sharing it. Start building a professional identity outside of your company’s email ID. If your job disappears tomorrow, your company’s email ID goes with it. But your blog, your YouTube channel, your reputation in the community, that stays with you.

Number five, and this is the one people always skip, talk to your family. Have the conversation. “I want to discuss something about my work. The industry is going through changes. I want us to be prepared.” You do not have to scare them. You do not have to cry. Just be honest. I have seen too many people carry this burden alone until it becomes a health problem. Your spouse, your parents, your close friends, they deserve to know what you are dealing with. And you will be surprised how much lighter you feel when you are not carrying it alone.

The Business Owner’s Playbook for Survival

Mehul and I had a very long conversation that day. Here is what I shared with him, and I have since shared with several other business owners in similar situations.

First, figure out exactly what AI can and cannot replace in your business. Not in theory. In practice. Mehul and I sat down and went through every service his company offered. We found that about 40% of their work was standard reporting and dashboarding that AI tools could genuinely handle. But 60% was complex analytical work that required understanding the client’s industry, their specific quirks, their internal politics, and their unspoken expectations. AI is not doing that anytime soon. The problem was, most of the revenue was coming from the 40% side. So we had to figure out how to shift the revenue mix.

Second, start using AI yourself before your clients replace you with AI. Mehul was resisting AI tools because he saw them as the enemy. I told him, “The enemy is not AI. The enemy is a competitor who uses AI to deliver faster and cheaper than you.” He started integrating AI tools into his workflow. His team could now deliver the basic reports in one-fourth the time. He passed some of that efficiency to clients as cost savings and used the rest as margin. His clients actually came back for more work because he was now cheaper AND faster AND still had the human expertise layer on top.

Third, have the honest conversation with your team. Not the corporate HR scripted conversation. The real one. Mehul gathered his team and said something like, “Look, our industry is changing. Some of the work we do is going to get automated. I am not going to lie to you about that. But here is what I am doing about it, and here is how we can adapt together.” He told me the response blew him away. Three of his senior analysts came back with proposals for new service offerings. Two people volunteered to become AI tool specialists. One person said, “Mehul, I have been wanting to tell you that our competitor is already doing this, but I was scared to bring it up.” The honesty unlocked ideas he would never have gotten if he had kept pretending everything was fine.

Fourth, protect the human stuff as long as you can. The Friday biryani. The Diwali bonus. The birthday calls. Cut costs in other places. Renegotiate the office lease. Reduce software licenses you are not fully using. Switch to a co-working space if you have to. But the things that make people feel like they are part of a family, protect those. Because when this storm settles, and it will settle eventually, the businesses that are still standing will be the ones where good people chose to stay because they were treated like human beings and not like resources.

Fifth, if the business cannot survive in its current form, help your people land well. If the worst happens and you have to shut down or dramatically downsize, do it with dignity. Give people as much notice as you can. Write them genuine recommendation letters. Connect them with your network. Help them find jobs. Mehul told me, “If I have to shut down, I want every single person to know that I fought for them until the end.” That is not weakness. That is leadership.

The Real Talk About Data Professionals Specifically

I want to speak directly to my SQL Server community, my data professionals, my DBAs and data analysts and BI developers and data engineers. Because this hits close to home for all of us.

The honest truth is that a lot of what junior and mid-level data professionals do today is going to get automated. Writing basic queries, building standard reports, setting up routine monitoring, creating simple dashboards. AI tools are already doing this reasonably well and they are going to get better. If your entire value proposition is “I can write T-SQL queries,” you are in trouble. Not because T-SQL is going away, but because the barrier to getting a T-SQL query written just dropped to near zero.

But here is what AI cannot do. It cannot understand why a query matters. It cannot sit with a business user who says “the numbers look wrong” and spend two hours tracing the issue back to a data pipeline that was silently dropping records because of a timezone conversion bug that only happens on the last Sunday of March when daylight saving kicks in. I am not making that up, by the way. That was an actual issue I debugged last year and it took me, a human being with years of experience, nearly a full day to trace. An AI would have looked at the query and said “the query is correct.” Because the query WAS correct. The data was wrong. And understanding why the data was wrong required understanding the entire system, the business context, and the weird edge cases that only a human would think to check.

That is your value. The deep understanding. The weird edge cases. The ability to say “this number does not feel right” based on years of looking at data. The ability to explain to a non-technical CEO why their pet project’s dashboard is misleading without making them feel stupid. The ability to design a database that will still make sense five years from now when the business has changed in ways nobody can predict.

Move toward that. Grow into that. AI is taking the floor. You need to get to the next floor up.

A Word About Mental Health Because Nobody Ever Talks About It in Tech

I want to say something that might feel out of place in a tech blog. But I do not care. It needs to be said.

If the AI fear is keeping you up at night, if you are snapping at your kids because you are stressed, if you are doom-scrolling AI news at midnight, if you have stopped enjoying things you used to enjoy, please talk to someone. A friend, a family member, or a professional counselor.

I spoke to a DBA who told me he had developed a nervous twitch in his eye from stress. He laughed about it, but it was not funny. I spoke to a team lead who told me she had started having anxiety attacks on Sunday evenings because Monday morning meant another week of wondering if the “transformation” announcement was coming.

Career stress is real stress. Financial anxiety is real anxiety. The feeling that the ground is shifting under your feet while everyone around you seems fine is incredibly isolating. You are not being dramatic. You are a human being dealing with a very human problem.

Take care of yourself, friends. No job, no EMI, no career, nothing is worth your mental health. And ironically, you will make much better career decisions when you are not operating from a place of pure fear.

The Bottom Line

I am not going to tell you that everything will be fine. I do not know that. Nobody does. What I do know is that the people who are having honest conversations, who are learning new skills even when it is uncomfortable, who are getting their financial house in order, and who are building their professional identity beyond their current job title, those people are going to be in a much, much better position than the people who are pretending this is not happening.

The mortgage payment is due on the first. The credit card bill will come. Your kids will still want to go to that amusement park. Your parents will still need that monthly transfer. None of that stops because the tech industry decided to change the rules.

So do not wait for the perfect moment. Do not wait until you feel ready. Do not wait for someone to give you permission. Start today. Learn one new thing this week. Have one honest conversation. Save one extra thousand rupees. Make one connection.

And if you are a business owner, look at your team tomorrow morning when they walk in. Those are real people with real lives. Fight for them. Adapt for them. And if you have to make hard decisions, make them with honesty and humanity.

We have been through disruptions before. We will get through this one too. But only if we stop pretending it is not happening and start doing the hard, unglamorous, scary work of adapting.

I will leave you with what Ramesh, that DBA from Bangalore, told me at the end of our chai.

“Pinal, I am not going to let a machine decide my family’s future. I am going to figure this out.”

He said it with such determination that I believed him.

I believe in you too. But belief without action is just hope. And hope is not a strategy.

Now close this blog post, open that AI tool you have been avoiding, and start learning. The chai break is over.

Reference: Pinal Dave (https://blog.sqlauthority.com), X (twitter). 

First appeared on Who Pays My Bills if AI Takes My Job?

The most useful thing I can do is to tell you that a large number of the problems people hire me or email me for can be solved without hiring me. Free of cost. Tonight. With tools that exist right now and work remarkably well.

I have been doing SQL Server performance tuning for over two decades. I have a blog, I have written books, I have seen environments so broken that I needed a moment of silence before I could begin. And from that vantage point, with complete sincerity, I am telling you to try AI first. Not because I am being modest. Not as a marketing trick where I say that and you think “wow what a humble guy, I will hire him immediately.” I mean it practically and literally. There is a real chance you do not need me at all.

Here is where AI is genuinely, legitimately excellent at SQL Server performance work. Please go through this list before you consider emailing me.

1. Reviewing a single slow query. Paste your query, paste your execution plan XML, describe the table sizes, and a good AI will give you shockingly useful advice about missing indexes, implicit conversions, parameter sniffing, and scan vs seek patterns. This works well. Do this before you call anyone.
2. Explaining wait stats output. Copy your sys.dm_os_wait_stats results into AI and ask it what the top waits mean. It will explain CXPACKET, PAGEIOLATCH, ASYNC_NETWORK_IO, and SOS_SCHEDULER_YIELD clearly and correctly in plain English. It is genuinely good at this.
3. Reviewing your index strategy on a specific table. Give AI your table DDL, your most common query patterns, and your existing indexes. It will give you a surprisingly sensible opinion about which indexes are redundant, which are missing, and whether your clustered index key is reasonable.
4. Understanding execution plan operators. Hash joins, nested loops, key lookups, sort warnings, parallelism operators. AI explains all of these clearly and can tell you why the optimizer might have chosen them. This used to require reading thick reference books cover to cover. Now you just ask.
5. Writing initial DBCC and maintenance scripts. Index rebuild vs reorganize thresholds, statistics update scripts, integrity check routines. AI can produce a solid first draft of all of these, correctly, with reasonable defaults. You should still review it. But it is a very good first draft.
6. Understanding SQL Server configuration options. Max degree of parallelism, cost threshold for parallelism, max server memory, trace flags. AI knows the textbook answers and the common recommendations. It is right surprisingly often.
7. Explaining deadlock XML graphs. Paste the deadlock XML from your system health session and ask AI to explain who was the victim, what resources were contested, and what the general pattern looks like. It handles this well.
8. Reviewing your backup and recovery strategy. Describe your RPO and RTO requirements, your database sizes, your recovery model settings. AI will point out obvious gaps and ask the right clarifying questions. It is useful here.
9. Getting a plain-English explanation of a confusing error message. “Error 823” or “I/O request taking longer than 15 seconds” or the ever-mysterious “A fatal error occurred while reading the input stream from the network.” AI will tell you what these mean and what to investigate first.
10. Learning concepts before a meeting with a consultant. If you do eventually hire someone like me and want to get the most out of that time, spend 30 minutes the night before asking AI to explain wait stats, execution plans, and TempDB contention. You will get so much more value from the session. I genuinely recommend this. I am not joking.

Now, in the spirit of full honesty, AI has had its share of misses too. But that is a story for another post entirely, and I have plenty of those stories saved up. If you have a SQL Server problem, your first call should be to a chatbot, not to me. Try the ten things above. Try them seriously. A meaningful percentage of you will solve your problem completely and never need to email me at all, and I will consider that a genuine win.

But if you have worked through this list, given AI a genuine shot, and something is still quietly ruining your Mondays, then perhaps what you need is someone who has sat inside 400 plus SQL Server environments, and who will explain every single thing while your hands stay on the keyboard and your passwords stay in your head.

That is what the Comprehensive Database Performance Health Check is. A focused 4-hour Zoom session where we work through your SQL Server together, I share every script I run and explain each one, and you walk away genuinely understanding what was wrong and how to keep it from coming back.

Reference: Pinal Dave (https://blog.sqlauthority.com), X (twitter). 

First appeared on Hire AI and Not Me: Human Can Make Mistakes

The Night a Query Finished Before I Did

I have seen this pattern before. Cardinality estimation gone wrong. Parameter sniffing, maybe. Or outdated statistics. This is the kind of puzzle I have solved for decades. You start with sys.dm_exec_query_stats. You check wait stats. You glance at missing index DMVs, but you do not trust them blindly. You think about workload patterns, concurrency, memory grant pressure. It is not just technical analysis. It is instinct, built from years of late-night production calls and early-morning postmortems.

Out of curiosity more than need, I pasted the query and some surrounding details into an AI assistant.

Within seconds, it responded with structured reasoning. It pointed out the Key Lookup and suggested a covering nonclustered index. It mentioned parameter sniffing and recommended OPTIMIZE FOR or OPTION (RECOMPILE). It even explained the row estimate mismatch in plain, simple language.

I stared at the screen.

Not because it was revolutionary. But because it was fast.

And in that speed, something inside me felt unsettled.

When Your Brain Has Always Been the Optimizer

For most of my career, I have joked that my brain is the real query optimizer. Before SQL Server decides on a plan, I have already predicted what it might choose. If a table has skewed data distribution, I can almost sense where the plan will break. If the memory grant is too generous, I anticipate spills to tempdb. If CXPACKET waits suddenly spike, I am already thinking about parallelism thresholds and cost threshold for parallelism before anyone opens sp_configure.

This ability did not come from reading documentation alone. It came from nights spent firefighting blocking chains. From watching deadlocks unfold in Profiler. From tuning queries where a missing index was not the answer because the entire data model needed to be rethought. That kind of thinking was never mechanical. It was deeply personal. It was the craft of performance tuning. Messy, hard-won, and irreplaceable.

So when a machine begins to replicate parts of that thinking, even partially, it touches something beyond convenience.

It makes you question whether what you believed was uniquely earned can now be simulated.

That is not an easy feeling to sit with.

The Execution Plan of the Ego

There is a quiet comparison that happens when you read AI-generated analysis of a complex SQL Server issue. You read it and instinctively measure it against your own thinking. You ask yourself, would I have explained the memory grant issue this way? Would I have pointed at the Nested Loops operator first? Sometimes you feel reassured because you spot the gaps. The AI suggests creating an index without considering write overhead on a busy OLTP system. It does not understand that this database runs 24×7 and cannot afford heavy index maintenance windows. It does not factor in the fragmentation that a wide nonclustered index will introduce on tables with high insert rates.

But sometimes, and this is the uncomfortable part, the explanation is clean. Logical. Structured. It reads like something you would confidently present in a performance review meeting.

And in that moment, your ego runs its own little execution plan. It calculates your value. It estimates your uniqueness. It checks its own cost model.

If clarity can be generated in seconds, what exactly is your edge now?

That question is not really about job security. It is about identity.

Information Is Not the Same as Judgment

AI can scan massive volumes of SQL Server documentation in an instant. It can explain the differences between READ COMMITTED SNAPSHOT and SERIALIZABLE isolation levels. It can talk about fragmentation thresholds, fill factor adjustments, statistics update strategies, and Query Store baselines. It can even walk through troubleshooting steps using DMVs in a way that sounds remarkably competent.

But it does not sit in the room when a wrong index decision causes write latency to climb across the entire OLTP workload. It does not remember the production outage three years ago where a well-intentioned index change triggered unexpected lock escalation during peak hours. It does not feel the weight of looking a business leader in the eye and telling them that their reporting query is fundamentally flawed, and that the fix is a redesign, not a hardware upgrade.

Experience changes how you think. Not just what you know, but how carefully you apply it.

When I recommend creating an index, I am not thinking about that one query alone. I am thinking about write overhead, maintenance windows, fragmentation behaviour, rebuild strategy, storage impact, and long-term scalability. That layered thinking comes from consequence. From having made decisions that went wrong and learning from them in real time, under real pressure.

Consequence cannot be simulated.

The Danger of Relying on Instant Answers

There is another uncomfortable truth here. AI reduces friction. And friction is exactly where expertise gets sharpened.

When I first learned performance tuning, I manually inspected execution plans operator by operator. I traced each arrow. I looked at estimated subtree cost and compared it against actual runtime behaviour. I learned, slowly and painfully, to correlate wait stats with workload patterns. That struggle built instinct. It trained my internal model of how SQL Server behaves under stress.

If I now rely entirely on AI-generated summaries to interpret execution plans, I will certainly save time. But will my internal model stay sharp? Will I still be able to diagnose a complex concurrency issue without outside help? Or will my brain slowly offload pattern recognition to an external system, the way muscles weaken when you stop using them?

This is not about rejecting AI. I am not arguing for that.

It is about protecting cognitive depth.

Because output can remain high while depth quietly decreases. And depth is what makes expertise resilient, especially in the moments that matter most.

From Solver to Strategist

Over time, I have started to see this shift differently. AI is not replacing my thinking. It is changing my role.

Earlier, I was the primary solver. I was the one who found the answer. Now, I am increasingly the strategist. AI can suggest ten tuning options. It can propose query rewrites, index additions, MAXDOP adjustments, changes to cost threshold for parallelism. It can generate those recommendations quickly and coherently.

But I decide which lever to pull.

I decide whether a plan guide makes sense for this particular scenario. I decide whether forcing a plan through Query Store is safe given this workload’s volatility. I decide whether the right answer is a configuration change, an architectural redesign, or an honest conversation with the development team about how their code interacts with data.

Decision-making under uncertainty remains deeply human. And as the number of available options multiplies, judgement does not become less important. It becomes more critical.

The Real Evolution

The strange emotional shift of working alongside a machine that “thinks” is not dramatic or loud. It does not arrive in a single moment. It is gradual and deeply personal. It forces you to sit quietly with yourself and examine what part of your expertise is information and what part is wisdom.

When I look at a slow SQL Server today, I still open the execution plan manually. I still examine wait stats. I still think carefully about memory grants, parallelism, index design, and workload patterns. Those habits are not going anywhere.

But I also allow myself to collaborate. I use AI to pressure-test my assumptions, to explore alternate approaches I might not have considered, to draft structured explanations faster than I could on my own. And then I layer my experience on top of it.

The machine may suggest an index. But it does not carry the responsibility of implementing it in production at 2 AM when hundreds of users are active. It may produce reasoning about deadlocks or blocking chains. But it does not carry the memory of past incidents that make you cautious. The ones that taught you to pause before acting, even when you are confident.

It does not feel the pressure of accountability. That remains entirely human.

In the end, this shift is not really about machines becoming intelligent. It is about us becoming more intentional about how we think. If we use AI carelessly, it will slowly replace depth with convenience. If we use it consciously, it will amplify decades of hard-earned experience into something even more powerful.

The choice is not technical. It is psychological.

And that choice still belongs to us.

Reference: Pinal Dave (https://blog.sqlauthority.com), X (twitter). 

First appeared on The Strange Emotional Shift of Working Alongside a Machine That “Thinks”

Friends, last week I was sitting in a coffee shop and a young developer came up to me. He said, “Pinal bhai, I built an entire application last weekend and I did not write a single line of code myself.” I looked at him. I thought he was joking. He was not joking. He showed me the app on his phone. It was working. It was clean. And he built it by simply talking to an AI. That is vibecoding. And trust me, once you understand it, you will not look at software development the same way again.

Today I am introducing this new Vibecoding icon, and anyone is free to use it in their posts, projects, and experiments.

So What Exactly Is Vibecoding?

Let me explain it simply. Vibecoding means you describe what you want to build in plain English, and an AI tool writes the code for you. You do not open Visual Studio and start typing SELECT statements (I know, heartbreaking for a SQL guy like me). Instead you open an AI coding tool and say something like “Build me a dashboard that shows monthly expenses with a nice pie chart and make it look professional.”

And the AI does it. The HTML, the CSS, the JavaScript, all of it. Right there in front of your eyes.

The term became popular because of Andrej Karpathy. He is a very well known AI researcher. My friend called it “coding without coding” and honestly that is the most accurate description I have heard so far.

How Does It Work in Practice?

The process is surprisingly simple. You open a tool like Cursor, GitHub Copilot, Replit Agent, or Claude. Then you type what you want in normal language. Not pseudocode. Not syntax. Just plain words like you are explaining to a colleague over chai.

For example you might say: “I want a student management system where I can add students, edit their marks, and see who is failing. Use a clean modern design.”

And the tool generates everything. You look at it, you ask for changes, you say “make the table sortable” or “add a search box at the top” and it updates accordingly.

It is like having a very fast junior developer sitting next to you who never gets tired, never complains about deadlines, and never takes a lunch break. (Although honestly, someone should give the AI a lunch break. It is working too hard.)

The whole experience feels like a conversation. You talk, the AI builds, you review, you talk some more. Back and forth until the application is what you wanted. Sometimes it takes five minutes. Sometimes you and the AI go back and forth twenty times and you start feeling like you are arguing with your spouse about where to go for dinner. “No, I said blue background.” “I have updated the background.” “That is green.” “I apologize.” Classic.

Why I Think This Is a Genuine Revolution

Now let me tell you why I am so excited about this. And I do not say “revolution” loosely. I have been in this industry for over two decades. I have seen many trends come and go. But this one is different.

Think about how many people in the world have brilliant ideas for software but cannot build it because they never learned programming. Teachers who want a better classroom management tool. Small shop owners who want a simple billing app. That cousin of yours who has a “million dollar app idea” that he brings up at every family function. Until now, all of them were stuck. They either had to learn coding (which takes years) or hire a developer (which takes money).

Vibecoding removes that barrier completely. You just need to know what you want. That is it. The AI handles the how.

For working developers, this is not a threat. I want to be very clear about that because I know many of you are worried. Vibecoding handles the boring repetitive stuff. The boilerplate. The scaffolding. The things that make you want to close your laptop and go sell pakoras instead. It frees you up to think about architecture, performance, security, and the actually interesting problems.

I was talking to a DBA friend recently and he told me he used vibecoding to quickly build an internal monitoring dashboard that would have taken him two weeks to code manually. He did it in one evening. One evening! He spent the rest of the week actually optimizing queries, which is what he should have been doing all along.

The Funny Reality of Vibecoding

Now I will be honest. Vibecoding is not all sunshine and rainbows. There are some genuinely funny situations happening out there.

People are deploying applications to production that they cannot debug because they never actually read the code. Imagine sitting in a client meeting and someone asks “Can you explain how the authentication module works?” and you have to smile and say “It works very well” and quickly change the topic. We have all been in meetings like that, but now there is a whole new reason for it.

The debugging process with vibecoding is also comedy gold. When something breaks, you just copy the error message and paste it back to the AI and say “please fix.” It is basically the same energy as taking your car to the mechanic and saying “it is making a sound” and hoping for the best. Sometimes the AI fixes it instantly. Sometimes it introduces three new bugs while fixing one. And sometimes you end up in a loop where the AI keeps apologizing and breaking things further and you start wondering who is debugging whom.

My favourite part is when people say “I am a full stack developer now” after vibecoding one todo app. Bhai, I have been writing SQL for twenty plus years and I still learn something new every week. But sure, you vibecoded a calculator app, you are full stack now. Congratulations. Put it on LinkedIn.

What This Means Going Forward

Jokes aside, I genuinely believe vibecoding is going to open doors that were previously closed for millions of people. The ability to turn an idea into working software using just your words is powerful beyond what most people realize right now.

Will every vibecoded app be ready for enterprise use? No. Will some of these apps fall apart the moment real users touch them? Absolutely yes. But that is okay. Every revolution starts a little messy. The important thing is that people who were never part of the software building process are now part of it. And that changes everything.

My advice is simple. Try it. Open any AI coding tool this weekend. Describe something you always wanted to build. See what happens. You might be surprised. You might be frustrated. You will definitely laugh at least once.

And if the app breaks, do what every great developer has done since the beginning of time.

Close the laptop. Make chai. Try again tomorrow.

A Funny Thought I Had With Myself

While writing this post, I had a little conversation with myself that I want to share with you all.

Me: You know what, Pinal? Someone is going to read this blog post and try to vibecode your Comprehensive Database Performance Health Check service.

Also Me: What do you mean?

Me: I mean someone will open an AI tool and type “Build me something that does what Pinal Dave does in 4 hours for SQL Server performance tuning.” And the AI will generate a nice looking dashboard with some charts and a big green button that says “Fix Everything.”

Also Me: And? Will it work?

Me: It will look impressive. It might even run a few scripts. But here is what the AI cannot vibecode: twenty plus years of experience. The ability to read a system like a doctor reads an X-ray. The instinct to know exactly which query is causing trouble within the first 15 minutes. The understanding of why something is broken, not just what is broken.

Also Me: So you are saying your job is safe?

Me: I am saying you can vibecode a todo app. You can vibecode a dashboard. But you cannot vibecode experience and intuition. At least not yet. Until the AI learns to drink chai and troubleshoot deadlocks at the same time, I think my Comprehensive Database Performance Health Check is safe.

Also Me: Fair enough. Now go make chai.

If you have tried vibecoding already, I would love to hear your experience in the comments. And if you vibecoded something that went hilariously wrong, please share that too. We could all use a good laugh.

Note: Images and minor grammar improvements were assisted by GenAI, but the story, opinions, and writing are entirely my own.

Reference: Pinal Dave (https://blog.sqlauthority.com)

First appeared on Vibecoding: What Is It and Why I Think It Will Change Everything