Problems displaying this newsletter? View online.
SQL Server Central
Featured Contents
Question of the Day
 
The Voice of the DBA
 

The Quiet Part

Apparently, Meta did what a lot of employees suspect their management will do: use AI to lay off people. In this case, there is a report (and lawsuit) that Meta used it's AI-integrated HR platform to make decisions about who to let go in a layoff. The rumor is that the AI used productivity metrics to choose who was the target of the layoff. As with a lot of AI failures, this appears to be another case of poor communication guiding the AI, or the AI not actually taking individual situations into account.

A number of the people terminated were on maternity/paternity leave, which is a protected activity. Others may have been on other medical leave, though for privacy reasons, the article doesn't have firm data to prove this. The lawsuit will likely bring more of this out, but this appears to be a case not just of AI making decisions, but of poor behavior from management. Plaintiffs were discouraged from taking leave off, which is something sh****y humans have said to people for decades. We need you; your baby or family isn't important, so don't use your leave. It's one aspect of working in the US that is way worse than overseas, where there are more employee protections.

Meta disputes the case, saying the AI didn't make decisions. However, that brings out an interesting point. If the AI recommends things, who's responsible? The humans, right? They still have to sign off on the decision. If they don't perform due diligence, they're still responsible, correct? I think so; after all, I'm responsible for code the AI writes if I commit it. Even if an agent does the work, I have to oversee it and approve (or grant permissions for) the actions.

I. Am. Responsible.

Trusting an AI to do a lot of work is like trusting a lot of smart, but very inexperienced staffers to work in your environment. There are always inconsistencies and reasons why we might code something, configure something, or deploy something a certain way. What seems like a good way to tackle the situation from the outside doesn't always make sense when you have experience. Humans often have experience that AI agents lack.

LLMs are relatively stateless, and while we can provide context, give them guidance, and provide comprehensive codebases, they still sometimes do silly things. This can be problematic, especially with database changes, which are stateful and disruptive to rollback.

AI agents can make mistakes much like humans, only faster. Much, much faster.

Labor is one of the most expensive parts of many organizations' budgets. Plenty of management would like to replace relatively expensive humans with cheaper tokens. That isn't working out as well in practice, despite lots of experiments. Hopefully, other organizations realize that AI is a tool, not a replacement for humans, and we can't trust it or even believe it's outputs without some human judgment.

Steve Jones - SSC Editor

Join the debate, and respond to today's editorial on the forums

 
 
 Featured Contents
SQLServerCentral Article

BIT_COUNT in SQL Server

john.martin from SQLServerCentral

Learn how the BIT_COUNT() function works and how it enabled operations where data is stored in bits.

Technical Article

Power BI Best Practices

Additional Articles from SQLServerCentral

In this tip, we’ll look at some best practices to help you get the most out of your models. We will also look the DAX formula language.

Blog Post

From the SQL Server Central Blogs - Microsoft announces new cybersecurity AI multi-model

K. Brian Kelley from Databases – Infrastructure – Security

Yesterday, July 27, 2026, Microsoft announced a new cybersecurity effort called Project Perception. Included in that announcement were high level details about MDASH with MAI-Cyber-1-Flash, which is reported to...

From the SQL Server Central Blogs - Rambling about Data on Wheels – origins, branding, expansion

DataOnWheels from DataOnWheels

I have been asked many times about how the name “Data on Wheels” came to be. I decided that is a good topic to ramble about, so here goes....

Introduction to PostgreSQL for the data professional

Introduction to PostgreSQL for the data professional

Site Owners from SQLServerCentral

Adoption and use of PostgreSQL is growing all the time. From mom-and-pop shops to large enterprises, more data is being managed by PostgreSQL. In turn, this means that more data professionals need to learn PostgreSQL even when they have experience with other databases. While the documentation around PostgreSQL is detailed and technically rich, finding a simple, clear path to learning what it is, what it does, and how to use it can be challenging. This book seeks to help with that challenge.

 

 Question of the Day

Today's question (by Steve Jones - SSC Editor):

 

Backing Up a DMK

In SQL Server 2025, I have a database with a Database Masker Key (DMK). I want to back up this key and keep a copy offline. When do I have to open this key before running the backup?

Think you know the answer? Click here, and find out if you are right.

 

 

 Yesterday's Question of the Day (by Steve Jones - SSC Editor)

A Limited Startup

I add this parameter to SQL Server 2025 in the Configuration Manager:

-mDynamics

What does this do?

Answer: This limits connections to a client connection string that specifies "Dynamics" as the application name

Explanation: The -m parameter allows you to limit connections to only those applications who pass the parameter value as the application name. Ref: Database Engine Startup Options - https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/database-engine-service-startup-options?view=sql-server-ver17

Discuss this question and answer on the forums

 

 

 

Database Pros Who Need Your Help

Here's a few of the new posts today on the forums. To see more, visit the forums.


Editorials
Fixing P1 Queries - Comments posted to this topic are about the item Fixing P1 Queries
Building Your Own Software - Comments posted to this topic are about the item Building Your Own Software
Make It Routine - Comments posted to this topic are about the item Make It Routine
AI Observability Challenges in FinOps as a DBA - Comments posted to this topic are about the item AI Observability Challenges in FinOps as a DBA
Article Discussions by Author
Why SQL Server Database Attach fails and how to repair it - Comments posted to this topic are about the item Why SQL Server Database Attach fails and how to repair it
BIT_COUNT() IV - Comments posted to this topic are about the item BIT_COUNT() IV
Symmetric Key Encryption - Comments posted to this topic are about the item Symmetric Key Encryption
The “Successful Login” Dilemma: Why Your Login Auditing Strategy Might Be Hurting Your Server - Comments posted to this topic are about the item The “Successful Login” Dilemma: Why Your Login Auditing Strategy Might Be Hurting Your Server
DBCC CHECKDB Limits III - Comments posted to this topic are about the item DBCC CHECKDB Limits III
CROSS APPLY Fundamentals: Part 1 - Comments posted to this topic are about the item CROSS APPLY Fundamentals: Part 1
SQL Agent Job Automated Change Capture Process - Comments posted to this topic are about the item SQL Agent Job Automated Change Capture Process
SQL Server 2022 - Administration
Alamat Kantor BCA KCU Wisma Asia Telp:08218200174 - Via Wa:628218200174 Alamat Wisma Asia, Jl. Letjen S. Parman No.Kav. 79, RT.4/RW.9, Kota Bambu Sel., Kec. Palmerah, Kota Jakarta Barat, Daerah Khusus Ibukota Jakarta 11420
Alamat Kantor BCA KCU Kebayoran Baru Telp:08218200174 - Via Wa:628218200174 Alamat. Jl. Melawai Raya No.Blok B, RT.7/RW.5, Kramat Pela, Kec. Kby. Baru, Kota Jakarta Selatan, Daerah Khusus Ibukota Jakarta 12130
Alamat Kantor BCA KCU Wisma Millenia Telp:08218200174 - Via Wa:628218200174 Alamat.Jalan Letjen M.T. Haryono No.Kav. 16 11, RT.11/RW.5, Tebet Bar., Kec. Tebet, akarta Selatan, Daerah Khusus Ibukota Jakarta 12810
Migration Challenge: Excessive FULLSCAN Statistics Update Duration Blocking SQL - Hello everyone , I am planning to migrate a database from SQL Server 2014 to SQL Server 2019. The migration process includes a double-run, and one of the steps in the timeline is an UPDATE STATISTICS with FULLSCAN. This operation takes more than three days, which makes the cutover impossible because such a delay is […]
 

 

RSS FeedTwitter

This email has been sent to {email}. To be removed from this list, please click here. If you have any problems leaving the list, please contact the webmaster@sqlservercentral.com. This newsletter was sent to you because you signed up at SQLServerCentral.com.
©2019 Redgate Software Ltd, Newnham House, Cambridge Business Park, Cambridge, CB4 0WZ, United Kingdom. All rights reserved.
webmaster@sqlservercentral.com

 

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -