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 month.
Speaker 1: We'll get you that and a special dot net rocks
Speaker 1: patron mug. Sign up now at Patreon dot dot NetRocks
Speaker 1: dot com. Hey guess what might it's dot ad rocks
Speaker 1: episode nineteen seventy nine. And I said that with an
Speaker 1: Australian accent because I'm Carl Franklin here in Connecticut.
Speaker 2: And I'm Richard Campbell, and I'm down in Queensland, Australia.
Speaker 1: So and our guest is in Australia as well, So
Speaker 1: it's gonna be a down Under show today.
Speaker 2: Say we got a Southern Hemisphere bias?
Speaker 1: Yeah, all right, Uh so let's talk a bit out
Speaker 1: the show number. It's nineteen seventy nine, So what happened
Speaker 1: in that year?
Speaker 2: Well, let me just oh a fair bit. Yeah, a
Speaker 2: lot of things. You perusing the list, I've got a
Speaker 2: lot of space and a lot, well a little bit
Speaker 2: of space, a lot of science at a huge amount
Speaker 2: of compute, Well.
Speaker 1: A lot happened in Iran, China, and the Soviet Union
Speaker 1: in Afghanistan. Three Mile Island happened, the Iran hostage crisis,
Speaker 1: the Iranian Revolution, Soviet invasion of Afghanistan.
Speaker 2: That didn't end well, Nope for them, for anyone.
Speaker 1: US China relations. United States severed diplomatic ties with Taiwan,
Speaker 1: established full diplomatic relations with the People's Republic of China. Oh,
Speaker 1: let's see some The music for UNSEF concert was kind
Speaker 1: of important.
Speaker 2: We're heading into the Live aid era, right, Yeah, that's coming.
Speaker 1: The Dukes of Hazzard premiered on January twenty sixth I
Speaker 1: remember my brother and Nice to drive my mother crazy,
Speaker 1: all the car chases and stuff. She would like come
Speaker 1: in and turn the television off. It just drove her
Speaker 1: up the wall. I think that was the point of
Speaker 1: the Dukes, that hazard, wasn't it.
Speaker 2: Driver.
Speaker 1: Yeah, you'll talk about space. So an anti nuclear demonstration
Speaker 1: happened on September twenty third. Nearly two hundred thousand people
Speaker 1: protested nuclear power in New York City, or just nuclear
Speaker 1: in general. But tell us about space and compute what happened.
Speaker 2: Ninety seventy nine is the year that the Columbia Shuttle
Speaker 2: is delivered to Kennedy Space Center. It's still two years
Speaker 2: away from flying, but they it has now been built.
Speaker 2: Enterprise is being retired as a museum article after finishing
Speaker 2: its testing. It was too expensive to refit it into
Speaker 2: being a spacecraft, although that had been the original attension.
Speaker 2: Instead they'll use a different test article, which will become Challenger. Yeah,
Speaker 2: but Columbia's now assembled, bunch of changes. It still has problems.
Speaker 2: It's the heaviest of the shuttles that will fly, and
Speaker 2: so it's limited by certain aspects. But it's still you know,
Speaker 2: we're making progress, although a couple of years away from flying.
Speaker 2: Voyager one and two make their fly bys of Jupiter
Speaker 2: in nineteen seventy nine, and Pioneer eleven does the very
Speaker 2: first flyby of Saturn. Wow. So those are all new things.
Speaker 2: And Skylab in July nineteen seventy nine now originally been
Speaker 2: launched in nineteen seventy three as part of the Apollo
Speaker 2: Missions projects. It was only intended for one hundred and
Speaker 2: forty days of use, okay, and so this is already
Speaker 2: six years later. They actually had one hundred and seventy
Speaker 2: two days of use over three missions they extended it.
Speaker 2: It had plenty of problems they and it had been
Speaker 2: left empty, although prepped for someone else to visit it.
Speaker 2: They had a welcome kit, the door been left unlocked,
Speaker 2: all that sort of thing. And they had thought that
Speaker 2: they would be able to get the shutle ready in
Speaker 2: time to keep an a do over. In fact, they
Speaker 2: figured it would stay it over till at least the
Speaker 2: early eighties, but there was a solar maximum going on
Speaker 2: then they and the additional solariation expands the atmosphere to
Speaker 2: the dragon Skylab was greater than expected. Also, there was
Speaker 2: a lot broken. You know, they used control moment gyros
Speaker 2: for directional stabilization on Skylab, and at that point one
Speaker 2: had already failed and another one was failing, and there
Speaker 2: had been no plan to make them serviceable, so there
Speaker 2: was really no way to fix them. They would literally
Speaker 2: have to deploy a new set of gyros on some
Speaker 2: kind of attachment to the space station. So there's going
Speaker 2: to get this point was like, you could just build
Speaker 2: another space station.
Speaker 1: So Skylab was manned. At one point.
Speaker 2: My Skylab had three mission sent to it, yes, okay, one, two,
Speaker 2: and three, and we talked about those you know, in
Speaker 2: the past few shows when when those happened. But now
Speaker 2: it had been empty for several years, the atmosphere had expanded,
Speaker 2: so it was reintercasterment and expected, and it came down
Speaker 2: over the Indian Ocean and Australia, and.
Speaker 1: It lasted a lot longer than my and my brother's
Speaker 1: snow sculpture referring to the blizzard of seventy eight that
Speaker 1: we talked about last week's.
Speaker 2: In the previous episode. One other science one before we
Speaker 2: get into the computing stuff, because the community stuff so extensive,
Speaker 2: is nineteen seventy nine is the year that we first
Speaker 2: found hydro thermal events. So this was the Riviera submersible
Speaker 2: experiments off the southern south of Baja California, about eighty
Speaker 2: five hundred feet of water with you remember the Alvin
Speaker 2: submersible woods whole. So they were looking around for underwater
Speaker 2: volcanic activity and came across these things we now know
Speaker 2: as black smokers. So these were jets of black material
Speaker 2: coming out of the ocean floor and the extremely hot
Speaker 2: three hundred eighty degrees celsius like seven hundred degrees fahrenheit
Speaker 2: in the deep dark abyssal parts of the ocean. And
Speaker 2: they're surrounded by life. There are tube worms and kinds
Speaker 2: of crabs and all sorts of things that are feeding
Speaker 2: off of the heat and the minerals that are pouring
Speaker 2: out of these black smokers. And it was a revolution
Speaker 2: in thinking around where life could emerge. It was this
Speaker 2: belief that you needed to be a certain distance away
Speaker 2: from the sun and have pad with water and all
Speaker 2: these things. And here was this completely dark place that
Speaker 2: had life emerging around it. And it speaks to the
Speaker 2: idea that we talk about these days about perhaps the
Speaker 2: Europa in orbit around Jupiter, with enough heat, could possibly
Speaker 2: have life under that ocean, underneath the ice cap that
Speaker 2: is Europa. So that all begins in seventy nine with
Speaker 2: its discovery. Nobody thought they were there. This was a
Speaker 2: fine So is the important moment.
Speaker 1: You know what I remember fondly about this period National
Speaker 1: Geographic magazine. There was some great photos and especially from
Speaker 1: those space missions, and just amazing, amazing stuff. And as
Speaker 1: a kid, I was just wrapped by a National Geographic
Speaker 1: My mother recently passed and we're cleaning out her attic,
Speaker 1: and it turns out there they saved all their National
Speaker 1: Geographic magazines going back to the thirties.
Speaker 2: Wow, that's crazy. Yes, So so here's a weird one
Speaker 2: about those black smokers. So you'll share this nationally graphic magazine.
Speaker 2: Those two birds are brightly colored. They're white and red.
Speaker 2: It's like it's dark. Why these things have colors? Yeah,
Speaker 2: I did do, all right. Let's talk about computers. Nineteen
Speaker 2: seventy nine the release of the Atari model four hundred
Speaker 2: and eight hundred, also the TI ninety nine that is
Speaker 2: a scientific calculator. No, no, t I nine nine was a
Speaker 2: computer made by talking instruments. Yeah no, I mean games
Speaker 2: for it back in the day. The Motor sixty eight
Speaker 2: thousand processor is released, and a couple of online things.
Speaker 2: The origin of CompuServe. Oh yeah, I love the CompuServe.
Speaker 2: So originally a company a subsidiary of Golden United Life
Speaker 2: Insurance out of Columbus, Ohio, which they actually started in
Speaker 2: nineteen sixty nine renting time on PDP tens, but in
Speaker 2: seventy nine they added dial up so you could island.
Speaker 2: It was acually internal customers primarily, but they started opening
Speaker 2: up to consumers and it didn't go particularly well. The
Speaker 2: company gets acquired in nineteen eighty by H and R.
Speaker 2: Block for twenty five million dollars. They only have they
Speaker 2: have less than a thousand users at that time, but
Speaker 2: by ninet eighty four it'll be one hundred and ten thousand.
Speaker 1: Wasn't they owned by Sears at one point.
Speaker 2: Yeah, it went through many hands before it end up
Speaker 2: at AOL.
Speaker 1: But I just remember the snap packs which had you know,
Speaker 1: a code and it had the password explore plus world,
Speaker 1: right you remember that?
Speaker 2: Yeah? Yeah, and so much fun. This is also just
Speaker 2: beginning of modes in general. So this is when I
Speaker 2: first got a motem as well. And for better or worse,
Speaker 2: like the Vancouver area had a ton of BBS's, it
Speaker 2: was very early on. It just ways for geeks to
Speaker 2: connect to each other. It's also the first computer worm
Speaker 2: was built by John Shock and John Hopp at Xerox Park,
Speaker 2: largely by accident of propagating piece of software across networks.
Speaker 2: And so there was your first computer worm. But by far,
Speaker 2: without a doubt, the most important thing for computing in
Speaker 2: nineteen seventy nine VisiCalc. Van Bricklin, the precursor to all
Speaker 2: the spreadsheets. Yeah, and the first real you know they
Speaker 2: at one point it was personal computers are described as
Speaker 2: an accessory for Visical. Right, this was the point of
Speaker 2: the personal computer first released in seventy nine on the
Speaker 2: Apple two and IBM sites in their history of the
Speaker 2: IBM PC that that product shipping made them accelerate the
Speaker 2: development of the IBM PC to get a version of
Speaker 2: Hysical Chronic. Now, the ibm PC made sense and they
Speaker 2: got it out in nineteen eighty. The story of VISICALCU
Speaker 2: is also one of mush drama too, because a former
Speaker 2: Visit Corp employee, Michiga Porl leaves and forms the Lotus
Speaker 2: Corporation Lotus one two three, create Lotus one two three
Speaker 2: and then the Electronic Frontier Foundation. Yeah, that was part
Speaker 2: of that, and that's nineteen eighty three, and what was
Speaker 2: the claim to fame for Lotus one two to three
Speaker 2: totally optimized for the IBM PC, and that of course
Speaker 2: will later lead to multi Plan by Microsoft, which will
Speaker 2: eventually become Excel. Yeah.
Speaker 1: I remember my father bought a Tiers eight Model four
Speaker 1: and that's kind of my first foray into computers, and
Speaker 1: he bought it for Visical.
Speaker 2: YEP. Visical was villefort because.
Speaker 1: He did his taxes and bills and everything on Visical.
Speaker 1: Can I remember once a month and getting that thing
Speaker 1: out and putting it on the dining room table and
Speaker 1: we didn't see him for a few hours.
Speaker 2: You know this is really up until now, personal computers
Speaker 2: have been toys. Yeah right, this is the product that
Speaker 2: made it actually a business product and important and changed everything. Yeah.
Speaker 1: Still a critical tool in the arsenal today.
Speaker 2: Oh yeah, spreadsheets, spreadsheets. Whole companies built around spreadsheets without
Speaker 2: a doubt.
Speaker 1: You have a great joke, don't you, Richard? How about
Speaker 1: you and your wife in spreadsheet?
Speaker 2: Oh but yeah, she's the industrial engineer. I'm a programmer.
Speaker 2: When we argue, it involves a spreadsheet. Yeah, and it's
Speaker 2: only because that happened, right. We were trying to we
Speaker 2: were arguing about how to redo a deck, and in
Speaker 2: the end resolved the argument with a spreadsheet. I'm like,
Speaker 2: this is who we are. It's great, this is reality
Speaker 2: for us. Awesome? So is that it? That's it? All right?
Speaker 1: Well with that, let's roll the crazy music for better
Speaker 1: no framework?
Speaker 2: Man, what do you got?
Speaker 3: Well?
Speaker 1: I realized when we were recording last week's show that
Speaker 1: this might have been a better, better no framework for that.
Speaker 1: But tech Nitium Software has a DNS server written in
Speaker 1: C sharp that's open source and their tagline is self
Speaker 1: host a DNS server for privacy and security, block ads
Speaker 1: in malware at the DNS level for your entire network,
Speaker 1: and technitium I don't know how you say it, but
Speaker 1: tech nit i um technitium probably technician who knows. DNS
Speaker 1: server is an open source, authoritative as well as recursive
Speaker 1: DNS server that can be used for self hosting a
Speaker 1: DNS server for privacy and security. It works out of
Speaker 1: the box with no or minimal configuration and provides a
Speaker 1: user friendly web console accessible using any modern web browser.
Speaker 1: Cool how about that?
Speaker 2: Yeah? Yeah, interesting? And we always argument of like what
Speaker 2: DNA server should you run, because you know, there's plenty
Speaker 2: of free ones out there, but this is a free
Speaker 2: one too, guys. It's just open source, so good stuff.
Speaker 1: But if you think about it, like your basic Windows
Speaker 1: land has everything except the DNS server, and back in
Speaker 1: the day we were editing host files and putting IP
Speaker 1: addresses and names in there, and then you had some
Speaker 1: other protocols on top of that that worked with anything
Speaker 1: but TCP IP, right, So you know, this is kind
Speaker 1: of a it's kind of an important thing. If you
Speaker 1: don't want to go outside of your network for DNS. Yeah,
Speaker 1: there you go. If you're gonna know if you need it. Yeah,
Speaker 1: we're not going to try to sell.
Speaker 2: You on No. And without a doubt. It's like, yeah,
Speaker 2: it's one of those things. Just learned to configure it correctly.
Speaker 2: It's important, right, you know that whole running joke of
Speaker 2: it could be DNS, it's always DNS. Definitely, definitely DNS.
Speaker 2: It's impossible if it's DNS. It could be DNS. It's
Speaker 2: dns NS. Okay, Well that's what I got today. Richard,
Speaker 2: who's talking to us awesome, grabbed a comment off show
Speaker 2: nineteen seventy four, the one we did with Don Delamarski
Speaker 2: when we talked about Gethub spec kit. Yeah, and they've
Speaker 2: said a huge conversation, lots going down there. And I've
Speaker 2: read comments from this show before, and I'm gonna read
Speaker 2: oother one. This one's from Richard Cox who said, I
Speaker 2: just finished listening to this. I think there's one part
Speaker 2: that your guests got wrong. If m inference stopped, work
Speaker 2: stops thanks to the bubble bursting. Talking about the AI bubble,
Speaker 2: the models will start to degrade as new input like
Speaker 2: code using new versions of tools will not be included.
Speaker 2: Then the output will not use those new capabilities. IE.
Speaker 2: Over time, as the rest of the world moves forwards,
Speaker 2: the lms will increasingly be stuck in the past. Yeah,
Speaker 2: I mean, I get the sentiment that, you know, when
Speaker 2: the bubble bursts, a certain amount of work's going to
Speaker 2: go away. Would argue there's too many models. Now, I'm
Speaker 2: sure there'll be a few models, so they'll continue to
Speaker 2: go forward. But we're seeing such incredible overspending at the moment, right,
Speaker 2: It'll be interesting to see what happens. And modelbility is
Speaker 2: getting easier, and I would also argue less important, like
Speaker 2: in that sense that it's just going to be part
Speaker 2: of the flow. It'll be interesting to see what models
Speaker 2: emerge post bubble burst, right, and boy, there's lots of
Speaker 2: noises about the bubble versus these days. It's be interesting
Speaker 2: to see what happens. Oh, I know it, but fair point,
Speaker 2: it's all we're you know. The interesting thing about this
Speaker 2: is this software in some ways does degrade because the
Speaker 2: world keeps moving on and these things need to keep
Speaker 2: being regenerated and optimized. So Richard, thank you so much
Speaker 2: for your comment and a copy of music co Buy is
Speaker 2: on its way to you, and if you'd like a
Speaker 2: copy of music, go buy. I write a comment on
Speaker 2: the website at dot netrogs dot com or on the facebooks.
Speaker 2: We publish every show there and if you comment there
Speaker 2: and ever reading the show, we'll send your copy us
Speaker 2: to go buy.
Speaker 1: And of course needs to co by developed a while
Speaker 1: ago to provide music that's neither too boring or to
Speaker 1: distracting twenty five minutes track and there's now twenty three
Speaker 1: tracks and you can get it at Musicdoco by dot
Speaker 1: net and the entire collection in wave, flak and MP
Speaker 1: three formats. Okay, let's introduce Callum Simpson and he is
Speaker 1: a solution architect with fourteen years of software development experience
Speaker 1: as of this recording, and recently promoted VP of AI SSW,
Speaker 1: an enterprise consultancy based in Australia. Our friend Adam Cogan
Speaker 1: runs that he spends most of his time using AI
Speaker 1: to help deliver projects faster or building projects that use AI,
Speaker 1: and usually both. Despite being more productive than ever, he
Speaker 1: claims to have not written a complete line of code
Speaker 1: in over a year. He's also a product owner of
Speaker 1: SSW yak Shaver, an AI product. He'll tell us about today.
Speaker 3: Callum, thank you very much, Carl, and great to be here.
Speaker 2: Hey Richard, hey Man, great to have you. I was
Speaker 2: just down at SSW was part of their brainstorming day,
Speaker 2: so we had a chance to hang out.
Speaker 3: Okay, what did you think about it?
Speaker 2: Yeah, that's great. You know, it's not my first brainstorm.
Speaker 2: It's always fun. What I think you saw my clothes
Speaker 2: where I commented on you know, SSW is clearly all
Speaker 2: in on the AI space, and more than anything, what
Speaker 2: I saw was a bunch of different teams trying to
Speaker 2: find a way to rain the LMS in, to put
Speaker 2: parameters around them so that they focus on the things
Speaker 2: that are important productivity wise, whether that's around controlling architecture,
Speaker 2: deployment strategies you talked about. It was a group that
Speaker 2: we're talking about, I said, a UX frameworks that also
Speaker 2: the LMS would be pressed against. It's like this is
Speaker 2: how you build UI when you write, when you're building code,
Speaker 2: and I just thought it was really clear thinking from
Speaker 2: a group of really smart developers trying to get the
Speaker 2: most value from these tools.
Speaker 3: That's awesome, that's right. Yeah, we're trying to use it.
Speaker 3: I guess in every way we possibly can to get
Speaker 3: as much value out of it. So anything that can
Speaker 3: be sold by AI, we are trying to do it.
Speaker 2: Cool.
Speaker 1: I am so curious about yak shaver. First of all,
Speaker 1: what a funny name. Wow, And I think.
Speaker 2: Adam Cogan was involved. What do you think was going
Speaker 2: to happen?
Speaker 1: I'm sure, yeah, But but there's probably just a very
Speaker 1: small handful of people in this world who have ever
Speaker 1: attempted to shave a yak.
Speaker 2: Well, first you have to own a yak, don't you.
Speaker 1: Well, you know, necessarily you could be a yak shaver
Speaker 1: professional and go around from yak to yak to yak,
Speaker 1: you know. I mean they have obviously yaq milkers who
Speaker 1: make butter from yak, you know, cream or whatever.
Speaker 2: I've had yak milk in my coffee, in my tea.
Speaker 2: You know, it's the thing when you're in Nepal.
Speaker 3: I was gonna say it's potentially an alternative name, but
Speaker 3: the name itself came from I think there was a
Speaker 3: guy called Colin Vieri in the nineties, was a PhD
Speaker 3: student at MIT, and he got the name from an
Speaker 3: episode of The Ren and Stimpy Show. In that show,
Speaker 3: there was a yak shaving day, and basically yac shaving
Speaker 3: Day was sort of like this thing where where these
Speaker 3: people do this series of ridiculous tasks. And so the
Speaker 3: concept of yak shaving is sort of like when you
Speaker 3: start doing your main mission and then you realize, all, right,
Speaker 3: in order to achieve this mission, I need to go
Speaker 3: down a side quest, and then in order to do
Speaker 3: this side quest, I need to go and do another
Speaker 3: side quest first before I can come back and finish
Speaker 3: my first side quest to finish the main goal. And
Speaker 3: then you end up going down this like ten ten
Speaker 3: layers of causality, and whatever you're doing has absolutely nothing
Speaker 3: apparently to do with the original goal, but you have
Speaker 3: to do it unblock all your other things to get
Speaker 3: back up to the original task.
Speaker 1: And then every new layer you say to yourself, should
Speaker 1: I really be doing this exactly?
Speaker 3: What am I doing with my wife?
Speaker 2: Better use is of my time?
Speaker 3: Exactly? And so that's sort of what we're what we're
Speaker 3: trying to do with with Yakshava is cut out as
Speaker 3: much of that sort of busy work as possible. Now,
Speaker 3: obviously we are software developers, so most of the busy
Speaker 3: work we do has to do with or at least
Speaker 3: a large part of it has to do with putting
Speaker 3: items in backlogs. So that was the sort of original concept.
Speaker 3: Is you know, when you've got an issue, when you
Speaker 3: see a bug on a website, what do you have
Speaker 3: to do to actually report that bug to the right team?
Speaker 3: You know, you need to figure out which backlog does
Speaker 3: this PBI belonging, who are the stakeholders of this project,
Speaker 3: all that sort of stuff, And if you're on a
Speaker 3: call with a bunch of important people, you can either
Speaker 3: sort of skip over the problem because you know you've
Speaker 3: got better things to talk about, or you can tell everyone,
Speaker 3: all right, wait for five minutes, I need to go
Speaker 3: figure out all these details, put in the right backlog
Speaker 3: all that stuff first. So it is a tough problem.
Speaker 3: And obviously we don't want to skip over issues when
Speaker 3: we see them, but we also don't want to waste
Speaker 3: everyone's time. So that's that's sort of the whole idea
Speaker 3: of what we're trying to achieve or the problem we're
Speaker 3: trying to solve.
Speaker 1: So yak shaver does it? Is it sort of an
Speaker 1: agent kind of thing where you give it permission to
Speaker 1: do stuff, you know, like an MCP word and why
Speaker 1: wouldn't you just use an MCP.
Speaker 3: Yeah, good question. So when Yakshava first was conceptualized, it
Speaker 3: was sort of like, I think it's almost three years
Speaker 3: ago now, so back then we didn't have mcps. We
Speaker 3: had only just got you know, of custom GPTs that
Speaker 3: can do tool calls and stuff like that. But yeah,
Speaker 3: the idea of an MCP was still very far off.
Speaker 3: So back then the idea was instead of just you know,
Speaker 3: letting the agent do whatever it wants because obviously models
Speaker 3: weren't as reliable, then we would force it through a
Speaker 3: pipeline where there's a couple of branching points where it
Speaker 3: can either do this or do that. Is, are you
Speaker 3: trying to report a PBI or send an email for example,
Speaker 3: as one of those branches, and we make each.
Speaker 1: Of the all right, So it's not you're not giving
Speaker 1: a total agency, You're you're guiding it.
Speaker 3: As you say, exactly, That's that's sort of the the
Speaker 3: Yakshav V one you have mentioned MCP. We are currently
Speaker 3: developing a V two that will indeed use MCP servers.
Speaker 1: Okay, video context, what's that?
Speaker 2: Yeah, exactly.
Speaker 3: So the the main I think distinguishing factor between Yakshava
Speaker 3: and maybe firing up a you know, a MCP host
Speaker 3: like clawed Desktop and just saying hey, go create an
Speaker 3: item in the backlog is with Yakshava, we use a
Speaker 3: video as the input. So what you'll do is, you know,
Speaker 3: you'll share your screen and then you'll speak into your
Speaker 3: microphone and you'll say, hey, I'm just on this website.
Speaker 3: There's a URL, and here's the problem that I've got
Speaker 3: on the website, and then stop recording. And then basically
Speaker 3: the AI will obviously analyze the transcript, will analyze what
Speaker 3: it can from the screen that you shared, and then
Speaker 3: interesting go ahead and you figure out where to put
Speaker 3: it and how to format it all that stuff.
Speaker 1: So it's a little more powerful than something like play rate,
Speaker 1: which can go and navigate a site and all that stuff.
Speaker 1: But what if you're not using a website, What if
Speaker 1: you're using a piece of software. Right, yeah, exactly, use
Speaker 1: a video screen. I'm sure it's brilliant.
Speaker 3: That's right, And and some creative people have used it,
Speaker 3: even completely unrelated to software, which was an unexpected use case.
Speaker 3: You know, people like the building maintenance team when they find,
Speaker 3: you know, like an issue with the coffee machine, for example. Yeah,
Speaker 3: record a video of it and it gets filed off
Speaker 3: in the appropriate Obviously we're using back clothes for the
Speaker 3: office maintenance because Adam's the boss.
Speaker 2: But in the same way that people use GitHub for
Speaker 2: recipes and things like, it's useful to have a coherent
Speaker 2: documentation chain for any of these things.
Speaker 1: Well, chat GPT is good for that, and I find
Speaker 1: that the chat GPT is more consumer oriented that way,
Speaker 1: Like I can take a video when I could say, hey,
Speaker 1: what is what is this thing? You know, here's the
Speaker 1: here's a couple of pictures I snapped at my laptop,
Speaker 1: and it figures out what it is from that, here's
Speaker 1: the problem I'm having. I take a screen, you know,
Speaker 1: video of the screen, and it you know, can diagnose
Speaker 1: problems that way. So, but what I don't like about
Speaker 1: chat GPT is it doesn't understand the context of code
Speaker 1: right for example, and I don't want it to right Yeah.
Speaker 2: Yeah, yeah.
Speaker 3: So one of the I guess main things that we're
Speaker 3: doing with Yakshav, apart from the video input, is also
Speaker 3: the sort of organizational consistency. So what you'll do with
Speaker 3: Yakshav is set up you know, these are all my projects,
Speaker 3: These are all my people and who's associated with which project,
Speaker 3: and these are the formats that I like to have.
Speaker 3: My pbis created in all that sort of stuff, you'll
Speaker 3: sort of define it and that way everyone who uses
Speaker 3: it ends up with a consistent result, because obviously if
Speaker 3: everyone just used chat GPT and recorded a video of
Speaker 3: whatever with none of that consistency, then you're going to
Speaker 3: end up with a completely different thing.
Speaker 2: Every time. The world is full of abandoned video that's
Speaker 2: just sort of a normal thing, right, Like this is
Speaker 2: I think the important part in all of these things.
Speaker 2: And I'm not going to point out they actuap per se,
Speaker 2: but it's like what do you do with it after?
Speaker 2: Like where does it go? How does anybody ever look
Speaker 2: at it? Although you've always got the quality problem right,
Speaker 2: like we've been you see this recurring theme with AI
Speaker 2: generated text in general. People are writing their corporate emails
Speaker 2: using these tools and they're over long and over complicated,
Speaker 2: and some ways you're pushing the problem down the line,
Speaker 2: like right, yeah, well, I guess this is the challenge
Speaker 2: with anything related to these AI tools is like how
Speaker 2: do you make sure the thing you're making is concise?
Speaker 2: That the next person down the line isn't being dumped
Speaker 2: with a lot of unnecessary work.
Speaker 3: Yeah, well, I'm glad you mentioned that actually, because one
Speaker 3: of the other really cool things about yakshaber is not
Speaker 3: only does it generate the PBI, but it also puts
Speaker 3: the link to the video that you recorded on the PBI.
Speaker 3: So what it means is that the developer who picks
Speaker 3: up that issue and works on it, they, if they want,
Speaker 3: can just ignore all the AI generated PBI text and
Speaker 3: just watch the video of the user explaining the problem
Speaker 3: and what do you mean when you see PBI backlog items?
Speaker 3: So that's basically the of the bug. So if we've
Speaker 3: got a bug on a website, we've recorded a video
Speaker 3: showing that bug, and then the developer who picks up
Speaker 3: that that issue to fix can watch the video.
Speaker 1: That's very Adam Cogan. He used to and maybe he
Speaker 1: still does. But when we had issues with our website,
Speaker 1: we would get emails from Adam that had screenshots that
Speaker 1: were annotated with you know, things circled and whatever, and
Speaker 1: you know this should be that, and that should be this,
Speaker 1: and yeah he's always been that way.
Speaker 3: Yeah, yeah, yeah, But often there's heaps of details in
Speaker 3: the video that has an extra being transcribed in the text, right,
Speaker 3: and just being able to watch the video is it
Speaker 3: makes it so much easier because you don't have to
Speaker 3: go back to the original reporter and say, hey, what
Speaker 3: are your reproduction steps? So you know all that sort
Speaker 3: of stuff. You can just watch the video.
Speaker 2: Yeah, anytime you can avoid having to go struggle with
Speaker 2: a reproduction is good. It's all about capturing that. But
Speaker 2: it's interesting to think about this from a workflow perspective
Speaker 2: of what's the next thing We're trying to avoid shave
Speaker 2: in the act here? Right? So are these just distraction
Speaker 2: items from a main thing? Because we also talked about
Speaker 2: the fact that there's many little things you need to
Speaker 2: do before you can get on with the main thing,
Speaker 2: right right, So I guess it's some of this just
Speaker 2: getting harnessing more people into the workflow so when they
Speaker 2: get those things done, you can move forward.
Speaker 1: I'm curious about video transcription. I know that there are
Speaker 1: tools out there that do it, but they're kind of
Speaker 1: the transcription is usually integrated into those things, right, Like
Speaker 1: there's we use camtesa a little bit here, and I
Speaker 1: have maybe an older version.
Speaker 2: I don't know.
Speaker 1: If the newer versions do trans but transcription rather, but
Speaker 1: that is a huge thing for me, so if I
Speaker 1: have meetings, I know that Zoom can generate transcriptions, but
Speaker 1: just it would be really easy to to have a
Speaker 1: desktop application though. You could just drop a video into
Speaker 1: it and it could transcribe the video. Yeah, for sure,
Speaker 1: it seems like a simple thing. But then I could
Speaker 1: look it up. I could look up what we're we
Speaker 1: talking about.
Speaker 3: You know that's true, And I mean that sounds like
Speaker 3: an interesting future feature that weak we can backlog. Maybe
Speaker 3: we could actuate it right now and you your details
Speaker 3: about it will form the video, and then the developer
Speaker 3: who picks it up, we'll have all the context of
Speaker 3: why you wanted it, so that.
Speaker 2: Yeah, I like it. All right, take a break?
Speaker 1: Yeah, all right, Well this seems like a good place
Speaker 1: to take a break, so we'll be right back after
Speaker 1: these very important messages. Did you know you can easily
Speaker 1: migrate asp net web apps to Windows containers on Aws.
Speaker 1: Use the app to Container tool to containerize your iis
Speaker 1: websites and deploy to AWS managed container services with or
Speaker 1: without Kubernetes. Find out more about app to Container at
Speaker 1: aws dot Amazon dot com. Slash dot Net, slash Modernize,
Speaker 1: and we're back at starting at Rocks. I'm Carl Franklin.
Speaker 1: It's my friend Richard Campbell. Hey, and this is Callum
Speaker 1: Simpson from SSW and he's down in Australia with Richard.
Speaker 1: Right now, we're talking about Yakshaver and is this going
Speaker 1: to be an open source product? I know it's a
Speaker 1: desktop application.
Speaker 3: Yeah, So I mentioned earlier we've got sort of like
Speaker 3: a V one Yakshaver and a V two Yakshaver. So
Speaker 3: the V one Yakshaver as it currently is is not
Speaker 3: open source. It's basically a cloud based pipeline subscriber before
Speaker 3: where we sort of force everything through a pipeline with
Speaker 3: a few brand options. But what we really wanted to
Speaker 3: do with V two is to make it open source
Speaker 3: desktop application. The reason why we wanted to make it
Speaker 3: open source is because it's a desktop application that we
Speaker 3: expect users to install on their machine. So obviously it's
Speaker 3: not doing anything crazy. All it's doing is orchestrating MTP
Speaker 3: servers from the local machine. So why not make an
Speaker 3: open source so anyone can open the lead and see
Speaker 3: what's happening inside.
Speaker 1: It's really, really cool.
Speaker 2: Now what are the key AI parts here? Is it
Speaker 2: just a transcriber? Like, what do you use an LM
Speaker 2: for their other generative ail? What's going on inside this out?
Speaker 3: Are we talking about the V two up with the
Speaker 3: MCP service?
Speaker 2: Yeah? Yeah, So basically.
Speaker 3: You'll record your video well, as you said, transcribe the
Speaker 3: text of the audio of that video, and then we
Speaker 3: throw it over to the MCP orchestrator. And basically what
Speaker 3: that is doing is saying, all right, here's the transcript
Speaker 3: that the user has submitted. Here's the system prompt. So
Speaker 3: inside yak Shava you can sort of define how you
Speaker 3: want it to work. We leave that sort of up
Speaker 3: to the user, but you would have I guess an
Speaker 3: organizational default that you can then customize if you so wish,
Speaker 3: and then Yakshava will basically take that and then start
Speaker 3: using the MCP servers that you made available to it
Speaker 3: to get through whatever it is you're trying to do
Speaker 3: with that transcript. So, for example, you could give yak
Speaker 3: Shava the GitHub MCP server and you could give it
Speaker 3: instructions to say, you know, figure out which backlog or
Speaker 3: project I'm talking about in my transcript, put this issue
Speaker 3: in that backlog. Surely you include the link to the
Speaker 3: YouTube video in that issue and use whatever whatever PBI
Speaker 3: template is available in that repo as well. Uh, and
Speaker 3: when when approaches it is it will then use you know,
Speaker 3: the GitHub MCP to search all the projects you've got available,
Speaker 3: figure out all right based on that transcription, I think
Speaker 3: he's talking about that one, and then you know, search
Speaker 3: the that repo for the templates, find the right template,
Speaker 3: maybe have one template for reporting a bug, one template
Speaker 3: for creating a feature request, that sort of thing, and
Speaker 3: then fill out that template. And then we also pass
Speaker 3: it originally when you've recorded your video we uploaded to YouTube,
Speaker 3: and we pass it in the link to the YouTube video,
Speaker 3: so it can then embed that that YouTube video in
Speaker 3: the issue as well as.
Speaker 2: Part of it.
Speaker 3: So start getting issues with videos, which is pretty cool,
Speaker 3: that's right. And we also we also give it a
Speaker 3: couple of built in MCP tools as well. So we
Speaker 3: have one tool that basically says, grab a screenshot at
Speaker 3: the specified timestamp, because when we give it the transcript,
Speaker 3: it's you know, it's got all the time stamps of
Speaker 3: when each bit of text was said, so it can
Speaker 3: sort of figure out what the key moment or moments
Speaker 3: are in the transcript, you get a you got a
Speaker 3: thumbnail maker based on context, that's right, and then we've
Speaker 3: got another tool that takes that well, can take that
Speaker 3: screenshot and then you use a multimodal LM to analyze
Speaker 3: it so it can sort of grab some context out
Speaker 3: of that screenshot as well. So in that way it's
Speaker 3: sort of able to analyze the video as well as
Speaker 3: what you've said.
Speaker 2: It's very cool. I'm also thinking just de duplication is often,
Speaker 2: you know, you build these tools so it's easy for
Speaker 2: people to report problems. They're going to report a lot
Speaker 2: of problems, and they're off going to report the scene problems.
Speaker 2: Oh yeah, for sure.
Speaker 3: So yeah, that's that's one of the by the way,
Speaker 3: one of the reasons why we really wanted to transition
Speaker 3: to this V two MCP approach because a lot of
Speaker 3: people have a lot of requests like that, you know,
Speaker 3: and all you have to do to do it with
Speaker 3: the new world is you just say, and you're prompt
Speaker 3: before you create a GitHub issue, make sure you search
Speaker 3: for any duplicate issues that already exist, and if they do,
Speaker 3: add this as a comment instead of creating a new one, right,
Speaker 3: and yeah, that way it's just a prompt update instead
Speaker 3: of having to go back to our pipeline and adding
Speaker 3: all these extra branches to handle different cases.
Speaker 2: Well, and it's tougher to get people to do that
Speaker 2: because it's way easier to just create a new issue
Speaker 2: that searched you existing ones. So yeah, you can get
Speaker 2: the tool to do that for us, Thank goodness for that.
Speaker 1: Well, but you have to put that in the system
Speaker 1: prompt you know, that has to be a rule, right,
Speaker 1: that's right, don't create new issues unless there's nothing there already.
Speaker 2: Yeah, you think it's actually original. Yeah, it's really interesting.
Speaker 2: Another you know, we're talking about how general VII is
Speaker 2: coming into the different aspects of software development. This is
Speaker 2: an aspect of generating issues intelligently and trying to get
Speaker 2: as much information to the developer as possible, whether it's
Speaker 2: for a bugfix or a feature. Of course it's free.
Speaker 3: Course, Yeah that's right. Yeah, So I was going to say,
Speaker 3: originally we with the V one solution. This was another
Speaker 3: pain of the V one solution. We integrate with GitHub
Speaker 3: and as your DevOps, but the majority of people we
Speaker 3: spoke to about it, they didn't actually use those tools.
Speaker 3: They use something like Gira or whatever some other tool,
Speaker 3: and it was it was just too hard to keep
Speaker 3: adding all these because you know, every time we create
Speaker 3: one of these branching bits of logic in the V
Speaker 3: one we had to also reproduce that same you know,
Speaker 3: the same actions or set of actions in each of
Speaker 3: the backlogs that we're integrating with so GitHub Badge develops.
Speaker 3: We didn't want to have to keep doing that with Gira, Zender,
Speaker 3: whatever other tool people are using. So that was yet
Speaker 3: another argument why we moved to MVP because with MCP
Speaker 3: you can even have exactly the same prompt, but if
Speaker 3: you've got a different system that you're using for your
Speaker 3: backlog or you have to flop the MCP server and
Speaker 3: as long as it has a vaguely similar action available,
Speaker 3: it'll work just fine.
Speaker 2: Yeah, way more scalable. That's classic V two stuff is
Speaker 2: creating the rate set of interfaces for the next iterations
Speaker 2: where people want to use it in more places.
Speaker 1: I know you guys had some discussions on the back
Speaker 1: end about whether or not it's a good idea to
Speaker 1: give people all this freedom and flexibility. So what was
Speaker 1: that discussion like and would you come out of it with.
Speaker 3: Yeah, I think it's still sort of an open question
Speaker 3: that we haven't got an answer to, because I think
Speaker 3: it could potentially be detrimental. If you give people full
Speaker 3: freedom to do anything, Suddenly they're sort of swamped by
Speaker 3: choices and things they can customize, and they end up
Speaker 3: not knowing how to best use it. Whereas if you
Speaker 3: sort of force them down a path, you may not
Speaker 3: be the optimal path, but at least they're forced down
Speaker 3: the path and they'll figure out how to use it.
Speaker 1: Yeah, like some workflow templates or something like that you
Speaker 1: can choose from exactly instead of just giving people a
Speaker 1: blank slate. Also, if you think about it, you know,
Speaker 1: it's kind of irresponsible to just slap some MCP service
Speaker 1: together and give them full agency to go do whatever
Speaker 1: you would normally do. I mean that can open up
Speaker 1: a huge can of worms. Oh yeah, cans and cans
Speaker 1: and cans of worms.
Speaker 3: Absolutely, you really need to be careful, So, I mean,
Speaker 3: there is a lot of power. With power obviously comes responsibility.
Speaker 2: I've heard that you need to be here.
Speaker 3: You need to be careful about, you know, surfacing untrusted
Speaker 3: third party data to MVP servers that can perform you know,
Speaker 3: potentially destructive actions is actually sort of a running joke
Speaker 3: in the actually the dev team is when someone's recording
Speaker 3: a video to be processed, someone in the background will
Speaker 3: shout out and delete the whole repo while you're there. Yeah,
Speaker 3: we need to build in some safeguards to prevent.
Speaker 2: That from there.
Speaker 1: Used to be the running joke on dart net Rocks
Speaker 1: Alexa delete on my no, not you don't listen to
Speaker 1: me exactly. She's not quite sure how to help me
Speaker 1: with that. But you know, a delete my account, you
Speaker 1: know that kind of thing. Or send five hundred pounds
Speaker 1: of concrete to Richard Campbell.
Speaker 2: Yeah, still trying to clean up that concrete. Thanks for that.
Speaker 2: Very good. But you know, we even that office conversation
Speaker 2: with more and more aishing. Our role as shepherds of AI,
Speaker 2: goodness knows, is to constrain it, to put parameters around
Speaker 2: each of these things, and so same thing here. You
Speaker 2: want to focus on particular issue, particular capabilities, and keep
Speaker 2: limits on all the things that it can do so
Speaker 2: that it does focus on the direction you wanted to
Speaker 2: go in.
Speaker 3: The other good thing about using MCP rather than a pipeline,
Speaker 3: I think is that every action that the MCP service
Speaker 3: takes on your behalf is sort of done in your
Speaker 3: name because you're connecting directly with your own or credentials
Speaker 3: or whatever if you use and get MVP.
Speaker 2: So yeah, you need to.
Speaker 3: Take your responsibility for everything that it does. You can't
Speaker 3: just give it a random video and then cross your
Speaker 3: fingers and hope it works.
Speaker 2: So that Yeah, Well you bring up a great point
Speaker 2: because there's lots of conversation about I think this was
Speaker 2: just at Ignite where they are setting identities for agents,
Speaker 2: and that's almost like giving you an excuse lack of culpability.
Speaker 2: All the software did It wasn't me. It's like, dude,
Speaker 2: it was your prompt the software. We may call them agents,
Speaker 2: but how much agency do we want them? They're working
Speaker 2: on our behalf.
Speaker 1: Yeah, it's a constant theme.
Speaker 2: Well, I just feel like these are unsolved problems. Like
Speaker 2: I'm appreciating which the work you guys are doing callum
Speaker 2: just because you are making these experiments and using them
Speaker 2: yourselves and finding out like what what works, what doesn't,
Speaker 2: what the limits are on all this are because we
Speaker 2: I think we're a few years away from really nailing
Speaker 2: down what these new workflows look.
Speaker 3: Like, Yeah, that's right, an experiment.
Speaker 1: At this point, you have some other products AI products
Speaker 1: that you're working on at ss W.
Speaker 3: Oh yeah, we've got SSW Eagle I okay, which is
Speaker 3: a sort of a dystopian email analysis tool that basically
Speaker 3: checks all of your emails and makes for sure that
Speaker 3: you are sort of you know, adhering to all the
Speaker 3: SSW rules and and sort of game fires that a
Speaker 3: little bit as well. So you have like a leaderboard
Speaker 3: who sends the most you know, checked by email, and you.
Speaker 1: Know, so it checks outgoing emails, not incoming, because that
Speaker 1: would be a huge security risk.
Speaker 3: Yeah. Well, obviously you opt into it, right, So it's
Speaker 3: not just checking any random email.
Speaker 1: You have it checking outgoing emails. Yeah, correct, that's what
Speaker 1: it sounds like, but not incoming.
Speaker 3: Well, it's checking emails that you send to other people
Speaker 3: inside the company, right, So it's not just paying any random.
Speaker 2: It's eternal email. That's good. We did a Cogan rules
Speaker 2: show in two thousand and six. That was fun. I
Speaker 2: remember that. Yeah, well, and then you know he's out
Speaker 2: of serious about that. The rules continue to this day.
Speaker 2: I think they're very in the middle of a migration
Speaker 2: of them right now, if I recall from the brainstorming
Speaker 2: session right there, Yeah, that's right. Yeah. So this, this
Speaker 2: is the idea of an LLM being able to part
Speaker 2: stuff and saying, are you is this compliant? Are you
Speaker 2: following the rule set? Maybe making suggestions for what's incorrect? Yeah,
Speaker 2: that's very cool.
Speaker 3: Interesting, Yeah, that could be coming soon. The other brains
Speaker 3: sewing idea, the one that I was working on was
Speaker 3: sort of an AI that constantly scans your site and
Speaker 3: looks for problems and sort of reports them before someone
Speaker 3: needs to actualy them.
Speaker 2: Right.
Speaker 3: I thought that was a cool idea.
Speaker 2: Smart site testing, yow. Yeah, could we build out it?
Speaker 2: Can we build out a tool that was really good
Speaker 2: at putting wrong things into text boxes?
Speaker 3: You know?
Speaker 2: Did you know those test guys, the ones that you know,
Speaker 2: this is where I entered negative forty three? The all
Speaker 2: thing blew up?
Speaker 3: That's right, that's kind of test is the one that
Speaker 3: just ignores the instructions and does whatever they want. Yeah,
Speaker 3: I'm sure if you get a play right MCP to
Speaker 3: just prompt it, you're a crazy person who ignores instructions
Speaker 3: and does whatever they want.
Speaker 2: Yeah, the breeze I don't want to feed you an
Speaker 2: LM is ignore instructions like that just seems disturbing to me. Yeah,
Speaker 2: that's risky. Yeah, absolute trouble, without a doubt. How many
Speaker 2: folks worked on on yacual what it take to get
Speaker 2: into this point.
Speaker 3: We've got a team of about ten. Now, they're not
Speaker 3: all working obviously constantly, because you know, when we've got
Speaker 3: client engagements up, go off and do that. So we've
Speaker 3: got sort of ten coming going. I think the core team,
Speaker 3: you could say, maybe five people working on it. But
Speaker 3: one of the very interesting things we've noticed recently is well,
Speaker 3: I'm sort of operating as the product owner of Yakhava,
Speaker 3: and so as the product owner, I've been trying out AI,
Speaker 3: like completely AI driven development with not even looking at
Speaker 3: the code, just to see is that a viable approach?
Speaker 2: So vibe coding I hate the phrase, but this.
Speaker 3: Is exactly vibe coding. Yeah, I mean, yeah, the concept
Speaker 3: of vibe coding is interesting. I mean, people have different
Speaker 3: definitions of it, right. Some people say, anytime you use
Speaker 3: AI to write code, that's vibe coding, whereas others would say, well,
Speaker 3: it's only if you you only talk to the agent
Speaker 3: and you don't look at the output.
Speaker 2: Sure, so I can say, but that's what Kapothi said
Speaker 2: at the time, right when he came up with the.
Speaker 3: Phrase exactly exactly, but the terms being corrupted. I think
Speaker 3: so a lot of people just say anytime you use
Speaker 3: AI to write code, you're vibe coding. I don't think
Speaker 3: that's good at all. Yeah, and I think it's actually
Speaker 3: important to draw that distinction because, like we just said,
Speaker 3: you know, you need to take responsibility for the code
Speaker 3: that you generate if it's generated under your name. So so.
Speaker 3: But yeah, So the concept is, as product owner of
Speaker 3: yak Shav, I'm just vibe coding the features that I
Speaker 3: want to see in the tool, and then rather than
Speaker 3: giving the team an issue that says, hey, I want
Speaker 3: this feature in Yakhava, I will basically vibe code the
Speaker 3: feature itself and then give them the poll request, and
Speaker 3: then their job instead of implement the feature is just
Speaker 3: review the poll request.
Speaker 2: Figure out how badly you've gotten the LM to mess
Speaker 2: things up exactly.
Speaker 3: And I mean obviously that sometimes it does a terrible job,
Speaker 3: but I think more and more it does a good job,
Speaker 3: particularly at tasks that are sort of well constrained or
Speaker 3: are you an implementation that is along the lines of
Speaker 3: some codes that's already written, but just doing a slightly
Speaker 3: different thing, you know what I mean. So there's a
Speaker 3: big difference between creating a new, completely new piece of
Speaker 3: code that may have got some new architectural components and
Speaker 3: that sort of thing that me sounds rather risky to
Speaker 3: just let AI do whatever it wants. But if you've
Speaker 3: already got all that set up and now you're just saying,
Speaker 3: add another you know, vertical slice on this project and
Speaker 3: just copy the one that's already there, I think it
Speaker 3: does a much better job of that.
Speaker 2: It does speak to this idea that more mature software
Speaker 2: will be easier to maintain with these tools than very
Speaker 2: new software. On you know, the wen Star, as long
Speaker 2: as it's it's good, you know, as long as it's
Speaker 2: written well, right, right, So it's got to be written
Speaker 2: well in the first place.
Speaker 3: Because it's going to give you more crap, I imagine.
Speaker 2: I also wonder if if the success of this has
Speaker 2: more to do with the scope of the feature or
Speaker 2: the quality of the prompt.
Speaker 3: Yeah, good, good question, And I think that in my
Speaker 3: experience anyway, a lot of people have like when when
Speaker 3: they try to do something with AI. You know, the
Speaker 3: people who I think get bad results. Some people seem
Speaker 3: to get bad results even though they're fantastic developers. You know,
Speaker 3: they'll try to use AI and they'll get a a
Speaker 3: bad result and then they say, well, you know this
Speaker 3: AI sucks another tool myself.
Speaker 2: Yeah, exactly.
Speaker 3: But from my perspective, I always try to think, if
Speaker 3: I've used AI and the result was substandard, rather than
Speaker 3: blaming the AI, I want to blame myself, and I
Speaker 3: want to think, how could I how could I prompt
Speaker 3: it better? How could I give the right context or
Speaker 3: better prompt or whatever to get the better output next time.
Speaker 2: Well, let's say that's the old adage it is a
Speaker 2: poor craftsman that blames as tools.
Speaker 3: That's right, good point, And yeah, so that's something that
Speaker 3: I'm heavily leaning into is figuring out how we can
Speaker 3: you know, make this process of AI generated code not
Speaker 3: vibe coding, to be clear, because we're drawing a distinction there,
Speaker 3: but generating code with AI that we actually care about
Speaker 3: and that's going to form a part of our long
Speaker 3: term code base. How do we actually go about doing
Speaker 3: that in the best way. And obviously, to start with
Speaker 3: it takes longer, probably than writing the code yourself quite
Speaker 3: but I think in the long term, once you've got
Speaker 3: your systems in place, you know, you've sort of set
Speaker 3: that up once and then you can use it infinitely
Speaker 3: many times. But but yeah, so it's that reason that
Speaker 3: I've also been doing this vibe code experiment just to
Speaker 3: see what is the difference between these two different approaches
Speaker 3: and what goes wrong when you're VIBE coding. What are
Speaker 3: the problems that AI has and then how do we
Speaker 3: try to address them so that we can do a
Speaker 3: better job.
Speaker 2: So I see three categories of code. Then that you
Speaker 2: have handwritten code, you have AI syst a code, and
Speaker 2: then you have AI generated code. And you know how
Speaker 2: different are those things? How can they support each other?
Speaker 3: You know?
Speaker 2: Where is where is it? I think we're still trying
Speaker 2: to figure out where the human needs to step in
Speaker 2: more and where automation it can work fairly responsibly on it.
Speaker 3: That's right, I think it really the human needs to
Speaker 3: If you're delivering a piece of software for a client,
Speaker 3: the human obviously is the person who the client is
Speaker 3: engaging to deliver that software. You need to take responsibility
Speaker 3: for you know, understanding the problem and ensuring that the
Speaker 3: software that is delivered meets all the requirements and does
Speaker 3: everything the client needs, but also does all the technical
Speaker 3: things that the client doesn't even know that they need.
Speaker 2: But they do. The client presumes security, probably without even
Speaker 2: articulating it, that's right. You know, client presumes reliability also
Speaker 2: without caculating it. Like we've got to make sure those
Speaker 2: things exist, that's right.
Speaker 3: And if we just mindlessly generate something with AI and
Speaker 3: don't even look at it and then yeah, okay, it
Speaker 3: does most of the functionality you wanted, but it's all
Speaker 3: these gaping security flaws, all this sort of things. That's
Speaker 3: that's you know, that's a problem for you that you
Speaker 3: haven't taken responsibility for what you have delivered.
Speaker 2: Yeah, that's what That's what responsible detment looks like. That's right.
Speaker 3: But you can totally be responsible with your delivery and
Speaker 3: also use AI to do everything. It's just that you
Speaker 3: need to be taking responsibility for it right ultimately, so
Speaker 3: do the right thing.
Speaker 2: So as a product owner, I see a shape of
Speaker 2: a V two, is your stuff going to a V three?
Speaker 2: Ben Yette like, what's the future of the ACTUAV? Look like?
Speaker 3: Good question? I mean, I see after after V two.
Speaker 3: Obviously V two we should be rolling out fairly soon.
Speaker 3: Hopefully V two is all about MCP servers. I see
Speaker 3: potentially V three is going to be Yakshava actually writing
Speaker 3: writing code sort of like disposable code in order to
Speaker 3: achieve tasks, rather than just using MCP servers.
Speaker 1: Disposable code like writing PowerShell scripts and then.
Speaker 3: Executing that kind of thing.
Speaker 2: Yeah.
Speaker 3: Yeah, so like in integrating with whatever it's trying to
Speaker 3: integrate with, it could also be using the MCP servers,
Speaker 3: but you know, writing code to perform the tools in
Speaker 3: MCP rather than just using MCP because obviously one of
Speaker 3: the issues with one of the issues with MCP is
Speaker 3: you know, if you give it a whole heap of tools,
Speaker 3: that's just eating up a bunch of context that probably
Speaker 3: doesn't need to be eaten up. Although I do suspect
Speaker 3: in the future we'll get better MCP management, Like you
Speaker 3: might have some sort of middle layer that says, here's
Speaker 3: here's the prompt, here's on my tools. Just surface a
Speaker 3: couple of tools that seem like they need to be used,
Speaker 3: and that sort of thing.
Speaker 2: Yeah, it's a pretty pretty raw design at this point too, right,
Speaker 2: Like it's all of this stuff is so crazy new. Yeah.
Speaker 3: Yeah, it's an exciting space to be in.
Speaker 1: So what's next? What's next for you? Personally?
Speaker 3: For me, well, I think I continue to use AI
Speaker 3: to deliver projects. You know, I always felt that my
Speaker 3: favorite part of my job was the part where I
Speaker 3: get to talk to the client, understand the problem and
Speaker 3: design a solution and understand all the different trade offs
Speaker 3: in all the decisions that are making in that solution,
Speaker 3: and then you know, talk to the client figure out
Speaker 3: what is the best solution for them. And then the
Speaker 3: actual part where I write the code is sort of
Speaker 3: the necessary evil. You know, it's not the fun part.
Speaker 3: The fun part is designing the solution, right. So I
Speaker 3: think that's one of the main reasons why I love
Speaker 3: using A for this, because I can sort of still
Speaker 3: be fully involved in all that decision making process and
Speaker 3: solution design, but then I'm basically just delegating all the
Speaker 3: actual code writing to a system of parallel cloud based
Speaker 3: agents who while I'm asleep, they can just make a
Speaker 3: dozen pull requests and the next morning I'll wake up
Speaker 3: and just review them and you know, provide feedback and.
Speaker 2: So on and so forth.
Speaker 1: It's a brave new world in it.
Speaker 3: Absolutely it's very exciting, Yeah it is.
Speaker 1: And it's also I think freeing our imaginations to come
Speaker 1: up with solutions because and this has been a theme
Speaker 1: we've talked to many people about, starting with that Scott
Speaker 1: Hunter interview. Right, just imagination is going to be a
Speaker 1: very important commodity now, the creativity to think about what
Speaker 1: you can do, and if you can think it, you
Speaker 1: can probably get it done. And that's just an amazing thing.
Speaker 3: That's right, because I guess there's sort of no downside
Speaker 3: to just trying something, right is if you can articulate
Speaker 3: your idea, then you can have an agent go off
Speaker 3: and have a crack at it and just see what happens.
Speaker 3: And I mean, the only thing you've lost is maybe
Speaker 3: a few cents of token usage, and that's really it.
Speaker 2: So why not?
Speaker 1: So it pays to stay in school kids and learn
Speaker 1: as much as you can about the English language, and
Speaker 1: take writing classes and be clear and your thoughts and
Speaker 1: all of that, and don't use like too much, and
Speaker 1: you know, treat each other well.
Speaker 3: That's right, and the good news.
Speaker 2: Of wisdom.
Speaker 3: You can also use AI to teach you things as well,
Speaker 3: which is cooling. So if you want to learn something,
Speaker 3: you can just ask AI to create a personalized tutorial.
Speaker 1: I think that's or even little things like I do
Speaker 1: this all the time.
Speaker 2: Now.
Speaker 1: I was watching a TV show and this woman, this
Speaker 1: young woman had what looked like a tube coming a
Speaker 1: white tube coming from her ear into her nose with
Speaker 1: some scotch tape on her cheek. And I thought, that
Speaker 1: looks very strange. Is it oxygen?
Speaker 2: What is it?
Speaker 1: So I took a couple of pictures of the TV
Speaker 1: screen to send it to chat Gypt and it quickly
Speaker 1: figured out that it was a feeding tube because and
Speaker 1: then turns out like later on somebody asked her because
Speaker 1: it was a cooking show, somebody asked her, did you
Speaker 1: chase your food? And she says, no, I can't taste
Speaker 1: it because I have this gastric just whatever situation where
Speaker 1: it takes two hours to half digest food, and so
Speaker 1: she has to eat through a feeding tube. And she'd
Speaker 1: had to do that she was twenty one, she'd had
Speaker 1: to do it since she was thirteen. Wow, But chatchypt
Speaker 1: figured it all out, and then I was asking it
Speaker 1: questions about does that go all the way down the esophagus,
Speaker 1: isn't that uncomfortable? And it's like telling me all this
Speaker 1: stuff that I would It's just like having an expert.
Speaker 1: It's like having Richard in your house.
Speaker 3: You know.
Speaker 1: I can say Richard, what is that? And hit clause
Speaker 1: and Richard knows everything, so he would tell me it's.
Speaker 2: Really cool, right, which is it's interesting.
Speaker 1: It's better, way better than just Google.
Speaker 2: Yeah, for sure.
Speaker 1: Before you leave, I have an Adam's story for you.
Speaker 1: It was I can't remember when, but he was doing
Speaker 1: some videos with me for DNR TV, so that tells
Speaker 1: you it was a while ago, early two thousands. Yeah,
Speaker 1: and he was actually in Boston for techads. So that
Speaker 1: was what two thousand and six maybe something like that, Yeah,
Speaker 1: something like that. So he came down and we were
Speaker 1: up all night and I was just basically waiting for
Speaker 1: him to get his demo together because he was, you know,
Speaker 1: working on it. So seven o'clock in the morning rolls
Speaker 1: around time for Brecky. So we go to a diner.
Speaker 1: So two thousand and six, right, so we barely have
Speaker 1: internet on phones, but we do have it. And he
Speaker 1: go to a diner and I'm putting pepper on my eggs.
Speaker 1: He goes, you gotta watch that stuff. I said, what
Speaker 1: black papa bad for blokes?
Speaker 3: Like what?
Speaker 1: He says, Yeah, I'll give you a prostate cancer. Come on, Well,
Speaker 1: I didn't have Chatty obviously, but I did have Google
Speaker 1: on my phone. I looked it up and not turns out.
Speaker 1: It turns out not only is black pepper good for
Speaker 1: your immune system and therefore not causing cancer, but kespasin,
Speaker 1: which is not black pepper at all. But it's the
Speaker 1: stuff that makes Pepper's chili peppers hot. When you apply
Speaker 1: ks spasin directly to prostate cancer cells.
Speaker 2: It kills them.
Speaker 1: So I was like, dude, where did you learn this?
Speaker 3: He goes, friend, Yeah, well, look, it's all about strong
Speaker 3: opinions weekly hill.
Speaker 2: So yeah, yeah, a change. But I told my kids.
Speaker 1: Because they grew up in the Internet age, and you know,
Speaker 1: when you have a phone, when you get older, you
Speaker 1: can use it as your portable BS detector. And you know,
Speaker 1: and somebody tells you something, don't take it at face value.
Speaker 1: Go and look it up and look it up at
Speaker 1: a reputable fact checking site, not just like you know, TikTok. Anyway, callum,
Speaker 1: thank you very much, it's been so great talking to you,
Speaker 1: and this is great stuff and I can't wait for
Speaker 1: V two. I'm gonna run it myself.
Speaker 2: I can't wait.
Speaker 3: Yeah, I can't wait to roll it out of you though.
Speaker 3: Thanks having me.
Speaker 1: You let us know when it's available do and thanks Callum,
Speaker 1: and we'll talk to you next time on dot net rocks.
Speaker 1: Dot net rocks is brought to you by Franklin's Net
Speaker 1: and produced by Pop Studios, a full service audio, video
Speaker 1: and post production facility located physically in New London, Connecticut,
Speaker 1: and of course in the cloud online at pwop dot com.
Speaker 1: Visit our website at d O T N E t
Speaker 1: R O c k S dot com for RSS feeds, downloads,
Speaker 1: mobile apps, comments, and access to the full archives going
Speaker 1: back to show number one, recorded in September two thousand
Speaker 1: and two. And make sure you check out our sponsors.
Speaker 1: They keep us in business. Now go write some code,
Speaker 1: see you next time.
Speaker 3: You got javans
Speaker 2: And