September 2, 2026 • 60 mins
How can constraints make software development assistants more efficient? Carl and Richard talk to Don Demcsak about his work on getting LLMs to build higher-quality software with fewer resources. Don talks about how domain-driven language techniques help to define and constrain language around a given application problem space, but that largely hasn't been applied to coding agents so far. And as powerful as domain-driven is, it has challenges when it comes to building applications - and, more importantly, testing them. That's where behavior-driven approaches have advantages, which can also be applied to agents. Applying techniques of the past to tools of the future can accelerate development even further!
Listen
Watch
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:01):
How'd you like to listen to. NET Rocks with no ads? Easy.
Become a patron. For just $ 5 a month, you get
access to a private RSS feed where all the shows
have no ads. $ 20 a month will get you that
and a special. NET Rocks patron mug. Sign up now
at patreon.dotnetrocks.com. Hey, and welcome back to. NET Rocks. I'm
(00:36):
Carl Franklin.
Speaker 2 (00:37):
And I'm Richard Kaplan.
Speaker 1 (00:38):
Our friend Don XML, I mean, Don Demsack is here.
Speaker 3 (00:41):
Oh, jeez.
Speaker 1 (00:42):
Or is he Don Jason? Are you Don Jason now?
Speaker 4 (00:45):
That's my brother.
Speaker 2 (00:48):
At least he didn't say Don Yammel. God knows. No.
Speaker 5 (00:51):
No.
Speaker 1 (00:53):
This is going to be a good one. This is
episode 2018. And as we always do at the top
of the show, let's talk about things that happened that year.
I get all the depressing ones and Richard gets all
the happy ones in space and tech.
Speaker 2 (01:09):
Just have to pick carefully.
Speaker 1 (01:11):
Yeah, I guess so. But, you know, these are important events, right?
Speaker 2 (01:15):
Are they?
Speaker 1 (01:16):
School shootings.
Speaker 2 (01:17):
Are they?
Speaker 1 (01:18):
Robert Mueller's Russia investigation.
Speaker 2 (01:20):
Oh, yeah.
Speaker 5 (01:21):
Well.
Speaker 1 (01:21):
Brett Kavanaugh, Supreme Court confirmation battle.
Speaker 4 (01:25):
Yeah.
Speaker 1 (01:25):
The 2018 midterm elections when the Democrats took over. The
Democrats strike back. Did they?
Speaker 5 (01:32):
Okay.
Speaker 1 (01:33):
Well, okay.
Speaker 2 (01:33):
I don't know.
Speaker 1 (01:37):
Trump and Kim Jong-un, still crazy after all these years.
Speaker 4 (01:41):
Nice.
Speaker 1 (01:42):
Still friends.
Speaker 2 (01:42):
I think that was one of the first meetings, wasn't it?
Speaker 4 (01:45):
Yeah, yeah.
Speaker 1 (01:46):
June 12th in Singapore. Jamal Khashoggi, as Trump said, these
things happen. He was killed and dissolved in a bathtub
of acid.
Speaker 2 (02:01):
Or something.
Speaker 5 (02:01):
Okay. Okay.
Speaker 1 (02:02):
Or something. That's what we think. California wildfires happens every year,
but 2018 was particularly bad. The Me Too movement and
the Larry Nassar scandal. And just to put a little
fine point on it, hurricanes Florence and Michael.
Speaker 3 (02:18):
Right.
Speaker 2 (02:18):
Those are good ones.
Speaker 1 (02:19):
Catastrophic flooding in the Carolinas.
Speaker 2 (02:21):
Yeah.
Speaker 1 (02:21):
And the Florida panhandle. All right, Richard. That's enough.
Speaker 2 (02:24):
Well, it was also, remember that cave rescue in Thailand? Oh, yeah.
Those students went in and there was the flash flood.
That's when that happened.
Speaker 1 (02:32):
That was a good story.
Speaker 5 (02:33):
It was.
Speaker 2 (02:33):
I mean, one of the rescuers lost their lives trying
to save those kids. Right. But they were successful. Do
you remember when, I think that's when Elon started going crazy. Yeah.
Remember he really wanted to be involved in that. It's like,
you're not actually qualified. I'll build a submersible. It's like, A,
you don't know how to build a submersible. And B,
that's not going to work in a cave either. And
(02:53):
then he got really snarky and started calling people pedophiles
and things. Yeah. I don't know. It was one of
those moments because this is the same year that the
Falcon Heavy flies for the first time and Elon put
his red Tesla Roadster on top of it as the payload,
which was pretty cool.
Speaker 1 (03:11):
I thought that was the cool Elon doing that.
Speaker 2 (03:13):
Yeah. But it's interesting to think that's the same year
he goes nuts on this cave rescue thing so i
mean things are just getting.
Speaker 1 (03:22):
Weirder and weirder yeah weirdness weirdness abides um also i
want to mention aretha franklin and anthony bourdain died in
2018 yeah very sad also paul allen very sad about
have you there's a new movie like a documentary about anthony.
Speaker 2 (03:39):
There's an anthony bourdain movie coming out imminently yeah so
it hasn't come out yet I think it's just out
brand new. Okay.
Speaker 1 (03:44):
Yeah. I want to see that.
Speaker 5 (03:45):
Yeah.
Speaker 1 (03:45):
Also George H.W. Bush and John McCain died. Yeah.
Speaker 2 (03:49):
All right, Richard, save us from this misery. So I
mentioned the Falcon heavy flight, which, yeah, that was pretty cool.
We ended up doing a geek out about it. I mean,
it was just an extraordinary rocket strapping three side by side.
Originally he had planned on doing something called asparagus staging,
where he was actually going to feed the fuel from
the wing of boosters into the center so that when
the outer boosters were empty and separated, the center booster
(04:12):
would be completely full. Never happened. Instead, they do it
the simpler way, which is simply to throttle down the
center booster so it doesn't burn as much fuel. That
being said, Falcon Heavy, you'd be never real happy with
it The simple reason that it has a lot of power,
but it doesn't have a lot of payload space. And
so there's relatively few cases where it's needed. And he
was already talking about what we now know is Starship, uh,
(04:35):
and starting to do prototypes around all of that. Uh,
we have a lot of cool, uh, satellites up in 2018,
starting with tests, the transiting exoplanet survey satellite. So this
was the only, the third of the dedicated finding exoplanet
satellites that the, the successor of Kepler. Kepler had launched
back in 2009 and found 2,600 exoplanets. That was Kepler's
(04:59):
mission was to do deep surveys to see how common
are planets. And the answer is very common. Most stars
have planets. TESS as a survey satellite is not designed
to observe as closely, but to cover much larger tracks
of the sky. And fast forwarding eight years now, it's
found over 8,000 potential objects that generally need additional surveying.
(05:24):
because it is a survey spacecraft. But of those 8,000,
almost 1,000 have not been confirmed as exoplanets. So if
you're keeping count, we're up around 6,300 confirmed exoplanets so
far from all of our different collection methodologies. This is
not how Star Trek was supposed to work. Remember in
(05:44):
Star Trek, you had to fly to the solar system
to see the planets? No, we're going to have a
map of all of them long before we can get
to any of them. There's a couple of asteroid missions.
Hayabusa 2 in June got to Rigu. And in December,
OSIRIS-REx gets to Bennu, which is cool. We start to
explore asteroids sort of on a regular basis. In August,
(06:06):
the Parker Solar Probe, the first time we've ever tried
to fly a satellite to the sun. to actually do
measurements of its outer atmosphere. That's a very difficult thing
to do. You have to go really, really fast to
do that.
Speaker 1 (06:18):
Remember Richard Pryor's bit, the first man to walk on
the sun?
Speaker 4 (06:21):
Ooh, ah, ah, ooh, how?
Speaker 2 (06:26):
So to make the solar probe go fast enough to
get that close to the sun, they launched on a
Delta IV, which is one of the highest performance rockets
ever made. It's largely obsolete now and retired and broke
a bunch of speed records to try and get it
down there. It'll take a while to actually get close
enough and actually start to do sampling of the sun.
Also in August was when on the International Space Station,
Soyuz MS-09, this is the vehicle that they transport astronauts
(06:50):
to and from the space station, which at that time,
because the shuttle is no longer flying and Crew Dragon
doesn't exist yet, it's still in development, was the only
way to get to the station. They find a two
millimeter hole in the orbital module of the Soyuz. And
there was a lot of controversy about whether it was
drilled because it was sort of a perfect hole or
was it just that right hole? you know, penetrator that
(07:12):
it went through there. Anyway, fixed with a piece of
cape on tape.
Speaker 1 (07:16):
Could have been mice.
Speaker 2 (07:17):
You know, and because it was the Orbridge module, it
doesn't have to survive re-entry, so it's not that big
of a deal. But yeah, it kicked up a lot
of speculation. And if that wasn't enough, the very next
Soyuz in October, this is Soyuz MS-10, it was only
carrying two passengers. Normally, the Soyuz can carry three, but
occasionally fly with less. In this case, it had Alexei Ovichin, And, uh,
(07:39):
from Roscosmos and Nick Hague from NASA, they were going
to be part of the exhibition 57 to the international
space station. But two minutes after launch, there was a failure.
And Soyuz is one of the most reliable, most flown
spacecraft of all time.
Speaker 1 (07:53):
Yeah.
Speaker 2 (07:53):
This was one of the very rare failures and it
was a failure that had never occurred before. There was
something wrong in the sensor of one of the strap-on boosters.
There are four strap-on boosters that famously separate from a
Soyuz and do what they call the Korolev cross. As
they come flying off. And it didn't happen this time.
And the one booster hung up. And then when it
did break away, it struck the central booster core. And
(08:17):
that ended the going into space. As Nick Hague said,
as soon as the bouncing around started, I guess we're
not going to the space station. But at this point,
they're already 50 kilometers up. And that's too high for
the escape tower. So it's already been ejected. But there is...
Mode 2, Ascent Abort, a system that had been tested
(08:38):
but never used. And this was the first and only
time it's ever been used.
Speaker 1 (08:43):
So they basically turned it around and re-entered?
Speaker 2 (08:45):
It's more complicated than that because you've got an exploding
rocket behind you, so you don't want to be near that.
So instead of abort motors fire and push the Soyuz
assembly away from the booster, and then you have to
get into... descent mode because you're carrying the propulsion module
as well as descent module and the orbital module so
those each have to be pushed off and then it
(09:05):
has to switch over to descent mode get the heat
shield pointed down and actually land because of the angle
of ascent they only get to about 90 kilometers so
they spend some time in free fall still going up
the explosion happened.
Speaker 1 (09:16):
At 50 dude you should make movies This is great.
Speaker 2 (09:20):
It's crazy.
Speaker 1 (09:21):
It's like I'm on the edge of my seat.
Speaker 2 (09:22):
And they're in free fall, and now they have to reorient,
and they do a ballistic return, which means those poor
guys pulled about seven Gs as they came back down.
Worked perfectly. Both astronauts walked away. The crazy part is
realizing from launch at Balkanur to on the ground about
200 kilometers downrange in Kazakhstan, 19 minutes.
Speaker 4 (09:44):
Oh, my God.
Speaker 1 (09:45):
Goodness.
Speaker 2 (09:46):
It was fast and it's all automated. Like basically they
were having trouble keeping up with the control systems working
through it.
Speaker 1 (09:53):
That's definitely not enough time for a feature film.
Speaker 2 (09:55):
No, it's pretty quick, but I'm sure there's a bit
of story to go around it. Anyway, it worked flawlessly.
and they would eventually get to space on a different
spacecraft because that one weren't no good no more. In November,
we have the 20th anniversary of the International Space Station
because the Zarya module went up in 1998. We're also
fully over into commercial resupply now. So Roscoff's mostly due
(10:18):
to five deliveries in 2018. But SpaceX does three on
Cargo Dragon. Orbital ATK does three with Cygnus. And JAXA
has one HTV delivery. So a total of, what is that, 12.
And also in November, the InSight lander lands on Mars.
First thing to have landed on Mars since Perseverance. And
it's doing measurements of Mars quakes and interior mapping of Mars.
(10:41):
by looking at reverberations that travel through the planet. And finally,
in December, China launches the Chang'e 4 relay satellite in
preparation for their landing, putting a lander and rover down
on the far side of the moon. They need a
satellite to be able to communicate with the far side
of the moon. So that goes up in 2018. The
big mission will be in 2019. Ready for compute stories?
Speaker 1 (11:02):
Yes.
Speaker 2 (11:03):
And you always think I have to give you all
the good news. So let's start off in January with
Meltdown Inspector. Okay.
Speaker 1 (11:10):
Okay.
Speaker 2 (11:10):
So these were discovered potential exploits using a speculative execution
that exists in both AMD and Intel processors. And there
was no security around that. So the theory was that
if you did stuff exactly right, you might be able
to grab data from another virtual machine that was running through.
(11:31):
This exploit has never been found in the wild. Even
attempts to try and utilize it have been largely futile.
But at the time, they really freaked out. And putting
security rules in place caused substantial performance penalties. I think
to talk about literally 20% of available compute disappeared to
fix spectrum and meltdown.
Speaker 1 (11:50):
Not good.
Speaker 4 (11:51):
Remember that?
Speaker 1 (11:51):
Wow.
Speaker 2 (11:52):
And adding to my, I don't only have good news
stories in 2018, Google officially removes their don't be evil
from their code of conduct. I mean, they didn't add
be evil, but they just took out the don't be.
And then in March, uh, The Cambridge Analytica scandal. Oh, yes.
Where Cambridge Analytica had mined Facebook data in a way
that not even Facebook had thought about and was very
(12:15):
effective at doing things like creating ads for individuals where
the individual didn't realize they're the only ones seeing the ad.
A very effective strategy for getting a group of English
people to vote against their best interests and exit the EU.
Speaker 1 (12:29):
Now we have Facebook and nobody cares.
Speaker 2 (12:31):
There you go. Yeah.
Speaker 1 (12:32):
Targeted ad.
Speaker 2 (12:33):
And in April, Belgium declares... video game loot box systems
to be gambling and illegal for minors, which it is.
I don't disagree with them. Interesting problem. Yeah. Don't manipulate children, please. Well,
not too heavily. And then in May, the GDPR is enacted.
It's been in development for a few years. This is
(12:53):
why you have to keep agreeing to cookies as well
as a bunch of other things like the right to
be forgotten and serious fines for not being forthright with breaches.
Speaker 5 (13:03):
Yeah.
Speaker 2 (13:03):
Um, over on the Microsoft side of things, it may,
we have build 2018, which ships.net core 2.1. But also,
and I realized this in hindsight, when I was putting
this together is sort of the first wave of AI stuff.
Remember visual studio and telecode? I think we did a
show on it.
Speaker 4 (13:18):
Yeah. Yeah.
Speaker 3 (13:18):
Yeah.
Speaker 2 (13:19):
Where it wasn't an, you know, we're really talking about having,
helping to generate code for testing and things. It's also
the year they ship ml.net machine learning.net for, for doing
models that way.
Speaker 5 (13:28):
Right.
Speaker 2 (13:29):
And certainly last but not least, for the build announcements,
one of the ones that I jumped over was Azure Sphere.
Do you remember this? This is when Microsoft starts building
their own flavor of a Linux operating system for IoT.
It's subsequently been phased out now, but for a few
years here, it's like, Microsoft makes their own Linux. I
love that.
Speaker 5 (13:48):
Mm-hmm.
Speaker 2 (13:49):
Later in the year, in October, well, actually it was
announced in June, but completed in October, Microsoft acquires GitHub
for $ 7. 5 billion. And our friend, Nat Friedman, formerly of Xamarin,
now a Microsoft employee, becomes the new CEO of GitHub.
We get Core 2.2 at the end of the year
in December. Yeah.
Speaker 4 (14:05):
A couple other compute stories.
Speaker 2 (14:08):
This is the year that Elon Musk attempts to take
over OpenAI from his partners and gets booted out of it.
And he's still angry about that and purse fights with
Sam Altman on regular basis.
Speaker 1 (14:16):
Yeah, because... That's where he is right now.
Speaker 2 (14:19):
Because reasons, because I realized all the same, the same
year that he flies the biggest rocket in history into
space and puts a sports car into space, which still orbiting,
you know, between the earth and Mars also, you know,
call some guy trying to save children in Thailand, a pedophile, uh,
also tries to hijack the AI company. Yeah. Uh, We're
(14:39):
coming into the period of excitement as we're going through
these next few years in quantum computing. And in 2018,
there was a very important paper published, the NISC paper,
which means Noisy Intermediate Scale Quantum, this paper by John Preskill.
This is the point where companies are starting to build qubits,
build these chandelier dipped in liquid helium style computers that
(15:03):
have about 50 qubits or so forth. And in this paper,
he talks about it's all going to be about error correction.
that we're getting out of the lab. These things are
going to be able to do certain levels of compute,
but without really fault tolerance in this, you're not going
to be able to get much done. And that sets
up Google, who's driving a lot of this stuff with
their quantum toolkit, aimed at researchers for testing what prototype
(15:26):
hardware could do, which is funny because next year they'll
actually produce the second market process. So obviously Google was anticipated.
And that's what I got.
Speaker 4 (15:34):
All right.
Speaker 1 (15:34):
Well, before we bring Don on, let's talk about Better
Know Framework. Roll the music.
Speaker 5 (15:40):
Awesome.
Speaker 3 (15:40):
All right, man.
Speaker 1 (15:44):
What do you got? Guess who's back in Better Know Framework?
Speaker 2 (15:51):
I think I know. He's Australian. It's Simon.
Speaker 4 (15:57):
It's Simon.
Speaker 1 (15:58):
So he belongs to our Appfee Next Slack channel. And
he basically knew that I had done some work into
looking into serializing link queries and passing them from client
to server and pretty much gave up. And there was
(16:18):
a whole smattering of GitHub repos out there of people
who attempted it. And I tried like 50% of them
and they all failed. And so he came up with
this thing called SCRY, S-C-R-Y, or maybe it's SCARY. I
don't know.
Speaker 2 (16:33):
Or Scree.
Speaker 1 (16:34):
Or Scree?
Speaker 4 (16:35):
Yeah.
Speaker 1 (16:35):
He doesn't have a pronunciation legend, but he says it's
a type-safe serializable link from a client to a server
side EF core model. And I had told him, and
both Mateus Carvalho and I had worked on this before,
and Mateus came up with something, and I came up
(16:56):
with something, AVN repository, that basically tells Did the same,
but I used classes and serialized those classes for filtering
and basically all aspects of a SQL query, a link query, right?
A where, an order by, all of that stuff just
turned into data and passed in.
Speaker 2 (17:16):
And it works.
Speaker 1 (17:17):
But as Simon pointed out, it's not as efficient as
what he's doing. Yeah. So this is, and he has a,
there's two links. We're going to give you a link
to the scary or the scry or scree project. And
then there's this doc querying MD composing a query at runtime.
(17:37):
And so he just talks about how to do that,
how to create projections and computer projection members. It's really cool. And,
and it works interesting.
Speaker 2 (17:49):
And so, yeah.
Speaker 1 (17:50):
And, and so, yeah. Um, Simon, you win the prize.
Speaker 2 (17:55):
You're awesome.
Speaker 1 (17:56):
You're the first person I know who has actually done this.
And maybe I just resigned and said, I can't be done.
And maybe it was done, you know, long before that.
Speaker 2 (18:06):
I don't know.
Speaker 4 (18:06):
But that reminds me of link to rest.
Speaker 1 (18:09):
Oh, link to rest. Well, that sounds exactly like what
I was doing.
Speaker 2 (18:13):
Yeah. Yeah.
Speaker 4 (18:14):
Because it was the inverse.
Speaker 3 (18:16):
Right.
Speaker 4 (18:16):
Where you, well, you created from a link query, you
could create a query string.
Speaker 3 (18:23):
Right.
Speaker 1 (18:24):
But you couldn't put it back on the other side
and turn it into a link query, which is, which
is what he's doing. And what I wanted to do
as well, right? Because you've got a form and it's
got a whole bunch of search parameters. And if your
data is local, great link query.
Speaker 4 (18:38):
Well, no, so it did it the other way too.
Speaker 1 (18:41):
If it's behind an API.
Speaker 4 (18:43):
Link to REST, it would, it was an ASP.NET. It
was NBC, ASP.NET. It would, take that query string and
then turn it into a link.
Speaker 1 (18:54):
Oh, okay. Well, that's great. Link to rest, rest to link. Okay. Well,
check out scary or scree or scry or whatever it is.
And ask Simon how to pronounce this thing.
Speaker 2 (19:06):
Cause I don't know.
Speaker 4 (19:07):
I'm sure there's a difference, but yeah.
Speaker 5 (19:09):
Right.
Speaker 4 (19:09):
I just remember link to rest.
Speaker 1 (19:11):
Well, Richard, who's talking to us today?
Speaker 2 (19:14):
Grabbed a comment off show 1994, the one we did
with our friend Brady Gaster, talking about Squad. A lot
of good comments on that show.
Speaker 3 (19:20):
Yeah.
Speaker 2 (19:21):
And this one comes from Paula Pinto, who says, while
interesting as always, the whole Squad enthusiasm was pretty much
focused on single developer workflow. Now not having to depend
on anyone else to do related development tasks. It was
all about their nicknamed agents without any ethical discussion of
what tooling like Squad will have in developer teams. I've
already observed how teams have been downsized. Thank the SaaS
(19:43):
products for placing the need for backend developers, AI tooling
doing the work of team members that used to do
translations or asset creations for CMS platforms. Now we get
tools like Squad reducing even further the amount of humans
in the loop, getting celebrated for what a single developer
could choose while taking into account the repercussions it has
on those that are deemed no longer needed to be
kept around as employees.
Speaker 1 (20:01):
Unless you didn't have a team to begin with.
Speaker 2 (20:03):
In a late capitalism-driven society, if $ 5 can do what...
work of 20 developers thanks to tooling like squad the
remaining 15 are out of the company like an old
detroit they will need to find work that isn't yet taken.
Speaker 1 (20:12):
By ai unless you didn't start with a team yeah
you were always one guy.
Speaker 2 (20:18):
But i also think it's kind of a short-sighted mindset
too because i'm seeing more nobody team's not getting laid
out but just working on the other stuff they hadn't
gotten to like the joke for years was none of
us would get to the bottom of our to-do list
And now we're getting through the feature lists and starting
to get into tech debt. And then other features start
(20:38):
to appear. It's only the shortest-sighted of companies that would
work on one thing and not think, what are the
other things we could do? You've got a group of
people who are now more powerful. Utilize them.
Speaker 1 (20:51):
You take all those people on the team, give them
all a unique task, give them their AI tools. And
set them free. And before you know it, you're through
all of those things.
Speaker 5 (21:00):
Yeah.
Speaker 1 (21:01):
Technical debt's a big one.
Speaker 2 (21:02):
I also think there is a larger conversation about what
the shape of teams looks like with these tools going forward. Right.
We're still in early days.
Speaker 4 (21:10):
I've been running into folks who, in the startup community,
are saying they don't need developers anymore.
Speaker 2 (21:16):
Yeah. That doesn't seem true.
Speaker 4 (21:20):
Somebody I ran into, he just came back from two
weeks of a startup incubator, and he was saying, Of
the 20 or so startups there, none of them had developers.
Speaker 3 (21:31):
Yeah.
Speaker 4 (21:31):
Right.
Speaker 1 (21:32):
That's easy to understand.
Speaker 2 (21:33):
Sure. All right, Paulo. Thank you so much for your comment.
And a copy of Music Code Buy is on its
way to you. And if you'd like a copy of
Music Code Buy, write a comment on the website at. netronics. com
or on the Facebooks. We publish every show there. And
if you comment there and I read it on the show,
we'll send you a copy of Music Code Buy.
Speaker 1 (21:46):
Or you could just go to musictocodebuy.net and get it yourself. MP3, WAV,
and FLAC formats. Go ahead. You know you want it.
All right, let's bring on Don Demsack. Don is a
technology leader dedicated to strengthening the tech ecosystem in Central
Pennsylvania and beyond. His day job is with a major
(22:09):
technology company's infrastructure group where he helps CIOs and CTOs
think like COOs. His nights and weekends go to volunteering
as a board member of the Technology Council of Central
PA and as an active member of Tech Lancaster. You
can find his latest ramblings over on Substack. This is
(22:30):
his fourth trip to. NET Rocks and the first in
almost 20 years.
Speaker 2 (22:33):
It's been too long.
Speaker 1 (22:35):
Dude, I remember your first episode. It was during the
Rory years. So it's episode 62. Rory years were 50
to 100. And he somehow convinced you to come up
to the studio. And you were there in the studio
for us, with us.
Speaker 4 (22:53):
Yep. And you remember.
Speaker 1 (22:55):
Richard Roy used to do the Google weirdos thing.
Speaker 5 (22:57):
Right.
Speaker 1 (22:59):
So just for people who don't remember, he would look,
he had a blog, popular blog, neopolian.com. And it was
hysterical and very, very surreal. And he took it down
because he, he wanted to be taken more seriously as
a developer and everybody just wanted comic relief, but he
was very funny. Anyway, he would look at the logs and,
(23:24):
of what people typed into Google and then landed themselves
on his blog, right? He could tell that it came
from Google and the string is in the log, right?
Speaker 4 (23:36):
The URL.
Speaker 1 (23:38):
And so he would read these and they were just crazy,
what people were looking for. But one of them, and
I remember this specifically, Don, tell Don XML to come
home and take out the garbage.
Speaker 4 (23:52):
You just made my wife's week. That is exactly. Make
sure Carl brings that up.
Speaker 1 (23:59):
Oh, well, how could we not?
Speaker 2 (24:00):
I mean, it's crazy.
Speaker 1 (24:03):
But yeah, you used to be Don XML. And then
I think by your third episode, which was 271, it
was Don Demsack on Link to XML.
Speaker 4 (24:12):
Yeah. And who did the session before Mike? Do you remember?
Speaker 2 (24:16):
Uh, two 70 to 70.
Speaker 1 (24:18):
Let's see. I got the list right here.
Speaker 2 (24:22):
It's funny. It's all online. That's weird.
Speaker 4 (24:23):
Yes, it is. I can tell you.
Speaker 1 (24:25):
No, I got it right here. It was Eric Meyer,
Eric Meyer.
Speaker 2 (24:30):
Oh, why the Eric Meyer on link on link? Yeah.
The guy who helped create it.
Speaker 1 (24:35):
Something he knows a little thing about.
Speaker 3 (24:37):
Yeah.
Speaker 4 (24:37):
Just a little. Um, if you haven't, he, or, uh,
been paying attention to him, uh, He recently has a
video up on YouTube of a presentation.
Speaker 2 (24:49):
AI.
Speaker 4 (24:50):
Engineering, around how AI agents got teeth once we allowed
them to do more than just chat when he gave
them access to tools. And he throws out a whole
theory of how we can lock down AI agents by
(25:11):
making them do... mathematical proofs that the stuff that they're
doing won't negatively impact something. It is an awesome video.
Speaker 1 (25:22):
Yeah, we need more of that. Absolutely.
Speaker 4 (25:25):
100%.
Speaker 1 (25:26):
I saw an article that you wrote on LinkedIn, which
was also on your sub stack. Everything that I've seen
from you has been thought-provoking, but this was about the
new MCP 2.0 and how you can't make a stateful
(25:48):
MCP server anymore if you're using 2.0. And so, yeah,
we talked about that. I talked about that with Rocky
on Code with AI. And Richard found your substack and
found some good stuff that you're thinking of and talking about.
And here you are.
Speaker 4 (26:06):
Yeah, it ties right back to what Eric is talking about.
It was funny because I've been working on this for
a bit. But this whole idea of how do we
govern these agents better?
Speaker 2 (26:23):
Right. Sure.
Speaker 4 (26:23):
Everybody. Now, for the last two years, people have been
really complaining about governance. But the big thing everybody now
is complaining about is tokenomics.
Speaker 1 (26:34):
Tokenomics.
Speaker 4 (26:36):
That's the big thing that everybody is looking because now
there's a cost per token.
Speaker 2 (26:41):
Right.
Speaker 4 (26:41):
Well, those two things are kind of related. about two
years ago, just over two years ago, through my day job,
I got to see a demo of some agentic AI.
And the demo that they created was really thought-provoking because
it didn't just show what the agents were working on,
(27:09):
but it actually, at the bottom of it, showed the
conversations the agents were actually having with each other. And
I was like, wow, that looks like a Teams or
a Slack conversation. But I'd never thought of agentic AI
in that way. We're software developers. We think about APIs,
(27:32):
application programming interfaces. Now there's this whole idea of a
natural language interface.
Speaker 2 (27:38):
Or semi-natural, like The way those tools talk to each
other is not that normal, but I get what you're saying.
It is English of a sort.
Speaker 4 (27:49):
And that, that was the thing that jumped out at
me was it was too generic in a team's chat.
You expect a lot of three letter acronyms and very
specific words. for each of the roles that are there.
Think about chat between a DBA, a front end developer
(28:13):
and a middle and a mid tier developer, all the conversations,
all the acronyms that they wind up using.
Speaker 2 (28:19):
Yeah.
Speaker 4 (28:19):
That was lacking.
Speaker 2 (28:21):
It speaks to a lack of common context between the agents.
Speaker 4 (28:24):
And that's where my head was going was how do I, that,
that seems to be missing. Um, and as you guys know,
and you've got, you guys had a bunch of over
the years, especially recently, domain-driven design type folks. I was like,
there's no ubiquitous language.
Speaker 5 (28:42):
Right.
Speaker 4 (28:43):
What if we made these agents speak the ubiquitous language
of the domain that they're in charge of?
Speaker 2 (28:56):
Right.
Speaker 4 (28:57):
That would be super cool.
Speaker 2 (28:59):
And really what you're doing is bracketing their context, right?
That they need to use the correct language.
Speaker 4 (29:04):
Correct. And by doing that, there's side effects, lots of
good side effects. If you can constrain them or control
their language, I'm calling it a controlled natural language. Um,
then they can only do what they can express.
Speaker 5 (29:21):
Yeah.
Speaker 2 (29:22):
And it's another kind of constraint.
Speaker 4 (29:23):
Think about the open AI hacking of hugging face.
Speaker 5 (29:28):
Right.
Speaker 4 (29:28):
Where it had access via MCP to a tool. figured
out how to do something that wasn't desired by that tool.
But if we had a natural, a constrained or controlled
natural language in front of that, then they wouldn't be
able to ask the things that they shouldn't be able
to do.
Speaker 2 (29:48):
Yeah.
Speaker 4 (29:49):
So that's, and so the term, these are patterns that I,
I'm using for this is instead of bounded context, domain-driven design,
how about bounded agency? So how do we build walls
around what the domain that that particular agent can do,
(30:11):
not via just security, but actually ways to express it?
If they don't have the language to express it, they
can't do it.
Speaker 3 (30:17):
Right.
Speaker 1 (30:18):
So if you're adding another layer... Doesn't, uh, doesn't that
affect your tokenomics?
Speaker 4 (30:23):
That's the other side is now you can actually decrease the, um, the,
the verbiage that's going across. Um, and one of the
major challenges with a natural language as us as humans
is there's a lots of different ways to say the
(30:43):
exact same thing, which leads to ambiguity. Right. And there's, and,
By constraining it or controlling that language, you actually reduce
the actual word count, which you're going to reduce the tokens.
But then you're also decreasing your ambiguity, too, because you
can only say it a certain way.
Speaker 1 (31:05):
Well, aren't you using tokens for that intermediate layer that
does the translation?
Speaker 4 (31:11):
So originally, that's where I was thinking. But then I
take it one step further.
Speaker 5 (31:17):
If I.
Speaker 4 (31:18):
can control the language, and so I can control the syntax.
And this goes back to stuff that you guys know
me from, XML. What did I do with XML? I
created domain-specific languages. What did you do with JSON? Create
domain-specific languages. What do we do with Fluent APIs and LINQ?
We created the Fluent APIs and other languages within code. Well,
(31:44):
with all the stuff that's been going on with chat
GPT and natural language processing and stuff that we were
doing with, with link back in the day. What if
I could put a intent compiler in front of the
(32:05):
tool that then parses that text because it's a constrained
natural language. And instead of feeding everything to the model,
what if I if I knew what words mapped to
specific functions, I could actually call those functions instead of
(32:28):
having to pass it through to the agent who would
eventually pass it through to an MCP server somewhere to
actually call the tool. So now I've actually reduced, dramatically
reduced how much is actually going to the models because
I'm pulling some pieces of that.
Speaker 1 (32:46):
From this static glossary kind of thing. But, And I
imagine that the best of both worlds would be if
the word doesn't exist in the glossary and it can't
express it in a more concise way, then it would
go out and get definitions for those words and add
them to the domain.
Speaker 4 (33:02):
So you, you, you really want to control that language
so that you're controlling what it can do.
Speaker 1 (33:08):
Right.
Speaker 4 (33:09):
So you would prefer, uh, to keep to, uh, to
programmatically add the new languages. Don't let it do it
on its own.
Speaker 1 (33:20):
Well, at least it could make you a list.
Speaker 4 (33:22):
A list of it.
Speaker 1 (33:24):
Yeah, a list of things that it didn't understand or whatever.
Speaker 4 (33:26):
Correct. And you can publish that language. And that's one
of the things that models are great at, converting from
one language to another language.
Speaker 2 (33:37):
Right.
Speaker 4 (33:38):
So if you have a way to declare that controlled
natural language, it can convert it automatically.
Speaker 1 (33:44):
Yeah, that's right. I could see repos for all sorts
of vertical industries, uh, DSLs in used in that way to,
to rein in your LLMs and your tokenomics.
Speaker 4 (33:58):
I make it a heck of a lot easier for that.
And so, um, so I actually built, uh, uh, uh,
I built a couple of different things based on that,
but I actually have a, uh, MVP that you can
go pull down from GitHub. It's called Limelight X. Well,
Rush is out this year, right?
Speaker 2 (34:19):
Doing the tour.
Speaker 4 (34:20):
So Rush fan had to pull that in. So Limelight X.
And so you go there, you can actually go see
how to do this. So you can give it the
natural language, the constrained natural language. give it a text
(34:44):
and it will actually give you the intermediate steps so
you can visualize it. So how do you parse that
apart to an AST? How do you take that AST
and optimize it? Then you take that AST and turn
it into intermediate result, which then gets put into an
expression tree a la link. How do you do that?
(35:08):
Because what I've found is, Most people doing AI engineering,
AI agents, they don't come from our comp sci background. Right.
They come from the dynamic language.
Speaker 2 (35:26):
Side of the house.
Speaker 4 (35:27):
They're Python and JavaScript type script. So parsing and compiler
theory type stuff is not something that sits in their domain.
While you can do some of that stuff with those languages,
you don't typically do it. So they're not thinking that way.
So how do I get best of both worlds? That's
(35:49):
part of the challenge.
Speaker 1 (35:51):
Before we go any further, I think we should take
a little break. You think so, Richard?
Speaker 2 (35:55):
Sure, let's do it.
Speaker 1 (35:55):
All right, we'll be right back after these very important messages. Hey,
Carl here. You probably know text control is a powerful
library for document editing and PDF generation. But did you
know they're also a strong supporter of the developer community?
It's part of their mission to build and support a
strong developer community by being present, listening to users, and
(36:19):
sharing knowledge at conferences across Europe and the United States.
So if you're heading to a conference soon, check if
Text Control will be there and stop by to say hi.
You can find their full conference calendar at www.textcontrol.com. And
make sure you thank them for supporting. NET Rocks.
Speaker 2 (36:42):
And we're back. It's.
Speaker 3 (36:43):
NET Rocks.
Speaker 2 (36:43):
I'm Richard Campbell. That's Carl Franklin.
Speaker 4 (36:45):
Hey.
Speaker 2 (36:45):
Talking to our friend Don Demsack a bit about, well,
you just brought up Limelight X as a way to
sort of create a natural language-like set of instructions, which,
I mean, in some ways reminds me of the way
we write specs anyway. Software development is somewhat language. I mean,
you have the programming language is a constraint. But if
you also notice, the average product manager speaks in a
(37:10):
somewhat constrained language. They're trying to communicate with developers, and
developers speak a weird form of English.
Speaker 1 (37:18):
Dilbert proved that.
Speaker 2 (37:20):
They're really trying to just be very clear on what
the intent is, and I think it serves the LLMs
pretty well to stick with that same kind of language barrier.
Speaker 1 (37:29):
100%.
Speaker 4 (37:30):
And then domain-driven design never took off.
Speaker 2 (37:35):
Yeah.
Speaker 4 (37:36):
We all know it works, but one of the side
effects of implementing it is you needed to have a
subject matter expert who can pull that the main logic
out of that, those communications that was very specialized.
Speaker 2 (37:52):
Yeah.
Speaker 4 (37:53):
Well, nowadays with coding assistance and the spec driven development world,
we are starting to put that context into text documents
that obviously we could use models to start pulling out
that domain-specific language from the specifications.
Speaker 1 (38:15):
I would even go one step further and say we're
heading towards, if we're not there already, just not thinking
of it, conversation-based development. In this last episode that I
did with Rocky Latka, he talked about how he and
three other guys sat down to design a system He
whipped out his Android phone, started recording. It made a transcript.
(38:36):
He uploaded that transcript to Claude and said, build me
a spec based on this conversation. Whoa. I mean, talk
about layers, right?
Speaker 2 (38:46):
Using the tool as the preprocessor.
Speaker 1 (38:49):
Yeah.
Speaker 4 (38:50):
It's an interesting space that we're in because that's been
the art of being a developer is has been really
taking these vague requirements and then converting it into code.
What was my favorite, what's the number one thing whenever
(39:10):
I would build something, the business person would typically turn
around and say, I know that's what I asked for,
but that's not what I wanted.
Speaker 2 (39:18):
Yeah, right.
Speaker 4 (39:20):
Because humans are really, really, really bad at giving requirements. Weird.
Speaker 2 (39:24):
Yeah. And in some ways, like you want the domain
expert because they know the space, but they often skip over.
essential parts because they're so knowledgeable in the space. They
don't even realize what they know.
Speaker 4 (39:35):
Yeah.
Speaker 2 (39:35):
Yeah.
Speaker 4 (39:35):
And that's, I mean, because Rocky's been around, he knows
what he needs to put into that. And so how
do you teach that to these new wave of, uh,
coding engineers that are using coding assistants to do that. Well,
(39:57):
we could teach them better requirement skills. And that's one
of the things I started doing a couple of years
ago in prompt engineering was a big rage two years ago.
And now it's context engineering. But when I explain it
to the average person, what a prompt is, I tell
them it's a requirement. Think of it as giving it
(40:21):
a requirement to another human.
Speaker 5 (40:22):
Right.
Speaker 4 (40:22):
Got to put in all that extra context. And then
because of my agile background, I like to use given
when then, so that as measured by. And then I
would teach people to write their prompts in that structured
form and they get better results out of the engine
because you're giving it all the context that you would need.
Speaker 1 (40:45):
Yeah. That's brilliant.
Speaker 4 (40:47):
And so that's, And so that's the same problem that
I'm running into with the spec-driven development is while they
have great structure for the documents, how do you build
the tests? Right. What you really kind of need to
be able to do is create, given when then type scenarios,
(41:11):
do more behavior-driven development. So testing for behavior that's expected
or not expected. rather than writing generic tests.
Speaker 2 (41:20):
You're right. Domain-driven development is great at defining what we'd
like it to do, but behavior-driven development is much better
at defining what it actually does and if that's what
we really wanted to do.
Speaker 4 (41:32):
And then if you could take that, those behavior-driven tests,
now you can also use that to drive the controlled
natural language because you're expressing the behaviors that you're looking for.
Speaker 2 (41:47):
And so.
Speaker 4 (41:48):
Besides Limelight X, I have a project called VectorRen, V-E-C-T-O-R,
my SVG days, Ren, R-E-N, so two R's. And it
was built with that in mind to show developers how
to build an SVG game, a web-based with JavaScript, with
(42:12):
generic JavaScript, no framework. And so what was the, you
guys remember, what the big game was when we were
trying to do demo SVG back in the day, it
was asteroids. Right.
Speaker 1 (42:24):
Oh yeah. So that's right.
Speaker 4 (42:25):
There is in half an hour using this methodology, I
describe what the game should do and given one then,
and it generated a simple implementation of asteroids. And you
can go to vector ren.org or go to vector ren, uh,
the GitHub page, uh, out there and you can pull
(42:47):
it down. And it's a very simple way to learn
JavaScript from this point of view, without any of the frameworks,
something simple that, that, that people can actually leverage, uh,
because we have this generation of developers who don't have
the traditional comp side background.
Speaker 2 (43:05):
Right.
Speaker 5 (43:05):
Yeah.
Speaker 2 (43:06):
I'm just thinking about, we're revising this. We've been playing
with what the software development life cycle with these tools
is supposed to look like. And, and I'll, I think
there's a lot more energy put into the context up
front just because the tools will generate lots and lots
of code. It's just most of it is not that
good if you haven't really done a good job of
(43:27):
setting up these constraints.
Speaker 4 (43:30):
I've been doing a lot of stuff with AI here
in Central Pennsylvania. One of the interesting feedback I'm getting
from non-traditional developers is we don't care.
Speaker 2 (43:42):
Yeah.
Speaker 4 (43:44):
It gets the job done, and that's all.
Speaker 5 (43:45):
I care about.
Speaker 2 (43:46):
You're going to care.
Speaker 4 (43:50):
I hit up one of the folks I was talking about.
I was talking about, hey, you're just creating dynamic scripts.
This feels a lot like what JavaScript felt like before jQuery,
before we got V8, before we got TypeScript. We're sending around.
Speaker 2 (44:10):
Yeah, before we put constraints around for reliability.
Speaker 4 (44:14):
And consistency. So, and I was like, you know, from
a tokenomics point of view, every time you send that text,
you're getting charged for it. Yeah. And so there's a
cost because I don't care. It's cheaper for me to
do that than to spend the time to actually write
(44:35):
the compiled code.
Speaker 2 (44:36):
For now, anyway, the costs are going up. But often
the folks don't care because they don't know the consequences.
Speaker 4 (44:42):
They don't know good engineering principles.
Speaker 2 (44:44):
Yeah, they don't know how the software will bite them later.
It's generally what works right now.
Speaker 4 (44:48):
And what I'm seeing is a lot of the vibe
coders realizing that they can only go so far of
vibe coding, and then they start going to coding assistants,
but then they don't know how to create these good
engineering principles. And so I think there's a big market
for that.
Speaker 2 (45:04):
So the AKA they're starting to care.
Speaker 4 (45:07):
And it makes me sad because as a VB guy,
old school VB guy, isn't that what the C plus
plus people complained about us about?
Speaker 2 (45:17):
Yep.
Speaker 4 (45:17):
Yeah, we weren't real developers.
Speaker 2 (45:19):
Well, Yeah, and again, the argument was, is the software
quality sufficient? And let's face it, we built a lot
of bad quality software, and then we learned, hey, software
quality matters. And you could do it with VB, you
just had to follow some good practices.
Speaker 1 (45:32):
I think a lot of that nose turning down at
VB developers was a byproduct of what happened between C
developers and basic developers in the very early days of programming.
Basic with go-tos was looked at as horrible. I was
(45:52):
using Visual Basic and then attending a community college and
the computer science lady, I told her that I was
using Visual Basic. She goes, oh, basic. Oh, you can't
say basic.
Speaker 4 (46:04):
No go-tos, no go-tos.
Speaker 1 (46:05):
I'm like, no, it's completely changed now. You know, it's
come into its own and they still just, you know,
you get an idea in your mind and it's hard
to shake.
Speaker 4 (46:15):
And I don't want to be that Get off my
lawn guy. Yeah, right. And I don't want to be
that old guy.
Speaker 1 (46:21):
Nobody does.
Speaker 4 (46:22):
I've got the gray hair, fine. But I don't want
to be that guy. Same thing with coding assistants. What
I've been talking about to a lot of folks is
coding assistants is the new IDE. I remember back when
we were talking, you know, Vim was it. You didn't
(46:43):
use Studio.
Speaker 3 (46:44):
Right.
Speaker 4 (46:44):
IntelliSense. Coding is novel. You had to know it and
remember it in your head and use a text editor.
Real developers use text editors.
Speaker 1 (46:54):
I think it took Don Box a long time to
come to grips with the fact that people are going
to use IDEs, not them.
Speaker 4 (47:01):
It would be interesting to get his opinion on coding.
Speaker 2 (47:03):
You see those positions all over the place. I think
you're making a mistake as soon as you're bound to
a tool. In the end, the goal was to deliver
value to customers.
Speaker 4 (47:15):
And then there's this whole, and this ties into Run
As Radio, then there's this whole angle from the IT
admin side of the house where IT admins were doing automation,
but they were doing it via a GUI tool because
IT admins didn't write code.
Speaker 3 (47:35):
Right.
Speaker 4 (47:35):
That was for the developer world.
Speaker 1 (47:37):
Right.
Speaker 4 (47:38):
In my day job, what I'm starting to see is
more and more IT admins admins leveraging coding assistance to
actually create better code than they could ever written because
all they ever wrote scripts. This is much better code
and it's making their lives a heck of a lot easier.
So that's just, I mean, that's an unintended consequence, but
(48:02):
it's helping, especially in these days when so many companies,
so many on-prem companies who are using VMware and now
they're kind of A little bit of a backlash. They're
all trying to move off, and now they're more open
to how do I do this automation rather than using
a tool.
Speaker 1 (48:20):
One quick correction. I think I misspoke. When I was
in a community college, it wasn't VB. It was Quick Basic.
Quick Basic. Quick Basic was compiled, and it was structured,
and it was great back then. And this computer science
person was like, no go-tos.
Speaker 5 (48:37):
Don't say it.
Speaker 2 (48:39):
Well, and it's the thing, there's nothing wrong with the language.
It just had a construct that was a problem. Hey,
remember option explicit? Like we did learn.
Speaker 3 (48:46):
Sure.
Speaker 1 (48:48):
On error, resume next.
Speaker 2 (48:50):
Yeah.
Speaker 1 (48:53):
I don't have any bugs.
Speaker 2 (48:55):
What?
Speaker 5 (48:55):
Yeah.
Speaker 4 (48:56):
So one of the things that I've been starting to
work with is how do I start creating skills to
be able to help teach these non-developers these good habits?
So like one of the things, That's in a beta
right now is a requirements interrogator skill. So help the
average person create that given when then brief so that
(49:20):
they get better requirements when they're trying to build something.
Speaker 2 (49:24):
Yeah, you have to wonder if we're not going to
end up with more opinionated agents that are like, I
can't start building this until I have these broader requirements
settled around those kinds of constraints that are going to
matter for security and architecture and reliability and scalability. all
of the abilities that everyone doesn't care about until they
care about them.
Speaker 3 (49:43):
Yeah.
Speaker 4 (49:44):
One of them I'm playing with right now is, is
creating a skill to create architectural decision records.
Speaker 5 (49:50):
Right.
Speaker 4 (49:50):
We've never, I mean, we all always wanted to have them,
but now if I'm using a coding assistant, that helps
make my coding system better. It tells the architecture and
the reasons why we picked certain things.
Speaker 2 (50:05):
Yeah.
Speaker 3 (50:07):
Yeah.
Speaker 2 (50:07):
There's lots to all of that. I mean, again, I
feel like we're just groping around right now trying to
figure out.
Speaker 4 (50:13):
It's early days.
Speaker 2 (50:15):
What are the, yeah, the tools are shifting. Just remember,
we were trying to develop on. NET in the early
days where every time they got a build out, the
editor changed, the framework had changed, and the language had changed.
Everything you're doing, incorrect. Yeah.
Speaker 4 (50:32):
I was part of that early days. I don't even
remember if I ever mentioned it to you guys, but
the framework The client that I had back in 99, 2000,
their president was on the board for Microsoft, and I
was building dashboards for him, and I got introduced to
(50:54):
Project Cool.
Speaker 2 (50:55):
Before it was announced. Before it became C Sharp?
Speaker 4 (50:57):
Yeah, before 2000, the announcement at PDC 2000.
Speaker 3 (50:59):
Yeah.
Speaker 2 (51:04):
I think it was actually TechEd, but yeah.
Speaker 5 (51:06):
TechEd.
Speaker 4 (51:06):
Yeah, it was TechEd. That's where I'm at.
Speaker 2 (51:08):
But yeah, but I'm also thinking about the craziness that was.
NET Core in, you know, 2018 or 2016. Because it
took them 18 months to get that first version built
and there were so many previews. And every time you
got a preview, everything shuffled on you. And it just
seems an awful lot like trying to work with Anthropica
or OpenAI or any of these tools right now, where
(51:30):
every time you get A new build, new harness, like
there's so many different components that presuming it works the
same way is crazy. It changes. It changes a lot.
Speaker 1 (51:40):
And just like with. NET Core, Richard, I think that
there's still a lot of people not dipping their toes
into AI developer-wise for the very same reason.
Speaker 4 (51:52):
So have you guys had anybody on for Microsoft Foundry Local?
Not yet.
Speaker 2 (51:57):
Not yet. No, it's on my radar.
Speaker 4 (51:59):
I've been intimate with that. So that's part of what
the bounded context. Part of what I realized is to
use these smaller models, you had to be very prescriptive
in the prompts that you were giving.
Speaker 2 (52:13):
Right, right.
Speaker 4 (52:14):
And when I started writing the code, I didn't want
to put that code as text into my program. I
wanted to pull it out. And so I created a
YAML language that did essentially prompt as a function so
that you could import it in and create it. And
there's a couple different prompt as a function frameworks out there.
(52:39):
BAML is one and DPSY, another where it makes it
easy to put prompts into your programming languages. The Dipsy
is Python only. BAML is TypeScript and Python. And so
(53:02):
I built a framework to be able to do that
because I was trying to run local models. I was
running local models on what I'm using now, Copilot Plus PC.
The Copilot Plus PCs were supposed to be the place
to be able to run these models. It's just not.
Not as good as it could have been.
Speaker 2 (53:21):
At 40 tops, that's not a lot. Meantime, I'm looking
at my RTX 5080 at 1,500 tops and saying, why
aren't I a co-pilot PC?
Speaker 4 (53:32):
So I am super excited for the new RTX Spark laptops.
I'll be the first to go buy one of them
when they come out.
Speaker 2 (53:40):
They're actually going to be a laptop, because right now
it's a NUC.
Speaker 4 (53:44):
Well, the big difference is the DGX Spark, Right. That's
the one you're thinking is the RTX Spark. Two separate things.
The DGX is Linux.
Speaker 3 (53:55):
Right.
Speaker 4 (53:55):
The RTX laptop, which is, that was, it was a nook.
The RTX is a laptop. It is going to run
Windows on ARM.
Speaker 2 (54:05):
Right.
Speaker 4 (54:05):
So it's, you could think of it as the Uber
Co-Pilot Plus piece.
Speaker 2 (54:09):
Possibly, yeah. It'll be interesting. It's one of the things
I've seen over and over again with the DGX Spark,
but folks are actually using it is, You end up
running NVIDIA's models because they're so much better optimized for
their hardware that you just get vastly better responses or results.
So it's not a universal anything. Where is our ODBC
(54:34):
so that you really have some equanimity across all of
these different products? and can really see what all the
different hardware solutions can be there. I hate that we're
building dedicated to hardware solutions, but I get it.
Speaker 4 (54:45):
Part of why I created that prompt as a function
to make it portable, to describe what's the model, what's the,
am I using VLR? Am I using Foundry Local? What's
the model? So I can abstract that away so you
don't have to worry about it and be able to
switch it in and out. And so I've got a
(55:06):
framework for that and I'm, I hit my limit with
the Copilot Plus PC and I'm waiting for these new
ones to come out. But that's a whole different conversation
because there's so many people, so many clients and customers
I talk to that can't use public models.
Speaker 5 (55:22):
Right, right.
Speaker 2 (55:23):
There's whole classes of work that are just not an
option to be going, leaving your machine in any way.
Combined with tokens are only getting more expensive and all
you can eat is disappearing and The methodologies we've been
using with the sort of adversarial agent model are just
mo tokens.
Speaker 4 (55:40):
And smaller models hallucinate less. Right.
Speaker 2 (55:45):
They are more bound.
Speaker 4 (55:47):
And then you bound it by a language, a constrained language,
a controlled language, and you can reduce it even worse.
That's kind of where I'm going with this. Still early days.
I do a lot of Foundry local type stuff, running
to issues, report bugs. There's a whole Viber community. Folks
(56:09):
who are interested in getting into dipping their toe in
how do I inject AI LLMs, highly recommend checking it out.
It's an easy install. And there's a command line tool
that you can use just to get started to have
a chat. Have some fun. And then they've got some
great SDKs, whatever language you want to use from.
Speaker 2 (56:29):
NET to Rust.
Speaker 1 (56:30):
It's out there.
Speaker 4 (56:31):
I highly recommend it.
Speaker 1 (56:32):
This is good stuff, Don.
Speaker 5 (56:34):
Excellent.
Speaker 2 (56:35):
And it got me thinking.
Speaker 1 (56:36):
Yeah, definitely got us thinking. Where can we find you
online besides your Substack?
Speaker 4 (56:42):
My Substack and LinkedIn. I do both. LinkedIn, it's marketing
hell right now. People are all complaining. Um, it's not
where the developers are. Right. And Substack, I tried Reddit.
I tried, uh, various Discord servers. Um, my local Lancaster
(57:06):
folks have a great Slack team. So I'm there, Tech Lancaster.
Those folks are awesome. But Substack feels like the blogging
from the old days. It's, it's, it's a good community there.
Speaker 1 (57:18):
So in the Lancaster area, do you find that there
are many Amish developers there?
Speaker 4 (57:23):
There are some that you'd be surprised.
Speaker 3 (57:26):
Wow.
Speaker 4 (57:26):
You'd be surprised. And I wrote up a whole article on,
because I'm new to the area, Lancaster feels to me
like Portland, Oregon 20 years ago. They like that weird,
let's be weird attitude.
Speaker 2 (57:42):
Right.
Speaker 4 (57:43):
They like the back to nature, had the farming, all
that sort of stuff.
Speaker 2 (57:48):
Yeah.
Speaker 3 (57:48):
But.
Speaker 4 (57:49):
They also like the tech side and there's two massive
data centers coming in. Coral Reeve is the big AI
company is putting a big data center and Google's putting
a big data center in there. So there's a lot
of innovation going on in that Amish community. It's an
interesting time.
Speaker 1 (58:08):
Yeah.
Speaker 4 (58:09):
Most people don't think of it that way, but land
is a heck of a lot cheaper. They can't build
any more data centers in, um, Northern Virginia. So they're
moving north into central PA and south into Richmond.
Speaker 5 (58:21):
Okay.
Speaker 1 (58:23):
Well, you have to keep us apprised. And when you
trade your first AI training for a shoe fly pie,
let me know. All right, Don, thanks very much.
Speaker 2 (58:38):
Good to catch up with you again.
Speaker 4 (58:39):
Good to catch up. And let's not make it in
another 20 years.
Speaker 1 (58:42):
Definitely. And we'll talk to you, dear listener, next time on.
NET Rocks.
Speaker 5 (59:08):
NET Rocks is brought to you by Frankenstein.
Speaker 3 (59:10):
Net and produced by Plop Studios, a full-service audio, video,
and post-production facility located physically.
Speaker 5 (59:17):
In New London, Connecticut, and, of course, in the cloud.
Online at pwop.com.
Speaker 3 (59:24):
Visit our website at dotnetrocks.com for RSS feeds, downloads, mobile apps, comments,
and access to the full archives going back to show
number one, recorded in September 2002. And make sure you
check out our sponsors. They keep us in business. Now
go write some code.
Speaker 1 (59:44):
See you next time.
How'd you like to listen to. NET Rocks with no ads? Easy.
Become a patron. For just $ 5 a month, you get
access to a private RSS feed where all the shows
have no ads. $ 20 a month will get you that
and a special. NET Rocks patron mug. Sign up now
at patreon.dotnetrocks.com. Hey, and welcome back to. NET Rocks. I'm
(00:36):
Carl Franklin.
Speaker 2 (00:37):
And I'm Richard Kaplan.
Speaker 1 (00:38):
Our friend Don XML, I mean, Don Demsack is here.
Speaker 3 (00:41):
Oh, jeez.
Speaker 1 (00:42):
Or is he Don Jason? Are you Don Jason now?
Speaker 4 (00:45):
That's my brother.
Speaker 2 (00:48):
At least he didn't say Don Yammel. God knows. No.
Speaker 5 (00:51):
No.
Speaker 1 (00:53):
This is going to be a good one. This is
episode 2018. And as we always do at the top
of the show, let's talk about things that happened that year.
I get all the depressing ones and Richard gets all
the happy ones in space and tech.
Speaker 2 (01:09):
Just have to pick carefully.
Speaker 1 (01:11):
Yeah, I guess so. But, you know, these are important events, right?
Speaker 2 (01:15):
Are they?
Speaker 1 (01:16):
School shootings.
Speaker 2 (01:17):
Are they?
Speaker 1 (01:18):
Robert Mueller's Russia investigation.
Speaker 2 (01:20):
Oh, yeah.
Speaker 5 (01:21):
Well.
Speaker 1 (01:21):
Brett Kavanaugh, Supreme Court confirmation battle.
Speaker 4 (01:25):
Yeah.
Speaker 1 (01:25):
The 2018 midterm elections when the Democrats took over. The
Democrats strike back. Did they?
Speaker 5 (01:32):
Okay.
Speaker 1 (01:33):
Well, okay.
Speaker 2 (01:33):
I don't know.
Speaker 1 (01:37):
Trump and Kim Jong-un, still crazy after all these years.
Speaker 4 (01:41):
Nice.
Speaker 1 (01:42):
Still friends.
Speaker 2 (01:42):
I think that was one of the first meetings, wasn't it?
Speaker 4 (01:45):
Yeah, yeah.
Speaker 1 (01:46):
June 12th in Singapore. Jamal Khashoggi, as Trump said, these
things happen. He was killed and dissolved in a bathtub
of acid.
Speaker 2 (02:01):
Or something.
Speaker 5 (02:01):
Okay. Okay.
Speaker 1 (02:02):
Or something. That's what we think. California wildfires happens every year,
but 2018 was particularly bad. The Me Too movement and
the Larry Nassar scandal. And just to put a little
fine point on it, hurricanes Florence and Michael.
Speaker 3 (02:18):
Right.
Speaker 2 (02:18):
Those are good ones.
Speaker 1 (02:19):
Catastrophic flooding in the Carolinas.
Speaker 2 (02:21):
Yeah.
Speaker 1 (02:21):
And the Florida panhandle. All right, Richard. That's enough.
Speaker 2 (02:24):
Well, it was also, remember that cave rescue in Thailand? Oh, yeah.
Those students went in and there was the flash flood.
That's when that happened.
Speaker 1 (02:32):
That was a good story.
Speaker 5 (02:33):
It was.
Speaker 2 (02:33):
I mean, one of the rescuers lost their lives trying
to save those kids. Right. But they were successful. Do
you remember when, I think that's when Elon started going crazy. Yeah.
Remember he really wanted to be involved in that. It's like,
you're not actually qualified. I'll build a submersible. It's like, A,
you don't know how to build a submersible. And B,
that's not going to work in a cave either. And
(02:53):
then he got really snarky and started calling people pedophiles
and things. Yeah. I don't know. It was one of
those moments because this is the same year that the
Falcon Heavy flies for the first time and Elon put
his red Tesla Roadster on top of it as the payload,
which was pretty cool.
Speaker 1 (03:11):
I thought that was the cool Elon doing that.
Speaker 2 (03:13):
Yeah. But it's interesting to think that's the same year
he goes nuts on this cave rescue thing so i
mean things are just getting.
Speaker 1 (03:22):
Weirder and weirder yeah weirdness weirdness abides um also i
want to mention aretha franklin and anthony bourdain died in
2018 yeah very sad also paul allen very sad about
have you there's a new movie like a documentary about anthony.
Speaker 2 (03:39):
There's an anthony bourdain movie coming out imminently yeah so
it hasn't come out yet I think it's just out
brand new. Okay.
Speaker 1 (03:44):
Yeah. I want to see that.
Speaker 5 (03:45):
Yeah.
Speaker 1 (03:45):
Also George H.W. Bush and John McCain died. Yeah.
Speaker 2 (03:49):
All right, Richard, save us from this misery. So I
mentioned the Falcon heavy flight, which, yeah, that was pretty cool.
We ended up doing a geek out about it. I mean,
it was just an extraordinary rocket strapping three side by side.
Originally he had planned on doing something called asparagus staging,
where he was actually going to feed the fuel from
the wing of boosters into the center so that when
the outer boosters were empty and separated, the center booster
(04:12):
would be completely full. Never happened. Instead, they do it
the simpler way, which is simply to throttle down the
center booster so it doesn't burn as much fuel. That
being said, Falcon Heavy, you'd be never real happy with
it The simple reason that it has a lot of power,
but it doesn't have a lot of payload space. And
so there's relatively few cases where it's needed. And he
was already talking about what we now know is Starship, uh,
(04:35):
and starting to do prototypes around all of that. Uh,
we have a lot of cool, uh, satellites up in 2018,
starting with tests, the transiting exoplanet survey satellite. So this
was the only, the third of the dedicated finding exoplanet
satellites that the, the successor of Kepler. Kepler had launched
back in 2009 and found 2,600 exoplanets. That was Kepler's
(04:59):
mission was to do deep surveys to see how common
are planets. And the answer is very common. Most stars
have planets. TESS as a survey satellite is not designed
to observe as closely, but to cover much larger tracks
of the sky. And fast forwarding eight years now, it's
found over 8,000 potential objects that generally need additional surveying.
(05:24):
because it is a survey spacecraft. But of those 8,000,
almost 1,000 have not been confirmed as exoplanets. So if
you're keeping count, we're up around 6,300 confirmed exoplanets so
far from all of our different collection methodologies. This is
not how Star Trek was supposed to work. Remember in
(05:44):
Star Trek, you had to fly to the solar system
to see the planets? No, we're going to have a
map of all of them long before we can get
to any of them. There's a couple of asteroid missions.
Hayabusa 2 in June got to Rigu. And in December,
OSIRIS-REx gets to Bennu, which is cool. We start to
explore asteroids sort of on a regular basis. In August,
(06:06):
the Parker Solar Probe, the first time we've ever tried
to fly a satellite to the sun. to actually do
measurements of its outer atmosphere. That's a very difficult thing
to do. You have to go really, really fast to
do that.
Speaker 1 (06:18):
Remember Richard Pryor's bit, the first man to walk on
the sun?
Speaker 4 (06:21):
Ooh, ah, ah, ooh, how?
Speaker 2 (06:26):
So to make the solar probe go fast enough to
get that close to the sun, they launched on a
Delta IV, which is one of the highest performance rockets
ever made. It's largely obsolete now and retired and broke
a bunch of speed records to try and get it
down there. It'll take a while to actually get close
enough and actually start to do sampling of the sun.
Also in August was when on the International Space Station,
Soyuz MS-09, this is the vehicle that they transport astronauts
(06:50):
to and from the space station, which at that time,
because the shuttle is no longer flying and Crew Dragon
doesn't exist yet, it's still in development, was the only
way to get to the station. They find a two
millimeter hole in the orbital module of the Soyuz. And
there was a lot of controversy about whether it was
drilled because it was sort of a perfect hole or
was it just that right hole? you know, penetrator that
(07:12):
it went through there. Anyway, fixed with a piece of
cape on tape.
Speaker 1 (07:16):
Could have been mice.
Speaker 2 (07:17):
You know, and because it was the Orbridge module, it
doesn't have to survive re-entry, so it's not that big
of a deal. But yeah, it kicked up a lot
of speculation. And if that wasn't enough, the very next
Soyuz in October, this is Soyuz MS-10, it was only
carrying two passengers. Normally, the Soyuz can carry three, but
occasionally fly with less. In this case, it had Alexei Ovichin, And, uh,
(07:39):
from Roscosmos and Nick Hague from NASA, they were going
to be part of the exhibition 57 to the international
space station. But two minutes after launch, there was a failure.
And Soyuz is one of the most reliable, most flown
spacecraft of all time.
Speaker 1 (07:53):
Yeah.
Speaker 2 (07:53):
This was one of the very rare failures and it
was a failure that had never occurred before. There was
something wrong in the sensor of one of the strap-on boosters.
There are four strap-on boosters that famously separate from a
Soyuz and do what they call the Korolev cross. As
they come flying off. And it didn't happen this time.
And the one booster hung up. And then when it
did break away, it struck the central booster core. And
(08:17):
that ended the going into space. As Nick Hague said,
as soon as the bouncing around started, I guess we're
not going to the space station. But at this point,
they're already 50 kilometers up. And that's too high for
the escape tower. So it's already been ejected. But there is...
Mode 2, Ascent Abort, a system that had been tested
(08:38):
but never used. And this was the first and only
time it's ever been used.
Speaker 1 (08:43):
So they basically turned it around and re-entered?
Speaker 2 (08:45):
It's more complicated than that because you've got an exploding
rocket behind you, so you don't want to be near that.
So instead of abort motors fire and push the Soyuz
assembly away from the booster, and then you have to
get into... descent mode because you're carrying the propulsion module
as well as descent module and the orbital module so
those each have to be pushed off and then it
(09:05):
has to switch over to descent mode get the heat
shield pointed down and actually land because of the angle
of ascent they only get to about 90 kilometers so
they spend some time in free fall still going up
the explosion happened.
Speaker 1 (09:16):
At 50 dude you should make movies This is great.
Speaker 2 (09:20):
It's crazy.
Speaker 1 (09:21):
It's like I'm on the edge of my seat.
Speaker 2 (09:22):
And they're in free fall, and now they have to reorient,
and they do a ballistic return, which means those poor
guys pulled about seven Gs as they came back down.
Worked perfectly. Both astronauts walked away. The crazy part is
realizing from launch at Balkanur to on the ground about
200 kilometers downrange in Kazakhstan, 19 minutes.
Speaker 4 (09:44):
Oh, my God.
Speaker 1 (09:45):
Goodness.
Speaker 2 (09:46):
It was fast and it's all automated. Like basically they
were having trouble keeping up with the control systems working
through it.
Speaker 1 (09:53):
That's definitely not enough time for a feature film.
Speaker 2 (09:55):
No, it's pretty quick, but I'm sure there's a bit
of story to go around it. Anyway, it worked flawlessly.
and they would eventually get to space on a different
spacecraft because that one weren't no good no more. In November,
we have the 20th anniversary of the International Space Station
because the Zarya module went up in 1998. We're also
fully over into commercial resupply now. So Roscoff's mostly due
(10:18):
to five deliveries in 2018. But SpaceX does three on
Cargo Dragon. Orbital ATK does three with Cygnus. And JAXA
has one HTV delivery. So a total of, what is that, 12.
And also in November, the InSight lander lands on Mars.
First thing to have landed on Mars since Perseverance. And
it's doing measurements of Mars quakes and interior mapping of Mars.
(10:41):
by looking at reverberations that travel through the planet. And finally,
in December, China launches the Chang'e 4 relay satellite in
preparation for their landing, putting a lander and rover down
on the far side of the moon. They need a
satellite to be able to communicate with the far side
of the moon. So that goes up in 2018. The
big mission will be in 2019. Ready for compute stories?
Speaker 1 (11:02):
Yes.
Speaker 2 (11:03):
And you always think I have to give you all
the good news. So let's start off in January with
Meltdown Inspector. Okay.
Speaker 1 (11:10):
Okay.
Speaker 2 (11:10):
So these were discovered potential exploits using a speculative execution
that exists in both AMD and Intel processors. And there
was no security around that. So the theory was that
if you did stuff exactly right, you might be able
to grab data from another virtual machine that was running through.
(11:31):
This exploit has never been found in the wild. Even
attempts to try and utilize it have been largely futile.
But at the time, they really freaked out. And putting
security rules in place caused substantial performance penalties. I think
to talk about literally 20% of available compute disappeared to
fix spectrum and meltdown.
Speaker 1 (11:50):
Not good.
Speaker 4 (11:51):
Remember that?
Speaker 1 (11:51):
Wow.
Speaker 2 (11:52):
And adding to my, I don't only have good news
stories in 2018, Google officially removes their don't be evil
from their code of conduct. I mean, they didn't add
be evil, but they just took out the don't be.
And then in March, uh, The Cambridge Analytica scandal. Oh, yes.
Where Cambridge Analytica had mined Facebook data in a way
that not even Facebook had thought about and was very
(12:15):
effective at doing things like creating ads for individuals where
the individual didn't realize they're the only ones seeing the ad.
A very effective strategy for getting a group of English
people to vote against their best interests and exit the EU.
Speaker 1 (12:29):
Now we have Facebook and nobody cares.
Speaker 2 (12:31):
There you go. Yeah.
Speaker 1 (12:32):
Targeted ad.
Speaker 2 (12:33):
And in April, Belgium declares... video game loot box systems
to be gambling and illegal for minors, which it is.
I don't disagree with them. Interesting problem. Yeah. Don't manipulate children, please. Well,
not too heavily. And then in May, the GDPR is enacted.
It's been in development for a few years. This is
(12:53):
why you have to keep agreeing to cookies as well
as a bunch of other things like the right to
be forgotten and serious fines for not being forthright with breaches.
Speaker 5 (13:03):
Yeah.
Speaker 2 (13:03):
Um, over on the Microsoft side of things, it may,
we have build 2018, which ships.net core 2.1. But also,
and I realized this in hindsight, when I was putting
this together is sort of the first wave of AI stuff.
Remember visual studio and telecode? I think we did a
show on it.
Speaker 4 (13:18):
Yeah. Yeah.
Speaker 3 (13:18):
Yeah.
Speaker 2 (13:19):
Where it wasn't an, you know, we're really talking about having,
helping to generate code for testing and things. It's also
the year they ship ml.net machine learning.net for, for doing
models that way.
Speaker 5 (13:28):
Right.
Speaker 2 (13:29):
And certainly last but not least, for the build announcements,
one of the ones that I jumped over was Azure Sphere.
Do you remember this? This is when Microsoft starts building
their own flavor of a Linux operating system for IoT.
It's subsequently been phased out now, but for a few
years here, it's like, Microsoft makes their own Linux. I
love that.
Speaker 5 (13:48):
Mm-hmm.
Speaker 2 (13:49):
Later in the year, in October, well, actually it was
announced in June, but completed in October, Microsoft acquires GitHub
for $ 7. 5 billion. And our friend, Nat Friedman, formerly of Xamarin,
now a Microsoft employee, becomes the new CEO of GitHub.
We get Core 2.2 at the end of the year
in December. Yeah.
Speaker 4 (14:05):
A couple other compute stories.
Speaker 2 (14:08):
This is the year that Elon Musk attempts to take
over OpenAI from his partners and gets booted out of it.
And he's still angry about that and purse fights with
Sam Altman on regular basis.
Speaker 1 (14:16):
Yeah, because... That's where he is right now.
Speaker 2 (14:19):
Because reasons, because I realized all the same, the same
year that he flies the biggest rocket in history into
space and puts a sports car into space, which still orbiting,
you know, between the earth and Mars also, you know,
call some guy trying to save children in Thailand, a pedophile, uh,
also tries to hijack the AI company. Yeah. Uh, We're
(14:39):
coming into the period of excitement as we're going through
these next few years in quantum computing. And in 2018,
there was a very important paper published, the NISC paper,
which means Noisy Intermediate Scale Quantum, this paper by John Preskill.
This is the point where companies are starting to build qubits,
build these chandelier dipped in liquid helium style computers that
(15:03):
have about 50 qubits or so forth. And in this paper,
he talks about it's all going to be about error correction.
that we're getting out of the lab. These things are
going to be able to do certain levels of compute,
but without really fault tolerance in this, you're not going
to be able to get much done. And that sets
up Google, who's driving a lot of this stuff with
their quantum toolkit, aimed at researchers for testing what prototype
(15:26):
hardware could do, which is funny because next year they'll
actually produce the second market process. So obviously Google was anticipated.
And that's what I got.
Speaker 4 (15:34):
All right.
Speaker 1 (15:34):
Well, before we bring Don on, let's talk about Better
Know Framework. Roll the music.
Speaker 5 (15:40):
Awesome.
Speaker 3 (15:40):
All right, man.
Speaker 1 (15:44):
What do you got? Guess who's back in Better Know Framework?
Speaker 2 (15:51):
I think I know. He's Australian. It's Simon.
Speaker 4 (15:57):
It's Simon.
Speaker 1 (15:58):
So he belongs to our Appfee Next Slack channel. And
he basically knew that I had done some work into
looking into serializing link queries and passing them from client
to server and pretty much gave up. And there was
(16:18):
a whole smattering of GitHub repos out there of people
who attempted it. And I tried like 50% of them
and they all failed. And so he came up with
this thing called SCRY, S-C-R-Y, or maybe it's SCARY. I
don't know.
Speaker 2 (16:33):
Or Scree.
Speaker 1 (16:34):
Or Scree?
Speaker 4 (16:35):
Yeah.
Speaker 1 (16:35):
He doesn't have a pronunciation legend, but he says it's
a type-safe serializable link from a client to a server
side EF core model. And I had told him, and
both Mateus Carvalho and I had worked on this before,
and Mateus came up with something, and I came up
(16:56):
with something, AVN repository, that basically tells Did the same,
but I used classes and serialized those classes for filtering
and basically all aspects of a SQL query, a link query, right?
A where, an order by, all of that stuff just
turned into data and passed in.
Speaker 2 (17:16):
And it works.
Speaker 1 (17:17):
But as Simon pointed out, it's not as efficient as
what he's doing. Yeah. So this is, and he has a,
there's two links. We're going to give you a link
to the scary or the scry or scree project. And
then there's this doc querying MD composing a query at runtime.
(17:37):
And so he just talks about how to do that,
how to create projections and computer projection members. It's really cool. And,
and it works interesting.
Speaker 2 (17:49):
And so, yeah.
Speaker 1 (17:50):
And, and so, yeah. Um, Simon, you win the prize.
Speaker 2 (17:55):
You're awesome.
Speaker 1 (17:56):
You're the first person I know who has actually done this.
And maybe I just resigned and said, I can't be done.
And maybe it was done, you know, long before that.
Speaker 2 (18:06):
I don't know.
Speaker 4 (18:06):
But that reminds me of link to rest.
Speaker 1 (18:09):
Oh, link to rest. Well, that sounds exactly like what
I was doing.
Speaker 2 (18:13):
Yeah. Yeah.
Speaker 4 (18:14):
Because it was the inverse.
Speaker 3 (18:16):
Right.
Speaker 4 (18:16):
Where you, well, you created from a link query, you
could create a query string.
Speaker 3 (18:23):
Right.
Speaker 1 (18:24):
But you couldn't put it back on the other side
and turn it into a link query, which is, which
is what he's doing. And what I wanted to do
as well, right? Because you've got a form and it's
got a whole bunch of search parameters. And if your
data is local, great link query.
Speaker 4 (18:38):
Well, no, so it did it the other way too.
Speaker 1 (18:41):
If it's behind an API.
Speaker 4 (18:43):
Link to REST, it would, it was an ASP.NET. It
was NBC, ASP.NET. It would, take that query string and
then turn it into a link.
Speaker 1 (18:54):
Oh, okay. Well, that's great. Link to rest, rest to link. Okay. Well,
check out scary or scree or scry or whatever it is.
And ask Simon how to pronounce this thing.
Speaker 2 (19:06):
Cause I don't know.
Speaker 4 (19:07):
I'm sure there's a difference, but yeah.
Speaker 5 (19:09):
Right.
Speaker 4 (19:09):
I just remember link to rest.
Speaker 1 (19:11):
Well, Richard, who's talking to us today?
Speaker 2 (19:14):
Grabbed a comment off show 1994, the one we did
with our friend Brady Gaster, talking about Squad. A lot
of good comments on that show.
Speaker 3 (19:20):
Yeah.
Speaker 2 (19:21):
And this one comes from Paula Pinto, who says, while
interesting as always, the whole Squad enthusiasm was pretty much
focused on single developer workflow. Now not having to depend
on anyone else to do related development tasks. It was
all about their nicknamed agents without any ethical discussion of
what tooling like Squad will have in developer teams. I've
already observed how teams have been downsized. Thank the SaaS
(19:43):
products for placing the need for backend developers, AI tooling
doing the work of team members that used to do
translations or asset creations for CMS platforms. Now we get
tools like Squad reducing even further the amount of humans
in the loop, getting celebrated for what a single developer
could choose while taking into account the repercussions it has
on those that are deemed no longer needed to be
kept around as employees.
Speaker 1 (20:01):
Unless you didn't have a team to begin with.
Speaker 2 (20:03):
In a late capitalism-driven society, if $ 5 can do what...
work of 20 developers thanks to tooling like squad the
remaining 15 are out of the company like an old
detroit they will need to find work that isn't yet taken.
Speaker 1 (20:12):
By ai unless you didn't start with a team yeah
you were always one guy.
Speaker 2 (20:18):
But i also think it's kind of a short-sighted mindset
too because i'm seeing more nobody team's not getting laid
out but just working on the other stuff they hadn't
gotten to like the joke for years was none of
us would get to the bottom of our to-do list
And now we're getting through the feature lists and starting
to get into tech debt. And then other features start
(20:38):
to appear. It's only the shortest-sighted of companies that would
work on one thing and not think, what are the
other things we could do? You've got a group of
people who are now more powerful. Utilize them.
Speaker 1 (20:51):
You take all those people on the team, give them
all a unique task, give them their AI tools. And
set them free. And before you know it, you're through
all of those things.
Speaker 5 (21:00):
Yeah.
Speaker 1 (21:01):
Technical debt's a big one.
Speaker 2 (21:02):
I also think there is a larger conversation about what
the shape of teams looks like with these tools going forward. Right.
We're still in early days.
Speaker 4 (21:10):
I've been running into folks who, in the startup community,
are saying they don't need developers anymore.
Speaker 2 (21:16):
Yeah. That doesn't seem true.
Speaker 4 (21:20):
Somebody I ran into, he just came back from two
weeks of a startup incubator, and he was saying, Of
the 20 or so startups there, none of them had developers.
Speaker 3 (21:31):
Yeah.
Speaker 4 (21:31):
Right.
Speaker 1 (21:32):
That's easy to understand.
Speaker 2 (21:33):
Sure. All right, Paulo. Thank you so much for your comment.
And a copy of Music Code Buy is on its
way to you. And if you'd like a copy of
Music Code Buy, write a comment on the website at. netronics. com
or on the Facebooks. We publish every show there. And
if you comment there and I read it on the show,
we'll send you a copy of Music Code Buy.
Speaker 1 (21:46):
Or you could just go to musictocodebuy.net and get it yourself. MP3, WAV,
and FLAC formats. Go ahead. You know you want it.
All right, let's bring on Don Demsack. Don is a
technology leader dedicated to strengthening the tech ecosystem in Central
Pennsylvania and beyond. His day job is with a major
(22:09):
technology company's infrastructure group where he helps CIOs and CTOs
think like COOs. His nights and weekends go to volunteering
as a board member of the Technology Council of Central
PA and as an active member of Tech Lancaster. You
can find his latest ramblings over on Substack. This is
(22:30):
his fourth trip to. NET Rocks and the first in
almost 20 years.
Speaker 2 (22:33):
It's been too long.
Speaker 1 (22:35):
Dude, I remember your first episode. It was during the
Rory years. So it's episode 62. Rory years were 50
to 100. And he somehow convinced you to come up
to the studio. And you were there in the studio
for us, with us.
Speaker 4 (22:53):
Yep. And you remember.
Speaker 1 (22:55):
Richard Roy used to do the Google weirdos thing.
Speaker 5 (22:57):
Right.
Speaker 1 (22:59):
So just for people who don't remember, he would look,
he had a blog, popular blog, neopolian.com. And it was
hysterical and very, very surreal. And he took it down
because he, he wanted to be taken more seriously as
a developer and everybody just wanted comic relief, but he
was very funny. Anyway, he would look at the logs and,
(23:24):
of what people typed into Google and then landed themselves
on his blog, right? He could tell that it came
from Google and the string is in the log, right?
Speaker 4 (23:36):
The URL.
Speaker 1 (23:38):
And so he would read these and they were just crazy,
what people were looking for. But one of them, and
I remember this specifically, Don, tell Don XML to come
home and take out the garbage.
Speaker 4 (23:52):
You just made my wife's week. That is exactly. Make
sure Carl brings that up.
Speaker 1 (23:59):
Oh, well, how could we not?
Speaker 2 (24:00):
I mean, it's crazy.
Speaker 1 (24:03):
But yeah, you used to be Don XML. And then
I think by your third episode, which was 271, it
was Don Demsack on Link to XML.
Speaker 4 (24:12):
Yeah. And who did the session before Mike? Do you remember?
Speaker 2 (24:16):
Uh, two 70 to 70.
Speaker 1 (24:18):
Let's see. I got the list right here.
Speaker 2 (24:22):
It's funny. It's all online. That's weird.
Speaker 4 (24:23):
Yes, it is. I can tell you.
Speaker 1 (24:25):
No, I got it right here. It was Eric Meyer,
Eric Meyer.
Speaker 2 (24:30):
Oh, why the Eric Meyer on link on link? Yeah.
The guy who helped create it.
Speaker 1 (24:35):
Something he knows a little thing about.
Speaker 3 (24:37):
Yeah.
Speaker 4 (24:37):
Just a little. Um, if you haven't, he, or, uh,
been paying attention to him, uh, He recently has a
video up on YouTube of a presentation.
Speaker 2 (24:49):
AI.
Speaker 4 (24:50):
Engineering, around how AI agents got teeth once we allowed
them to do more than just chat when he gave
them access to tools. And he throws out a whole
theory of how we can lock down AI agents by
(25:11):
making them do... mathematical proofs that the stuff that they're
doing won't negatively impact something. It is an awesome video.
Speaker 1 (25:22):
Yeah, we need more of that. Absolutely.
Speaker 4 (25:25):
100%.
Speaker 1 (25:26):
I saw an article that you wrote on LinkedIn, which
was also on your sub stack. Everything that I've seen
from you has been thought-provoking, but this was about the
new MCP 2.0 and how you can't make a stateful
(25:48):
MCP server anymore if you're using 2.0. And so, yeah,
we talked about that. I talked about that with Rocky
on Code with AI. And Richard found your substack and
found some good stuff that you're thinking of and talking about.
And here you are.
Speaker 4 (26:06):
Yeah, it ties right back to what Eric is talking about.
It was funny because I've been working on this for
a bit. But this whole idea of how do we
govern these agents better?
Speaker 2 (26:23):
Right. Sure.
Speaker 4 (26:23):
Everybody. Now, for the last two years, people have been
really complaining about governance. But the big thing everybody now
is complaining about is tokenomics.
Speaker 1 (26:34):
Tokenomics.
Speaker 4 (26:36):
That's the big thing that everybody is looking because now
there's a cost per token.
Speaker 2 (26:41):
Right.
Speaker 4 (26:41):
Well, those two things are kind of related. about two
years ago, just over two years ago, through my day job,
I got to see a demo of some agentic AI.
And the demo that they created was really thought-provoking because
it didn't just show what the agents were working on,
(27:09):
but it actually, at the bottom of it, showed the
conversations the agents were actually having with each other. And
I was like, wow, that looks like a Teams or
a Slack conversation. But I'd never thought of agentic AI
in that way. We're software developers. We think about APIs,
(27:32):
application programming interfaces. Now there's this whole idea of a
natural language interface.
Speaker 2 (27:38):
Or semi-natural, like The way those tools talk to each
other is not that normal, but I get what you're saying.
It is English of a sort.
Speaker 4 (27:49):
And that, that was the thing that jumped out at
me was it was too generic in a team's chat.
You expect a lot of three letter acronyms and very
specific words. for each of the roles that are there.
Think about chat between a DBA, a front end developer
(28:13):
and a middle and a mid tier developer, all the conversations,
all the acronyms that they wind up using.
Speaker 2 (28:19):
Yeah.
Speaker 4 (28:19):
That was lacking.
Speaker 2 (28:21):
It speaks to a lack of common context between the agents.
Speaker 4 (28:24):
And that's where my head was going was how do I, that,
that seems to be missing. Um, and as you guys know,
and you've got, you guys had a bunch of over
the years, especially recently, domain-driven design type folks. I was like,
there's no ubiquitous language.
Speaker 5 (28:42):
Right.
Speaker 4 (28:43):
What if we made these agents speak the ubiquitous language
of the domain that they're in charge of?
Speaker 2 (28:56):
Right.
Speaker 4 (28:57):
That would be super cool.
Speaker 2 (28:59):
And really what you're doing is bracketing their context, right?
That they need to use the correct language.
Speaker 4 (29:04):
Correct. And by doing that, there's side effects, lots of
good side effects. If you can constrain them or control
their language, I'm calling it a controlled natural language. Um,
then they can only do what they can express.
Speaker 5 (29:21):
Yeah.
Speaker 2 (29:22):
And it's another kind of constraint.
Speaker 4 (29:23):
Think about the open AI hacking of hugging face.
Speaker 5 (29:28):
Right.
Speaker 4 (29:28):
Where it had access via MCP to a tool. figured
out how to do something that wasn't desired by that tool.
But if we had a natural, a constrained or controlled
natural language in front of that, then they wouldn't be
able to ask the things that they shouldn't be able
to do.
Speaker 2 (29:48):
Yeah.
Speaker 4 (29:49):
So that's, and so the term, these are patterns that I,
I'm using for this is instead of bounded context, domain-driven design,
how about bounded agency? So how do we build walls
around what the domain that that particular agent can do,
(30:11):
not via just security, but actually ways to express it?
If they don't have the language to express it, they
can't do it.
Speaker 3 (30:17):
Right.
Speaker 1 (30:18):
So if you're adding another layer... Doesn't, uh, doesn't that
affect your tokenomics?
Speaker 4 (30:23):
That's the other side is now you can actually decrease the, um, the,
the verbiage that's going across. Um, and one of the
major challenges with a natural language as us as humans
is there's a lots of different ways to say the
(30:43):
exact same thing, which leads to ambiguity. Right. And there's, and,
By constraining it or controlling that language, you actually reduce
the actual word count, which you're going to reduce the tokens.
But then you're also decreasing your ambiguity, too, because you
can only say it a certain way.
Speaker 1 (31:05):
Well, aren't you using tokens for that intermediate layer that
does the translation?
Speaker 4 (31:11):
So originally, that's where I was thinking. But then I
take it one step further.
Speaker 5 (31:17):
If I.
Speaker 4 (31:18):
can control the language, and so I can control the syntax.
And this goes back to stuff that you guys know
me from, XML. What did I do with XML? I
created domain-specific languages. What did you do with JSON? Create
domain-specific languages. What do we do with Fluent APIs and LINQ?
We created the Fluent APIs and other languages within code. Well,
(31:44):
with all the stuff that's been going on with chat
GPT and natural language processing and stuff that we were
doing with, with link back in the day. What if
I could put a intent compiler in front of the
(32:05):
tool that then parses that text because it's a constrained
natural language. And instead of feeding everything to the model,
what if I if I knew what words mapped to
specific functions, I could actually call those functions instead of
(32:28):
having to pass it through to the agent who would
eventually pass it through to an MCP server somewhere to
actually call the tool. So now I've actually reduced, dramatically
reduced how much is actually going to the models because
I'm pulling some pieces of that.
Speaker 1 (32:46):
From this static glossary kind of thing. But, And I
imagine that the best of both worlds would be if
the word doesn't exist in the glossary and it can't
express it in a more concise way, then it would
go out and get definitions for those words and add
them to the domain.
Speaker 4 (33:02):
So you, you, you really want to control that language
so that you're controlling what it can do.
Speaker 1 (33:08):
Right.
Speaker 4 (33:09):
So you would prefer, uh, to keep to, uh, to
programmatically add the new languages. Don't let it do it
on its own.
Speaker 1 (33:20):
Well, at least it could make you a list.
Speaker 4 (33:22):
A list of it.
Speaker 1 (33:24):
Yeah, a list of things that it didn't understand or whatever.
Speaker 4 (33:26):
Correct. And you can publish that language. And that's one
of the things that models are great at, converting from
one language to another language.
Speaker 2 (33:37):
Right.
Speaker 4 (33:38):
So if you have a way to declare that controlled
natural language, it can convert it automatically.
Speaker 1 (33:44):
Yeah, that's right. I could see repos for all sorts
of vertical industries, uh, DSLs in used in that way to,
to rein in your LLMs and your tokenomics.
Speaker 4 (33:58):
I make it a heck of a lot easier for that.
And so, um, so I actually built, uh, uh, uh,
I built a couple of different things based on that,
but I actually have a, uh, MVP that you can
go pull down from GitHub. It's called Limelight X. Well,
Rush is out this year, right?
Speaker 2 (34:19):
Doing the tour.
Speaker 4 (34:20):
So Rush fan had to pull that in. So Limelight X.
And so you go there, you can actually go see
how to do this. So you can give it the
natural language, the constrained natural language. give it a text
(34:44):
and it will actually give you the intermediate steps so
you can visualize it. So how do you parse that
apart to an AST? How do you take that AST
and optimize it? Then you take that AST and turn
it into intermediate result, which then gets put into an
expression tree a la link. How do you do that?
(35:08):
Because what I've found is, Most people doing AI engineering,
AI agents, they don't come from our comp sci background. Right.
They come from the dynamic language.
Speaker 2 (35:26):
Side of the house.
Speaker 4 (35:27):
They're Python and JavaScript type script. So parsing and compiler
theory type stuff is not something that sits in their domain.
While you can do some of that stuff with those languages,
you don't typically do it. So they're not thinking that way.
So how do I get best of both worlds? That's
(35:49):
part of the challenge.
Speaker 1 (35:51):
Before we go any further, I think we should take
a little break. You think so, Richard?
Speaker 2 (35:55):
Sure, let's do it.
Speaker 1 (35:55):
All right, we'll be right back after these very important messages. Hey,
Carl here. You probably know text control is a powerful
library for document editing and PDF generation. But did you
know they're also a strong supporter of the developer community?
It's part of their mission to build and support a
strong developer community by being present, listening to users, and
(36:19):
sharing knowledge at conferences across Europe and the United States.
So if you're heading to a conference soon, check if
Text Control will be there and stop by to say hi.
You can find their full conference calendar at www.textcontrol.com. And
make sure you thank them for supporting. NET Rocks.
Speaker 2 (36:42):
And we're back. It's.
Speaker 3 (36:43):
NET Rocks.
Speaker 2 (36:43):
I'm Richard Campbell. That's Carl Franklin.
Speaker 4 (36:45):
Hey.
Speaker 2 (36:45):
Talking to our friend Don Demsack a bit about, well,
you just brought up Limelight X as a way to
sort of create a natural language-like set of instructions, which,
I mean, in some ways reminds me of the way
we write specs anyway. Software development is somewhat language. I mean,
you have the programming language is a constraint. But if
you also notice, the average product manager speaks in a
(37:10):
somewhat constrained language. They're trying to communicate with developers, and
developers speak a weird form of English.
Speaker 1 (37:18):
Dilbert proved that.
Speaker 2 (37:20):
They're really trying to just be very clear on what
the intent is, and I think it serves the LLMs
pretty well to stick with that same kind of language barrier.
Speaker 1 (37:29):
100%.
Speaker 4 (37:30):
And then domain-driven design never took off.
Speaker 2 (37:35):
Yeah.
Speaker 4 (37:36):
We all know it works, but one of the side
effects of implementing it is you needed to have a
subject matter expert who can pull that the main logic
out of that, those communications that was very specialized.
Speaker 2 (37:52):
Yeah.
Speaker 4 (37:53):
Well, nowadays with coding assistance and the spec driven development world,
we are starting to put that context into text documents
that obviously we could use models to start pulling out
that domain-specific language from the specifications.
Speaker 1 (38:15):
I would even go one step further and say we're
heading towards, if we're not there already, just not thinking
of it, conversation-based development. In this last episode that I
did with Rocky Latka, he talked about how he and
three other guys sat down to design a system He
whipped out his Android phone, started recording. It made a transcript.
(38:36):
He uploaded that transcript to Claude and said, build me
a spec based on this conversation. Whoa. I mean, talk
about layers, right?
Speaker 2 (38:46):
Using the tool as the preprocessor.
Speaker 1 (38:49):
Yeah.
Speaker 4 (38:50):
It's an interesting space that we're in because that's been
the art of being a developer is has been really
taking these vague requirements and then converting it into code.
What was my favorite, what's the number one thing whenever
(39:10):
I would build something, the business person would typically turn
around and say, I know that's what I asked for,
but that's not what I wanted.
Speaker 2 (39:18):
Yeah, right.
Speaker 4 (39:20):
Because humans are really, really, really bad at giving requirements. Weird.
Speaker 2 (39:24):
Yeah. And in some ways, like you want the domain
expert because they know the space, but they often skip over.
essential parts because they're so knowledgeable in the space. They
don't even realize what they know.
Speaker 4 (39:35):
Yeah.
Speaker 2 (39:35):
Yeah.
Speaker 4 (39:35):
And that's, I mean, because Rocky's been around, he knows
what he needs to put into that. And so how
do you teach that to these new wave of, uh,
coding engineers that are using coding assistants to do that. Well,
(39:57):
we could teach them better requirement skills. And that's one
of the things I started doing a couple of years
ago in prompt engineering was a big rage two years ago.
And now it's context engineering. But when I explain it
to the average person, what a prompt is, I tell
them it's a requirement. Think of it as giving it
(40:21):
a requirement to another human.
Speaker 5 (40:22):
Right.
Speaker 4 (40:22):
Got to put in all that extra context. And then
because of my agile background, I like to use given
when then, so that as measured by. And then I
would teach people to write their prompts in that structured
form and they get better results out of the engine
because you're giving it all the context that you would need.
Speaker 1 (40:45):
Yeah. That's brilliant.
Speaker 4 (40:47):
And so that's, And so that's the same problem that
I'm running into with the spec-driven development is while they
have great structure for the documents, how do you build
the tests? Right. What you really kind of need to
be able to do is create, given when then type scenarios,
(41:11):
do more behavior-driven development. So testing for behavior that's expected
or not expected. rather than writing generic tests.
Speaker 2 (41:20):
You're right. Domain-driven development is great at defining what we'd
like it to do, but behavior-driven development is much better
at defining what it actually does and if that's what
we really wanted to do.
Speaker 4 (41:32):
And then if you could take that, those behavior-driven tests,
now you can also use that to drive the controlled
natural language because you're expressing the behaviors that you're looking for.
Speaker 2 (41:47):
And so.
Speaker 4 (41:48):
Besides Limelight X, I have a project called VectorRen, V-E-C-T-O-R,
my SVG days, Ren, R-E-N, so two R's. And it
was built with that in mind to show developers how
to build an SVG game, a web-based with JavaScript, with
(42:12):
generic JavaScript, no framework. And so what was the, you
guys remember, what the big game was when we were
trying to do demo SVG back in the day, it
was asteroids. Right.
Speaker 1 (42:24):
Oh yeah. So that's right.
Speaker 4 (42:25):
There is in half an hour using this methodology, I
describe what the game should do and given one then,
and it generated a simple implementation of asteroids. And you
can go to vector ren.org or go to vector ren, uh,
the GitHub page, uh, out there and you can pull
(42:47):
it down. And it's a very simple way to learn
JavaScript from this point of view, without any of the frameworks,
something simple that, that, that people can actually leverage, uh,
because we have this generation of developers who don't have
the traditional comp side background.
Speaker 2 (43:05):
Right.
Speaker 5 (43:05):
Yeah.
Speaker 2 (43:06):
I'm just thinking about, we're revising this. We've been playing
with what the software development life cycle with these tools
is supposed to look like. And, and I'll, I think
there's a lot more energy put into the context up
front just because the tools will generate lots and lots
of code. It's just most of it is not that
good if you haven't really done a good job of
(43:27):
setting up these constraints.
Speaker 4 (43:30):
I've been doing a lot of stuff with AI here
in Central Pennsylvania. One of the interesting feedback I'm getting
from non-traditional developers is we don't care.
Speaker 2 (43:42):
Yeah.
Speaker 4 (43:44):
It gets the job done, and that's all.
Speaker 5 (43:45):
I care about.
Speaker 2 (43:46):
You're going to care.
Speaker 4 (43:50):
I hit up one of the folks I was talking about.
I was talking about, hey, you're just creating dynamic scripts.
This feels a lot like what JavaScript felt like before jQuery,
before we got V8, before we got TypeScript. We're sending around.
Speaker 2 (44:10):
Yeah, before we put constraints around for reliability.
Speaker 4 (44:14):
And consistency. So, and I was like, you know, from
a tokenomics point of view, every time you send that text,
you're getting charged for it. Yeah. And so there's a
cost because I don't care. It's cheaper for me to
do that than to spend the time to actually write
(44:35):
the compiled code.
Speaker 2 (44:36):
For now, anyway, the costs are going up. But often
the folks don't care because they don't know the consequences.
Speaker 4 (44:42):
They don't know good engineering principles.
Speaker 2 (44:44):
Yeah, they don't know how the software will bite them later.
It's generally what works right now.
Speaker 4 (44:48):
And what I'm seeing is a lot of the vibe
coders realizing that they can only go so far of
vibe coding, and then they start going to coding assistants,
but then they don't know how to create these good
engineering principles. And so I think there's a big market
for that.
Speaker 2 (45:04):
So the AKA they're starting to care.
Speaker 4 (45:07):
And it makes me sad because as a VB guy,
old school VB guy, isn't that what the C plus
plus people complained about us about?
Speaker 2 (45:17):
Yep.
Speaker 4 (45:17):
Yeah, we weren't real developers.
Speaker 2 (45:19):
Well, Yeah, and again, the argument was, is the software
quality sufficient? And let's face it, we built a lot
of bad quality software, and then we learned, hey, software
quality matters. And you could do it with VB, you
just had to follow some good practices.
Speaker 1 (45:32):
I think a lot of that nose turning down at
VB developers was a byproduct of what happened between C
developers and basic developers in the very early days of programming.
Basic with go-tos was looked at as horrible. I was
(45:52):
using Visual Basic and then attending a community college and
the computer science lady, I told her that I was
using Visual Basic. She goes, oh, basic. Oh, you can't
say basic.
Speaker 4 (46:04):
No go-tos, no go-tos.
Speaker 1 (46:05):
I'm like, no, it's completely changed now. You know, it's
come into its own and they still just, you know,
you get an idea in your mind and it's hard
to shake.
Speaker 4 (46:15):
And I don't want to be that Get off my
lawn guy. Yeah, right. And I don't want to be
that old guy.
Speaker 1 (46:21):
Nobody does.
Speaker 4 (46:22):
I've got the gray hair, fine. But I don't want
to be that guy. Same thing with coding assistants. What
I've been talking about to a lot of folks is
coding assistants is the new IDE. I remember back when
we were talking, you know, Vim was it. You didn't
(46:43):
use Studio.
Speaker 3 (46:44):
Right.
Speaker 4 (46:44):
IntelliSense. Coding is novel. You had to know it and
remember it in your head and use a text editor.
Real developers use text editors.
Speaker 1 (46:54):
I think it took Don Box a long time to
come to grips with the fact that people are going
to use IDEs, not them.
Speaker 4 (47:01):
It would be interesting to get his opinion on coding.
Speaker 2 (47:03):
You see those positions all over the place. I think
you're making a mistake as soon as you're bound to
a tool. In the end, the goal was to deliver
value to customers.
Speaker 4 (47:15):
And then there's this whole, and this ties into Run
As Radio, then there's this whole angle from the IT
admin side of the house where IT admins were doing automation,
but they were doing it via a GUI tool because
IT admins didn't write code.
Speaker 3 (47:35):
Right.
Speaker 4 (47:35):
That was for the developer world.
Speaker 1 (47:37):
Right.
Speaker 4 (47:38):
In my day job, what I'm starting to see is
more and more IT admins admins leveraging coding assistance to
actually create better code than they could ever written because
all they ever wrote scripts. This is much better code
and it's making their lives a heck of a lot easier.
So that's just, I mean, that's an unintended consequence, but
(48:02):
it's helping, especially in these days when so many companies,
so many on-prem companies who are using VMware and now
they're kind of A little bit of a backlash. They're
all trying to move off, and now they're more open
to how do I do this automation rather than using
a tool.
Speaker 1 (48:20):
One quick correction. I think I misspoke. When I was
in a community college, it wasn't VB. It was Quick Basic.
Quick Basic. Quick Basic was compiled, and it was structured,
and it was great back then. And this computer science
person was like, no go-tos.
Speaker 5 (48:37):
Don't say it.
Speaker 2 (48:39):
Well, and it's the thing, there's nothing wrong with the language.
It just had a construct that was a problem. Hey,
remember option explicit? Like we did learn.
Speaker 3 (48:46):
Sure.
Speaker 1 (48:48):
On error, resume next.
Speaker 2 (48:50):
Yeah.
Speaker 1 (48:53):
I don't have any bugs.
Speaker 2 (48:55):
What?
Speaker 5 (48:55):
Yeah.
Speaker 4 (48:56):
So one of the things that I've been starting to
work with is how do I start creating skills to
be able to help teach these non-developers these good habits?
So like one of the things, That's in a beta
right now is a requirements interrogator skill. So help the
average person create that given when then brief so that
(49:20):
they get better requirements when they're trying to build something.
Speaker 2 (49:24):
Yeah, you have to wonder if we're not going to
end up with more opinionated agents that are like, I
can't start building this until I have these broader requirements
settled around those kinds of constraints that are going to
matter for security and architecture and reliability and scalability. all
of the abilities that everyone doesn't care about until they
care about them.
Speaker 3 (49:43):
Yeah.
Speaker 4 (49:44):
One of them I'm playing with right now is, is
creating a skill to create architectural decision records.
Speaker 5 (49:50):
Right.
Speaker 4 (49:50):
We've never, I mean, we all always wanted to have them,
but now if I'm using a coding assistant, that helps
make my coding system better. It tells the architecture and
the reasons why we picked certain things.
Speaker 2 (50:05):
Yeah.
Speaker 3 (50:07):
Yeah.
Speaker 2 (50:07):
There's lots to all of that. I mean, again, I
feel like we're just groping around right now trying to
figure out.
Speaker 4 (50:13):
It's early days.
Speaker 2 (50:15):
What are the, yeah, the tools are shifting. Just remember,
we were trying to develop on. NET in the early
days where every time they got a build out, the
editor changed, the framework had changed, and the language had changed.
Everything you're doing, incorrect. Yeah.
Speaker 4 (50:32):
I was part of that early days. I don't even
remember if I ever mentioned it to you guys, but
the framework The client that I had back in 99, 2000,
their president was on the board for Microsoft, and I
was building dashboards for him, and I got introduced to
(50:54):
Project Cool.
Speaker 2 (50:55):
Before it was announced. Before it became C Sharp?
Speaker 4 (50:57):
Yeah, before 2000, the announcement at PDC 2000.
Speaker 3 (50:59):
Yeah.
Speaker 2 (51:04):
I think it was actually TechEd, but yeah.
Speaker 5 (51:06):
TechEd.
Speaker 4 (51:06):
Yeah, it was TechEd. That's where I'm at.
Speaker 2 (51:08):
But yeah, but I'm also thinking about the craziness that was.
NET Core in, you know, 2018 or 2016. Because it
took them 18 months to get that first version built
and there were so many previews. And every time you
got a preview, everything shuffled on you. And it just
seems an awful lot like trying to work with Anthropica
or OpenAI or any of these tools right now, where
(51:30):
every time you get A new build, new harness, like
there's so many different components that presuming it works the
same way is crazy. It changes. It changes a lot.
Speaker 1 (51:40):
And just like with. NET Core, Richard, I think that
there's still a lot of people not dipping their toes
into AI developer-wise for the very same reason.
Speaker 4 (51:52):
So have you guys had anybody on for Microsoft Foundry Local?
Not yet.
Speaker 2 (51:57):
Not yet. No, it's on my radar.
Speaker 4 (51:59):
I've been intimate with that. So that's part of what
the bounded context. Part of what I realized is to
use these smaller models, you had to be very prescriptive
in the prompts that you were giving.
Speaker 2 (52:13):
Right, right.
Speaker 4 (52:14):
And when I started writing the code, I didn't want
to put that code as text into my program. I
wanted to pull it out. And so I created a
YAML language that did essentially prompt as a function so
that you could import it in and create it. And
there's a couple different prompt as a function frameworks out there.
(52:39):
BAML is one and DPSY, another where it makes it
easy to put prompts into your programming languages. The Dipsy
is Python only. BAML is TypeScript and Python. And so
(53:02):
I built a framework to be able to do that
because I was trying to run local models. I was
running local models on what I'm using now, Copilot Plus PC.
The Copilot Plus PCs were supposed to be the place
to be able to run these models. It's just not.
Not as good as it could have been.
Speaker 2 (53:21):
At 40 tops, that's not a lot. Meantime, I'm looking
at my RTX 5080 at 1,500 tops and saying, why
aren't I a co-pilot PC?
Speaker 4 (53:32):
So I am super excited for the new RTX Spark laptops.
I'll be the first to go buy one of them
when they come out.
Speaker 2 (53:40):
They're actually going to be a laptop, because right now
it's a NUC.
Speaker 4 (53:44):
Well, the big difference is the DGX Spark, Right. That's
the one you're thinking is the RTX Spark. Two separate things.
The DGX is Linux.
Speaker 3 (53:55):
Right.
Speaker 4 (53:55):
The RTX laptop, which is, that was, it was a nook.
The RTX is a laptop. It is going to run
Windows on ARM.
Speaker 2 (54:05):
Right.
Speaker 4 (54:05):
So it's, you could think of it as the Uber
Co-Pilot Plus piece.
Speaker 2 (54:09):
Possibly, yeah. It'll be interesting. It's one of the things
I've seen over and over again with the DGX Spark,
but folks are actually using it is, You end up
running NVIDIA's models because they're so much better optimized for
their hardware that you just get vastly better responses or results.
So it's not a universal anything. Where is our ODBC
(54:34):
so that you really have some equanimity across all of
these different products? and can really see what all the
different hardware solutions can be there. I hate that we're
building dedicated to hardware solutions, but I get it.
Speaker 4 (54:45):
Part of why I created that prompt as a function
to make it portable, to describe what's the model, what's the,
am I using VLR? Am I using Foundry Local? What's
the model? So I can abstract that away so you
don't have to worry about it and be able to
switch it in and out. And so I've got a
(55:06):
framework for that and I'm, I hit my limit with
the Copilot Plus PC and I'm waiting for these new
ones to come out. But that's a whole different conversation
because there's so many people, so many clients and customers
I talk to that can't use public models.
Speaker 5 (55:22):
Right, right.
Speaker 2 (55:23):
There's whole classes of work that are just not an
option to be going, leaving your machine in any way.
Combined with tokens are only getting more expensive and all
you can eat is disappearing and The methodologies we've been
using with the sort of adversarial agent model are just
mo tokens.
Speaker 4 (55:40):
And smaller models hallucinate less. Right.
Speaker 2 (55:45):
They are more bound.
Speaker 4 (55:47):
And then you bound it by a language, a constrained language,
a controlled language, and you can reduce it even worse.
That's kind of where I'm going with this. Still early days.
I do a lot of Foundry local type stuff, running
to issues, report bugs. There's a whole Viber community. Folks
(56:09):
who are interested in getting into dipping their toe in
how do I inject AI LLMs, highly recommend checking it out.
It's an easy install. And there's a command line tool
that you can use just to get started to have
a chat. Have some fun. And then they've got some
great SDKs, whatever language you want to use from.
Speaker 2 (56:29):
NET to Rust.
Speaker 1 (56:30):
It's out there.
Speaker 4 (56:31):
I highly recommend it.
Speaker 1 (56:32):
This is good stuff, Don.
Speaker 5 (56:34):
Excellent.
Speaker 2 (56:35):
And it got me thinking.
Speaker 1 (56:36):
Yeah, definitely got us thinking. Where can we find you
online besides your Substack?
Speaker 4 (56:42):
My Substack and LinkedIn. I do both. LinkedIn, it's marketing
hell right now. People are all complaining. Um, it's not
where the developers are. Right. And Substack, I tried Reddit.
I tried, uh, various Discord servers. Um, my local Lancaster
(57:06):
folks have a great Slack team. So I'm there, Tech Lancaster.
Those folks are awesome. But Substack feels like the blogging
from the old days. It's, it's, it's a good community there.
Speaker 1 (57:18):
So in the Lancaster area, do you find that there
are many Amish developers there?
Speaker 4 (57:23):
There are some that you'd be surprised.
Speaker 3 (57:26):
Wow.
Speaker 4 (57:26):
You'd be surprised. And I wrote up a whole article on,
because I'm new to the area, Lancaster feels to me
like Portland, Oregon 20 years ago. They like that weird,
let's be weird attitude.
Speaker 2 (57:42):
Right.
Speaker 4 (57:43):
They like the back to nature, had the farming, all
that sort of stuff.
Speaker 2 (57:48):
Yeah.
Speaker 3 (57:48):
But.
Speaker 4 (57:49):
They also like the tech side and there's two massive
data centers coming in. Coral Reeve is the big AI
company is putting a big data center and Google's putting
a big data center in there. So there's a lot
of innovation going on in that Amish community. It's an
interesting time.
Speaker 1 (58:08):
Yeah.
Speaker 4 (58:09):
Most people don't think of it that way, but land
is a heck of a lot cheaper. They can't build
any more data centers in, um, Northern Virginia. So they're
moving north into central PA and south into Richmond.
Speaker 5 (58:21):
Okay.
Speaker 1 (58:23):
Well, you have to keep us apprised. And when you
trade your first AI training for a shoe fly pie,
let me know. All right, Don, thanks very much.
Speaker 2 (58:38):
Good to catch up with you again.
Speaker 4 (58:39):
Good to catch up. And let's not make it in
another 20 years.
Speaker 1 (58:42):
Definitely. And we'll talk to you, dear listener, next time on.
NET Rocks.
Speaker 5 (59:08):
NET Rocks is brought to you by Frankenstein.
Speaker 3 (59:10):
Net and produced by Plop Studios, a full-service audio, video,
and post-production facility located physically.
Speaker 5 (59:17):
In New London, Connecticut, and, of course, in the cloud.
Online at pwop.com.
Speaker 3 (59:24):
Visit our website at dotnetrocks.com for RSS feeds, downloads, mobile apps, comments,
and access to the full archives going back to show
number one, recorded in September 2002. And make sure you
check out our sponsors. They keep us in business. Now
go write some code.
Speaker 1 (59:44):
See you next time.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
The Clay Travis and Buck Sexton Show
The Clay Travis and Buck Sexton Show. Clay Travis and Buck Sexton tackle the biggest stories in news, politics and current events with intelligence and humor. From the border crisis, to the madness of cancel culture and far-left missteps, Clay and Buck guide listeners through the latest headlines and hot topics with fun and entertaining conversations and opinions.