That is an uncomfortable thought when you have spent your career becoming the person who can solve the difficult problems. The architecture nobody understands. The decision nobody wants to make. The deadline somebody has to rescue.
​
Being needed feels good. Until your team’s capacity becomes limited by your availability. “𝘐 𝘤𝘢𝘯 𝘥𝘰 𝘪𝘵 𝘧𝘢𝘴𝘵𝘦𝘳.” Probably. Today.
​
But if you keep taking the work back, that will still be true next year. As engineers, we design for resilience. We eliminate single points of failure. Then we build teams where every meaningful decision passes through us. We should recognize that architecture.
​
“𝘠𝘰𝘶𝘳 𝘯𝘦𝘹𝘵 𝘭𝘦𝘷𝘦𝘭 𝘪𝘴 𝘯𝘰𝘵 𝘥𝘰𝘪𝘯𝘨 𝘦𝘷𝘦𝘳𝘺𝘵𝘩𝘪𝘯𝘨. 𝘐𝘵 𝘪𝘴 𝘮𝘢𝘬𝘪𝘯𝘨 𝘮𝘰𝘳𝘦 𝘱𝘰𝘴𝘴𝘪𝘣𝘭𝘦 𝘵𝘩𝘳𝘰𝘶𝘨𝘩 𝘰𝘵𝘩𝘦𝘳𝘴.”
​
For me, that means sharing the reasoning alongside the responsibility. Explain the outcome. Make the constraints clear. Give people authority to decide. Stay available when they need support. Then comes the uncomfortable part: accepting a sound approach that differs from yours.
​
Your preference is not automatically a requirement.
​
Across enterprise engineering and open source, I care about a simple test: can someone else explain the decision, own the outcome, and keep things moving when I am unavailable? That capability takes time to build. Taking over every time we feel impatient keeps postponing it. I still want to solve hard problems. I also want more people to be ready to solve them.
​
What is one decision you could help someone else own this week?

Personal data (like customer data) usually reaches an AI tool by accident, not by attack. Someone is busy and the chat window is one CTRL+V away, so it’s a quick and easy solution.

The most common ways personal data leaks into AI tools? Clean-up requests, BI assistant summaries, over-shared files read by copilots, coding assistants, call transcripts, and browser extensions.

Thankfully, you can prevent this happening without ‘banning’ the use of AI by masking data at the source, fixing permissions before enabling AI ‘copilots’, providing an approved enterprise AI tool, and adding technical guardrails such as browser data loss prevention (DLP).

How (and why) does personal data leak into AI tools by accident?

A data analyst pastes a CSV into an AI tool like ChatGPT for “clean up”. A business intelligence (BI) assistant then uses GPT to summarize a dashboard full of customer emails. Nobody intended to share personal data, but they did.

My previous article on anonymizing PII in LLM pipelines covered the pipelines you design, whereas here I’m focusing on the pipelines not designed to ingest PII (personally identifiable information).

I’ll explain how personal data (or customer data from an organization’s perspective) slips into AI tools by accident, and how to stop it without banning the use of AI.

From both a personal and professional perspective, the fastest way to get work done nowadays is via an LLM (large language model) – and naturally, we’re all handling data of some sort every day. Data that, depending on the context, is usually full of PII.

That ends up being fed into the LLM – and this is often missed. Here are a few of the reasons this can happen within an organization/business:

What are the most common ways customer data ends up in AI tools?

The most common ways personal data ends up in AI tools like ChatGPT is through pasting data for clean-up, BI assistants summarizing dashboards, workspace ‘copilots’ reading over-shared files, coding assistants seeing result sets, emails, transcripts and screenshots, and browser extensions.

Most look harmless at the time.

Pasting data into ChatGPT to “clean it up”

Exporting and pasting a query into ChatGPT and prompting “dedupe this”, “split the name column”, etc. This happens when someone needs help with the data’s shape, but actually pasted the data itself – triggering the accidental PII exposure.

BI assistants summarizing dashboards

Most BI platforms now have an AI assistant summarizing report pages. The assistant will read whatever the report exports, including the tables with names and emails.

Enterprise-licensed assistants often keep data within the vendor’s boundary, but the summary can still end up in an email, a Slack channel, or a personal ChatGPT account.

Workspace ‘copilots’ and permissions creep

AI ‘copilots’ in email and documents answer from everything a user can access. A customer spreadsheet shared with everyone is readable by the copilot too. In short: AI respects permissions, but everyone means everyone.

In fact, it’s how I once accidentally threw my social security (national ID) number into Claude Code. I simply wasn’t paying attention to what I’d allowed the agent to see. Rookie mistake!

Coding assistants and agents seeing result sets

Pasting a failing query is fine, but pasting error output or sample rows is not. The same goes for AI coding agents given production database access to ‘debug’ something.

Emails, transcripts, and screenshots

Personal data lives outside of tables as well. Pasting an email thread to draft a reply, using a built-in AI notetaker/assistant on a support call on Zoom or Microsoft Teams, or uploading a screenshot of a customer relationship manager (CRM) record – these all give third-party software free access to PII.

Browser extensions and shared links

Any extension that can read page content can read your prompts. Be careful when discussing personal data in the browser, and remember that shared chat links can also expose pasted data to anyone who has the URL.

What happens to customer data after it’s pasted into an AI tool?

The data is stored by the provider, on their terms. The data may be retained after deletion, and on consumer plans may be used for training. Depending on the account type:

Two caveats (even on business plans):

It’s still a disclosure. Under the General Data Protection Regulation (GDPR), sending personal data to a processor needs a lawful basis and a data processing agreement. A personal account does not fall under that.

Deletion is hard to prove. Clearing a chat is not a guarantee of complete deletion.

Be cautious – treat every prompt as an outbound data transfer.

How do you stop personal data leaking into AI tools?

The goal is to make pasting data harmless, not to ban AI. A ban alone just pushes usage onto personal devices.

In summary, here’s how to make pasting data harmless from the potential dangers of AI:

How it leaks	Quickest fix
Pasting data for clean-up	Masked or synthetic copies by default, plus an approved AI tool
BI (business intelligence) assistant summaries	Strip PII from semantic models; move customer-level drill-throughs into restricted reports
Workspace copilots	Fix “everyone” sharing before rollout; test that row-level security holds
Coding assistants and agents	Masked dev data; no production access for agents
Emails, transcripts, screenshots	Approved AI notetaker; browser DLP (data loss prevention) that also checks images
Browser extensions and shared links	Managed browser with an extension allowlist; disable public chat sharing

Mask data at the source

Give analysts and developers masked or synthetic copies by default. Redgate Data Masker, for example, keeps this consistent rather than a one-off script.

Use views, column permissions or SQL Server’s Dynamic Data Masking so that reporting roles see region, not email.

Classify PII columns first, then apply these anonymization techniques.

Clean up BI tools and permissions before enabling AI

Give people an approved AI tool they’ll actually use

People use personal accounts because it’s easiest. Provide an enterprise AI plan with training off and SSO, make it the default everywhere, and write a one-line rule: no customer names, contact details, payment data or support notes in any AI tool except the approved one.

Add technical guardrails

Checklist: what to check before you paste anything into an AI tool

If you can’t tick every box, strip the data first.

Done	Question
☐	Am I using the approved AI tool on my work account?
☐	Have I replaced real values with masked or synthetic ones (since the model only needs the structure?)
☐	Have I removed names, contact details and IDs (including from free-text fields and screenshots?)
☐	Have I checked that any error output or result rows pasted alongside my query contain zero personal data?
☐	Is this chat staying private, with no plan to share it or its output more widely?

If you slip up, delete the conversation and tell your data protection officer (DPO) straight away.

Accidental AI data leaks are a design problem, not a people problem

Accidental AI data leaks are a design problem, not a people problem. Customer data reaches ChatGPT because it’s easy to reach and easy to overlook.

Mask it at the source, keep identities out of reports that don’t need them, fix permissions before copilots read them, and give people an approved tool they want to use.

Pair this with the five anonymization techniques for LLM pipelines to cover data sent on purpose and by accident.

And, to automate masking, why not try Redgate Data Masker free for 14 days?

The post How personal data leaks into AI tools by accident (and how to stop it) appeared first on Simple Talk.

Many people think¹ that getting “good at AI” is trivial. Sure, with some early models there were tricks you had to learn,² but current models don’t need them. Even if there are different tricks³ that work on current models, the next generation will render them obsolete, so why bother? Just tell the model what you want it to do.

This take is particularly popular with the anti-AI crowd, who scoff⁴ at the idea that AI-reluctant people are being left behind, or that it might be irresponsible to advise other engineers to avoid AI use entirely. According to them, if AI does ever become capable enough to be worth using, they’ll be able to start using it with no learning curve. Is that right?

No. Like most things, getting good at using AI isn’t just about clever tricks. It requires developing long-term skills⁵, which takes time and practice.

Supplying the right context

One failure mode I’ve seen with people who are new to AI is expecting it to read their mind: for instance, asking it to “solve my issue” without ever saying what the issue is, or asking it about some Slack-related problem without actually connecting your agent to Slack. Agents are flexible and will try their absolute hardest to guess what problem you’re facing and how to solve it, but the guesses will be largely wrong. Skilled AI users will pick up on the fact that the agent is missing key context and backtrack.

Skilled AI users will also reflexively include why they want to achieve their current goal, so that the agent has enough context to make decisions. This is often non-trivial: most of us know what we want to do but have to take a second to think about the broader reasons behind it.

Knowing what the model can and can’t do

AI capabilities are weird: they are very good at some tasks and very bad at others, and it’s hard to predict which task falls into which category. For instance, I know that I can ask an agent to come up with new architectural ideas for how to structure a service, but that I shouldn’t ask it to come up with new features that the service can offer. Worse still, there is a third category⁶ of tasks that AI models are bad at but can be prompted into being good: for instance, writing PR descriptions.

Of course, this changes with new models, but less than you’d think. In general, new models get much better at the tasks the old models were already good at, and a little better at the tasks the old models sucked at. So developing a sense of what AI can and can’t do is a surprisingly durable skill.

Really internalizing what the model can do is trickier than it sounds. For instance, I initially struggled to set up MCP servers for GitHub Copilot before realizing⁷ I could just ask Copilot to install its own MCP servers. I now reflexively ask AI agents to do local testing of changes — standing up servers, hammering them with curls, running through variations and edge cases — but it took me a while to realize I could ask for that. I have only just started scheduling a job for 6am my time for an agent to go through messages that have come in from different timezones and do some preliminary investigation. What other capabilities⁸ am I leaving on the table?

Knowing what mistakes the models make

Reviewing AI-generated code is a substantially different skillset from reviewing human-written code. There are whole categories of bugs — off-by-one errors, for instance — that human-written code is prone to but AI-generated code is not. Similarly, there are mistakes that are rare in human-written code but are very common in AI-generated code. I’ve written about how these tend to be mistakes of misalignment: over-engineering some areas that humans would know aren’t important, or trading off important requirements in order to satisfy made-up ones, and so on.

Reviewers used to human-written code are often dazzled by the superficial fluency of AI-generated code. It’s always exhaustively commented and tested and uses sophisticated language features. If a human programmer produced code like this, you’d be inclined to trust their judgment that a mutex is required in this case — but with an AI programmer, you ought to be very suspicious about new mutexes, which are often introduced to satisfy completely insignificant edge cases.

Rapidly skim-reading AI slop

This skill is kind of silly, but it’s so practically important I have to include it. AI models produce a lot of useful output, but it’s often lost in a thick forest of verbiage. Once you’ve read enough of it, you can sort of just let your eyes flow over the phrasing until you get to the specific claims and evidence. If you’re not used to this, you will waste a lot of time and emotional energy trying to cut through the foliage.

Will these skills be made obsolete too?

It’s possible that these skills are also temporary. Maybe in the future the agent will just do what we want perfectly, freeing us from the need to actually read its output. Maybe model tooling will get good enough to automatically supply the right context, and the models will get good enough to be able to do everything and make no mistakes. Maybe! But that would require the models to get so good that humans aren’t needed at all.

Don’t be a doomer. Like chess, software’s centaur age — the period where a human-machine pairing can beat individual humans or machines — may last decades. Developing skills for the centaur age is still worthwhile, just like it was worthwhile to learn Angular or React even though it seemed likely that those frameworks would be obsolete⁹ in a decade.

Conclusion

I’ve left a lot of skills out: knowing when to abandon or steer an agent session, how to break work up between agents, when to trust AI claims and when to verify, how to minimize costs by using smaller models, and so on. On top of all that, even though it’s not durably useful to stay up to date with the current set of tricks (plus knowing which model is the best for which tasks), it’s still very useful in the short-term. Keeping up without getting lost is a skill in its own right.

It shouldn’t be surprising that working with AI involves actual skills. It’s like working with a really weird person: a savant with mad skills in some areas and huge gaps in others, a prolific but inexpert communicator, a workaholic with no long-term memory, and so on. If you were a manager and had someone like that as your employee, you could likely get a lot of value out of them, but it would take time¹⁰ to figure out how.

If you’re deliberately avoiding using AI, you are likely being left behind by the people who aren’t. If you’re advising other people to avoid AI completely, you are doing them no favors. I do think it’s a mistake to go fully into AI, because LLMs reward expertise, which is best gained by hand. However, if you never practice using AI, you are never going to get good at it.

Let’s say you’re working with a big copy of the Stack Overflow database, and you wanna get all the users, like for a data export. SQL Server doesn’t parallelize this query, not even if you use the query hint that asks for a parallel plan:

SELECT Id FROM dbo.Users;

SELECT Id FROM dbo.Users 
    OPTION (USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));

I’m only asking for the Ids here because in the big copies of the Stack Overflow database, the Users table is over 1GB. It takes a looong time for SQL Server Management Studio to paint result grids with 1GB of data, and demonstrating a slow SSMS isn’t the point here. If you’re going to follow along with me in this demo, make sure you’re using a current version of SQL Server Management Studio, because I don’t want these demos to run your machine out of memory, which old versions of SSMS would do.

So, why isn’t it going parallel? The short answer is that SQL Server knows it has to shove all the millions of rows of results out the network, through a single stream going out to the end user’s app (in this case, SSMS). It doesn’t have the ability to send multiple network streams of data down to the client, and furthermore, even if it did, our queries often ask for sorted data, like ORDER BY something. In that case, we need to deliver the results in order – something that isn’t really doable with multi-threaded result sets.

But … how could we force SQL Server into using multiple threads to gather the data, then consolidate the data into a single set going out to the network, just to demonstrate that parallelism on this query would be a bad idea?

To do that, we need to trick SQL Server into thinking that our query has a selective filter that will only return a limited amount of rows, when in reality, it’s still returning all of the rows.

We’ll take advantage of the fact that SQL Server doesn’t have statistics on the output of mathematical formulas, and doesn’t put the slightest bit of thought into what that output could be:

SELECT Id FROM dbo.Users
    WHERE Id - Id = 0;

Now, you and I know that if we take any number, and subtract itself, the result will be zero. SQL Server, as smart as it is, does not know that, and it thinks that the filter will be quite selective. Check out the execution plan:

SQL Server estimates that only ONE ROW will come back! Isn’t that awesome? I love these little edge-case hard-coded rules inside the query optimizer. I really wish there was a yellow bang over any query operator that had a hard-coded cardinality estimation, because clearly that estimate of 1 row isn’t based on any kind of advanced heuristic, heh.

So because SQL Server thinks our filter will be so selective, it believes few rows will need to be sent back over the network, and as a result, introduces parallelism into the plan to read all that data.

Let’s compare the actual plans and their statistics for the single-threaded versus parallel plan. Here’s what SET STATISTICS TIME reports:

• Parallel: CPU time = 16297 ms, elapsed time = 46267 ms
• Single-threaded: CPU time = 5703 ms, elapsed time = 43103 ms

The parallel version used about 3X more CPU time. Granted, an unknown chunk of that was caused by subtracting a number from itself, but SQL Server also had to recombine the data across multiple parallel threads in order to ship the data out via a single threaded network stream. (We’re not even sorting the output here.) The parallel query didn’t actually finish any faster, because it takes forever to shove all that data out the network, and have SSMS consume the results, painting them into a grid.

However, here’s where stuff really goes off the rails. Check out the actual query plans, and note the times on their operators:

The parallel plan LOOKS faster – it looks like it only took a few seconds, when the single-threaded plan took a lot more seconds. However, these times are only how long it took for SQL Server to do its work – not how long it took the data to reach the client. To see client delivery time, you’ll need to turn on SET STATISTICS TIME ON to get the numbers I mentioned earlier.

Another way you can see that the parallel plan isn’t “better” in any meaningful sense is to look at their wait statistics. Right-click on each select operator, click Properties, and go down to the wait stats section.

• Parallel plan: 171 seconds of CXPACKET waits, 43 seconds of ASYNC_NETWORK_IO waits
• Single-threaded: 37 seconds of ASYNC_NETWORK_IO waits

So the parallel plan doesn’t run any faster, burns more CPU time, and produces more parallelism overhead. That’s why, when you don’t have a truly selective filter in the where clause, and you’re bringing back a lot of data, introducing parallelism doesn’t speed things up – it makes them worse.

What if we’re not returning the rows?

What if we’re pumping them into a temp table, something that should allow for parallelism?

SELECT Id 
    INTO #Temp1
    FROM dbo.Users
    WHERE Id - Id = 0;

SELECT Id 
    INTO #Temp2
    FROM dbo.Users;

Now, the situation is different: both query plans go parallel.

We don’t need any trickery – even the plain, unfiltered query gets parallelism.

• Tricky WHERE clause: CPU time = 25391 ms, elapsed time = 7834 ms
• No WHERE clause: CPU time = 17703 ms, elapsed time = 5674 ms

This further drives home the fact that when SQL Server needs to pipe that data out via a single-threaded stream of data, it doesn’t make sense to get parallelism involved – but if the data target is something that can handle multiple threads of streamed output at once, then it does.

This post was inspired by Louis Tochon’s post about this same topic, which I was just giddy to read because this is one of my favorite niche topics. This knowledge has never served me any real purpose in client work, since it’s something that SQL Server already does perfectly well and shouldn’t be mucked with, but it’s really fun to muck with and understand why it does things the way it does. I can imagine a situation where this knowledge might come in handy – when SQL Server lowballs an estimate and goes parallel for the wrong reasons – but I’ve never hit this particular edge case in real life. Someday! Fingers crossed, and now someday this knowledge will help you too.

I was looking over the CHOOSE() function while editing an article at SQL Server Central. I realized there isn’t a documentation note on how many parameters can be included. I decided to test.

This post looks at the tests and results.

Tl;dr It appears 3925 is the most arguments.

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

Building a Script

Since I want to know where things fail, I decided to make a short T-SQL script that tests increasing numbers of parameters. This script builds a dynamic CHOOSE() select using a number of parameters and then loops for a set number of times, adding 1 parameter each time.

SET NOCOUNT ON;
 
DECLARE @MaxValues int = 5150;   -- largest number of CHOOSE value arguments
DECLARE @n         int = 300;    -- current number of value arguments
DECLARE @i         int;
DECLARE @idx       int;
DECLARE @args      nvarchar(max);
DECLARE @sql       nvarchar(max);
 
WHILE @n <= @MaxValues
BEGIN
    -- Build value list: 'Value 1', 'Value 2', ... 'Value n'
    SET @args = N'';
    SET @i = 1;
    WHILE @i <= @n
    BEGIN
        SET @args += CASE WHEN @i > 1 THEN N', ' ELSE N'' END
                   + N'N''V' + CAST(@i AS nvarchar(10)) + N'''';
        SET @i += 1;
    END;
 
    -- Random index in 1..n (CHOOSE is 1-based; out of range returns NULL)
    SET @idx = ABS(CHECKSUM(NEWID())) % @n + 1;
 
    SET @sql = N'SELECT ' + CAST(@n AS nvarchar(10)) + N' AS ArgCount, '
             + CAST(@idx AS nvarchar(10)) + N' AS PickedIndex, '
             + N'CHOOSE(' + CAST(@idx AS nvarchar(10)) + N', ' + @args + N') AS Result;';
 
    PRINT @sql;                 -- show the generated statement
    EXEC sys.sp_executesql @sql; -- run it
 
    SET @n += 1;
END;

This returns the command run. For the first 2 values of n, setting @n to 1 and @max to 2, I get this:

SELECT 1 AS ArgCount, 1 AS PickedIndex, CHOOSE(1, N'V1') AS Result;
SELECT 2 AS ArgCount, 1 AS PickedIndex, CHOOSE(1, N'V1', N'V2') AS Result;

This let me test different values. I tried various values and eventually got this error:

I tried this a few different times, disconnecting and reconnecting and it seemed that I could get the number of parameters up to 3925. It failed sometimes at 3924 and sometimes at 3925.

I’ve submitted a PR to add the max number to the docs, but it appears CHOOSE() works at a level that would cover lots of items. I see this as a small syntactic sugar add, and if I really needed to index 1000 entries, a join with a reference table would be a better choice.

SQL New Blogger

This script took a few minutes to write, but the testing took about 45 minutes. I was running this in the background with different values. 1..256, 255..1024, etc. I noticed that SSMS responded slower, so I started jumping to small ranges at large values to find the error.

This post took me about 20 minutes to put together after the testing, which included the PR for Microsoft. This is an easy way to show that you can examine possibilities and find the limits of your code. That helps us decide how scalable or robust our solutions are.

You could write this post and impress an interviewer. Choose your own T-SQL function and run an experiment.

The post Experimenting with CHOOSE: #SQLNewBlogger appeared first on SQLServerCentral.

How I Use Claude Code to Build Stuff

Chapters

• 00:00:00 – Introduction and Setup
• 00:02:30 – Opus and Fable Usage
• 00:06:00 – Agent Management and Token Usage
• 00:08:30 – Example Workflow with Opus
• 00:11:00 – Setup and Tools Overview
• 00:12:30 – Monitoring and Complex Projects

Full Transcript

Erik Darling here with Darling Data and in today’s video I’m going to talk because I get questions quite a bit about how I work and build on my free database performance monitoring tools. And so I want to share a little bit about that because it’s been a learning and growing adventure with me and my friend Claude working on things. It’s, you know, like there is a learning curve to this stuff and there are things you can do that make your life better and easier and all that good stuff. Down in the video description you will find all sorts of helpful links where you can hire me for consulting, buy my training, I guess I can even come teach you how to use Claude to do stuff because a lot of people are real dumb about it, including me when I started.

If you want to buy my training, become a supporting member of the channel or ask me office hours questions, there are helpful little things that you can click on down there that do all this stuff. And of course, as always, like, subscribe, tell a friend, oh yeah, ba-da-da-da-da-da. We’re going to, you know, go to code.erikdarling.com.

Not only can you get the free monitoring tool that I’m going to show you how I build, but also some of the stuff in this video are all Claude plugins that I built myself to help me do things better, which you can also download there. And of course, Seattle, Washington, November 9th through 11th, past Summit West, I will be out there ranting and raving about SQL Server, which is much closer to my home turf than anything else. But who knows, who knows how much longer that’ll last. We all might need to just be A8 spurts in order to continue on.

But let’s move this thing out of the way. And I’m going to talk a little bit about this. So this is my typical Claude code setup. I’ll have a few open windows. And the one cool thing about what Claude can do is agents can talk to each other across sessions.

So I have basically four tabs open right now. There’s a you can ignore the one that says past Summit West session. That one is in charge of something else.

But the one that I have up now is sort of like my general utility coordinator session. It keeps it keeps track of what all the other sessions are doing. Make sure that issues get assigned as they come in and that the queue gets worked through.

Right. So like this and this is the one that I spend the most time talking to because this is the one that basically is in charge of all the other ones. But that’s not to say that all the other ones are just doing top line work because they’re not.

This one over here is basically in charge of watching pull requests. So as the other two sessions finish working on issues, pull requests come in. This one is tending to those that that involves basically just like watching the CI run in GitHub.

And if anything fails, fixing that and then basically just seeing them through until they merge and then closing issues that are attached to them. So this one here doesn’t do a lot of work, but you know, it stays it stays busy with the with the pull requests. And then these two over here are ones that are directly working issues.

There are at any given point, you know, a bunch of issues open. And these two things are in charge of making sure that, you know, like looking at the issue, triaging it, looking at the code, building code to either make a feature or fix a bug or whatever it is. Reviewing the code changes to make sure that nothing is screwy and also testing them.

In the video that I did last week, there was the background behind me. You could see Claude actually like running the GUI on the performance monitoring tool, looking at stuff in there. That’s another part of what it does, because if I had to click through every chart graph and tab and I had to sit there and be like, how does this look?

Does this look great? Let me go. Let me go. Tell it what looks wrong. I used to have to do that and it was quite painful. How I started off using Claude was basically just like I would have one tab open and I would have this one poor agent doing everything, running out of context constantly, like working on like kind of one issue at a time.

And then I started working on, you know, multiple issues with multiple tabs open and that got turned out to be a mess until I discovered Git work trees and I could have them work separately on stuff without like the weird GitHub. Like, oh, sorry, I switched branches and overrode everything that you just did. It was real messy at first, but I’ve learned how to do some stuff.

Now, one thing that becomes really important when you work on more advanced agent coding setups is keeping track of your tokens and how much you’re spending or how much you’re digging into your Claude Max account. Or some people out there who might have two Claude Max accounts just in case, you know, like there’s a lot of stuff you have to keep track of and there’s a lot of stuff you don’t want to do. For example, like Claude has different levels of agents.

There’s like Fable, which is like like the big powerful one. And then there’s Opus, which is like the medium powerful one. And then there’s like Sonnet and Haiku, which are not very thinky. They’re kind of like soft cheese up here.

But they’re good for like easy mechanical work and they’re much cheaper. They’re much cheaper to use. I don’t recommend using them for anything that like requires like a lot of, you know, I want to say thought because they’re, you know, I thought because they’re LLMs and they don’t think.

But anything that requires a lot of effort, it’s probably a good way to think of it. So what I have set up in my repo and what you can find at the code.erikdarling.com repo in the Claude plugins folders, is you can find how I sort of route agents of the appropriate model type and thinking level to different tasks.

Like you can see in this section here, PM worker helper three has a bunch of the sub agents running. And they’re all sort of at different, they’re all sort of at different levels of stuff. So like a bunch of them are Sonnet five, you know, these ones are high thinking, but the effort level can be adjusted between like high, medium, low, depending on what they’re doing.

And you can see how much each one of these costs as far as like, you know, like for whatever tokens it’s been using. This one down here is thinking about a roll up migration plan. And so it’s using Opus on extra high because it’s got to look at a whole bunch of stuff and a whole bunch of code to figure out if it’s doing things right.

Like if it’s really thought, really thought through everything, all that other stuff. This, this window here looks very similar, right? This one has a bunch of lanes where they’re basically, well, these ones are all using Sonnet a different look.

Actually, these are all high too. I got to have a talk with these robots. They’re spending, they’re blowing their credit cards. This one here is on extra high because it’s got to think about a lot of stuff that it has to do.

But this is how I run stuff and this is how I keep track of stuff so that I kind of know what they’re all getting up to. And it took a long time to get to this setup. You know, like if I just had like one of these things, like all the anything that’s in a tab up top there, those are all using Opus.

And Claude has this advisor thing, right, that you can say, hey, if you get stuck or if you want to like double check your work, you can use a higher level model to go and like, you know, look everything over and futz about and tell you if you’re right, wrong or in between. And so all of these are Opus and they can use Fable as an advisor. But when I when they’re using sub agents, you don’t need Opus for everything, right?

You don’t need Fable for everything. They’re good for like top level stuff because, you know, like like things that the lower level agents do come back to them and then they review it and they figure out how bad of a job like the little workers did. So like when I when I first started doing this stuff, it would be like, cool, I got Opus, use sub agents and it would be like, I’m going to use Opus sub agents, too.

And then it would be like, you hit your weekly limit and I’d be like, I got three days of nothing to do that. Right. And that’s how you keep having to like, you know, buy the extra tokens like another 250 bucks. Go ahead and take it, burn it away.

Like they’re like as you get to use this stuff more, you have to figure out ways to conserve and do a better job of using the limits attached to either your your account or however your credit card bill or however you’re paying for stuff and doing things. It’s always a good idea to, you know, make sure that you’re not like using Opus to like change a file name. Right. Like there’s stuff you don’t need.

Like what’s the weather? Crappy probably. I’m in I’m in a server. It’s hot in here. Like, I don’t know. I just where’s all the water? I thought I thought we were drinking all the water in the world.

Where is it? I’m dying. So like what you don’t want to do is just have like crazy level agents doing all this stuff that they like they have no place doing. Right. Just like way too much for that.

You it’s perfectly fine to have a top level agent who’s like, you know, is less dumb than the other ones sort of directing them and then reviewing their work and then coming back to you with anything that they might need you for. For example, in this window, I’m trying to figure out how to make the continuous integration that runs in GitHub go a little bit smoother because the problem that I’m having is one that was unfamiliar to me as a database person where like, you know, something would start building and some of the tests would run and like the builds would take a long time and then a test would fail. And then they’d be like, oh, I got to fix that.

I got to rerun the whole thing is another 45 minutes. It just got to be a real pain. So I’ve been I’ve been trying to do some work to make that less annoying by like sharding stuff and like bucketing tests that take longer across like some across the different shards. So it’s not like one shard does all like the tests that take 10 minutes or something.

So that’s sort of what this this this session is helping me with at the moment. And I’ve got this little, you know, it’s got a question for me. I should go answer it before it gets mad at me.

But you can you can see up here where it’s giving me an update on session three and four. There’s nothing big. I restarted them to install an update that probably isn’t going to do much of anything.

But anyway, this is a little bit about my setup and how I do stuff. I’ve gotten some questions about it. So I wanted to just talk a little bit about it because I thought maybe if if a couple few people are asking me the question, then maybe there’s some broader interest in how I do all this stuff.

So that’s about it. I don’t I don’t have anything more formal than that. It was just sort of me rattling off the top of my head some stuff that’s on my screen currently.

Again, if you’re interested in any of the plugins or mods that I’ve built for Claude Code, they’re all at code.erikdarling.com and the Claude plugins folder. There’s a lot of stuff in there that looks like this and, you know, things that you can use to make your bigger building experiences a little bit more tolerable and easy.

And, you know, like if you’re just cracking open an agent session, like, you know, like if I were to like if I wanted to like work on something in quickie store or one of my store procedures, I would probably just open an Opus window and be like, hey, look over all this stuff.

I want to do this thing and then go, you know, like write the code for it and then test it. Right. Because I give Claude access to SQL CMD and my local SQL Server VM. So we can go and run the store procedures, look at the results, figure out if things look good, bad or ugly and say, hey, I think I’m done.

And then I can look things over and say either no, this is screwed up. You go go back to the get back in the mines or, you know, no water for you. Or, you know, like, yeah, it looks good.

Let’s, you know, do some stuff with it. And this is just, you know, that I would do that. But like working on the monitoring stuff, there is way too much to do to work like that. So my, my, my, my setup has gotten necessarily more complex over time.

But, you know, maybe you don’t have that situation. Maybe, maybe, maybe you’re stuck with some, you know, real soup brain like co-pilot. I’m sorry if you are, or any, one of those open AI models that, you know, couldn’t give you a reliable recipe for ice cubes.

I don’t know. But this, this is how I do my stuff with Claude. And now things are fairly good and fairly streamlined.

But there we are. Anyway, thank you for watching. I hope you enjoyed yourselves. I hope you learned something.

And I will see you in tomorrow’s video where I will try to find something else to talk about. All right. Goodbye.

Going Further

If this is the kind of SQL Server stuff you love learning about: these days I have AI do the annoying stuff for me. My new video course teaches you to work the same way, and I teach whole teams in a one-day workshop. Someone still has to know enough SQL Server to keep the robots in check, and that’s what my training is for.

The post How I Use Claude Code to Build Stuff appeared first on Darling Data.