Speaker 1: How'd you like to listen to dot net rocks with
Speaker 1: no ads? Easy? Become a patron For just five dollars
Speaker 1: a month, you get access to a private RSS feed
Speaker 1: where all the shows have no ads. Twenty dollars a
Speaker 1: month will get you that and a special dot net
Speaker 1: Rocks patron mug. Sign up now at Patreon dot dot
Speaker 1: NetRocks dot com. Hey, welcome back to dot net rocks.
Speaker 1: I'm Carl Franklin and A'mirchrid Campbell, and we're recording this
Speaker 1: right before we leave for dev Intersection in Orlando. But
Speaker 1: you are not home, sir.
Speaker 2: No, No, It'll all have been over by then. It'll
Speaker 2: almost be, you know, Halloween, so right, I'll be in
Speaker 2: the Netherlands when this publishes, so something.
Speaker 1: But right now, you're not at home, are you?
Speaker 2: I am, Yeah, I'm leaving. Oh you are. Literally we're
Speaker 2: recording a show and then I'm packing up to head
Speaker 2: to the mainland tomorrow. Okay, see you in Orlando, dude.
Speaker 1: All right, Okay, I thought you were on a trip before.
Speaker 2: Maybe you were.
Speaker 1: I don't know. I can't keep track of you. I
Speaker 1: don't even want to.
Speaker 2: Yeah, me neither. I don't even know where I am,
Speaker 2: Wait a minute, are you?
Speaker 1: Who are you? What'd you do with Richard Mind?
Speaker 2: I'm just another AI.
Speaker 1: Yeah right, uh well, let's you know, since this is
Speaker 1: episode nineteen seventy four, let's talk about what happened that year,
Speaker 1: shall we before we do anything else.
Speaker 2: Oh, it's an exciting year. It's an exciting year. Nixon.
Speaker 2: Bye bye, Where do you want to start?
Speaker 1: Bye bye Nixon. Yeah, he's not a crook, but he
Speaker 1: is resigning.
Speaker 2: Are you sure? I don't know, I sound so sure?
Speaker 1: Well he said so, yeah, okay, And you know, after
Speaker 1: that day, we didn't have Dick Nixon to kick around anymore.
Speaker 1: So I think he did for a while longer, but yeah,
Speaker 1: oh yeah, yeah, as long as I miss was alive,
Speaker 1: he was getting kicked on a daily basis.
Speaker 2: Yeah.
Speaker 1: The Turkish military invaded Cyprus following a coup, leading to
Speaker 1: a division of the island and increased international tensions.
Speaker 2: Which still persists this day. That division in Cyprus.
Speaker 1: The Carnation Revolution occurred in Portugal. That's a coup resulting
Speaker 1: in the overthrow of the authoritarian regime. So the FIFA
Speaker 1: World Cup took place in West Germany, where the host
Speaker 1: nation defeated the Netherlands two to one to win the championship.
Speaker 1: Just in case you were wondering, the boxing match known
Speaker 1: as the Rumble in the Jungle featured Muhammad Ali defeating
Speaker 1: George Foreman in Zaire. Ali would go forward to have
Speaker 1: a great after career life in George Foreman sold grills.
Speaker 1: He did a lot more than that. He had seven kids,
Speaker 1: all named George. The Swedish pop group Abba won the
Speaker 1: Eurovision Song Contest with their song Waterloo, making the start
Speaker 1: of their successful career. Have you seen the Eurovision Song
Speaker 1: Contest recently, Richard?
Speaker 2: Not recently, No, but I'm aware of it. You don't
Speaker 2: want to, okay.
Speaker 1: Some significant the film's release include The Godfather Part two, Chinatown,
Speaker 1: and Blazing Saddles, all movies that probably couldn't be made
Speaker 1: today in my opinion. I'm going to talk about the
Speaker 1: Terracotta Warriors. The first of those were discovering Jiang, China, unbelievable,
Speaker 1: leading to significant archaeological finds. What do you know about
Speaker 1: the terracotta warriors, Richard.
Speaker 2: I've been there, but just you know, I know that
Speaker 2: once they were exposed, they started to decay, like a
Speaker 2: lot of the paint was still on them. When they
Speaker 2: first were found, but.
Speaker 1: They were made to with the with the emperor, I
Speaker 1: suppose in the grave to protect him, right.
Speaker 2: Yeah, that's the that's the idea. Like nobody really knows
Speaker 2: for sure, but the Yeah, you'd have to see this thing.
Speaker 2: It's unbelievably vast. Yeah, and the crazy part is, like
Speaker 2: archaeology is not a huge thing in China, They've only
Speaker 2: done a little. There's so much more to be found there.
Speaker 2: And this is a culture that's been around literally for millennia. Yeah,
Speaker 2: you're talking these things are what two thousand or so
Speaker 2: years old, but there's so much more.
Speaker 1: I think the crazy part is that people actually built
Speaker 1: thousands of terracotta warriors and stuffed them in a grave. Yeah,
Speaker 1: that's kind of crazy.
Speaker 2: It speaks to the wealth of that country at that time,
Speaker 2: right that they could afford to do such just like
Speaker 2: building pyramids. Like, clearly you have too much money, right
Speaker 2: if you can build these things. But that, yeah, it's
Speaker 2: another example of that.
Speaker 1: So what happened in science and Tech and seventy four Richard.
Speaker 2: Not a big space year. Mariner ten made it to Mercury,
Speaker 2: the first probe to ever do that, actually do two
Speaker 2: flybys of Mercury, and that would be the only visit
Speaker 2: to Mercury in the twentieth century. That would be the
Speaker 2: Messenger spacecraft in the twenty first century. And that's about it.
Speaker 2: There's a couple of soused flights to sal you there's
Speaker 2: the plans for the Apollo Soy use missions, but they
Speaker 2: won't happen until the next year, so not a big
Speaker 2: year in space.
Speaker 1: And like Venus, Mercury is not a very hospitable planet.
Speaker 2: Well, it's awfully close to the Sun. It's very very hot,
Speaker 2: no atmosphere at all. Yeah, but still interesting, you know,
Speaker 2: and certainly something so we're studying further tricky to get
Speaker 2: to takes a lot of energy to get there.
Speaker 1: Do we actually get data from it before it burned up?
Speaker 1: Oh yeah, No, it's not that close. Was able to
Speaker 1: orbit around fly bys Mercury. You know, going into orbit
Speaker 1: around Mercury is very challenging. We won't do that for
Speaker 1: quite some time.
Speaker 2: The first reporting on the destruction of the ozone layer
Speaker 2: nineteen seventy four and will lead in a few years
Speaker 2: to the thing called the Montreal Accords. Well, we'll band
Speaker 2: CFC's and ultimate allow the ozone layer to repair itself
Speaker 2: a successful story and turns out it worked. It worked.
Speaker 1: Yeah, I'm giving away the ending. We can do those
Speaker 1: kinds of things, people, We can. We absolutely can. And
Speaker 1: I use that as an example when we talk about the
Speaker 1: current crisses. The first edition of Dungeons and Dragons is published.
Speaker 1: Gary Gygax and Dave Arnison from TSR derived from an
Speaker 1: earlier game played with miniatures and went.
Speaker 2: On to make geeks even geek here for many, many years.
Speaker 2: Oh yeah, but and I would say this is by
Speaker 2: far from in our part of the world. The most
Speaker 2: important thing happened in seventy four. Right at the end
Speaker 2: of nineteen seventy four, the mits altear eighty eight hundred.
Speaker 2: So this was not the only personal computer at the time.
Speaker 2: There were kits you could buy that would just be
Speaker 2: give you and you'd have to put together the parts
Speaker 2: and so forth. This was the first assembled machine based
Speaker 2: on the Intel eighty eighty. The design would largely lead
Speaker 2: to the S one hundred bus machine. In general, you
Speaker 2: could only had to set at LEDs on the front end.
Speaker 2: You would program it with switches, or you could add
Speaker 2: a serial card to it to have a teletype interface.
Speaker 2: Otherwise just not display no keyboard under that stuff. Yeah,
Speaker 2: and it was popular electronics. Is this magazine that was
Speaker 2: actually driving One of their rival magazines had published this
Speaker 2: kit on their cover, and they wanted to make sure
Speaker 2: they had something as well. So they were pushing and
Speaker 2: my admits to get this thing done in time. And
Speaker 2: so nominally it was on the cover of the January
Speaker 2: nineteen seventy five edition, but it was actually put on
Speaker 2: new stands in December seventy four, so I included the
Speaker 2: seventy four And why is it important? This is Microsoft's
Speaker 2: founding product. That cover is the thing that got Gates
Speaker 2: to drop out of Harvard and moved to Albuquerque and
Speaker 2: write a version of Basic would later be known as
Speaker 2: the Altar Basic, which was Microsoft's very first.
Speaker 1: Product, and he wrote it with the Altair.
Speaker 2: He used the alt He actually wrote it on a
Speaker 2: different machine because he didn't have one. He wrote it
Speaker 2: on a machine at Harvard, a lot of it by
Speaker 2: hand and by hand figured it all out because they
Speaker 2: had to run in four K, and then brought it
Speaker 2: down there and coated it in to test it. But
Speaker 2: the first time he already had it written before the
Speaker 2: first time he actually laid hand on an altar because
Speaker 2: there wasn't any of them, and the name Altar actually
Speaker 2: comes from the star Alta, although there's an apocryphal or
Speaker 2: adjacent story of the fact that around that same time,
Speaker 2: in the late seventies, the television show Star Trek had
Speaker 2: an episode on a mock time where they go to
Speaker 2: Altair six, and since it was a star of a technology,
Speaker 2: they ought to have a cool name, not just a number,
Speaker 2: so they called it.
Speaker 1: So I've seen pick of the Altear and you're right.
Speaker 1: It has like switches where you can turns the zeros
Speaker 1: into the ones on and then press the button to
Speaker 1: write it into memory. It kind of reminds me of
Speaker 1: a pressure cooker, you know, like, well, it's just a box, right,
Speaker 1: it's a issue here is it's turning over. It's before
Speaker 1: RAM exists. Yeah, so you had to hand key the bootloader. Wow,
Speaker 1: it was like one hundred and seventeen bytes something like that.
Speaker 1: So you literally so booed up was a process. Was
Speaker 1: literally once you got that thing running, you didn't want
Speaker 1: to turn it off. Power goes out.
Speaker 2: No, Yeah, and this is they weren't even using cassette
Speaker 2: tapes at this point. The first versions of Basic were
Speaker 2: on this paper tape with holes punched in it that
Speaker 2: they that the thing could read in to load up
Speaker 2: the version of Basic. It was a very small version
Speaker 2: of Basic because there's only four k RAM and you
Speaker 2: still have to run your program too, right, So.
Speaker 1: They really only had mainframes before that, right, main four
Speaker 1: or less.
Speaker 2: And many the PDPs are around, right, the mini computers,
Speaker 2: but they're all.
Speaker 1: Using cards, so it makes sense that they would be
Speaker 1: using that technology.
Speaker 2: He uses paper tape. And there's no copy of the
Speaker 2: original ALTA Basic. I think it exists anywhere. There is
Speaker 2: a version of the advanced version of that Basic in
Speaker 2: the Computer History Museum in the Silicon Valley, signed by Gates,
Speaker 2: and I think it was Gates's actual copy of it.
Speaker 1: Wow.
Speaker 2: And so yeah, yeah, the original original it starts the
Speaker 2: whole company.
Speaker 1: I think it's gone. That's pretty crazy. Yeah, so the
Speaker 1: history of dot net starts in nineteen seventy four, doesn't.
Speaker 2: Theoretically, I mean it's beginning of Microsoft. But yeah, yeah,
Speaker 2: all right in Albuquerque. Wow, good one.
Speaker 1: So let's start then next with better no framework?
Speaker 2: Awesome?
Speaker 1: Al what you got? Do you use bitwarden? So do?
Speaker 1: I I love Bitwarden? Did you know that you can
Speaker 1: run it on prem Yeah.
Speaker 2: Yeah, the open source product, right as it should be.
Speaker 1: Yeah, I didn't know this, and then I found the
Speaker 1: Bitwarden server get repository and apparently you know, so, like
Speaker 1: I said, I didn't know it. I thought it was
Speaker 1: a product that you subscribe to, and it is. But
Speaker 1: if you want to run it yourself in.
Speaker 2: There, you can use it for free or you can
Speaker 2: pay them like.
Speaker 1: You and so what's really cool about this is that
Speaker 1: you know, hey, maybe we don't even want to trust
Speaker 1: bitwarden dot com with our passwords. Maybe we want to
Speaker 1: you know, keep all our data behind the firewall and
Speaker 1: wherever we want to put it, and you know, to
Speaker 1: be more secure. I mean, whether it is or not,
Speaker 1: I don't know, but at least that's an option. So
Speaker 1: you can download the server. It has all the APIs
Speaker 1: and everything that you need to run it. You can
Speaker 1: even run it on a Windows machine. You can run
Speaker 1: it in Docker containers on a Windows machine if you
Speaker 1: want to. Of course, Linux and Mac it's all there.
Speaker 1: It's really really cool and.
Speaker 2: If we have made it clear, it's a password manager. Yes,
Speaker 2: you know, you can buy commercial products like one passes
Speaker 2: and so forth. But This is also one I've fallen
Speaker 2: on too. I had to leave last pass when last
Speaker 2: pass went insane. Me too, Yeah, which, by the way,
Speaker 2: I found migrating off the last pass less painful than
Speaker 2: I thought. Yep, I was dreading it. But the only
Speaker 2: real problem with a migrating from between password managers is
Speaker 2: at some point you're going to generate a CSV file
Speaker 2: of every single password in your life, and that will
Speaker 2: be upsetting. Well, the real way to do it is
Speaker 2: to just find the list of domains that you have
Speaker 2: passwords for in last past and go to each one
Speaker 2: of them and say, hey, I forgot my password, and
Speaker 2: go through the whole process of generation. Yeah. I mean,
Speaker 2: it's a terrible thing to do if you've got hundreds
Speaker 2: of them, but you know, in the reality is you
Speaker 2: can migrate your passwords over the other one, but you
Speaker 2: should probably change me after that and do yourself a
Speaker 2: favor delete that file when you're done. Absolutely, that file
Speaker 2: shouldn't exist. That files bad. What file? Yeah, and I'm
Speaker 2: super keen to get to pass keys. I just think
Speaker 2: passkey's still a half baked so.
Speaker 1: Yeah, they're not quite there yet. I like one global
Speaker 1: authenticator app would be really good.
Speaker 2: For me. Yeah, I don't know.
Speaker 1: Not nine authenticator apps, not ten?
Speaker 2: Good luck with that.
Speaker 1: Just one is all I want.
Speaker 2: I think there's a I's pretty sure there's an SKCD
Speaker 2: cartoon about this. It's like, we need a standard for everything.
Speaker 2: Now there's ten. Yay, Yeah, that's right. Remember scuzzy SCSI. Yeah,
Speaker 2: wasn't one of the SA's standing for standard. Yes, that's yeah.
Speaker 2: You know, how would that work out? No, there are
Speaker 2: no standards. Everybody fights against them.
Speaker 1: All right, Well that's what I got. Richard, who's talking to.
Speaker 2: Us today, jumped into the wayback machine because we haven't
Speaker 2: talked about stuff like specification driven development in a long time,
Speaker 2: but we have talked about it. And I grabbed a
Speaker 2: comment off a show nine to twenty one. Wow, this
Speaker 2: is when we talked about the product Cucumber working with
Speaker 2: behavior driven development Matt Wins show back in twenty thirteen.
Speaker 2: We've got a ton of comments on that show. Not surprising. Yeah,
Speaker 2: and gap has a Utz had this commed. He said, well,
Speaker 2: I had no real world experience with to driven development
Speaker 2: until now I've to use it on a new, relatively
Speaker 2: small project and we're now working on I'm really I'm
Speaker 2: trying to get to the place is what he's talking about,
Speaker 2: where you have an executical specification. And I just thought
Speaker 2: this comment was really relevant because we think about what
Speaker 2: we're doing with prompting with lllms these days, as could
Speaker 2: almost be an executable specification rather than having a separate document.
Speaker 2: It's supposed to document what the system does, but it's
Speaker 2: always out of sync, like what's the what do we
Speaker 2: make rules around all of this? But it would be
Speaker 2: cool to actually get on these large projects that we
Speaker 2: have a set of documentation that in this game were
Speaker 2: talking about. Cucumber generated the test to say does the
Speaker 2: software does what it's supposed to do? But I, you know, now,
Speaker 2: thinking ten years on looking at gatus as common, I'm like, wow,
Speaker 2: look where we are right now with the next generation
Speaker 2: of tools and another way of thinking about how we
Speaker 2: write a specification about an application and then how that
Speaker 2: specification turns into executable code.
Speaker 1: Cucumber was like all use cases, right, yeah, Like as
Speaker 1: a user, I want to be able to blay blah
Speaker 1: blah blah, and yeah, yeah, very cool.
Speaker 2: Yeah, it was acceptance testing, right, You're supposed to be
Speaker 2: able to write it in English, Like I don't know.
Speaker 2: I'll include a link to cucumber. Folks want to take
Speaker 2: a look at it. It would take a minute for
Speaker 2: me to go back and look at this now, just
Speaker 2: thinking about what lms have done to this whole space. Sure, anyway, Gattis,
Speaker 2: thank you so much for your comment, and a copy
Speaker 2: of music code By is on its way to you.
Speaker 2: And if you'd like a copy of music cobe I,
Speaker 2: write a comment on the website at dot NetRocks dot
Speaker 2: com or on the Facebook. We publish every show there,
Speaker 2: and if you comment there and I read in the show,
Speaker 2: I'll send you copy of music cobe.
Speaker 1: I was just using music to code By to prepare
Speaker 1: for my talks nice next week, and it's still going strong.
Speaker 1: Twenty two tracks, twenty five minutes long, designed for the
Speaker 1: Pomodoro technique, but not necessarily. You don't have to have
Speaker 1: a clock.
Speaker 2: You know.
Speaker 1: They're neither boring or too exciting. They're just in that
Speaker 1: middle space. They're just too right. Get you into a
Speaker 1: state of flow and keep you there, okay. Den de
Speaker 1: la Marski is our guest. He is a principal product
Speaker 1: engineer currently working at Microsoft, where he helps build developer
Speaker 1: tools in AI powered experiences that make engineers more productive.
Speaker 1: Den started his engineering journey all the way back in
Speaker 1: the nineties.
Speaker 2: Oh god, all the way back, all the way back,
Speaker 2: a long time ago.
Speaker 1: All the way back in the nineties.
Speaker 3: I did I tell you that I listened to your
Speaker 3: podcast when I was in middle school?
Speaker 2: Oh my god.
Speaker 1: Yeah, excuse me, take some geritol right now, Hang on
Speaker 1: a second.
Speaker 2: Yeah, yeah, all right.
Speaker 1: So in the nineties with the three eighty six box
Speaker 1: that was verily enough to run Doss games. He's upgraded
Speaker 1: since then. He has spent plenty of time writing code
Speaker 1: and visual basics six oh, but for more than two
Speaker 1: decades now he's writing see sharp and Python and there's more. Dan, welcome,
Speaker 1: thank you, so happy to be here. I'm such a
Speaker 1: fan of Dunn at Rocks.
Speaker 2: That's great. Wow.
Speaker 1: Well, after reading your bio, I'm a fan of yours
Speaker 1: TB six. I mean, I was there, we were there.
Speaker 1: I missed those days.
Speaker 3: I missed the days of just me like popping an ID,
Speaker 3: using the forum, designers, dropping some progress bars on clicking
Speaker 3: the buttons and things are.
Speaker 1: Just working well and not having to sign into an app.
Speaker 2: Nice and not having to sign in Ye, that was
Speaker 2: a product that was made fun of. You know, it
Speaker 2: wasn't real programming back in the day, and we were
Speaker 2: crying all the way to the bank as we knocked
Speaker 2: out the things that our customers actually needed in less time.
Speaker 1: I was there at BB one. Oh, I was there
Speaker 1: and quick Basic com pts Before.
Speaker 2: That, Yeah, yeah, no, I spent I did my time
Speaker 2: in the in MFC crashing windows repeatedly and wondering what
Speaker 2: I was doing wrong. VB showed out like this is better.
Speaker 1: What you do is you find yourself an MFCC plus
Speaker 1: plus programmer and then you just partner with them to
Speaker 1: do the hard stuff.
Speaker 2: Yeah.
Speaker 3: I gotta say, I just don't know that there was
Speaker 3: not that much stuff that was that hard. Like I
Speaker 3: love VB six, but you know, the one thing that
Speaker 3: just kind of annoyed me about it is when Windows
Speaker 3: XP came out and it had all these super nice
Speaker 3: styles and everything, and just VV six was constantly stuck
Speaker 3: in the Windows ninety five and I was like, oh,
Speaker 3: come on, man, Like, can I just get the nice
Speaker 3: progress bar, the nice button with the shadow.
Speaker 1: And you could if you went third party. They all
Speaker 1: adapted their stuff. Yeah, they had read through everything, but.
Speaker 2: I was broke and I had no money, I couldn't
Speaker 2: get that party. Well, and we didn't know that Microsoft
Speaker 2: was changing gears, right, like, yeah, that there wasn't going
Speaker 2: to be a VB seven right, Yeah.
Speaker 1: Those were the days days of drama.
Speaker 2: Yeah. So but that's talk to me about spec driven development,
Speaker 2: den What have you been up to here? What is
Speaker 2: this all? Right?
Speaker 3: So folks might have seen that about a month ago,
Speaker 3: we work with our friends at get hub to release
Speaker 3: this thing called spec Kit. So if you go to
Speaker 3: get up dot com slash, get up slash spec dash Kit.
Speaker 3: Spec Kit is nothing super magical. It's basically a set
Speaker 3: of templates, prompts, and scripts. And the whole purpose for
Speaker 3: that is that when we talk to folks that try
Speaker 3: to build software llms, like, there's a large swath of
Speaker 3: folks that are just very excited about the fact that, oh,
Speaker 3: I don't have to write boilerplate code, I don't have
Speaker 3: to write my tests from scratch because I can just
Speaker 3: you know, use quad code to do that stuff. So
Speaker 3: as we talk to more of these customers, especially customers
Speaker 3: and like bigger companies, customers that want to build something
Speaker 3: that is going beyond what we refer to as vibe coding. Oh,
Speaker 3: I'm building a podcast landing page, like, oh, yeah, you
Speaker 3: can vibe code that in the day. If you're building
Speaker 3: a i don't know, like a CRM or like a
Speaker 3: plugin for a CRM, all of a sudden you're in
Speaker 3: the world of hurt because you're getting into this state
Speaker 3: of now I need to go and just constantly prompt
Speaker 3: for changes, and then things went off the rails and
Speaker 3: I need to go back somehow and then redo it.
Speaker 3: But now I don't have any history. So for that
Speaker 3: we thought, okay, we have an idea for an experiment.
Speaker 3: What if all of this stuff can be encoded into specs?
Speaker 3: And this is idea as old as time, as kind
Speaker 3: of Richard called out like spectrum development and the idea
Speaker 3: of writing specs as the underlying kind of the layer
Speaker 3: of software is not exactly new like it existed for
Speaker 3: some time. This is more of a it's a new
Speaker 3: incarnation of it and in this context, and by the way,
Speaker 3: a lot of this was also driven by one of
Speaker 3: my colleagues, John Lamb, who was inspired.
Speaker 1: Yeah.
Speaker 3: John Lamb is great from the Iron Python days. For
Speaker 3: folks that don't know, Yeah.
Speaker 1: From a developmentor before that, I think yes.
Speaker 2: Yeah.
Speaker 3: So John was somewhat frustrated by the fact that Claude's Sonnet,
Speaker 3: the model from Anthropic, was very over eager.
Speaker 2: When you'd give it coding test.
Speaker 3: You'd be like, oh, can you like I'm building this
Speaker 3: new components, like oh, let me write this component, let
Speaker 3: me write all to the framework for this component and
Speaker 3: everything around it.
Speaker 1: Yeah.
Speaker 3: So the idea was like, well, can we put guardrails
Speaker 3: around it? So make sure that, like if I ask
Speaker 3: you to do this, you do just that. So this
Speaker 3: is what essentially bootstrapped spec Kit. This was the foundational pieces.
Speaker 3: It's like, how do we make the model a little
Speaker 3: bit more contained if you will to do the things
Speaker 3: that we want. And as we started kind of exploring this.
Speaker 1: Couldn't you write a system prompt for Claude just to say, hey,
Speaker 1: state your lane and don't do anything I don't tell
Speaker 1: you to do.
Speaker 3: You could, but then you're just always in this like
Speaker 3: cat and mouse game, right, and you're writing system prompts.
Speaker 3: So and by the way, it's also like if you
Speaker 3: switch models all of a sudden.
Speaker 2: Like what what then? Like do I write a system prompt? So?
Speaker 1: Okay?
Speaker 3: Yeah, And also we live in a world where developer
Speaker 3: switch models, like every week there is I'm sure there's
Speaker 3: a model came out. Well, we're recording this that we
Speaker 3: did not know about this, this is somehow better or different
Speaker 3: models for different applications exactly. So Speckett was born out
Speaker 3: of that entire need, and as we started kind of
Speaker 3: evolving it, things pop top from customer conversations like, oh, well,
Speaker 3: if I starting coding requirements, how do I make sure
Speaker 3: that my technical requirements are correctly updated if I decided
Speaker 3: to change my tech stack. And that actually is one
Speaker 3: of the core value props of Speckett and the spectrum
Speaker 3: development here is that we're detaching the spect the requirements
Speaker 3: from code and from the tech stack, so that if
Speaker 3: you're a developer and previously you're like, Okay, I want
Speaker 3: to build a web app for my enterprise that does
Speaker 3: something like accounting, and I'm not entirely sure which framework
Speaker 3: is the most performed, is it next JS? Should I
Speaker 3: use Astro? Should I be framework less entirely? Should I
Speaker 3: write this in just tailwin CSS for UI, shad CN.
Speaker 2: And like, what would you have to do?
Speaker 3: You'd have to go and write this in whatever stack
Speaker 3: and then maybe do some benchmarks and figure out like
Speaker 3: what's the performance. Now, because you have a spec you
Speaker 3: can just go and ask it to write you like
Speaker 3: three versions out of the same requirements. So you basically
Speaker 3: you start speed running the iteration process and saying, oh,
Speaker 3: create me like three options that I can choose from.
Speaker 3: And that's kind of nice because now you have the requirements,
Speaker 3: they're separate from your technical requirements, and the LM can
Speaker 3: just build it for you and then you can assess it.
Speaker 2: Cool.
Speaker 1: So Cucumber plus AI, you could probably think.
Speaker 3: It's basically simplify yes, instead of as a user I
Speaker 3: can is like as a large language model, I can.
Speaker 1: Wow.
Speaker 2: But I think you're also skipping over some hard bits here,
Speaker 2: which is you really have to granulize the specification. Yes,
Speaker 2: you want to take small enough bites at the LM
Speaker 2: has a shot at building this thing.
Speaker 3: Success absolutely, And I think one of the biggest problems
Speaker 3: that we see with people trying to approach spectro of
Speaker 3: development is actually, like, first of all, the problem is
Speaker 3: under specification because if you are not yet comfortable writing
Speaker 3: specs or understanding.
Speaker 2: What you're building and why, you're.
Speaker 3: Gonna fall into the pit of under specification and what
Speaker 3: happens when you underspecify things. The AI starts guessing and
Speaker 3: it's like, oh, sure, like you did not tell me
Speaker 3: that you do not want the header to be green.
Speaker 3: I'll make it like whatever color I choose, right, And
Speaker 3: I think this is like it's a it's a mental shift, right.
Speaker 3: You previously have to get into the mode of like, oh,
Speaker 3: I'll just go and start writing things and see how
Speaker 3: it happens. Now you're like, no, no, no, I need to
Speaker 3: spend upfront time thinking about this, outlining this. And by
Speaker 3: the way, we also support this capability. We added this
Speaker 3: prompt inside spec kid that is called clarified and that
Speaker 3: is essentially you're using the language model to question your
Speaker 3: spec right, So if you're not if you have writer's block,
Speaker 3: you're you're not inspired, Uh, you can just ask the
Speaker 3: LM to say can you can you ask me quite,
Speaker 3: are there any blind spots that I might have? Are
Speaker 3: there the things that I don't know?
Speaker 2: I don't know? Right?
Speaker 3: Right, just keep keep prodding at this and so and
Speaker 3: absolutely you're right Richard, like there is a degreeable. So great, Well,
Speaker 3: we're going to have this massive specification. It's going to
Speaker 3: be massive, like it's going to be massive context windows
Speaker 3: for folks that know, like any large language model has
Speaker 3: basically a limited set of tokens again process at any
Speaker 3: given time before it starts losing track of what you
Speaker 3: asked it to do. So the context windows are relatively limited.
Speaker 3: So if you start with a giant, massive spec you
Speaker 3: can call it a context window. I'm going to call
Speaker 3: it a buffer overflush. Sure that's really what's happening. Absolutely, yes,
Speaker 3: that that's a very good way of putting it. Like
Speaker 3: you're going to get into the world of the buffer
Speaker 3: overflow where a lot of your instructions and guardrails are
Speaker 3: just going to be tossed out the windows. Like it's
Speaker 3: not going to be a plot.
Speaker 1: Yeah I heard Sun at four point five has more space.
Speaker 3: Yes, yes, modern models have like generally are improving in
Speaker 3: terms of like the the buffer overflail problem.
Speaker 2: Yeah.
Speaker 3: So what we also do here is not only do
Speaker 3: we ask you to create the specification, but we'll also
Speaker 3: break this down into chunks. So once SUSPEC is ready,
Speaker 3: once the technical plan is outlined, we have the capability
Speaker 3: to basically split this into consumable tasks. And then this
Speaker 3: is where I showed in my videos. I showed in
Speaker 3: a blog where it's like you can use slash tasks
Speaker 3: to then create a list of tasks that are based
Speaker 3: on the spec based on the technical plan, and the
Speaker 3: LM can do them in chunks. It's like, Okay, first
Speaker 3: of all, you need to bootstrap this project next to yes, okay,
Speaker 3: let me go do that. Now you need to create
Speaker 3: the CSS, Okay, let me go do that. So you're
Speaker 3: going through these controlled stages of creating things and get
Speaker 3: to an end result. Now, some of these tasks also
Speaker 3: going to be parallelized, and this is something that we
Speaker 3: see with coding agents like claud code that support sub agents,
Speaker 3: where the agent itself can spin up sub agents with
Speaker 3: their own context windows, and you can say, oh, this
Speaker 3: agent's going to be writing tests for this component, this
Speaker 3: agent's going to be running tests for this other component.
Speaker 3: And then you get into this world of kind of
Speaker 3: things are happening in parallel but also manageable chunks.
Speaker 2: Yeah no, and you sort of see your role as
Speaker 2: a shepherd there to push down the specifications in enough
Speaker 2: detail that the tools have a chance segregating into portions
Speaker 2: with headers that describe this is the context you're going
Speaker 2: to be living in. But it's shorter than the overall context.
Speaker 2: Now I need you to do this party, and I
Speaker 2: everywhere I see this being this approach be successful with
Speaker 2: unbelievable levels of testing too, right, I'm always a stun
Speaker 2: to llms. Often when given an instruction for a set
Speaker 2: of code to generate, get about halfway through and just
Speaker 2: kind of stop. It's like, you can finish this. It's
Speaker 2: your buffer overflow. I think it's a buffer overflow. And
Speaker 2: so so that test approach where I want you to
Speaker 2: generate the set of tests and then I want you
Speaker 2: to pass all the tests before you stop. It's kind
Speaker 2: of a way to again compress that context further right
Speaker 2: into these test loops to try and actually get complete
Speaker 2: sets of code from it, like the tools take the wrestling.
Speaker 1: When that happens. When that happens, though, it's it's really
Speaker 1: unnerving because it's in a state where you can't really
Speaker 1: debug it because not all the code is there that
Speaker 1: it was, yes, you know, spitting out and you ultimately
Speaker 1: have to roll stuff back and try again. And I
Speaker 1: hate that about code generation in general, is that you know,
Speaker 1: now this is intelligent code generation. By the way, John
Speaker 1: Lamb's been into code generation since like ninety one.
Speaker 2: Before it was cool.
Speaker 1: Yeah, but you know the problem of course is that
Speaker 1: if it creates something that you don't understand and can't
Speaker 1: explain in a meeting, for example, you're you're done for
Speaker 1: in my opinion.
Speaker 2: Oh absolutely absolutely.
Speaker 3: And I think this is an interesting tangent here to
Speaker 3: the role of expertise, Like I've heard somebody talk about
Speaker 3: kind of the role of the developer moving forward. If
Speaker 3: if LM has become really good at cogeneration and producing
Speaker 3: just just boatloads of code, what is your role as
Speaker 3: a developer on IT team? And I think there's a
Speaker 3: hypoth this is that that role is going to shift
Speaker 3: more to almost like a Richards. You go out like
Speaker 3: the Shepherd reviewer, right, it was like okay, but like
Speaker 3: even for you to be able to review things, you
Speaker 3: have to have expertise to know what you're looking at, right,
Speaker 3: because I've seen this happen. But like Carl, you're talking
Speaker 3: about like test or and development, Like to me, this
Speaker 3: aspect of like, okay, well, there's a bunch of tests,
Speaker 3: and I looked at some of the tests that some
Speaker 3: of the models generate, and sometimes like for me to
Speaker 3: test for the test to pass.
Speaker 2: Oh, let me make a change and just return true. Yeah, right,
Speaker 2: and test is passing now, Hey solved it.
Speaker 1: Look at it.
Speaker 2: It's all green.
Speaker 1: Now.
Speaker 3: Nice, But you need to have the expertise to actually
Speaker 3: look at it and be like, yeah, this ain't it?
Speaker 2: No, like I need like I.
Speaker 1: Kind of I kind of think of a roll moving
Speaker 1: forward as sort of like a general contractor building a house. Right,
Speaker 1: the general contractors in charge of all the subcontractors that
Speaker 1: have their sub specialties. But any general contractor worth their
Speaker 1: weight knows enough about those things to be able to
Speaker 1: take over if the electrician is out sick, or to uh,
Speaker 1: you know, remove the termite damage from these boards, if
Speaker 1: the carpenter doesn't you know, isn't there that day? That
Speaker 1: kind of stuff. So so you need to be able
Speaker 1: to understand everything that your subs are doing and be
Speaker 1: able to jump in when you can, but not necessarily
Speaker 1: build the house by yourself.
Speaker 3: Right, right, And we see this especially critical with things
Speaker 3: like security and awe, oh my goodness, Like I see
Speaker 3: so much stuff that is just tossing to get our
Speaker 3: bripo that clearly has been just like the AI told
Speaker 3: me that this is secure, Like oh no, you're returning
Speaker 3: to the two FA code and the adjacent response is
Speaker 3: you're expecting it like that's that's that's not going to
Speaker 3: be good. So yeah, so the these changes right, like
Speaker 3: there's a good degree of that expertise that needs to
Speaker 3: be embedded into the process and see that the the
Speaker 3: what the LM is generating, whether it's tests, the components,
Speaker 3: the structure is actually right and scope through the project
Speaker 3: you're building them because LM's go thrills all the time,
Speaker 3: right all the time, and they do wild things that
Speaker 3: if you don't know, like on a surface, it might
Speaker 3: seem like, oh it works. I was recently like rebuilding
Speaker 3: some of the stuff would alsope with the help of
Speaker 3: spec get on my blog and it's like, oh, I
Speaker 3: couldn't understand where your CSS is. I'm just going to
Speaker 3: recreate a bunch of CSS files and so I'd have
Speaker 3: like a bunch of duplication all of a sudden. Yeah
Speaker 3: it works though, but if I didn't know, if I'm
Speaker 3: somebody that has to maintain, they'll be like, wait, why
Speaker 3: just recreate these two folders for this exact same content.
Speaker 1: We're coming up with more and more of these examples
Speaker 1: where having the expertise would prevent working code. That's dumb.
Speaker 2: Yeah, yeah, yeah. The concept is what's worked, what's actually
Speaker 2: working right, and the software clearly has a different perception
Speaker 2: of working than you. Yeah right, get good enough guidelines. Hey,
Speaker 2: we got to take a break for these very important messages.
Speaker 1: Do you have a complex dot net monolith you'd like
Speaker 1: to refactor to a micro services architecture? The micro Service
Speaker 1: Extractor for dot Net tool visualizes your app and helps
Speaker 1: progressively extract code into micro services. Learn more at aws
Speaker 1: dot Amazon dot com, slash modernize.
Speaker 2: And we're back. It's don A. Rock's Emirateard Campbell. Let's
Speaker 2: Carl Franklin. You talking to our friend dem about the
Speaker 2: spec kit and this idea of I think essentially formalizing
Speaker 2: some practices around harnessing LMS for co generation. You're talking
Speaker 2: about uml right, yeah, yeah, that's what I want in
Speaker 2: my life.
Speaker 1: You're still way back in the nineties.
Speaker 2: Yeah, well, you know, it's linguist. It'd be interesting to
Speaker 2: get to a point where it was rendering, taking images
Speaker 2: and breaking them down into specifications as well. But I
Speaker 2: I do you know, now we've got the I'm starting
Speaker 2: to see the term work slop, just like AI slop,
Speaker 2: but it's hey, you you responded to a mediocre corporate
Speaker 2: email with even with generated results of even more mediocre.
Speaker 2: And the evil part about this is it takes time
Speaker 2: to read that and realize it's garbage, and so you're
Speaker 2: literally propagating garbage downward and making everything slower. Like there's
Speaker 2: a real risk here about not creating quality, but there
Speaker 2: is a way to create quality, like I have seen
Speaker 2: these things be successful. So part of this is really
Speaker 2: building you know, we talked about what's our job as
Speaker 2: the human in the loop here, it's actually having an
Speaker 2: eye to quality results that just setting it to true
Speaker 2: is non as acceptable that these tests are comprehensive. You know,
Speaker 2: you've got it, and but I also think you're going
Speaker 2: to be used the tool a lot for this. I
Speaker 2: like the idea of co generated from Claude being evaluated,
Speaker 2: you know, by open AI and how does it what
Speaker 2: its assessment looks like, and going passing back and forth
Speaker 2: between them so that you do have other assessments of
Speaker 2: everything being made.
Speaker 1: Have you guys ever hired somebody who talked to good
Speaker 1: talk and then when they sent their code in you
Speaker 1: could tell they had no idea what they were doing
Speaker 1: and you're just frustrated. You could lose your mind like that,
Speaker 1: Like if you're constantly retelling an LLM, No don't you
Speaker 1: don't downgrade to dot eight? Was dot nine? Did I
Speaker 1: tell you the down grade?
Speaker 3: No?
Speaker 1: I did not, So why are you doing? You could
Speaker 1: actually lose your mind if you know, after a while,
Speaker 1: if that's your job and no wonder people want to
Speaker 1: write code because at least they're in control of it
Speaker 1: and they got no one to blame but themselves.
Speaker 3: Yeah, so for that, by the way, like you call
Speaker 3: out of a very important point, which is, how do
Speaker 3: you set up these kind of requirements that the LM
Speaker 3: does not go off the rails in terms of your
Speaker 3: technical requirements and would spec it introduced this concept of
Speaker 3: the constitution. It sounds very fancy or like the you know,
Speaker 3: call it the charter if you will, or the Karda
Speaker 3: if you're British. You know, basically outline, it's the fundamental
Speaker 3: guys exactly, like the non negotiable things that will absolutely
Speaker 3: apply to your project. And this is where we've seen
Speaker 3: a lot of successful people coming in and saying I
Speaker 3: will write my constitution and say you always use.
Speaker 2: Dot net nine.
Speaker 3: You never downgrade anything else like, And the Constitution is
Speaker 3: grounded in every part of the spec process so that
Speaker 3: when it goes through like the technical plan and task breakdown,
Speaker 3: it always has to go and check like, what does
Speaker 3: the Constitution say about us?
Speaker 1: Oh?
Speaker 3: Dot net nine? Oops, I put dot net eight. Okay,
Speaker 3: can't do that. That's a constitutional violation. I'm gonna go
Speaker 3: ahead and redo this.
Speaker 1: Get up copilot agent. I think the engine was or
Speaker 1: still is in written in dot net eight, and so
Speaker 1: it didn't have a dot net nine compiling environment, and
Speaker 1: so it would always go downgrade and think it was
Speaker 1: doing you a favor.
Speaker 2: Right, So theory that's a long training thatta has a
Speaker 2: lot of impact on this. That's the long term support version, right,
Speaker 2: So there's a case but still but still, but you know,
Speaker 2: the only have this great race of context, which is
Speaker 2: you know you're describing the Constitution is a prefix prompt, right,
Speaker 2: It's like before you do anything, these are the rules.
Speaker 2: So a bunch of our context is now consumed by
Speaker 2: the prefix yes and no. Then we have the sort
Speaker 2: of state of being of the project, and then the
Speaker 2: request for what to create I'll say, we do it
Speaker 2: a little bit even trickier than that. So the Constitution
Speaker 2: is embedded in other prompts where you can essentially say,
Speaker 2: if you're building a technical plan, consult the Constitution, and
Speaker 2: within the technical plan, create a checklist of constitutional checks
Speaker 2: you have to go through before you move forward.
Speaker 3: So instead of us embedding the Constitution, the Constitution itself
Speaker 3: can say like, oh, okay, this has to be a Net
Speaker 3: nine application, this has to be using this library to
Speaker 3: connect to Microsoft SQL server. And then when you get
Speaker 3: to the implementation stage, before you do an implementation, we
Speaker 3: also do a checklist of essentially saying can you cross
Speaker 3: check once more the Constitution against the plan, against the task,
Speaker 3: against the spec and see if there's any violations. So
Speaker 3: you're essentially creating almost unit tests for.
Speaker 2: English like that.
Speaker 3: That's kind of the framing seris Okay, let me, let
Speaker 3: me go and just cross check to make sure that
Speaker 3: nothing went off the rails, because too often people fall
Speaker 3: into this kind of habit of oh, I've done the spec,
Speaker 3: I've done the planet done and task great, go build
Speaker 3: this now. But that's like hold on, you still need
Speaker 3: to check that what it created actually matches the expectation requirements.
Speaker 3: So there's a bit of a process, right, And I
Speaker 3: think this is where I was talking about, Like this
Speaker 3: is the mental shift that you now have to think
Speaker 3: about those things that you did not before, because before
Speaker 3: you would just start writing code and be like, oh sure, yeah,
Speaker 3: let me bootstrap a dot A nine project and visual
Speaker 3: studio at my NuGet packages and be on my merryway.
Speaker 3: Here it's like now I need to basically like spell
Speaker 3: it out for it. For like, you have an over
Speaker 3: eager intern that is very very happy to help you
Speaker 3: but has no knowledge of what you're trying to do
Speaker 3: and just go like if you don't tell me, I'll
Speaker 3: just guess. And this is where you're trying to kind
Speaker 3: of like put guardrails and say like can I guide
Speaker 3: you to the right thing, to the exactly what I want?
Speaker 1: Reminds me of Scooter from Mondays. Mister Miller, shop it
Speaker 1: on your pencils, I'll shove you beginning. I didn't find
Speaker 1: him with pencils up with cranons in shopping to miss
Speaker 1: the Miller.
Speaker 2: It's exactly that. It's exactly that. Uh, Now, I gotta
Speaker 2: think there's some people listening. Is this even worth it? Then?
Speaker 2: Like all of this work to try and get this
Speaker 2: code generation to behave properly.
Speaker 3: I think it depends. I think I'll say like it
Speaker 3: depends right, like it's it's a I I. I'd like
Speaker 3: to think the analogy like if you know, if you
Speaker 3: have a hammer, everything looks like a nail. So it's
Speaker 3: like I don't want to say like you have to
Speaker 3: use this for everything, but there's certainly value in getting
Speaker 3: from zero to a new feature, to a new component,
Speaker 3: to a new entirely new product with this. Even if
Speaker 3: you use this essentially scaffold this, just just get the
Speaker 3: bulk of the things, get the four pieces of vail,
Speaker 3: and then you with your expertise can come in. It's
Speaker 3: like you want to go and rewrite this component, go
Speaker 3: ahead and do this, you want to add like a
Speaker 3: moon and go ahead to do this. But it saves
Speaker 3: like a lot of this tediousness. So also a lot
Speaker 3: of these models are getting better, Like Sonnet four to
Speaker 3: five got released last week, Like GPT five got released
Speaker 3: like it was like last month, and like GPT five
Speaker 3: compared to GPT four was like night and day when
Speaker 3: it comes to coding, right, which like who saw that coming?
Speaker 2: Right? But like they're getting better and better.
Speaker 3: And I totally see a world where a lot of
Speaker 3: these guardrails were just kind of become leaner and it's
Speaker 3: not going to be as heavyweight because.
Speaker 2: You're not going to bang into them as often.
Speaker 3: And yeah, exactly because a lot of the constraints that
Speaker 3: we talked about like they wear. The reason they're there
Speaker 3: is that they were inspired by Sonnet four being over eager.
Speaker 2: Right, Yeah, I know every law is written in blood, right,
Speaker 2: like right right, what we're seeing.
Speaker 3: But as they become better, a lot of these constraints
Speaker 3: will become more lax because like you can just tell
Speaker 3: it like it's always dotten at nine is like cool,
Speaker 3: I remember it's always done at nine, I'm never touching
Speaker 3: anything else.
Speaker 2: Yeah, it's just you don't bang against it as much. Yeah,
Speaker 2: I just think there's an interesting balancing act for you know,
Speaker 2: what really you're saying them is there's a case for waiting.
Speaker 3: There's a case for waiting and experimenting.
Speaker 2: If I wait, the tools will get better.
Speaker 3: And experimenting and seeing what works in a wood doesn't
Speaker 3: then because Spekeett itself is an experiment, right, like we are.
Speaker 3: We got into the world with the intent of can
Speaker 3: you help us verify where this works and where it doesn't. Yeah,
Speaker 3: and like we're not making any statements of saying like, oh, yeah,
Speaker 3: this is going to absolutely destroy the software engineering career
Speaker 3: track is the yeah I got to write the code
Speaker 3: for It's like, no, like I want you to test
Speaker 3: this and tell me. Yeah, I've tried adding a feature
Speaker 3: to my enterprise app and it just completely went off
Speaker 3: the rails and it was completely useless.
Speaker 2: Like that to me is like super helpful. You back,
Speaker 2: I'd love to know that. No. And I saw this
Speaker 2: in the early GitHub copilot days where people's behavior changed
Speaker 2: in the repository, where there was far more reverts yep. Yeah,
Speaker 2: like they would use the tool to generate some core,
Speaker 2: they push it up, it would blow up, they would revert. Yeah,
Speaker 2: And so you know, we I could definitely tell you
Speaker 2: were using the tool because you were using the toolimate
Speaker 2: the code and then you weren't really editing much, or
Speaker 2: you weren't doing a whole lot. You were just trying.
Speaker 2: You were stuffing into the test suite. See what happened,
Speaker 2: and what happened was bl you know what, I'm going.
Speaker 1: To close this issue and open it again.
Speaker 2: Yeah, you know we we can just make that branch
Speaker 2: go away again.
Speaker 1: And everybody else how we screwed this up.
Speaker 3: This was a forcing function for me to actually get
Speaker 3: much closer to get interesting, because once I started going
Speaker 3: through like the spectrum processes like okay, let me go
Speaker 3: create the spec, let me create the plan, let me
Speaker 3: break it down and task. Okay, this looks reasonable. Let
Speaker 3: me check the SIN. Okay, so now I have the check.
Speaker 3: Now let's start generating the code. It's like, okay, I
Speaker 3: don't even push. The code I just generated was like, okay,
Speaker 3: this component, Okay, now it looks right. Checkpoint check the SIN.
Speaker 3: Now continue generating. Oh now it's screwed up. Just blow
Speaker 3: it all away. Let's do it again.
Speaker 2: The code that worked in the previous build does work
Speaker 2: this next build. Yeah, exactly.
Speaker 3: But the geit process is super helpful in this context
Speaker 3: because it allows me to checkpoint things, and it's like,
Speaker 3: all of a sudden, get went from this like, oh yeah,
Speaker 3: I just use this toss things into gethub into an
Speaker 3: actual like oh, I can checkpoint things, and I can
Speaker 3: create multiple branches and multiple implementations across different branches and
Speaker 3: then test them separately. Oh I'm curious, what if this
Speaker 3: button would instead be this kind of component. Let me
Speaker 3: create a new branch and do this and test this right, So,
Speaker 3: like you, you go through the process of using get
Speaker 3: as an.
Speaker 2: Actual helper here, Yeah, no kidding, surprised. Can I go
Speaker 2: to the checkpoint code and point the LM at dot
Speaker 2: and said, this code works? Why is this changed? Or
Speaker 2: you're going to make changes? Make sure it passes the
Speaker 2: same test, so you can use your validation skills against
Speaker 2: the various pieces of code with these checkpoints and force
Speaker 2: the tool down about right, let.
Speaker 1: Me change GET testing tests?
Speaker 2: Do I just change the tests?
Speaker 3: This is like see the lesson for future software engineers
Speaker 3: listening to this learn GET.
Speaker 2: Yeah, that's like that's gonna be your your your savior.
Speaker 1: GET.
Speaker 2: This is a tool that will help you. Yeah, but
Speaker 2: you know and now you're you're helping me shape my
Speaker 2: mind on the how different our work looks like and
Speaker 2: the tools that are actually going to help us to
Speaker 2: get there. And again with always designed to am I
Speaker 2: better off? Is as better results? I've definitely talked to
Speaker 2: folks here, So I'm being successful as a tool, but
Speaker 2: I'm not having as much fun, right, Yeah, yeah, I can.
Speaker 3: I can see this and I think there's a something
Speaker 3: to be said about the fact that coding and self
Speaker 3: engineering in and of itself is a creative process, right,
Speaker 3: Like you're you're sitting down, like, let me think through
Speaker 3: this problem, let me figure out how to this. But
Speaker 3: also there's no denying that there's like, at least for me,
Speaker 3: I know for a fact, that there's a lot of
Speaker 3: tedious tasks like oh my goodness, like I just do
Speaker 3: not want to deal with this, like writing us like okay,
Speaker 3: you need to write one hundred unit test for all
Speaker 3: these components, Like oh, like, can I can just somebody
Speaker 3: write these for me so I can actually focus on
Speaker 3: the components.
Speaker 2: One hundred percent coverage is so much more approachable when
Speaker 2: you got a tool generating the test solely. Man, Yeah,
Speaker 2: what'd you call me? So?
Speaker 1: Yeah, it's almost like you know these people who get
Speaker 1: their dopamine rush from just a clean compile, right, you know,
Speaker 1: you know, I just want to write this feature compiles.
Speaker 1: All right, it's good, but I get my dopamine rush
Speaker 1: on those weekly meetings where I show the boss what
Speaker 1: I've done and it works and everything's good. Yes, that's
Speaker 1: I'm holding off for the for my endorphins. To kick
Speaker 1: in at that moment. It's delayed gratification.
Speaker 2: I think that's that's there.
Speaker 3: There's value in that in the sense that we often
Speaker 3: can forget what this is in service of, right, Like
Speaker 3: you're like looking at me, like the stuff that the
Speaker 3: code that I write is in service I.
Speaker 2: Want to solve a specific customer problem. Yeah, this is
Speaker 2: our whole VB conversation at the of it. Yeah, no,
Speaker 2: it wasn't as cool as C plus plus, but boy
Speaker 2: is sure did bring solutions to customers faster. Exactly if
Speaker 2: this can bring solutions to customers faster, Okay, and how
Speaker 2: many of your customers did care that, Like, oh you
Speaker 2: didn't write this in C plus plus ooh, well, as
Speaker 2: long as it doesn't look like AI slop, right, this
Speaker 2: is come down to it. If it's triggering people the
Speaker 2: way that AI slop triggers people, then you're not succeeding.
Speaker 2: Just say no to AI slope.
Speaker 1: There you go.
Speaker 2: Yeah, demand quality from these tools. But I'm also you
Speaker 2: said this a while ago, and I should have grabbed
Speaker 2: onto this earlier down if this thing gets me eighty
Speaker 2: percent of the way by dealing with all the scot
Speaker 2: work so that I now have to just work on
Speaker 2: the twenty, which is arguably the coolest code and the
Speaker 2: most important in the project. You did me a favor,
Speaker 2: There's no two ways about that. Yeah. You know, if
Speaker 2: we could just Prato's law this and get that eighty
Speaker 2: out so that we can work on the hard stuff,
Speaker 2: we've definitely saved time provided value.
Speaker 3: I think that's the goal. Hard stuff is more fun anyway, Yeah,
Speaker 3: that's the more fun.
Speaker 2: Yeah. Yeah, well it's plus you're going to fight with
Speaker 2: the spec and the tokens to get those last few
Speaker 2: points so hard it's probably not worth it. Like there's
Speaker 2: going to be a point of diminishing returns on this, yeah,
Speaker 2: at some point. And I'll say, like, it's also the
Speaker 2: mental shift of you thinking ahead of these problems and
Speaker 2: having an actual artifact and being more crisp with your
Speaker 2: thoughts and more crisp with how the rubber dying effect
Speaker 2: here is huge.
Speaker 3: Yes, exactly is going to help you down the line
Speaker 3: to just create better stuffware, just but just by proxy
Speaker 3: of you being able to think about it more and
Speaker 3: understand how does this actually work?
Speaker 2: Why is it the way that it is?
Speaker 3: What are the things that I should be thinking of
Speaker 3: that I'm not thinking about You know, we saw this
Speaker 3: happen in offshoring when when it got easier to offshore
Speaker 3: to low cost markets and you didn't get good results,
Speaker 3: and you learned to write better and better specifications and
Speaker 3: better and better project plans so that you were successful
Speaker 3: with the offshore developers.
Speaker 2: It turned out if you took those things on shore,
Speaker 2: you got more success to Yeah, shocker, right, Like.
Speaker 3: If you're better and specifying your requirements, you get better outputs.
Speaker 2: Wow, there is a reality check to this whole thing.
Speaker 2: But I really appreciate the idea of don't try. You're
Speaker 2: getting one hundred pcent is probably not worth it that
Speaker 2: getting And once you get into the eighties, you've had
Speaker 2: a win and now you can go do the rest.
Speaker 2: Here's the other thing, you know, because my instinct, I'm
Speaker 2: going back to code generation responses in the language you've used. Now,
Speaker 2: I feel like I'm dealing with the code generator, which
Speaker 2: clearly I am. As soon as I touch that code,
Speaker 2: I can't touch the code generator again. But that's not
Speaker 2: true than l L. No, You're you're collaborating again. You
Speaker 2: have an intern in your hands. M hmm. You're working
Speaker 2: together to write the code. Yeah, I'm you're going to
Speaker 2: resist the anthropomorphic terms there dem like I have a
Speaker 2: piece of software that's fair, that's fair.
Speaker 1: Yeah, but it sooner or later you're going to have
Speaker 1: to agree that the world wants to anthropomorphize these things.
Speaker 2: And I know the world wants it. It's just wrong.
Speaker 2: It's absolutely fair.
Speaker 3: Actually, Like I I can get totally behind that idea,
Speaker 3: like we should not entermorphize the AI because like, it's
Speaker 3: just an algorithm, it's a computer background.
Speaker 1: But it makes it easier for us to understand it
Speaker 1: when we put it in human terms, right if when
Speaker 1: we I.
Speaker 2: Think it makes it easier if a story execuse it inappropriately.
Speaker 3: Yes, yes, that I think it's like it gives it
Speaker 3: gives us the way of saying like, oh, it's like
Speaker 3: it's just it's just like a humans, Like, no, it's
Speaker 3: not like a human.
Speaker 2: It's not at all like a human.
Speaker 1: Right, But if I was going to say what was
Speaker 1: it thinking rather than well, what algorithmic sequences brought.
Speaker 2: It to the result that it did? Now true?
Speaker 1: Which would you rather let me ask you? Right, No, it's.
Speaker 2: True, it's true.
Speaker 3: I think there's there's a kind of shades of grade
Speaker 3: of this it's like where it lands. But I generally
Speaker 3: feel like, yeah, may're they're they're not humans.
Speaker 1: So they're not they're not. We do have to remember that,
Speaker 1: and so they don't have responsibility. They don't you.
Speaker 3: Know, they're not accountable right right, or like if it
Speaker 3: produces your like right, like we as software engineers, we
Speaker 3: all know things like the the RAQ twenty five, right,
Speaker 3: like the incident about the X ray machine. Remind us,
Speaker 3: So there's an incident about with an X ray machine
Speaker 3: where because of a software bug and no hardware interlock,
Speaker 3: it would actually, uh for cancer patients would have basically
Speaker 3: like deadly doses of radiation in under very certain conditions.
Speaker 3: I think this happened like in the eighties. It's litical.
Speaker 3: I think it's like the RAC twenty five. And so
Speaker 3: the idea there is like, right, like, if if you
Speaker 3: have an LM right software that does something dangerous like this,
Speaker 3: who's accountable for that?
Speaker 2: Yeah? Right right? It's not the AI, like you can't
Speaker 2: it isn't. It isn't the equipment yea, yeah.
Speaker 3: It's like, it's not the equipment, it's whoever pushed that software.
Speaker 3: It's the software developer, just like with any other scenario right,
Speaker 3: So to me, it's like, I think it's AI. Is
Speaker 3: that it's it's INTELLISENTI and steroids. Was that Is that
Speaker 3: a good frame to put it here? Like, yeah, that's
Speaker 3: that's good.
Speaker 1: I mean, because we don't answer promorphize and tell a sense,
Speaker 1: do we?
Speaker 2: You try not to? Well, well, you could, says I
Speaker 2: mean the number of times I'm cursing a visual studio.
Speaker 2: What is it thinking?
Speaker 1: What were you thinking? Right?
Speaker 3: But yeah, so I think it's like long story, longer
Speaker 3: to what we talked about. I think that's a definitely
Speaker 3: a mental shift. It's definitely one of those things where
Speaker 3: you you have to treat it essentially as an assistant
Speaker 3: program that allows you to write code faster, but it's
Speaker 3: still up to you to make sure that you you
Speaker 3: review this and you have input, and you can look
Speaker 3: and say this is garbage, that's not what I asked,
Speaker 3: or this test just returns true.
Speaker 2: That's not how you pass a.
Speaker 3: Test like this are supposed to work, right, So you
Speaker 3: your expertise is still valuable. And I think that that's
Speaker 3: what also gets lost in the conversation because folks get
Speaker 3: so excited.
Speaker 2: I'm just I'm trying to de sex you this not
Speaker 2: out of this down this idea that I have a
Speaker 2: re entrant code generator. Yeah, that makes me very happy
Speaker 2: because that's something we haven't able to do before. It
Speaker 2: used to be when you use code generators. Once you
Speaker 2: touch that one way, I never run the generator again. Yeah. Now,
Speaker 2: the idea that I could stick this code generator back
Speaker 2: at the code that i've also that it contributed to
Speaker 2: and I modified and do another iteration, that's a big deal.
Speaker 2: Like this is it's pretty cool.
Speaker 3: Yeah, yeah, exactly because I can come in for a
Speaker 3: specific component and say, okay, this chunk here doesn't quite
Speaker 3: look right. And what I will seen people do, and
Speaker 3: I think this is a super valuable thing, is once
Speaker 3: you started going through the motions of okay, I saw
Speaker 3: where it failed. I saw that it did not create
Speaker 3: this component the way that I wanted. Based on the
Speaker 3: conversation that you had in code that back into the
Speaker 3: spec right and say okay, now that we know this,
Speaker 3: can you put them back in the spectrum technical plan?
Speaker 3: So that way, again, if I come in down the
Speaker 3: line and say, hey, we're going to take on a
Speaker 3: rewrite of the system, can I recreate the behavior that
Speaker 3: I had based on the learnings that I had and
Speaker 3: the iteration that I had in this new format. And
Speaker 3: this is where the speck comes in, because then you
Speaker 3: can say, oh, yeah, totally, I've encoded.
Speaker 2: All the larynx. This is also things that we hated
Speaker 2: doing as developers. Right, It's like, Yo, the spec is wrong,
Speaker 2: but nobody's actually gonna go fix the spec.
Speaker 3: But now oh no, zero people. Now you have a
Speaker 3: tool that you can demand it fix the spec. Yeah, exactly,
Speaker 3: Just do yourself a favor and make sure you check
Speaker 3: it in again. I really appreciate your thinking it will
Speaker 3: save you because it'll mangle your spec.
Speaker 2: Mm hmmmmmmm hmm. Yeah.
Speaker 3: I mean, and you're absolutely right in the sense like
Speaker 3: when I remember, like when I started my career as
Speaker 3: a product manager at Microsoft, you'd write a spec, you'd
Speaker 3: review it on a bunch of meetings, and then once
Speaker 3: a dev the moment the code on the starboard.
Speaker 2: Nobody ever touches that over.
Speaker 3: It's like and then even if you realize like, oh yeah,
Speaker 3: we forgot about like mentioning this, Hey dev, can you
Speaker 3: go fix this thing? Because we had this idea and
Speaker 3: they're like, oh sure, yeah, let's go change it. Like
Speaker 3: nobody goes to the doc and then six months later
Speaker 3: when you look at the doc and be like, product
Speaker 3: doesn't work this way.
Speaker 2: Well, this is how no new people can into the
Speaker 2: project as they start with the document.
Speaker 3: It's wrong exactly, and you and all those documents are
Speaker 3: wrong and they're all all out of date.
Speaker 2: We're trying to avoid that. All right, let's get weirder.
Speaker 2: Let's start taking after we finished making the code. Then
Speaker 2: you demand another tool generate a specification from the code
Speaker 2: you can see and compare against it.
Speaker 3: That's actually a thing, you know, and you know what.
Speaker 3: Where this is super helpful what we refer to as
Speaker 3: brownfield projects because where a lot of the spectrum of
Speaker 3: development stuff kind of falls over a lot of scenarios.
Speaker 3: Is all this is optimized for net new Like I'm
Speaker 3: starting from zero to one, I have nothing, Go get
Speaker 3: me something. But what if I already have a code
Speaker 3: base that is which, let's face it, mostly we do
Speaker 3: tens of thousands of Yeah, there's like can you do this?
Speaker 3: And this is where that reverse process is super helpful.
Speaker 3: Like I want you to write me a spec based
Speaker 3: on how my authorization library is working, and it's like, okay,
Speaker 3: let me go and look at the library that create this,
Speaker 3: and they're like, Okay, now that we have this context,
Speaker 3: can we now add a feature that changes how my
Speaker 3: oft flow works context it's all about content.
Speaker 2: Sure, No, this is a whole there's a whole other
Speaker 2: show here about Brownfield with lllms mm hmm. Just see
Speaker 2: I you know, because it's a great problem space. Right.
Speaker 2: Let's say so we have a ton of applications inside
Speaker 2: of organizations where the original dev team's long gone. Oddly enough,
Speaker 2: the spec is incorrect, but we need new features. Yeah,
Speaker 2: and you have a new team that's trying to take
Speaker 2: that code on. So the idea that you could point
Speaker 2: in ll at it first to generate a correct specification
Speaker 2: in theory, like, you need to validate that. So I
Speaker 2: probably want to iterate on that a few times and
Speaker 2: then start to build a plan around how you would
Speaker 2: make the change you want.
Speaker 1: Well, you could certainly build real documentation of your product
Speaker 1: by just sicken clawed copilot agent or whatever on it
Speaker 1: and it'll do that. I've done it with Jeff Fritz
Speaker 1: encoded with AI episode one and it created a pretty
Speaker 1: good user manual. So I know that's not a spec
Speaker 1: that's not an internal spec but it certainly is of
Speaker 1: that same idea that you take something that it already
Speaker 1: exists and then generate some documentation around it.
Speaker 3: Have you guys heard of this project called deep wiki
Speaker 3: deep wiki, deep wiki, deep wiki that sounds familiar to me.
Speaker 1: So has it been around a long time?
Speaker 3: No, it hasn't, but it's from the I believe it's
Speaker 3: some of the same people that wrote Devin, like the
Speaker 3: Coding Agent. So deep wiki is this place where you
Speaker 3: can actually come in. It's a documentation generator. Basically, it's
Speaker 3: an AI based documentation generator. You can come in and
Speaker 3: you can look at different repositories that already been documented
Speaker 3: or maybe even add your own, but you can just
Speaker 3: plug in the URL and then it's going to generate
Speaker 3: the docs. And to me, the fascinating part about this
Speaker 3: is just how freaking good it is at looking at
Speaker 3: the code base and like, oh vs code. Sure, let
Speaker 3: me look at the architecture and here's a renderer process,
Speaker 3: here's the main process, here's the extension host process. How
Speaker 3: they interact with each other's like none of this stuff
Speaker 3: is actually like encoded in some like there's a viscode
Speaker 3: architecture doc but like it infers it for the code,
Speaker 3: it points you to the lines of code, it generates
Speaker 3: mermaid charts, like it's a fascinating project. It's a deepwiki
Speaker 3: dot com.
Speaker 1: Does it use playwright to get screen captures of the
Speaker 1: application running?
Speaker 3: You can plug it in with any MCP servers, including Playwright.
Speaker 1: So that's what we did with with Visual Studio code
Speaker 1: and the agent. We told it to use the Playwright
Speaker 1: MCP to run the app and actually take screenshots and
Speaker 1: put it in the documentation, which is very, very helpful.
Speaker 2: Yeah.
Speaker 3: Yeah, Playwright MCP is one of my favorite tools hands down.
Speaker 2: Yeah.
Speaker 3: That's unbelievable, is just how good it is about both testing,
Speaker 3: providing screenshots and actually one of the validation steps that
Speaker 3: I've experimented for spect driven by the way it's like
Speaker 3: when it creates the UI, it uses player MCP to
Speaker 3: go and say, are there any components that overlap with
Speaker 3: each other or the UI is funky? And then if not,
Speaker 3: go and fix it.
Speaker 1: That's so cool.
Speaker 2: Wow.
Speaker 3: Right, So you're wiring these things together and we're back
Speaker 3: to the whole idea of like what's the role to
Speaker 3: develop in this? And this is like you are now
Speaker 3: the orchestrator of this fleet of software agents that do
Speaker 3: things for you? How do you make sure that app?
Speaker 2: Yeah? And you see, like I think about the large
Speaker 2: scale problems inside of big organizations right now. It's like
Speaker 2: they got a ton of asp down web form apps
Speaker 2: out there. Nobody wants to work on them anymore. Yeah,
Speaker 2: of course they Everybody wants a mobile client for a
Speaker 2: bunch of them, which is almost impossible, and rewriting them
Speaker 2: takes time and money. Yeah, And so the idea that
Speaker 2: I could fire up these llms use stuff like playwright
Speaker 2: to screenshot the whole app and then fire it through
Speaker 2: a generator to make it other version of the app.
Speaker 2: Now me, my twisted mind, what's my automatic reaction? It's like,
Speaker 2: let's make photocopies of photocopies. So I'm going to take
Speaker 2: this app, I'm going to generate a spec. Then I'm
Speaker 2: going to generate an app from the spec. Then I'm
Speaker 2: going to generate a spec from that version of the app.
Speaker 2: I don't see where we get to, because I bet
Speaker 2: you're going to hit a floor, yeah, of functionality at
Speaker 2: some point right where, because the compiler always has a say,
Speaker 2: because the app ultimately has a set of core functionality.
Speaker 2: Like I wonder if you'd end up with the most
Speaker 2: distilled version of an app if you did a bunch
Speaker 2: of iterations like that. Probably probably right.
Speaker 3: But also like we know that software there's more to
Speaker 3: building software than just carbon copy of things. Yes, right,
Speaker 3: And this is where like I see people posting on
Speaker 3: social media as like, oh, with the help of LM,
Speaker 3: I recreated docuside in three days. It's like, well, sure,
Speaker 3: pretty sure you didn't like yeah, but like it's you
Speaker 3: got to realize that there's more docusine than like just
Speaker 3: the uy of docusine, right, And that's part of it,
Speaker 3: is like we're really starting to just still into what
Speaker 3: are the important bits of software and what's the thing
Speaker 3: that should have our primary attention.
Speaker 1: Didn't some guy just recently tell uh and chat gipt
Speaker 1: or whatever to rebuild and recreate Kubernetes anthropic. It was anthropic,
Speaker 1: He said, rebuild me Kubernetes in Rust or something like that.
Speaker 1: And it's spent so many tokens that it costs anthropic
Speaker 1: four hundred thousand dollars and he only paid his two
Speaker 1: hundred dollars for the month.
Speaker 3: Yeah, but the question is did it did it recreate Kubernetes.
Speaker 1: Well, it spent four hundred thousand dollars worth of token.
Speaker 2: So it did something maybe nothing, that's in the end.
Speaker 2: What did that four hundred thousand dollars do but heat
Speaker 2: up a bunch of rocks? Yeah right, Yeah, the sand
Speaker 2: is working hard. Yes, made the rocks warm today.
Speaker 3: But I was genuinely curious, Like Carl, you were so
Speaker 3: excited about it, and I was like, but did it
Speaker 3: actually work? It's like that that that meme about like
Speaker 3: I rewrote my app in like one day, this massive
Speaker 3: enterprise scale things, like none of it worked, but did
Speaker 3: sure look pretty?
Speaker 2: Yeah? It was just another version of AI slop. But
Speaker 2: you know, now you're pressing us the next issue here,
Speaker 2: which is is this cost effective in the end, Like
Speaker 2: when we eventually have to pay the real costs because
Speaker 2: we know we're not so far. I mean we actually
Speaker 2: have to pay the real cost for the compute, for
Speaker 2: the tokens and so forth. Like now we're gonna have
Speaker 2: another layer on running this tool where it's going to
Speaker 2: now assess the token. Let's do an estimate before we
Speaker 2: run this. You know, no different than I do when
Speaker 2: I start provisioning apps into Azure we understand how much
Speaker 2: infrastructure we need to run, and I can throw at
Speaker 2: the CFO it's going to be this much a month. Yeah,
Speaker 2: you know, to operate this like that. Those are the
Speaker 2: trade offs are going to make, for sure, and it
Speaker 2: will get more efficient to a degree that these are
Speaker 2: going to be the trades, Yeah, for sure.
Speaker 3: And I see a world too where we can use them,
Speaker 3: maybe even a combination of things of what is actually
Speaker 3: net new stuff that needs to be delegated to a
Speaker 3: powerful generalized model versus something that can run locally on
Speaker 3: my machine. Call right, It's like, oh, this is a
Speaker 3: model that's trained specifically on ASB dot net core. It
Speaker 3: is excellent for ASP dot net core and nothing else.
Speaker 3: Can I potentially use that to go and write me
Speaker 3: the ASP dot net core code?
Speaker 2: Sure? Right. I also wonder about training model specific to
Speaker 2: an application, Like You've got a mature piece of software
Speaker 2: that's an awful lot of knowledge about what the software does,
Speaker 2: and so if I can have that run in a
Speaker 2: local model and just you know, let's not go out
Speaker 2: of scope here, I just want to add these features
Speaker 2: to it. So and yeah, the idea that these monster
Speaker 2: models are the only way to do things sistantly not true, right, right?
Speaker 3: And John and I were actually talking about John John
Speaker 3: Lamb again our good friend, about this concept of a
Speaker 3: prompt compiler, and the idea here is that with a
Speaker 3: lot of the contexts that we're passing to models, there's
Speaker 3: this context overload. There's just too much, like Richard used
Speaker 3: the concept like the buffer overflows like that, that's like
Speaker 3: we're trying to prevent. And it's like, and if I'm
Speaker 3: building an ASP do a net application with a specific
Speaker 3: like API structure, how do I encode just the relevant
Speaker 3: context from the spect it? So I don't just give
Speaker 3: it like, oh, here's all the front end pieces and
Speaker 3: everything else that you need to consider. But by the way,
Speaker 3: just build the apia like, right, can I just select
Speaker 3: the pieces that it needs for my task?
Speaker 2: Yeah? And maybe there is again, like a either a
Speaker 2: local model or something else that pre emptively can select
Speaker 2: these things and say okay, you only need this to
Speaker 2: execute this task and nothing else, and that drives some
Speaker 2: of the efficiency. So I think definitely we're we're right
Speaker 2: now in the space where all of this is like
Speaker 2: it feels like free money, right, Oh, four hundred thousand
Speaker 2: dollars of Kubernetes tokens for two hundred dollars a month, Like, yeah, sure,
Speaker 2: we're in the bubble of you know, the first wave
Speaker 2: of this stuff right right, This bubble will end, but
Speaker 2: you know, just no different than the dot com boom
Speaker 2: and the end of that, you still have an Internet afterwards,
Speaker 2: Like there will these tools will still exist, but we'll
Speaker 2: start to rationalize it. I'm real happy to be talking
Speaker 2: about the post bubble rationalizations.
Speaker 1: Yeah.
Speaker 3: Absolutely, yeah, I think this is where the whole conversation
Speaker 3: about the bubble misses the point that the utility of
Speaker 3: this is undeniable. Yes, Like I'm looking at the models
Speaker 3: that we have today, like from Anthropic, from open Ai,
Speaker 3: from like, and think about it, like if if the
Speaker 3: evolution of those model stops today, like if after two
Speaker 3: the refoard of the show nothing else ever gets released.
Speaker 3: There is still a ton of value behind them and
Speaker 3: building suffware and being able to like reduce the toil. Right,
Speaker 3: nothing changes, it does not improve at all, and there's
Speaker 3: still a lot of value in this.
Speaker 2: Now.
Speaker 3: Is there a lot of hype for things that are
Speaker 3: like chat GBT wrappers around in the wild, like all
Speaker 3: these like random startups Like absolutely, yeah, But the utility
Speaker 3: for the core underlying models and the capabilities that they
Speaker 3: offer for software development was like again to me, is undeniable.
Speaker 2: Yeah, I'm with you then, and I'm just you know,
Speaker 2: we can still get better, but yeah, it's certainly worthwhile,
Speaker 2: and I appreciate thing you're building, these kinds of tools
Speaker 2: to help us rein in the sort of randomness and
Speaker 2: start to think more coherently about what modern dev practices
Speaker 2: with these cod generators are going to look like going forward.
Speaker 1: Absolutely well, Dan, thank you very much. It's been great
Speaker 1: talking to you. Wow, blowing our minds over here.
Speaker 2: Thank you for having me. Yeah, my dream came true.
Speaker 2: I was in dot net rocks.
Speaker 1: That's great.
Speaker 2: There you go. And and we went for a ride too, friend,
Speaker 2: going to call that meaty goodness.
Speaker 1: Yet goodness absolutely all right, Thanks again to Den Delamarski,
Speaker 1: and we'll talk to you next time, dear listener on
Speaker 1: dot net rocks. Dot net Rocks is brought to you
Speaker 1: by Franklin's Net and produced by Pop Studios, a full
Speaker 1: service audio, video and post production facility located physically in
Speaker 1: New London, Connecticut, and of course in the cloud online
Speaker 1: at pwop dot com.
Speaker 2: Visit our website at d.
Speaker 1: O T N E t R O c k S
Speaker 1: dot com for RSS feeds, downloads, mobile apps, comments, and
Speaker 1: access to the full archives going back to show number one,
Speaker 1: recorded September two thousand and two. And make sure you
Speaker 1: check out our sponsors. They keep us in business. Now,
Speaker 1: go write some code. See you next time. You got
Speaker 1: your middle vans. This is home, then my Texes