The Role of LLMs in Visual Studio Productivity with Leslie Richardson

How are large language models going to change the way we use Visual Studio? Carl and Richard speak with Leslie Richardson about her work in Visual Studio, starting with the debugger and now focusing on the broader productivity features of the product. Leslie discusses how various Copilots are being integrated into Visual Studio to help users take advantage of the vast array of features available, which can sometimes be difficult to discover. The upcoming Visual Studio 2026 is available as an insider's preview if you want to get a jump on what's coming!

Episode Transcript

Speaker 1 (00:01):
How'd you like to listen to dot NetRocks with no ads? Easy?
Become a patron for just five dollars a month. You
get access to a private RSS feed where all the
shows have no ads. Twenty dollars a month. We'll get
you that and a special dot NetRocks patron mug. Sign
up now at Patreon dot dot NetRocks dot com. All right,

(00:35):
all right, all right, it's dot net Rocks episode nineteen
ninety seven.

Speaker 2 (00:39):
I'm Carl Franklin Richard Campbell. I think it's nineteen seventy seven.

Speaker 1 (00:42):
Did I say nineteen ninety seven?

Speaker 2 (00:44):
Yeah, you're jumping ahead, dude. It's like we got too
many shows. I get it, but come on, go hurry.

Speaker 1 (00:50):
Yes, nineteen seventy seven, Yes, yes, thank you, Richard. Uh,
it was a good year.

Speaker 2 (00:55):
It was a big year.

Speaker 1 (00:56):
Oh my god, it was a great year. Let's talk
about the year nineteen seventy seven. I'm going to start, Okay,
hit me with my favorite album came out in nineteen
seventy seven. That would be Asia by Steely Dan.

Speaker 2 (01:07):
That's not surprising at all, though, of course it is. Yeah,
I've heard more Steely Dan hanging around with you than
the rest of my life combined.

Speaker 1 (01:14):
I think most people in my life have heard more
Steely Dan from me. Also, Star Wars. Got to talk
about Star Wars. Yeah, yeah, what can you say? What
can you say? Yeah? Star Wars.

Speaker 2 (01:25):
None of us can see the original because he just
kept tinkering with it.

Speaker 1 (01:28):
But yeah. The first episode of Saturday Night Live aired
wow in December. December fifteenth July, New York City experienced
a massive blackout, leading to widespread looting, right, and.

Speaker 2 (01:43):
A lot of pregnancies.

Speaker 1 (01:45):
Yeah, let's see. In January, Jimmy Carter was inaugurated as
the thirty ninth President of the United States. February, Fleetwood
Mac released their iconic album Rumors. This is one of
my This has got to be my favorite year. The
amazing music year, amazing music and cultural year. Here sure,
Indira Gandhi withdrew the State of Emergency and Indie. Uh,

(02:07):
let's see what else we got here. The first personal computer,
the Commodore PET, was demonstrated. Was it really the first
personal computer?

Speaker 3 (02:16):
Yeah?

Speaker 2 (02:16):
I think that's that's not true. Yeah, okay. The ninety
seventy seven is an amazing year for for early personal computers.

Speaker 1 (02:22):
Yeah. The Atari twenty six hundred was released in August.

Speaker 2 (02:25):
Yeah, then was the VCS one of the first. They
didn't the twenty six hundreds a retro name.

Speaker 1 (02:30):
And the big bummer of nineteen seventy seven.

Speaker 2 (02:32):
Elvis dud.

Speaker 1 (02:35):
I could think of a couple others, Yeah, there were,
there were a couple other bummers. But man, what a
good year for music and movies for sure and stuff.
So anything else that we.

Speaker 2 (02:46):
Ninety seventy seven computer wise is yes, the Commodore Pat
but also the Tierras eighty Model one and the Apple two,
the trifecta. So I'm sorry, you can't pick a you
can't pick a winner there by the way each of
them ship they original versions for with four K of
ram awesome, although all subsequent but the pricing is hilarious.

(03:06):
The Tirsa Model one, which was four K cassette player
a version of Basic not BA by Microsoft. It was
a tiny Basic. Six hundred dollars is the original price. Wow.
The Commodore PET four K integrated cassette player for eight
hundred dollars, although the way they rigged the machine there
was so little memory left with four K that by
the next year they ship at the minimum of eight K.

(03:27):
That and also the Japanese are now making Rama RAM
prices drop quickly. The Apple two's initial release also four
KNA cassette player for twelve hundred US. You know, Apple
being the expensive machine. Turns out it was always true. Yeah,
so they all three of them. The Atari VCS, which
we'd later know as the twenty six hundred, was only

(03:48):
one hundred ninety dollars. Yeah, but it's because it only
had one hundred and twenty eight bytes a RAM in it.

Speaker 1 (03:53):
But it also played games, which was really they played
games and you know the gamer generation kind of core
up there, and they.

Speaker 2 (03:59):
Used this simplified version of the sixty five O two
called the sixty five oh seven. Yeah. By the way,
all those machines were sixty five O two except the
TIERRS eight, which was the eighty eighty last technology one
would be the original test of TCAPFP, which was between
Stanford and call A University College in London, was in
nineteen seventy five. In seventy seven they do the first

(04:20):
three way network test between UK US and Norway. Wow,
so just experimenting with can we do the pack of transfers?
Those things work reliable space related Yeah, so seventy six
was when the shuttle Enterprise was first rolled out. It
was originally called Constitution, but they relazed in Enterprise because
a bunch of Trekees rolled in. So seventy seven is

(04:41):
the first three flights of Enterprise, so the first two
theres are captive, so they're on the back of a
seven forty seven. Enterprise's job was to prove that you
could land a spaceship because nobody had never done that before,
and so on the back of seven forty seven they
go up unman just to make sure that the flight
dynamics are safe. Second flight, they have a crew in
it because there's no way out if something goes wrong,

(05:03):
so they're being very careful. And then in August they
do the first three flights, so releasing Enterprise from the
back of seven forty seven and it comes to lands
on the Long Strip at Edwards Air Force Base, and
again they're trying to figure out if they can actually
land a spacecraft on the ground with wheels. Enterprise had
intend they intended to make it into an actual spacecraft.

(05:25):
It never did. The main reason was it was wildly overweight,
and as was Columbia, the one that would ultimately fly
and they would get lighter from there. I could go
on for a long time about space shuttles, and you
know this.

Speaker 1 (05:38):
I know you can. I think you read the manual
in the front to back, didn't you? The operations manual well, And.

Speaker 2 (05:43):
The original, arguably the original geekout is me granting about
the end of the space Shuttle program in twenty eleven,
which was entirely your idea that I thought was a
bad idea, and I was wrong. But if you want
to go back and listen to all of my thoughts
of the space Shuttle, go back to the twenty eleven geekouts.

Speaker 1 (06:00):
It's worth it. You can even get an RSS feed
with the tag that you can get only the gas.

Speaker 2 (06:07):
The two more things on the space side. This is
the year that Voyager one and two launch. Now we
call them the Voyagers because they were the long range missions,
but these are still what they call Mariner class missions.
So the spacecraft that went to Venus and Mars and
Mercury there in seventy seven. There was a particular conjunction.
The motion of the planets allowed for a flight that

(06:29):
would hit multiple outer planet bodies, So Voyager one made
it to both Jupiter and Saturn. The most famous thing
I would say Voyager one did this was Carl Sagan's
idea is about ten years after the fly Biosaturn in
nineteen ninety, he had the spacecraft turn around and take
a picture of the Earth.

Speaker 1 (06:49):
It was the first Earth selfie. Yeah, flow got.

Speaker 2 (06:52):
Billion kilometers away, but yeah, the great famous pale blue
dot photo. Voyager two arguably had the more interesting flight
because of it and timing. It was not only able
to do a fly by of Jupiter and Saturn, but
also Uranus and Neptune. Both these vehicles.

Speaker 1 (07:06):
And now it's beyond this. Now it's beyond the Solar
System billions of miles away.

Speaker 2 (07:11):
Yet beyond the heliopause is the teedical term. So the
energy of the Sun pushing outward gets pushed back by
the interstellar energies past the heliopause, and both Barger one
and two are through those still operational, although on very
limited power. Many of their instruments are turned off. One

(07:31):
last point, and this is the thing we call the
Wow signal. So also in seventy seven, Ohio State University
had a radio telescope called the Big Ear, and they
occasionally got time to do SETI work or search for
extraterrestrial life. And in seventy seven there was a signal
that ran for seventy two seconds. Why seventy two seconds

(07:55):
because that was as long as the bigger could be
pointed in the direction of Sagittarius because the planet was moving,
so it could have been longer than that. It was
a very powerful signal, thirty times past the mean background
noise on the fourteen twenty megahertz spectrum, which is we
sort of agreed on, like if I was going to

(08:16):
communicate across a galaxy, I would use this hydrogen resonance frequency.
And so there it was, this massive signal from the
region of space around the constation Sagittarius. Never to be repeated.
Is that the one that turned out to be a pulsar?
They just don't know. They still don't know. Yeah, that
one's never been repeated. It's just a sort of unknown,
bizarrely powerful signal. Nothing interpretable from it. Don't know if

(08:39):
we even actually got the whole signal pretty sure we didn't.
Just one of those crazy, crazy things that happened, and
the only one of it's got Wow there you go.

Speaker 1 (08:47):
Oh all right, well, I guess we should roll the
music for the inimitable better Note of frameworks segments.

Speaker 2 (08:54):
Awesome, sard man, what do you got? So?

Speaker 1 (09:03):
Our friend Thomas Betts send me this email and he
said this is one for better No framework. If you
go to VS code and Leslie you can chime in
on this too. Let's just say stop, don't tell anybody,
but search vs code settings for yolo yolo as in

(09:27):
you only live once, that's right, Yolo mode. Basically, here's
what it says. It's a global auto approve experimental And
it says Yolo mode disables manual approval completely for all
tools in all workspaces, allowing the agent to act fully autonomously.

(09:51):
This is extremely dangerous and is never recommended. Even containerized
environments like code space and dev containers have user keys
forwarded into the container that could be compromised. This feature
disables critical security protections and makes it much easier for
an attacker to compromise the machine. But guess what, you

(10:12):
can turn it on.

Speaker 3 (10:16):
A little scary.

Speaker 1 (10:18):
It's a little scary, oh man?

Speaker 3 (10:21):
But hey, yeah that I I suppose.

Speaker 2 (10:28):
Yeah, yeah, all right.

Speaker 1 (10:29):
And I found that it was turned on in my
uh in my visual studio code and I don't know why.

Speaker 2 (10:36):
That's great.

Speaker 1 (10:37):
So it's turned off. Now that's my God. Isn't that crazy?

Speaker 2 (10:41):
I love it?

Speaker 3 (10:42):
Yeah? Yeah, oh yeah, they definitely don't. They hide that
in the documentation Somewhere, I like googled it as you
were chatting about it. I'm like, oh, they're.

Speaker 2 (10:51):
Really I found a GitHub repository with the list of
settings that you can apply to your configuration if you
want to. It's I'll include that in the show notes.
You want to live careful, do not run with scissors.

Speaker 1 (11:04):
Do not run with scissors. I would not recommend using
yellow mode for anything.

Speaker 2 (11:10):
I just want it.

Speaker 1 (11:11):
Don't shoot the messenger on.

Speaker 3 (11:13):
A disclaimer like, we're not responsible for any bad decisions
that are made you mad.

Speaker 1 (11:18):
Yeah, there is Thomas Betts. We hold him completely innocent. Okay,
well that's what I got, Richard, who's talking to us today.

Speaker 2 (11:26):
I grabbed a comment off a show eighteen seventy, the
one we did with Jeffert's talking about dot net comp
which should be you know, around the time the show
comes out, because Jeff coopf is imminent, and this comment
comes from our friend Mark Semen because one of the
conversations we have with Jeff was about the Visual Studio Debugger,
and since we have the Visual Studio Debugger Goddess on

(11:47):
the show today, I thought i'd bring it up because
it also leads to a broader conversation I think is
an interesting one. And Mark Semen has been a guest
on the show many times, one of our friends. He's right, transpirational,
very thoughtful guy, and so, of course, oddly enough two
years ago, what a very thoughtful message he said. The
visual studio a bugger is great, indeed, but I usually
try to teach my clients to use it less rather

(12:10):
than more. There are other good ways of troublesoit problems
with code notice and react to compiler warnings. Gez, didn't
you'd say exactly that to me when before we were recording.
It's like, you know, if you just look at what
the compiler says, you know a lot, use static code analysis.
It will often prevent errors. Actually read and try to

(12:30):
understand the error messages you're getting. Yeah, try to understand
because sometimes they're pretty opick. Sometimes have good test coverage
and run those tests. Write and test code in short
iterations instead of, as I've believed on the show, write
code for an hour only a learn it doesn't work,
write small isolated blocks of code, and favor pure functions

(12:53):
over state mutation. It's a perimeter in past the perimeter out.
That being said, I also use it a bugger, but
not that often and mostly when all those other techniques fail.
Me as impressive a piece of engineering as a debugger,
as one could argue that it's a great solution to
the wrong problem. You know, I think it's a great
solution all up, not the least of which because I'm

(13:15):
hanging with Leslie at the moment and I think her
work is amazing. But it also releases this broader conversation
of craftsmanship styles like I think Gil Gates was quoted about,
you know, the correct answer this just don't write any bugs.
It reminded me of a conversation we had maybe ten
years earlier with Scott Nimrod talking about not being a

(13:39):
professional debugger but being more a professional coder, and it
lit up a lot of controversy because I hate that
this idea there might be a schism between focusing purely
on never met writing a bug versus being able to
debug effectively, because I don't think either one of them
is achieved.

Speaker 1 (13:55):
It there could be some humorists there, like debuggering is
for FRENGI you know.

Speaker 3 (14:01):
I feel like they're part of the same job description, honestly.
I mean no matter like I think all of the
bullet points that were listed, you know, like avoiding state
mutations and stuff like that, making sure you're testing your
code isolated code, that's all still important, if not just
as important as debugging. But at the end of the day,
we're human. We're gonna run into problems regardless of how

(14:22):
well we understand the compile error that we're getting. And
that's and there's just gonna be times where we don't
catch it until we run the code, see that it
doesn't work and then have to debug.

Speaker 1 (14:32):
So I find most of the errors that the debugger
catches for me have to do with bad configuration, not
necessarily bad code. Do you know what I mean?

Speaker 3 (14:40):
Oh, yeah, no, that's totally fair. And I know for
me sometimes it's like catching logic errors as a visual person.
Sometimes it's like I don't fully catch it until I
see it out in the wild doing what it's supposed
to do contextually, and it's like, oh, that's not what
I expected it to do, so let's go re examine
the code.

Speaker 2 (14:59):
But the debug is also great at dealing with stuff
that isn't just the code immediately in front of you,
the crazy interactions between tiers, the race conditions that occur
into it, calling into multiple APIs simultaneously blocks on data stores.
You know, the internet was grumpy that day and my
software behaved weirdly, and the debugger often can save my
bacon for understanding where those interactions actually happen.

Speaker 1 (15:21):
Our congratulations you got the million to one odd race condition. Yeah,
so you win today.

Speaker 2 (15:30):
Yeah so it's but I appreciate like these things and
all go together. And also I wonder now with the
role of llms and coding, you know, suddenly getting tests
written got a whole bunch easier. You know, I could
never convince a junior to give me one hundred percent
code coverage, but you can batter an LLM into that. Well,

(15:52):
save that for the show for sure. And A Mark
thanks so much for your comment, and that copy of
music code by is on his way to you. And
if you'd like copy music code by right comment on
the website at dot net rocks dot com or on
the Facebook to Helpless every show there and if you
comment there and to read on the show, we'll send
you coffee music o YM.

Speaker 1 (16:07):
Music Code by. I'm working on episode episode track number
twenty three right now for music to Code by Mark Seman.
Obviously he's responsible for me taking that project on because
of what we were talking about with the flow. Yeah.
Uh okay, So let me introduce Leslie properly. Leslie Richardson

(16:27):
is a product manager on the dot net c Sharp
Developer Experience Team and the hosts of the VS Toolbox
show on YouTube and Twitch. She's focused on improving productivity
for writing MCP servers in the dot net C Sharp
space across VS and VS code. Leslie also worked on
the Visual Studio team, developing and enhancing extensibility and debugging features.

(16:50):
And yeah, that last sentence is loaded, isn't it. Leslie?

Speaker 2 (16:55):
I met you just.

Speaker 1 (16:57):
Recently in Orlando at devins Action. You were in the
audience when Maddie and I were doing the.

Speaker 2 (17:03):
Uh spiify spify.

Speaker 1 (17:05):
Spiifying dot net rocks. Yeah, and you came up to
the to us afterwards, and you were you and Maddie
obviously worked together, and you're having a conversation and in
about two minutes in I thought Oh my god, this
person is amazingly smart. We must have her on dot
net rocks. And of course you and Richard were already

(17:26):
talking about it. So so welcome.

Speaker 3 (17:28):
Thank you. I'm flattered to be here.

Speaker 2 (17:31):
Yeah. Yeah, And of course for a while there, your
job was a debugger. It isn't anymore, yes, yeah.

Speaker 3 (17:37):
Yeah, that was my very first job at Microsoft, working on.

Speaker 2 (17:40):
The way to Start.

Speaker 3 (17:42):
Yeah. I was like so scared about it initially because
I was fresh out of college at the time, and
I was like, oh my god, I barely used the
debugger beyond like print statements, and then one or two
great points he in there. What do I know about
improving in the bugger space? My goodness? And turns out
I think there's a lot of opportunities still to reveal

(18:05):
to people the beauty of the debugger in general, and
also for the visual studio a debugger, because so many people,
people who've been working in the industry way longer than
I ever have like don't know about this cool stuff. Yeah,
and it's worth sharing.

Speaker 1 (18:19):
What version were we on when you started working on debugger?

Speaker 3 (18:22):
Oh? We were on was it twenty Okay? Twenty eighteen
was about to come out at the time that I joined,
So it was the version before that, which one was that.

Speaker 2 (18:32):
It was twenty twenty fifteen.

Speaker 3 (18:33):
Fifteen, Yeah, we were in twenty fifteen.

Speaker 1 (18:35):
But we were That was Dottin at Court right.

Speaker 3 (18:37):
Right, And I want to say, I think like Dotna
Tour just came in to Fruition and Roslin.

Speaker 1 (18:43):
Do we have Roslin?

Speaker 2 (18:44):
Ross was announced at that point.

Speaker 3 (18:46):
Yeah, I think Roslin was. Yeah, it was at least announced.

Speaker 1 (18:50):
All right, so at least it was fun, right then.
I mean before Roslin in, before Core, it probably would
have been as much fun.

Speaker 3 (18:56):
I don't think, yeah, think about that. I think, yeah,
Roslin and Core a pretty fun. I do remember the
backlash from poor framework folks out there though. Yeah, transition, there's.

Speaker 2 (19:11):
Always discussion about what's going to make it across and
what isn't right. I think a Hunter said to me
ages ago, it's like, you only get to rewrite a
framework once, and and here we were, we're going to
commit to it, so and you've got it in the end.
The reason for the rewrite was that framework was just
too bound to Windows and if you really wanted to

(19:32):
be cross platform cloud friendly, you know, all of those
things they had to rethink a bounch of this stuff,
and they eventually get into certain libraries. And I'm looking
at you asb dot Net web forms just so bound
to iis so bound to Windows. There was no way
to lift it out that made it still the same thing.
You know, it would have it would not have been

(19:52):
the same same thing happened to wind forms, you know,
the wind forms version that went over across the three
one SDK is not the wind Forms of old. It
couldn't be.

Speaker 1 (20:01):
Yeah, and if Mono hadn't come around and all that
zammer and stuff, who knows how long it would have taken, right.

Speaker 2 (20:07):
I don't know if they would have done it, but
they would have. It's really a part of the Microsoft
becoming a cloud company instead of yeah, yeah that mindset
you said, Okay, well, then you needed to make tools
that support what your customers look like in the cloud.
And weirdly enough, your customers run a lot of Linux.

Speaker 1 (20:23):
So Leslie, you want to talk more about debugging, or
you want to talk about visual studio or productivity. It's
your show where you want to go?

Speaker 3 (20:30):
Yeah, I mean we can start with debugging since that's
been the topic that we're on, and kind of branch
from there because that is part of productivity, it's part
of VS in general. Yeah, So I mean it's more
really a question of where in the debugging world do
we want to even start, right, There's so much going on,
and I think with twenty twenty six especially, it's been

(20:51):
interesting to see how the debugger is evolving, especially now
that like AI and LMS are yeah, are being introduced
with it. Like I think of, I mean, obviously you
can just explain things with copilot or ask copilots to
analyze things for you. There's a whole debugger agent that

(21:11):
is coming out alongside twenty twenty six now that can
do a lot of that analyzing on your behalf, which
is really cool. And I really like the existing debugger
features that now have Copilot just built into it and
therefore help extend the productivity. Like I think of, one
of my favorite tools in VS and the debugger is

(21:35):
the I numerable visualizer. That's a yeah, and that's a
window if you don't know, it's a window that lets
you see a tabular representation of your list or anything
that's coming from an I numerable and really great already
because you can see that table based visualization. You know,
Excel as your friend, to the point where you can
even export that data to Excel if you wanted to

(21:58):
do that.

Speaker 1 (21:58):
But yeah, digging down into an I numerable and the
immediate window is not a no.

Speaker 3 (22:03):
Yeah, it's not fun, right, So nice people to have
this more visual, natural way of looking at it. And
now a co pilot added on top. I also like
to call my nickname for the Iumerable visualizer now is
the link sandbox, because it gives you already before Copilot
is even introduced. There's a space up top that lets

(22:24):
you enter link queries and see how that filters out
your list. That's fine, and the data in it, which
is really cool already, but then you put copilot on
top of it, and then you can ask Copilot to
create those link queries for you instead of having to
think of all those complex things put together yourself. So
a natural language.

Speaker 1 (22:43):
Just be got me curious about the copilot for the debugger.
Can you can you basically just say, you know, hey,
set up a watch variable for this and you know,
let me know. I mean, you can do that in
the debugger with a click, but can you do that
with the agent?

Speaker 3 (23:00):
I think that is not we're not quite there with
that yet, or if we are, I personally haven't gotten
it to work. But I think the beauty about that,
and it's.

Speaker 1 (23:08):
Not really a productivity booster, is it.

Speaker 3 (23:10):
I mean right, But that said, I think there could
be some merit to having the agent people to handle
some of that too, because especially if you're new to
the debugger, if you're new to visual Studio, you may
not know just yet that you can do well all
of that with the watch window.

Speaker 2 (23:27):
I mean, we open this conversation with the we barely
understand all the things that are in the debugger. Like
excited me about this is here's a tool that nominally
has access to every feature in the debugger, so presented
a debugging problem, maybe to activate features I never would
have naturally gone to with my knowledge of the debugger.

Speaker 1 (23:48):
Or maybe you know, when there's a scale issue, like
you know, you want to watch one variable, that's fine,
but what if there's a bunch of them that could
be implicated in a problem that you could just say, hey,
watch all the variables that that are created from here
on down something like that.

Speaker 3 (24:04):
Absolutely, yeah, and then there's a case of like watch
them only if this condition happens, which normally if you're
not using co pilots like you can use conditional breakpoints
for that, you can use dependent breakpoints for that, which
is one of those lesser known going to dig around
in the in the space to discover that one.

Speaker 1 (24:23):
Kind of have a propeller being to use that one.

Speaker 2 (24:25):
Yeah, now you're writing code in the debugger, right, You're
writing an expression in the debugger to debugger code. No.
I think that this this tool, this code generation tool
for the debugger like this, it could be incredible to
just get. You'll start using more of the debugger than
you ever have before.

Speaker 3 (24:44):
Yeah, I totally agree, And I feel like a lot
of my not vendettas, But I guess a lot of
my goals back when I was still on the team
even was just like, how can we take these tools
that are so cool that nobody knows about and how
can we just make them more discoverable.

Speaker 2 (25:00):
Yeah, this is a conversation you and I had in
a video series for Visual Studio. I think we spent
twenty minutes on exactly that problem is nobody knows what
they are, who knows about them?

Speaker 3 (25:09):
And it fricks my heart. Yeah, the punchline every time
I gave a debugging tips and tricks talk was always like,
is this new and twenty eighteen or whatever was the
newest version at the time, Like, no, it's been there since.

Speaker 2 (25:21):
Been there for years whatever.

Speaker 3 (25:23):
Yeah, that's actually how features like pinnable properties came about
because basically I was frustrated that there's this debugger attribute
that exists that you can or debugger display is the
name of the attribute where you can view like properties
of your objects and your classes and stuff directly within
the Watch autos and locals windows. But that's not very discoverable.

(25:44):
You have to modify your code to use it, that
sort of thing. So I was like, can we make
this more discoverable. Okay, let's have a little pin pop
up when you hover over your your properties. And adoption
for that has been way higher than the debugger display
attribute probably was. So it's just exposing the same functionality
in a more debugging friendly space.

Speaker 2 (26:06):
Well, and you always have to battle over popping anything
up that would an interrupted developer, Oh totally, even if
it's super helpful.

Speaker 3 (26:14):
Yeah, it's always that's always a debate that we have.
I'm actually dabbling a little bit on a project that
I can't talk about too much, but basically it's that
scenario of how do we improve this experience that everybody
is familiar with, but without making it seem too noisy

(26:34):
or impeding upon productivity that people already have.

Speaker 2 (26:38):
So interrupting is always the challenge, right yep? Are you
interrupting me? Is he going to make me grumpy if
you interrupt me? And yet you are interrupting me, but
arguably to a path of happiness.

Speaker 3 (26:51):
Yeah, hopefully to a path of productivity and goodness, less
frustration at two am when you're trying to fix some one.

Speaker 2 (26:58):
Just wrying to take come at this from a different way,
I mean again, because you're all in on twenty twenty
six right now, which is in an insider's preview. Yeah,
at the moment, so you can have access to it.
But do you see it as a rethink of visual studio.
It's just like the lllms have come to stay, and
how do we change our development experience in the idea,

(27:18):
I think.

Speaker 3 (27:20):
Reading is a big word, but I would see it
more as an extension of what our goals already have
been for visual Studio with the introduction of co pilot. Obviously,
the goal there is definitely to interweave that tool into
existing workflows so that it isn't interrupting you in a

(27:42):
bad way, as you mentioned, So that's definitely the goal there,
But a lot of the other goals that we've always
had have stayed the same, such as still improving performance
and still making sure that it looks modern and sleek,
and you're not focused about how bad the UI is
as you're trying to spend hours fixing your code or

(28:02):
something like that, and then just making sure that people
are still productive. So I don't think it's a complete
overhaul twenty twenty six, but just trying to streamline some
of that experience even further so that everything feels natural.

Speaker 2 (28:17):
Because you also work on visual studio code. I do, so,
I mean it says I just feel like the ID
is old school, Like there's a cold group of developers
coming out that's never been in an ID, which I
find frustrating because that was a happy place for novices,
like if you're new in the fact that you had
all your tools in front of you and it was

(28:38):
just there to help you do all the things. Yeah,
that doesn't seem to be the way that that new
people come into development these.

Speaker 3 (28:45):
Yeah, it's interesting because personally, I also when I was
at school studying computer engineering computer engineering, I was using
a full ide. I was using mostly Intelligent at the
time and a lot of x code because I a
Mac at the time. But yeah, full ID so for me,
and maybe I'm biased as a result. Like when I

(29:07):
started using vs code, it's I found a little harder
just because it's like all those tools that I'm used
to playing around with and using are not there by
default and having to.

Speaker 2 (29:19):
Yeah you have to assemble them.

Speaker 1 (29:20):
Yeah, you have.

Speaker 3 (29:21):
To figure it out kind of which, on the one hand,
can be nice because it gives you customers ability and
it's more, you know, the lightweight keyword is everyone's favorite
to use with thes code. But I definitely do think
the downside is like it kind of has the opposite
problem in a way with Visual Studio. Visual Studio, for
many people getting started, it can be really overwhelming, and

(29:42):
then yeah, it's because it's too much. And then I
think vs code, at least for me, can also feel
overwhelming because they're so little initially, so it's like, oh man,
where do I pull all this extra stuff?

Speaker 2 (29:53):
Well, and I always worry about forcing novices to make
decisions in their tooling that there don't you know, don't
have enough info on. It's like which of these baden
should I put in? Like what is the correct set?

Speaker 3 (30:06):
Right? Which extensions should I hear? And yeah, what?

Speaker 1 (30:10):
Yeah, I'm probably a little guilty of that in assuming
that everybody uses Visual Studio because I have an I
nine with sixty four gigs of RAM, Like it's very
fast and zippy for me, but probably not for your
average Windows laptop.

Speaker 3 (30:23):
Yeah, you know, yeah, I definitely actually use a dead
box most of the time when I'm using d S
or vs.

Speaker 2 (30:30):
Code because, right, because you want to a lot more.

Speaker 3 (30:32):
Consistent versus my laptop that I'm currently hanging out on.

Speaker 2 (30:35):
So yeah, you're sort of unloading the workload onto something
in the cloud.

Speaker 3 (30:40):
Right.

Speaker 1 (30:41):
But I've been I've been getting into vs code a
lot more lately, probably no thanks to Jeff Fretz, probably
more so than anything else, because he's, you know, we're
doing these shows together and he's always showing me stuff
in Visual Studio Code that I hadn't seen before. So yeah,
it's it's cool and you know, if it's see if
you have if you can look up things that you

(31:03):
are missing and you find them and you just work
around it. It's not a big deal.

Speaker 3 (31:08):
Yeah, I think once you get into a groove with either,
really you do get into a group. So as of
where I stand on vs CO now, like years after
starting with it, it's like, yeah, it's old hat, but
I sometimes worry about those getting started sometimes, like oh gosh,
it's like so minimal that it's hard to know where
to start.

Speaker 1 (31:28):
But you know, if you don't know where to start
and you don't know what you're doing, just call up
your good buddy mchaay calls them my bff, chat GPT.
You know, don't I do this?

Speaker 3 (31:37):
How I do download?

Speaker 1 (31:40):
Or just use the agent? You know, where's where's this button?

Speaker 2 (31:44):
You know? Totally please don't anthwer.

Speaker 1 (31:48):
Yeah, I really bugs Richard and you say worry.

Speaker 2 (31:53):
I'm t trying to keep people thinking coherently about these
software tools and very we can. It's very disturbing when
they get names.

Speaker 3 (32:02):
I mean, you know, yeah, I get scared to name
them too.

Speaker 1 (32:05):
Yeah, Kelly called chat GPT my bff from the very start.

Speaker 2 (32:09):
Nice, not a good thing. Hey we should take a break. Yeah,
let's do that, all right, we'll be right back after
these very important messages.

Speaker 1 (32:19):
Did you know you can lift and shift your dot
Net framework apps to virtual machines in the cloud. Use
the elastic beanstalk service to easily migrate to Amazon EC
two with little or no changes. Find out more at
aws dot Amazon dot com slash Elastic beanstalk.

Speaker 2 (32:43):
And we're back. It's Don at Rocks Amateur Camble. Let's
call Franklin Yolo hanging with Leslie Richardson. So recently have
both Orlando and Lisbon when we were doing our little
show too together. You're back home. I'm now fun. I'm
in New Zealand with the grand baby.

Speaker 3 (32:59):
Oh yeah, but I think you mentioned that.

Speaker 2 (33:01):
Yeah yeah, so have you had a good time, having
a great time? And if you hear dogs barking in
the background, it's the farm dogs because you know, farm
dogs do that sweet So outside of the debugger. Same
thing I have to see with visual studio all the time,
like the number of times I've been doing something a
visual studio and using a set of shortcut keys that
I've known for twenty years, like just pain switches and

(33:25):
things like that, and people go, wait, how did you
do that? Right? This discoverability problem is not a small.

Speaker 3 (33:33):
Issue, absolutely not. Yeah.

Speaker 2 (33:35):
Yeah, so it's so huge, it's so many features. But
again I think I wonder how much the LMS has
changed the way we're going to interact with code going forward. Yeah.

Speaker 3 (33:43):
Yeah, like my dream sort of either agent or extension
or maybe a mix of both that I do want
to write at some point I just don't have the
full hookups and needed to do it. Is I would
love for co Pilot to be able to be that
like Visual Studio or vs code feature suggestor like if

(34:05):
the user is talking to co Pilot like I want
to accomplish X y Z, why writing my code? Or
I find or let's use sticky scroll as an example,
like I get lost when I'm scrolling through my code.

Speaker 1 (34:18):
Is you're doing sticky codes? You know that you can
use this shart cut? Do you want me to just
do that for you?

Speaker 3 (34:27):
Yeah, except in this case you're prompting it so like
it's your choice. But at the very least co Pilot
would know about its existence and then be like, would
you like me to turn it on for you? Like yeah,
instead of having to search through the pavilion tools options.

Speaker 2 (34:42):
That is cool, that is or another kind of little
pop up, little icon thingy, like there's a lot of
those visual studios again, it's right. I know. I've had
conversations with folks where it's like, when is it you know,
the squiggles under code, you know, the TELISID stuff. We
are happy they're there, right, it tells us something. It's
not interrupt Sometimes the other ones, you know, can be

(35:03):
more problematic that you know, when is it a distraction?
And when is that help? But I just wonder if
the switch over to the LM approach of you know,
you could be or you know here, you could say,
watch how I do this, make suggestions on how I
could do it more efficiently. That's really interesting to me
because it's far more intentional.

Speaker 1 (35:23):
I hope Visual Studio twenty twenty six gets better at
things that in Visual Studio now, whatever I'm using twenty
twenty two can't remember. Yeah, it kind of loses track
of file handles and things once in a while and
says I can't build this because the file is in
use by another process. Well it's your process, right, it

(35:46):
certainly isn't.

Speaker 3 (35:46):
In mind.

Speaker 1 (35:48):
I didn't fire up notepad here, you know, and I
have to shut it down and reload it right and
then it's fine, right clean the solution. But if I
myself doing that a lot, and the other thing is like,
and I know Dustin worked on this in the Razor Editor,
just like squiggles when there shouldn't be squiggles, discoloration.

Speaker 3 (36:07):
Should canst be better.

Speaker 1 (36:09):
Yeah, so I'm really really I haven't checked it out yet,
but I'm really looking forward to the new version of
Visual Studio for because I know that it's better about
things like that.

Speaker 3 (36:17):
Yeah. I know, personally, I've had less hiccups with co
Pilot when I swapped over to twenty twenty six. I
think one of my biggest pet peaves that I had
with co Pilot in twenty twenty two. But to be fair,
I think this issue has since been resolved. I get
like the longer I chat with it, or specifically about

(36:38):
trying to get it to help me fix something wronger
to bug with me. Eventually it reached a point where
it'd be like it called this tool called get file,
I have no idea where that's coming from or whatever,
and then it would just freeze and do nothing, and
then I have to restart.

Speaker 1 (36:52):
I had the same exact problem and Visual studio code.
We don't really have that issue as well.

Speaker 3 (36:57):
Yeah, which is when I would swap forward to do
the thing. So yeah, I filed a bug on it
after much frustration, constantly seen it and I think it's
since been resolved. But that was definitely one one big
ripe I had with co Pilot on the twenty twenty
two side. I haven't experienced a gripe of that nature

(37:21):
since being on twenty twenty six, which I think is
pretty good.

Speaker 1 (37:25):
My favorite model for interacting with studio and studio code
and code and that stuff is clouds on it. I
don't know what yours is.

Speaker 3 (37:32):
Really, Yeah, yeah, I use clouds on it. Four point
five right now?

Speaker 1 (37:37):
Yeah, me too.

Speaker 2 (37:38):
Is that the latest?

Speaker 3 (37:39):
No, it's haiku. It's the latest one that just dropped.
It's got a number. I don't remember the number.

Speaker 2 (37:44):
Yet because I yeah, I've seen probably five folks working
in three five, seen him working at four four one.
Now it's four five.

Speaker 1 (37:52):
Haiku would be five to seven five, right.

Speaker 3 (37:54):
Yeah, No, I was waiting for that.

Speaker 2 (37:58):
God, I hope that's true. That would be the best
thing ever.

Speaker 3 (38:02):
Can we make a haiku about Claude Hahiku? Claude Hiku
is cool. Many models aren't as good. Use Claude Hiku.

Speaker 2 (38:18):
Now, lots of compile blinky lights.

Speaker 3 (38:25):
But yeah, I mean so that I enjoy clouds on
it the most, and then I buffer it up usually
with I'm on that awesome dash co pilot. Yes, repository
all the time, Like this mode is, I love to
use it.

Speaker 1 (38:43):
So this is like a repository of prompts and things, right, yeah,
so this is system prompts and yeah great, Yeah.

Speaker 3 (38:49):
Just a bunch of community created prompts, co pilot instructions,
chat modes, just a lot of different already made for you,
copy paste it and your ID choice things that enables
you to do certain tasks better with so cool pilot
and agents.

Speaker 1 (39:06):
Like plug ins and text mode. You know, is really
really simple, so good.

Speaker 3 (39:11):
I love it. Yeah, go clues gaved you the trouble
of having to write paragraphs of prompts as well, because
somebody else has already figured it out.

Speaker 2 (39:19):
So yeah, but it do feel like you, I think
we've talked about this on a previous show, like you
want to build up a repertoire of prompts, even a
record of them, for a given project, because it is
sort of it isn't a way it's your code now, Yeah,
the way you're describing, you know, features. And we talked
about githubspec kit for the same and in the same
sort of area. Yeah, how do we actually mature that

(39:41):
the prompts that are creating our projects?

Speaker 3 (39:43):
Absolutely, and yeah, that's becoming increasingly more and more important
to be able to hold on to those Unicorn prompts
that have been shown to work most of the time.
And I'm really glad it took v S a minute
to do it, but they finally introduce reusable prompts. I
still think that experience could be streamlined because right now
you still have to like go out and no pad,

(40:05):
copy and paste whatever prompt you want to write, and
then save it as a particular markdown and make sure
it goes in the right folder. All this stuff that
I think would be streamlined to just like one or
two steps instead of like the five you currently have
to do for that. But I do appreciate that it's
at least there so you can.

Speaker 2 (40:21):
You're you're on that path, just go through.

Speaker 3 (40:24):
Yeah, the prompts that are already listed in your project.

Speaker 2 (40:27):
I can imagine an enterprise organization that the architects have
a bunch of uh, you know, prefixes initial statements to
any prompt that in our organization, these are the rules
for co generation, and so whatever additional prompt you're putting
in there is shaped by the enterprise requirements exactly.

Speaker 3 (40:44):
It's so nice, Yeah, somebody, I'm sure teams have already
started to do that, Like, here's our set of rules
and standards for what we have, pass that into co
pilot and then just build on top of that. Right,
I think bonus points if co Pilot was more aware
of the editor can fig file, which I desperately want.
I feel like it's very hit or miss on whether

(41:05):
it acknowledges the contents of that.

Speaker 2 (41:08):
But getting there, how does that impact things?

Speaker 3 (41:13):
Yeah? So the editor can fig file, for those unaware,
is a really cool file you can add to your
project that basically keeps you and your team consistent with
how you're formatting, the kinds of analyzers you're choosing to use,
the severity levels of certain errors and things. So, for example,
if you want to make sure that everybody is placing

(41:34):
the standard eye in front of an interface when you're
defining an interface, you can change the severity level that
Visual Studio throws at you from being just like a
suggestion to a full on compilation error because you want
to make sure that everyone's staying consistent. So it's keeping
yourself accountable. It's a great file to have, and whatever

(41:55):
you put in there from a formatting standpoint overrides whatever
you've got in the tool options as it relates to formatting.

Speaker 1 (42:02):
So it reminds me of fx cop back in the day.

Speaker 3 (42:05):
I'm not familiar with that. Is it kind of similar?

Speaker 1 (42:08):
I was a dot net framework thing that you know,
basically helped enforce the standards of cotyle.

Speaker 3 (42:16):
Yeah, okay, I gotcha, Yeah, same deal. But yeah, I
bring it up because I would love for co pilot
to basically take the editor and can figure the editor
can fig file into account the same way it takes
into account the copilot dash instructions, not md file, and
it's like always using it as a reference no matter
what prompt I'm giving it, so that copilot also has

(42:38):
to follow the same rules that I have to follow
and the team has to follow.

Speaker 1 (42:43):
Have you found the LM's ignoring things in the system
prompt and and you know, sometimes following them and sometimes not,
Like if you tell them, never do this and they
do it anyway.

Speaker 3 (42:54):
Yeah, I've had some weird quirky moments with that every
every once in a while. I know, I think maybe
some of it is partially my human error. The last
time I could think of where I encountered that issue
is because I wrote a copilot dash instructions file and
it I forgot to put it in the dot GitHub

(43:15):
folder it's supposed to go in. But if anything, I
think that needs to be more clear in the documentation
because it's not off up front.

Speaker 1 (43:20):
But I've had this situation where you know, you're either
using that file, which is essentially a system prompt, yeah,
or a system prompt itself, and you know it's picking
up most of the things in the system prompt, but
some things that just completely ignored And I don't know why,
And I don't know. I couldn't tell you what it
was about that particular prompt that I gave it that

(43:43):
made it ignore the system prompt. But maybe, you know,
if it finds inconsistencies between the user prompt and the
system prompt, maybe a'll just ignore stuff. Yeah, I don't know.

Speaker 3 (43:53):
I guess maybe it start things start to get tricky
once you are involving multiple prompts that potentially contradict each
other in some ways.

Speaker 2 (44:01):
Maybe that isn't this a plot of two thousand and one?
A space out?

Speaker 3 (44:09):
I'm afraid I cannot do that.

Speaker 2 (44:13):
Sorry. What happens when you have to make keep the
mission safe at all conditions and you've now deducted that
having the other people alive is it is a risk
of the mission?

Speaker 3 (44:25):
Yeah, I know. One of my current frustrations I have
with co pilot ignoring or not ignoring things has to
do with MCP servers, because that's currently where I'm spending
a lot of my time these days. And sometimes, like
with the GitHub one, especially as an example, I'll be like,
write me a PR or just commit these changes with X,

(44:47):
y Z things, and then it's like sure, but then
it completely ignores the server that's just chilling waiting to go.
And then we'll just open the command line and start
running get commands there, and I'm like, that's not what
I wanted. So sometimes I have to be like super specific,
like use the MCB server, but is chilling out there?

Speaker 2 (45:06):
Mm hm, and you talget specifically the ge hub MCP server.

Speaker 3 (45:10):
Yes, yeah, So in this example, that's the one.

Speaker 2 (45:15):
But I mean, yeah, there's a there's a philosophical debate
here about if I have a tool that can generate code,
like why not just to generate assembly code, right like
go all the way to the bare bones right away.
You don't have to live with that code, it's just
going to generate it for you. And if that same
toke is like it can write the get hub messages itself,
why go through the MCP server, Like, you know, the

(45:37):
fact that we have to direct it that way is interesting,
Like it ought to default to the MCP server because
it's safer, Like what's the advantage there, right?

Speaker 3 (45:44):
Yeah, I mean it depends on what the given scenario
you're trying to accomplish is. But I know, for me personally,
I like to use the get hub MCP server over
like even just the built in visual studio get changes
page because get changes has evolved a lot, Like it
wasn't even there at the time that I joined Microsoft,
and now it's since blossomed into a fully and to

(46:05):
end like you can create prs in it straight up experience. Now. However,
I still like to use the MCP server one because
I like to use natural language, especially when it comes
to get. I'm kind of allergic to the terminal window sometimes,
so I don't always like to use CLI commands.

Speaker 1 (46:25):
Yeah, and it's just more stuff that you have to remember.

Speaker 3 (46:29):
Yeah, I agree, and trying to remember some more of
the niche commands like get blame or get rebase and
stuff like that I don't have to do because I
can just tell the MCP server that is what I
want to do, so please figure it out for me.
And also I do find that it writes better prs
for me than just doing it either myself or with

(46:52):
even the Visual Studio Integration Tool. Integrated tool does like
it gets really detailed about it, which I love because
I have experienced either because I'm guilty of it or
because I'm reading someone else's prs where there's nothing to
be found in the description. Sometimes it's just a header
and that's all.

Speaker 2 (47:10):
You get in my fixed stuff.

Speaker 3 (47:14):
Cool, we know what you're talking about.

Speaker 1 (47:17):
All right, here's something from out of left field. Just
from my experience in VS code and Individual Studio with
the agent, the asynchronous nature of it leaves me baffled sometimes,
like it will work on a problem right, and you'll
have one file that it changes and there will be
a keep button there, but it's still working. Yeah, Should

(47:38):
I press the keep button? Or shouldn't I press the
keep button? And should I wait until it's all done?
And there is there a keep all? I don't see it.
Keep all? Do I have to go find all the
things that change?

Speaker 2 (47:48):
Right?

Speaker 3 (47:49):
And that's the same to be strange time, it is
kind of scary, like I'm one where I get nervous
about doing it while it's in the middle of something,
So I don't keep until like the end of TEI.
But I feel like how it's maybe working behind the scenes,
and maybe if you talk to someone on the co
pilot team, they can give more detail. Here it feels

(48:10):
like it's making a change, and then it's basing all
future actions that are all future actions that copilot's doing
after the fact based off of those changes, whether you've
chosen to keep it or not.

Speaker 2 (48:21):
But how about that?

Speaker 1 (48:23):
How about this one? It makes changes in five different
files and it doesn't build and it says it's done
right right, Okay, you're not done? Should I keep it?
Should I keep this one or that one? Or undo everything?
Can I just tell you to undo everything?

Speaker 3 (48:40):
But I know I kind of hate the confidence about.

Speaker 2 (48:46):
Done when we're not able to build.

Speaker 3 (48:49):
This looks great. It works great, even though I didn't
build it at all. It does.

Speaker 1 (48:54):
It goes on. You're exactly right, Yes, let me.

Speaker 3 (48:58):
See that for you right the whole time. But yeah,
this was just a test. I was just testing you.

Speaker 2 (49:06):
Yeah, we've blown the wings off the airplaning. We're plumbing
towards the ground. But you were right that test would
blow the wings off. Yeah, thank you.

Speaker 3 (49:14):
That's why I like the beast mode prompt because, like,
if you use nothing else on Awesome dash Copilot, yeah,
I highly recommend beast mode. Yeah. So it's a really
great prompt. It's really long if you look it up
on Awesome dash Copilot. It's actually under the chat modes holder.
But it is a prompt that's basically at its core
telling co pilot you know nothing, Like you don't know

(49:37):
as much as you think you do. So as a result,
go look on the internet for additional documentation and other
resources before you give me a response. So I do that. Yeah,
it will make an itemized list. It's going to make
sure to at least try to build, try to build
the thing before it gives you the response of it
works great and go from there. So it just addresses

(49:58):
a lot of the nippicks that I think a lot
of people have with Alowans in general. And Wow, it
makes copilot. It puts co pilot down a peg, I
guess in terms of its confidence level. So it tries
to be right and that's double checking its answers more.

Speaker 1 (50:14):
That is one thing we've noticed about about sign it
in particular is that it tries to overperform, over deliver right. Hey,
while I was at it, I read your entire application.

Speaker 2 (50:29):
Like whoa Hey, whoa whoa whoa whoa Yeah.

Speaker 3 (50:34):
And best most nice because it also breaks down what
it's going to do in steps, like you get a
little to do list from it, and so for me
usually if I'm doing like vibe coding with it, I'll
be like, do this, but do not continue to the
next step that you're referring to until I say so,
so I can like review everything before it.

Speaker 2 (50:51):
This decreases the risk of the universe being turned into
paper clips.

Speaker 1 (50:55):
Yeah, find me the best price on a flight to Miami,
but don't buy it.

Speaker 3 (51:01):
Yeah, do not the goodness don't buy that. Spirit air
ones to tick up for one thousand dollars. What are
you doing?

Speaker 2 (51:09):
And I have to ride in an overhead bin? Oh
my god, buddy.

Speaker 3 (51:17):
Yeah, check out beast Mode. It's also a great It's
a pretty funny read too, because a lot of it's
like in all caps. It kind of reads like a
really tough coach in a sports movie being like Mercies
for the week, blah blah bla blah blah, don't do
this x y Z.

Speaker 2 (51:33):
Is this Burke Holland wrote this?

Speaker 3 (51:35):
Yeah, the awesome, wow, awesomeness. Who was Burt Holland.

Speaker 2 (51:39):
He's great, it's so funny.

Speaker 3 (51:42):
Yeah, he's wonderful.

Speaker 2 (51:44):
Yeah, a clue to linked to beast mode for in
the show notes for sure. For that, it's it's very
interesting when you push these tools into very specific behaviors,
they will follow. You know that. You know, we were
playing this game with the tool where we were stripping

(52:06):
away all of the obsequiousness, all of the decorative language,
and then and then so it respond very tersely. And
then when we press against certain subject areas that where
you know, some perhaps political in nature, suddenly the language
will get very big again. Like ah, okay, so this

(52:26):
is hard coded stuff like this is not the LM
generating it. Somebody's written in if you go, if you're
in this direction, this is what you must say. So
you know, there's lots of fixes inside these systems for
dealing with the reality of the world. I wonder if
beast mode turns the sycophancy off, you would hope, you know,
just just don't don't be such an ass kisser. I

(52:49):
wonder if I could just put that in the system
prompt it's like absequious mode, low.

Speaker 1 (52:59):
Purple, a clairvoyant.

Speaker 3 (53:02):
I do like having that ability. Like I I Vibe
coded an MCP server the other day that's basically like,
let's play Wordle. So it's a server that will boot
up a game of Wordle and copilot chat when I
tell it to. But by default it's maybe just because
of the clouds on it. It's super verbose about it,
and it's just like, hey, let me spoil the game

(53:24):
for you, okay, let me give you some suggestion words
to type in like no, So at one point I
was just like, just give me the map and how
many guesses I have left, and I will do the rest.
And it's like sure, and like MCP server still works,
but it's just a lot more blunt about it.

Speaker 2 (53:40):
Are there other mcps coming inside a Visual Studio then,
Like we talked about the GitHub one, but I can't
imagine there's a bunch of others in development, like.

Speaker 3 (53:47):
The registry, oh, the server in general. Yeah, so there's
a ton of MCP servers to take advantage of, and recently,
like I think, if you download the latest build of Insiders,
you should be able to act us a built in
way to browse MCP servers directly in Visual Studio. This
also applies to VS code, but VS just introduced there.

(54:10):
So similar to the Extension Manager where you can browse
for extensions, there's now an experience for MCP servers. I
think you can access it via the extensions tab in
Visual Studio, which if they place to put it, but
for now that's where it's located. Click that tab and
then there's an MCP like browsing option right that you

(54:30):
can click on to see all the different servers.

Speaker 1 (54:33):
We hear or I hear that there's a version of
the Microsoft Seql Server MCP coming that doesn't require node
and all of the other crazy things that it currently requires.

Speaker 3 (54:47):
That'd be cool.

Speaker 1 (54:48):
Uh yeah, yeah, waiting for that one.

Speaker 3 (54:51):
Yep, that would be nice. Actually, I enjoy that a lot. Yeah,
I think of some of my O our favorites I
really like, and the under the Azure MCP server, which
is huge, so I try to like filter the tools
I actually care about. I like the tools on Azure
Cousto because as a PM, we spend a lot of

(55:11):
time in Cousto looking at telemetry and trying to build
Cousto queries to get the telemetary that telemetry that we want.

Speaker 2 (55:19):
Nobody wants to write Cousto queries.

Speaker 3 (55:21):
No, exactly, nobody wants to write Nobody wants to do that.
It takes like half the day.

Speaker 2 (55:27):
It's horrible to write a Cousto queries. There's only two outcomes,
no data or all of the data nothing else.

Speaker 3 (55:36):
It's like that's too much. It's like, god, it sucks.
So yeah, the COUSTA one is nice because it does
a lot of that coustal query generation for you, and
it's starting to acknowledge some of the internal tables that
we have, which is so exciting because uh, nobody likes
to document what happens in each internal table that we

(55:58):
need to access, so you just have to get are
pretty God that somebody is around who knows what's up
with that table in its contents. Otherwise you're making educated
guesses a lot of time.

Speaker 2 (56:09):
So it's well, I interviewed Mark Morowski on run As Radio,
who's written the book on Cousto querying. Wow, but I
still feel like and it's a cookbook too, So it's
got a whole bunch of great queries that already in it, and
I absolutely courage people to have it. But you know what, boy,
this is a great use for LMS.

Speaker 3 (56:28):
I just you know, it's like you have the vision
in your head and you just do not know how
to put it on.

Speaker 2 (56:34):
To describe it in a prompt and let the tool
iterate on it till you get results. And you can
tell that prompt this is too much data. Narrow the
scope and right and have it try to solve the
problem for you. It might not succeed, but at least
you're not the one just monking with parameters trying to
figure out how do I narrow this. I wonder, I

(56:54):
wonder if your average dot and I Rock's listener knows
what KQL is, maybe we should just tell.

Speaker 3 (56:59):
Them Custo query language.

Speaker 1 (57:02):
Yeah, it's for querying. Azure. It's what you were just talking.

Speaker 2 (57:06):
About, right, Everything you possibly want an Azure, which by
the way, is too much stuff is in there.

Speaker 3 (57:13):
Yep. A little very similar to SQL, I think, but yeah,
just still still annoying to craft those queries just as.

Speaker 2 (57:21):
But yeah, but it queries across all kinds of different
stores inside of Azure. Like I said, it's very easy
to get.

Speaker 1 (57:27):
So you're saying there's an MCP for for KQL. That's
what you're saying, right, and it makes it so much easier.

Speaker 3 (57:34):
Yeah, good good, thank goodness.

Speaker 2 (57:37):
Yep.

Speaker 1 (57:37):
And this is going to come out when a couple
of weeks something like that.

Speaker 2 (57:41):
Yeah.

Speaker 1 (57:42):
Yeah, so on the twentieth I think. So this past
week Fritz and I did a code with AI that
where we tried to use the SQL MCP to query
a Netflix database Netflix publishes or somebody got held of
Netflix data for twenty twenty four and it's all historical data,

(58:04):
so it's no big deal and about all the movies
and titles in the visibility and all the you know,
how many people accessed it and all that, and yeah,
we tried to use the sequel MCP and we did.
We got it working. But just to try to explain
to people how to set it up. It turned out

(58:24):
we would spend most of the episode doing that and
actually using it. So what we did was I thought
pretty ingenious. We used the internal MCP in Aspire, set
up the sequel server with a script in Aspire, and
then we use the internal MCP to tell it, hey,
give us the schema for the tables. So it did that.

(58:46):
We put that in the system prompt. We said, here's
the schema, here's some mappings from English words to the
field names in these tables. And then just take the
text that we put in there the user puts in
and translate that to a t SQL statement And that
worked really well. And so there's two steps to it.
You see the t squl statement and then you hit

(59:06):
a button and it executes it and puts it in
a grid.

Speaker 3 (59:08):
It's pretty sweet.

Speaker 1 (59:10):
So I thought that was a pretty cool thing. But
I wouldn't want to do that if I had one
hundred tables a thousand tables. So yeah, looking forward to
the to an upcoming version of that makes it easier.
But the whole goal, right is, you know, hey, you
want to SEQL server MCP or this MCP or that one,

(59:30):
just push a button, poof install it. Now you've got it.

Speaker 3 (59:33):
Mm hmm yeah that is the general idea.

Speaker 2 (59:36):
Yep, I love it.

Speaker 1 (59:38):
Well, we are unfortunately out of time, but Leslie Richardson's
amazing talking to you.

Speaker 3 (59:45):
Thank you, thanks for having me. Was pun to chat
on this lovely prid.

Speaker 1 (59:48):
Let's do this on a more regular basis.

Speaker 3 (59:50):
I agree, Yeah, okay, and we'll.

Speaker 1 (59:53):
Talk to you next time on dot net rocks. Dot

(01:00:17):
net Rocks is brought to you by Franklin's Net and
produced by Pop Studios, a full service audio, video and
post production facility located physically in New London, Connecticut, and
of course in the cloud online at pwop dot com.

Speaker 2 (01:00:33):
Visit our website at.

Speaker 1 (01:00:34):
D O T N E t R O c k
S dot com for RSS feeds, downloads, mobile apps, comments,
and access to the full archives going back to show
number one, recorded in September two.

Speaker 2 (01:00:46):
Thousand and two.

Speaker 1 (01:00:47):
And make sure you check out our sponsors. They keep
us in business. Now go write some code, see you
next time.

Speaker 3 (01:00:54):
You got Jack Middle Vans O god that means home,
then my Texas in a line. Credit b