Follow Your Hunch

Posted on June 17, 2026 by way0utwest

For a while, I kept seeing that the cost of writing code was approaching zero. So many people felt that with an AI LLM, the costs would go way down to produce software. I’m not sure that’s true. In fact, some companies are finding they spend more on AI tokens than salaries.

However, the ability to produce more code, experiment with ideas, or generate proof of concepts has gone up. Whether it’s worth the cost or not depends on the engineer, but some organizations are finding that they can try more things than they would ever had time to try in the past. The time of engineers was the constraint, and if you can afford the cost, AI LLMs can relieve that time pressure.

Maybe the ability to get more done with agents means you should follow one of your hunches in software. Maybe you should try something.

Be thoughtful in your approach, use the LLM wisely, and learn to guide it efficiently, but use it to try an experiment that you might not think you have time to explore. Try an alternative. Implement something in a new way. OR implement it yourself and set the AI loose, asking it to work in a different way. You certainly could tell the LLM not to use your approach and try something different.

To me, the big advantage of an AI agent is it gives me time, something that I see as the most impactful constraint in my life. I’d like to get more done, but I’m not willing to work a lot more. Using an AI agent with a measured approach lets me tackle things that I might not otherwise get done. Certainly not as quickly as I get them done, and certainly not without stealing some personal time.

I get more done at work, without working more. I’m not working less, but I’m more effective. That’s what I’ve always aimed to do.

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

No Shortcuts for the SQLCMD Batch Terminator: #SQLNewBlogger

Posted on June 17, 2026 by way0utwest

I was messing around with SQLCMD and I realized something I hadn’t known. I’ve never tried it, but the batch separator has to be separate, which I’ll show.

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

The Batch Terminator

The default batch terminator in SQL Server tools is “GO”. We tend to use this in SSMS, and many of us know to type this in SQLCMD when we use it. In SSMS, we sometimes need it. Here’s an example where I create a proc and add a RETURN, which some people think means the proc ends.

It doesn’t.

2026-05_0092

The SELECT @@VERSION is a part of the proc. Now, if I drop the proc and then add a GO at the end of a line, , I get this:

2026-05_0093

Makes sense. Let’s try two commands. In this case, the GO is skipped and I get two results.

2026-05_0094

Using SQLCMD

If I run SQLCMD and enter that code, I get a new prompt. That’s because the batch separator in SQLCMD is a batch terminator. This is in the SQLCMD docs, and since I haven’t terminated a batch, nothing happens.

2026-05_0095

If I hit enter, I get a new prompt. This continues until I enter a go.

2026-05_0096

Once I enter Go, I’ll see my results.

2026-05_0097

A good thing to know, as you might think you can enter “select * from @@version go” and think it might execute. It won’t, as you see below:

2026-05_0098

This isn’t likely a problem for most people as they’ll instinctively enter GO if something doesn’t run, but newbies might miss this.

SQL New Blogger

This was about a 10 minute post, based on an experiment to see if I could get something to run quickly. Since I ran the experiment, I captured some screenshots and built this post.

Showcase continued learning, especially in this era of AI where you might need to guide an LLM along a better path.

Posted in Blog | Tagged , , | Leave a comment

The Slow Growing Problems

Posted on June 15, 2026 by way0utwest

Both as a DBA and developer, I’ve had plenty of immediate, this-is-broken, fix-it-quickly issues. Usually, I, or someone else, wrote some bad code and somehow got it deployed. I mean, I do test things, and I would (probably) never change code after I’d tested it to fix that one little annoying thing, like the formatting. I’d (almost) never do that, and I’m sure you wouldn’t either.

Yet somehow bugs slip in at times.

Those are the acute issues, and they can be hard to fix at times, but often we can reproduce the problem in development and build a fix. Sometimes we even spot the issue quickly and just fix it in production. I’m sure you never do that, but I have had that experience myself a few times.

However, in the database world, we can have other, slow-growing problems. I saw this post from Jacob Sebastian about production issues that don’t trigger alarms. There are just slowdowns that trickle across multiple systems and cause issues for clients. These aren’t things you instrument for, as a slowdown isn’t necessarily an issue. These things can resolve themselves, or they can develop into a major issue.

I think about this like vehicle traffic. A minor fender bender on a highway might not be a problem, but it can become one. Cars don’t get out of traffic quickly enough, or traffic police don’t arrive soon and move the cars. Traffic starts to back up, which slows down the response, including that important tow truck that might keep things moving. Suddenly, it’s not a few people inconvenienced by an accident, but thousands.

There are likely signals in your environment that would let you know about a potential issue coming soon. These are subtle and not always indicative of a problem individually, but taken together, they indicate a production issue is going to occur. To me, this is a place AI can eagerly be taught to look for these signals and then happily keep looking for them every day.

The future of monitoring is the active examination of correlated data that precede an issue, hopefully giving humans, or other AIs, enough time to respond and prevent customers from experiencing a slowdown.

I’d certainly welcome this in both traffic motorways and database systems.

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

AI Experiments: Parsing Payment Memos

Posted on June 15, 2026 by way0utwest

As part of my running the SQL Saturday charitable foundation, I get sponsorship money from vendors. Primarily Microsoft and AMD, but I hope to change that in the future. In any case, I recently got a payment notification that my invoice had been paid.

I knew I had a few invoices outstanding, so I wasn’t sure what was included. MS tries to bundle payments, but I don’t get an email for each one. For this one, I didn’t see an email, so I suspected I’d put the wrong one in or typo’d it.

The Usual Process

When I get payments, I have to reconcile those in my General Ledger, recording the amount and allocating to the events. I then send out payments to the event organizers and record those.

This is a mostly manual process, but since I sometimes submit multiple invoices at once, I have to figure out what was paid. I could submit 3 invoices and get 1, 2, or 3 payments. Microsoft Finance usually bundles things, but since I can have a lot of events in flight, I need to know where money gets allocated.

In this case, I didn’t see an email and didn’t want to log into the invoice system and start finding the various invoices paid and clicking through details. Instead, I logged into the bank to verify the amount and I saw a memo. It was something like this (I’ve changed a bunch of data in here.

2026-06_0123

I thought it would be obvious which invoices were paid, but I couldn’t quickly figure this out. I decided to turn to AI.

AI to the Rescue

First, I knew I had a “no training” AI plan with Claude, so I wasn’t concerned about data release here.

I had this prompt and then pasted in the data: “can you help me separate this by ? and make sense of what is included?”

The result was interesting, and useful. It labeled this task as EDI 820 parsing, so apparently this is EDI format. The last time I worked with EDI is was XML based, but perhaps this is the new way of doing things.

The results were great. I got a summary, none of which I needed, but good to know this was easily recognized and parsed.

2026-06_0124

The really interesting part was below some of the acronym descriptions, where my invoices were found.

2026-06_0125

I knew this would be certain events, but wanted to double check the numbers. When I put in an invoice number, I use the date and event. Here I got 3 of my events (1146, 1154, 1134) paid from a day where I invoiced 5 events. This let me quickly enter my GL and also know to whom I was sending money.

A cool time saving AI trick. Rather than 10-15 minutes to reconcile things, AI gave me answers in seconds and I had fixed the GL in a couple of minutes, allocating the funds to events.

Of course, I needed to ensure data security with my plan and I verified these were events where I had planned to send money. Still me as the expert reviewing things and making decisions, but way easier than trying to sort out invoice numbers from a bunch of EDI text.

Posted in Blog | Tagged , , | Leave a comment