When you ask data people how they feel about AI, you get pretty rabid, extreme reactions. People either love it or hate it. Set that aside for a second, and let’s zoom out and think about a bigger picture question.
What’s it like to work with someone you know, versus a stranger?
| Known Person | Unknown Person | |
| Work Quality | High | Varies |
| Price | Expensive | Cheap |
| Availability | Low | High |
With a known person, like a trusted employee, you know you can count on their work. However, they’re only available so many hours per week, and you have to pay a relatively high price for them to keep that same exact person on your staff.
With an unknown person, like contractors on Upwork or Fiverr, their work quality is highly unpredictable. You can put in a ton of work yourself to clarify the task at hand, build processes for them to follow, and build automated checks on their work – but unless you do that, you don’t really know what you’re going to get. However, companies are often willing to take that compromise in exchange for getting someone way cheaper, way more often, because it’s a giant pool of strangers. Over the last couple of decades, it’s become completely normal for companies to outsource as much as possible to other companies, with varying results. (I’m looking at you, Microsoft Support.)
You make this decision yourself too – compare having a dedicated car with your own full time chauffeur, as opposed to opening the Uber app and calling a car. Compare having a full time chef on your payroll, as opposed to going out to eat at a restaurant.
Now think about code:
| Known Code | Unknown Code | |
| Work Quality | High | Varies |
| Price | Expensive | Cheap |
| Availability | Low | High |
When a company builds their own app, they design the logic carefully, test it, and they’re confident that it produces the exact right result, every time, predictably. It’s expensive – especially if you do it right. Note that I said “Availability = Low” here because historically, you haven’t been able to just wave a magic wand and get yourself working app code. It takes time to produce. It’s not just instantly available.
AI is unknown, outsourced code.
When you send requests to large language models like ChatGPT and Claude, you can’t consistently predict the work quality over the course of everything you’re going to ask it to do, over time. Models change, prompts change, the quality of the data going in can vary, you name it.
Because you’re a technology professional – especially one that works with data, where we want very specific, predictable, accurate results – you probably read the above explanation and say to yourself, “Bingo, that’s everything I hate about AI. It’s as if I called a company’s support line – that sucks too, because I get some bozo who has no idea what they’re doing, and they keep asking me if I rebooted my router.”
I’m here to tell you it doesn’t matter what you think.
Many companies are willing to make that compromise because the work is available instantly, 24/7, and it’s cheap as hell. Just like they’re willing to outsource people in their call centers and other job roles (even tech ones.)
That’s why I expect to see SQL Server 2025’s AI used a lot in the wild.
SQL Server 2025 and Azure SQL DB’s new sp_invoke_external_rest_endpoint lets you call ChatGPT & friends directly via T-SQL. Clients have told me they want to try using it for tasks like:
- Translating product descriptions, menus, etc into other languages (Spanish, German, Japanese) – one client told me they’ll just start all new translations this way, and then have humans review the results rather than build all new translations from scratch
- Generating personalized customer emails – like passing in a customer’s details, order history, web site behavior, etc to deeply personalize email campaigns and transaction receipts, leading to better customer relationships and easier bypassing of spam filters
- Improving customer support calls by summarizing a customer’s activity – when a call center operator takes a call, they’ll see a short, two-sentence description of the customer, plus get a customized greeting to use (“Hi Alice! It’s Charlie here in support. Congrats on your recent milestone of hitting six months straight! What can I help you with today?”)
AI is a hybrid of outsourcing people, but also outsourcing code. I’m excited to see what clients build – but also at the same time, I’m kinda gritting my teeth because as a consumer, I’m not all that fond of the results from outsourcing people. It’s coming, and it’s useless to try to fight it.
I’m also really not excited to see how that code ages. Hard-coding API calls into T-SQL is a serious form of technical debt, especially in the day and age of rapidly evolving AI. That custom model version you call today may not be available in 3 years, let alone 5-10.
This post was for T-SQL Tuesday #189, and you can read the comments on that post to see thoughts from other bloggers on the topic about how AI is changing their careers.
12 Comments. Leave new
Good analogies. And no arguments on hardcoding API calls. That’s just bad design. “outsourcing code” likely doesn’t make much sense either.
Maybe a slightly different take tho…think more in terms of using AI like a pair programmer. I hate pair programming. One person is the typist, the other the thinker. It never worked for me. But it does with tools like vscode and various MCPs and gh copilot.
Your blog’s audience probably doesn’t need sql coding assistance from an ai pair programmer. They can think thru a problem in a set-based manner already. But think of a business analyst that maybe can’t do that. they need the help constructing the query that asks a self-service analytics style question. This is where it shines. “How many active customers did I have last month?”….if you send that into a typical NL2SQL engine the answer will be WRONG because the sql will likely be customers who bought anything last month. But maybe your company defines “active customer” as anyone who bought something in the last 6 months.
So AI-as-coding-assistant still isn’t enough. It needs intelligence as to what our business rules are. But we can help build those things. So, it may be that your audience’s role is less “generating SQL code” for a living and more “making automated SQL generation work for the masses”. What must we do to ensure the SQL is right?
And then this leads to using AI to answer difficult business questions that SQL and data analytics alone can’t answer. “I saw my revenue fell off a cliff last quarter. Why? And can you give me things to consider to fix it.” This is where AI can look at the revenue, customer mix, business, etc and realize the problem is import tariffs and provide assistance to the business folks to fix it. That’s a bit of a pipe dream, but it does work with some of these newer models.
None of this is new…we’re merely quickening the pace of tech innovation. 50 years ago if a business person asked those questions it required a cobol program and a week of effort. Then along came sql. We’re merely shifting the analytics further left.
This is Jevon’s Paradox stuff. As we shift-left, the world will find we need even more SQL programmers and analytics. Said differently, when the backhoe was invented, ditch diggers weren’t immediately unemployed. The world just realized there was an unmet demand for more holes. The job merely changed and there are more ditch diggers than ever.
> think more in terms of using AI like a pair programmer.
I think that only works if the human is the senior, and the AI tool is the junior or their peer.
The problem is, that’s not how people are using it. They’re “vibe coding”, simply asking AI to do the work, and either blindly trusting that the code is correct, or they don’t have enough knowledge to understand the problems in the code.
I see that all the time when I use AI coding tools on my live streams. Maybe 90% of the code is great – but the other 10% is so problematic, and it takes a senior person to spot the flaws.
AI is currently only qualified to play “fetch”. Human decides the object, scope, play area and the you tell AI to go fetch the code to wire it together. Without containment entropy prevails.
Throughout my career and in my book I have focused on scope, boundaries and platforms. An often overlooked aspect of most coding designs is “anticipated lifespans”, One aspect of lifespan is the lifespan of connected technology. AI has a turn of less than 4 months. Therefore, anything connected to it is also impinged by that lifespan. If you are connecting your code to an AI API call plan on revisiting that code again in 1/2 of its anticipated lifespan. If it’s integration is inevitable than plan accordingly.
Since recently I must work with copilot and GitHub copilot at work, answers are mostly Ok and very few bright ideas.
But more than once, I get that feeling that I’m training that smart bright junior developer that understands that if she can understand my way of thinking and problem-solving skills, she will enlarge her toolkit for the next time.
And, how long until these API will ask the old AI version to create its interface to the next generation?
> I think that only works if the human is the senior, and the AI tool is the junior or their peer.
The problem is that as more and more companies join these trends, there are less and less positions for juniors to start road and get to that senior status.
> Maybe 90% of the code is great – but the other 10% is so problematic, and it takes a senior person to spot the flaws.
How many more AI generations will it take to be 99% – 1%, 99.99% – 0.01%, I feel that this is a similar to the SLAs we had back when I was a junior in the ’80s and companies invested fortunes to reduce their downtime from 1 day per year (>99% uptime), to 1h per year (>99.99% uptime), etc.
In such scenario, the question is not “if”, but “when”.
I kind of pride myself in setting up the specs, testing harnesses and the actual testing. So I’m quite happy to leave AI with the weird and arcane algorithms. What I do find is that you can’t blindly trust it, there’s cases where it doesn’t learn and makes the same mistakes.
I’ve found it to be a great aid in looking up things, debugging odd errors in syntax and for code maintenance. Want to add some error checking with advanced logging? Surprisingly easy.
Ultimately what will sell it is price and convenience. Management won’t care as it’s easy to blame the human element that’s left to check it.
I use AI to help me with power shellscripts or tsql scripts. I’m an accidental dba.. Powershell and tsql , I can read but I am terrible at writng. Too chaotic in my mind and maybe to old (63) Started 3 years or so ago with sql server administration. So AI is very helpfull. Of course I dont use the scripts before reading and understanding from beginning til the end. Furthermore I recently used AI for grocery shopping. I live in the netherland but not far from the german border. I want to throw a party for 40 people and asked AI how much to buy, beer whisky red , white whine and food . I asked for a list and It had to compare it with the prices in germany. It looks like its cheaper to get it in Germany. I used a supermarket brand which is available in the Netherlands and Germany. Yep use it just for fun. I have never posted a comment anywhere so this is the first one.
“Hard-coding API calls into T-SQL is a serious form of technical debt”
I’m going to have to find a bridge across this river at some point. But what *isn’t* a form of technical debt?
My instinct would be to use Logic Apps in Azure… But I’m mainly defaulting to that for security reasons and to keep it near other integrations. What method would be debt free? Why is the T-SQL API call “serious” debt?
Great question, and there are a bunch of reasons. I’m just going to cover my favorite pitfall.
It suddenly requires direct communication between the database server and the API. That doesn’t sound like a big deal – until you implement high availability and disaster recovery, especially years from now. I’ve worked with 10-20 year old applications where the original developers were long gone, the company had grown, and its dependence on the application had grown. All they wanted to do was move to a newer SQL Server version with high availability and disaster recovery – but suddenly they were forced to troubleshoot network connectivity for things they didn’t even know existed. (In one case, for example, the developers had built an open query hard coded to a particular IP address.)
Thanks. It’s essentially directly coupling the SQL server to (even more) subtle and elusive services. My security-driven instinct to keep external integrations in logic apps sounds like a debt-free alternative.
I think the key comment is this one – ‘“Bingo, that’s everything I hate about AI. It’s as if I called a company’s support line – that sucks too, because I get some bozo who has no idea what they’re doing, and they keep asking me if I rebooted my router.”’
At this point, since most initial support has been either outsourced or been staffed by what seems to be the lowest common denominator, using AI doesn’t make a darn bit of difference except that (currently) most people can tell they’re being talked to by a computer/recording. Considering that in this day, some people (and companies) will still say “you should do a fresh re-install of Windows because (X driver) isn’t working on your system, since it works for everyone else”, why should we expect anything better?
Similarly, as various people have said here and elsewhere, it doesn’t have to be perfect, just “good enough”. And most of the AI models I’ve heard of fit that description. Even if it isn’t “real” results, is it close enough that people can use it to make decisions? In most cases, unfortunately yes.
Personally, I think that the current AI (LLMs) are abominations that should be shunned by rational people, but I also accept that it’s the way that we’re going currently. It’s here to stay, and we’ll have to deal with both them and people thinking that (as usual) “the computer told me this information, and so it has to be right!”.
[…] Brent Ozar(blog): AI is Like Outsourcing. #TSQL2sday […]