The New Software Team

One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

In 2026, that hasn’t changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today’s world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

In this short article on the rebirth of programming, the team is a team of n humans and m agents. N=1, and the architect, the coordinator, the project manager is the human (or a few humans). Code becomes less important, and the tests and other elements that describe and verify software become more important. Maybe even more important than today.

I’d even go so far as to say the performance of the code might not matter in the short term. Since the cost of writing, or re-writing code, becomes lower and lower, when something doesn’t perform well, just spin off a new team of your agent coders who don’t need sleep, aren’t worse at development if they work more than 40 hours every week, and are always happy to tackle new work. It’s a project manager’s dream team. At least, in theory.

That being said, the cost of writing this code isn’t zero. We see this rising every day, sometimes at a level that exceeds what we might pay human developers. That might change over time, but we certainly see some people spending more on tokens than salaries.

And your agents do lose focus. Fortunately, you can fire them and hire new ones every day, or every hour. It’s like a team of characters in a game that respawn on demand to tackle the next challenge. There is still plenty of coordination and onboarding work for the manager. They will need excellent documentation and descriptions of what the code looks like, what needs to be done, and all of your guidelines on how to structure things. Lots of tests are needed, but your team can build them (with oversight).

It seems like an amazing system, but we’re learning that excellent team leaders who are good architects are in short supply. And they can’t work long hours. Some early evaluation of these software managers seems to indicate that they can’t even work the full 8 hours for 5 days a week with a high level of effectiveness. They might not even be able to work half that amount of time.

So is the falling cost of code going to produce more software? Likely, though perhaps with many more leaders needed to manage those teams. I can certainly see many more one person companies spawned during off hours, where one person can focus on their passion project, something completely separate from the work they are paid to do by someone else.

It’s going to be fascinating to watch this work itself out across the next decade.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged , | Leave a comment

The Book of Redgate: Profits

Redgate is a for-profit company. We look to make money by building and selling tools that help you. If we do a good job, we make money. If we don’t, you shouldn’t buy our tools.

I found this value to be very interesting:

2026-04_0228

The next page has this statement:

Focusing purely on the numbers is a sure way to kill Red Gate’s culture. We believe that if we focus on the game – building awesome products that people want to buy, and then persuading them to buy them – then success will follow.

Profits matter. Certainly all of us want to be paid (and get a bonus of some sort). With the changes in Redgate’s board this year, this is a piece of culture that I believe in and advocate to keep as an item of focus.

We watch profits, but we don’t optimize for profit, we aim to optimize in building better and better products that meet the need of our customers and prove their value from an ROI standpoint. Especially in this era of subscription software.

Our goal is what’s in the quote: build awesome products.

I have a copy of the Book of Redgate from 2010. This was a book we produced internally about the company after 10 years in existence. At that time, I’d been there for about 3 years, and it was interesting to learn a some things about the company. This series of posts looks back at the Book of Redgate 15 years later.

Posted in Blog | Tagged , , | Leave a comment

Limit the Blast Radius

You still need DBAs (that know how to back up systems and test restores). If you think you don’t, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn’t the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process.

This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we’ve seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources.

Reading this, I can imagine this is how some of the AWS and Azure outages occurred over the last decade. Not the 2025/2026 AI inspired ones, but the 2010-2015 human mistakes that didn’t expect a change to have such a far reaching blast radius,

You still need guardrails, for both humans and AIs. Don’t get slack and assume either truly knows what they are doing and deserves rights everywhere. Don’t assume that your guardrails were setup correctly. AI agents make great helpers. Use some read only ones to examine your setup and look for holes. If/When we get the next Claude Mythos model (or the equivalents from Google/OpenAI/etc.) have it look for precisely the types of holes that come from bad code that looks to reset, redeploy, or re-anything in your environment.

We separate out roles for different people to limit the blast radius of the mistakes we inevitably make. AIs aren’t necessarily smarter or better than humans. Just faster. We need separate roles, separate rights, and governance for AI agents, precisely because they can make decisions faster than humans.

There’s tremendous potential, but and tremendous danger in allowing anyone, or anything, too many rights in any organizations. RBAC, audits, and all the other things we implement to try and reduce the number of silly mistakes are still needed. At some point we’re going to see amazing social engineered emails, messages, XSS, and other items that are designed to fool the AIs just like humans have been fooled in the past.

We need to ensure we set good guardrails and limits when that starts to happen. Or we’re going to lose control much quicker than expected.

PS If you want a fun and slightly scary read on how AI could go sideways, I enjoyed The Final System recently, which made me not want to deploy any sort of AI agent beyond tightly scoped ones with very, very limited rights.

Steve Jones

Listen to the podcast at Libsyn, Spotify, or iTunes.

Note, podcasts are only available for a limited time online.

Posted in Editorial | Tagged , , | Leave a comment

QUOTENAME Basics: #SQLNewBlogger

Recently I ran across some code that used a lot of QUOTENAME() calls. A colleague was having some trouble with the code, but what struck me was that I hadn’t often delved into the details of QUOTENAME and how it can be used in different ways. I’d always just passed in a string as a single parameter.

This post looks at a few details of how this function works.

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

QUOTENAME

The idea behind QUOTENAME() is that you pass in a string that might not be properly formatted to be an indentifier. QUOTENAME() returns the string with enclosing characters that ensure the string works in your code as a literal.

Here’s an example. If I have a string that is “Steve Jones”, I’ve quoted the string with double quotes. If I wanted to create a table with this string, I’d do this:

CREATE TABLE dbo.[Steve Jones] (id int);

I’ve explicitly put brackets around the string, which is what we commonly do in SQL Server if we have some reserved word or space we want in the object name.

NOTE: I am not recommending this, just showing this as an example.

If I were doing this in code, and maybe I wanted to dynamically create this table, I’d do this:

DECLARE @n nvarchar(20) = N'Steve Jones';
DECLARE @s nVARCHAR(100) 

SELECT @s = 'create table dbo.' + QUOTENAME(@n) + '(id int)'

EXEC(@s)

When QUOTENAME runs, by default, it will surround the string with brackets. You can see this in the results below.

2026-05_0281

This is a valid identifier, and we end up with a table that has a space in it’s name, which I abhor. But it works.

A Second Parameter

While this is how I’ve used QUOTENAME in the past, usually to clean up strings that might be reserved words, like name, there actually is an optional second parameter. The syntax for QUOTENAME is:

QUOTENAME ( string, [ character])

where

  • string – the string that you need to quote
  • character – a single character that represents the delimiters to be used to surround the string.

One might think that any character can be used, but that’s not true. Only a few characters are supported. The list is:

  • brackets, [], which is the default
  • braces, {}
  • single quotes, ‘
  • double quotes, “
  • angle brackets, <>

That’s it. Anything else produces not an error but a NULL, as shown here:

2026-05_0282

What’s interesting is that the parameter is a single character, but the function works out what the matching character should be. For single and double quotes, this is easy. The same character is used, as you can see below. Note the single quote is escaped.

2026-05_0283

For brackets, if I use either the left or right bracket, the result has a left bracket on the left side and a right bracket on the right side. You can see that below.

2026-05_0284

Same thing for braces.

2026-05_0285

And angle brackets.

2026-05_0286

What’s what I’d expect, but it’s nice to know it works. This limits flexibility for the function, and if I were designing it, I might make the second parameter two characters that represent the left and right enclosures. Or make a separate parameter for each. That would allow me to do something like:

SELECT QUOTENAME(‘Steve Jones’, ‘_>’ )

and get

_Steve Jones>

I could have run with a space at the beginning and a comma or period at the end, helping me clean up text. Winking smile

SQL New Blogger

This is a quick post that I actually spent about 10 minutes on during a flight. I had run into this while answering a friend and reading the docs, so I left a quick sentence as a reminder and then fleshed out this post. I spent another 10 minutes once I landed (and got plugged in) capturing the screen shots.

This is a good example of showing how I dug into a feature of SQL Server, I understand how it works, show how it can be used, and how I might have wished it would be used.

You could do this in a half hour at a coffee shop and start knowing that you can learn a few things and maybe show how you’d evaluate if this was needed in AI generated code, some of which you might see in the very near future.

Posted in Blog | Tagged , , | Leave a comment