Speaker 1: Cla command kind of became the test with a front
Speaker 1: end and the back end. You need to actually write
Speaker 1: some tests lean towards end and integration type tests that
Speaker 1: test the whole flow instead of testing small parts.
Speaker 2: Of your coach.
Speaker 1: Your codal change very quickly, so you have to rewrite
Speaker 1: those tests a lot.
Speaker 3: But does that mean that? But that means, if understand
Speaker 3: your description correctly, that you're effectively manually testing it. I
Speaker 3: mean you're you're running a certain script, but then you're look,
Speaker 3: you're you're you are the one who's actually checking to
Speaker 3: see that you get the expected results.
Speaker 1: Well, it's still a I mean, it's automated because you
Speaker 1: wrote a test. The test itself is going through steps
Speaker 1: that you would manually do yourself.
Speaker 2: But like I said, it's like it's like an end
Speaker 2: to end test.
Speaker 3: Yeah, it's not an end to end test. Yeah, that's
Speaker 3: what that was aiming for. So so yeah, so so
Speaker 3: vibe coding. I guess is because the system is so
Speaker 3: dynamic and everything is changing so rapidly, you're effectively also
Speaker 3: kind of acting, as to an extent, the manual QA
Speaker 3: for what you're developing.
Speaker 2: Yes, yeah, I think that's that's a good way to
Speaker 2: look at it.
Speaker 1: And as much as you can build in ways what
Speaker 1: a system can qa itself, you should there's always going
Speaker 1: to be at least some sort of points in time
Speaker 1: where you have to step outside and actually just like
Speaker 1: try it and see if it works or not. So
Speaker 1: I think there's a lot of the same kind of
Speaker 1: issues that we get just with testing in general, like
Speaker 1: what's it efficient way to test it work not?
Speaker 4: You know, in a lot of cases when I've done it,
Speaker 4: I just loaded in the browser and just click around
Speaker 4: and then I'll have it, I'll vibe code it and
Speaker 4: prompt it for unit tests. Did you but that it
Speaker 4: really does depend on what I'm building, because sometimes that's
Speaker 4: not the right way to do it if it's you know,
Speaker 4: completely command line based or something.
Speaker 3: By the way, coding, what do you usually generate, Anthony?
Speaker 2: What do I in terms of like what LM am
Speaker 2: I using?
Speaker 3: Or no, what you're using the l ELM generate code?
Speaker 3: Is it React code, straight on, dumb code, jQuery code,
Speaker 3: HTMX code. Yeah, I know you're generating a.
Speaker 2: Lot of stuff.
Speaker 1: Like I said, I first started by building a CLI
Speaker 1: and then I extended that functionality to a back end
Speaker 1: and front end which have gone through many different tech stacks.
Speaker 2: You know, I was a big framework.
Speaker 1: Guy, so I'm always kind of trying out different tools.
Speaker 1: My current stack in terms of what I'm deploying the
Speaker 1: auto show app with, which is the app I vibe
Speaker 1: coded is Astro with solid as the templating language, and
Speaker 1: Tailwind for the styling. And yeah, so that's the that's
Speaker 1: basically the back end and the front end. I've done
Speaker 1: stuff with like a noe JS Fastify server, I've done
Speaker 1: stuff with React. Really, any kind of popular technology that
Speaker 1: has a lot of usage and a lot of docs
Speaker 1: will probably do pretty well. Some people say you should
Speaker 1: always use next JS and super base, but like I think,
Speaker 1: as as all as you're not trying to use something
Speaker 1: really obscure and really new, it tends to work pretty well.
Speaker 1: If it is very obscure, very new, you should create
Speaker 1: like a just a single file that kind of has
Speaker 1: all the docs in it and drop that into the
Speaker 1: context of the LM.
Speaker 2: That will kind of help short change that issue.
Speaker 3: I think these days you also have various mcps that
Speaker 3: make it very easy to get content off of GitHub
Speaker 3: for examples.
Speaker 1: Yes, yeah, yeah, mcps at a whole other level of
Speaker 1: things for sure.
Speaker 4: Yeah, but when you're using the LL no, I just
Speaker 4: curious because you're asking about the tools are you doing
Speaker 4: this with like copilot connected to Gemini or GPT or
Speaker 4: Claude or using something like cloud code, or how are
Speaker 4: you doing that night. I'll also point out the copilot
Speaker 4: if you put it into agent mode instead of I
Speaker 4: can't remember the other mode, it'll actually put the code
Speaker 4: into your ID for you.
Speaker 2: And so I'm a little curious, like what level are
Speaker 2: you working at there?
Speaker 1: Yeah, so I've tried co pilot and cursor, I've tried
Speaker 1: clock code, I've tried you know, things like bolt and
Speaker 1: v zero. I think that is what Versailles thing is called.
Speaker 1: And then like when you have the agent loop, like
Speaker 1: you said, was actually changing your code for you. That
Speaker 1: is the full Vibe code experience. Like that is Steve
Speaker 1: Sworzneimer for sure. So I tend to it's kind of nice, It's.
Speaker 2: It can be very very nice. Yeah, totally.
Speaker 1: I think for like personal projects, that's definitely what I
Speaker 1: would do. I have an I have a flow that
Speaker 1: some people will consider it kind of strange and inefficient.
Speaker 1: I had used this tool called rebomix, which is a
Speaker 1: way to kind of intelligently take your code base and
Speaker 1: smush it into something that is small enough to fit
Speaker 1: in the context of these lllms. And then it also
Speaker 1: includes instructions of how I want my code to be
Speaker 1: styled and written.
Speaker 2: And then I just write what.
Speaker 1: I want to do as a line at the bottom
Speaker 1: of that whole thing, and then I PLoP that into
Speaker 1: either shatshept, Claude, or Gemini. I use all three kind
Speaker 1: of depending on which was going to work best, and
Speaker 1: then it gives it gives you the output, and then
Speaker 1: I put it into my file. And as I'm doing that,
Speaker 1: I'll quickly kind of look over the code and I'll
Speaker 1: look at the diffs. So I'm not doing a pure
Speaker 1: vibe coding experience that I am paying attention to my cokes.
Speaker 1: I'm doing a production app that has you know, payments
Speaker 1: and log in and stuff. So that gives me a
Speaker 1: step to kind of slow down, look at the code
Speaker 1: that's being written, look at what is changing in my project,
Speaker 1: get a sense of what's happening, and then I can
Speaker 1: then test it and see if it works.
Speaker 3: So do you generally, when when the NLM is suggesting stuff,
Speaker 3: do you usually approve it one by one, or do
Speaker 3: you just approve it all and then look at I
Speaker 3: don't know the get diffs or whatever.
Speaker 1: So I PLoP in all the changes that it gives me,
Speaker 1: and I tell to write codes files in full, so
Speaker 1: I just click copy paste for each of them, and
Speaker 1: the way my projits are structured usually only has to
Speaker 1: change a handful of files to make the change if
Speaker 1: it's atomic enough. And then after I've put all the
Speaker 1: files and all that, look at the diffs on each
Speaker 1: of those files. So if there's three files, I also
Speaker 1: go click over to the deff you're on vs code
Speaker 1: kind of look at all those and then I'll test
Speaker 1: the application with either a test scripture or just clicking through.
Speaker 3: Now, you mentioned that you use the project itself as
Speaker 3: the context or put it in the context in order
Speaker 3: to obviously create consistency within the code base. Yep. For
Speaker 3: consistency is only worthwhile once you have some code, and
Speaker 3: also assuming the code is structured the way that you
Speaker 3: like it. So do you also manually create or have
Speaker 3: created some sort of rule files or something along these
Speaker 3: lines as kind of a starting point or a way
Speaker 3: to keep aligning your code with a certain desired outcome.
Speaker 2: Yeah.
Speaker 1: So with repomix, it includes an instructions file that gets
Speaker 1: appended to each one, and for in there, I have
Speaker 1: things like how I want the logging to be done
Speaker 1: JavaScript kind of styling, so always using imports, not you know.
Speaker 3: Require kind of like cursor rules.
Speaker 2: Yeah, they're exactly that curse rules, Yeah, totally.
Speaker 1: So yeah, I think everyone should have those, and they
Speaker 1: should make sure like get down in writing how they
Speaker 1: actually want their code to look and behave and the
Speaker 1: coding styles that they want.
Speaker 3: So for me, it's interesting. So I've recently I'm working
Speaker 3: on several legacy projects at work that are there are
Speaker 3: definitely legacy, but there's still very much undergoing development by
Speaker 3: several developers, and I introduced rule files into all of them.
Speaker 3: And it was a very interesting experience for me in
Speaker 3: a lot of ways. It was my first real encounter
Speaker 3: with prompt engineering, you might say. So, first of all,
Speaker 3: it was really odd for me, being an old timer
Speaker 3: in tech, to effectively write configuration as English in a
Speaker 3: markdown file rather than in Jason or Yama or anything
Speaker 3: that you normally would expe configuration to be in. It's
Speaker 3: a very like it's a very strange experience the first
Speaker 3: time you do it, Like instead of saying, you know,
Speaker 3: yeslint colon, on, you say I want you to use yeslint.
Speaker 3: It's it's it's it's a very odd experience. But the
Speaker 3: other thing that obviously was a very significant thing for
Speaker 3: me was saying how seemingly very small changes that I
Speaker 3: would make in the rule files could have very significant
Speaker 3: impact on the generated code. And it wasn't always very
Speaker 3: trivial to totally understand why M.
Speaker 1: Is that The experience as one, Yeah, for me, this
Speaker 1: whole the rules came around very iteratively where I was
Speaker 1: working a lot with the lms, so it was generating
Speaker 1: a lot of code, and there would be a lot
Speaker 1: of time doing something consistently that I didn't want, and
Speaker 1: then every time that would happen, I would write a rule,
Speaker 1: and then I would make sure that rule actually change
Speaker 1: the thing I wanted to change, didn't change anything else.
Speaker 2: So you kind of need to do this. It takes
Speaker 2: some time.
Speaker 1: There's really no shortcut to doing it, and you have
Speaker 1: to just kind of get familiar with the llms and
Speaker 1: how they generate code, and when you're changing your rules
Speaker 1: trying it's another kind of like iterative process, where you
Speaker 1: get the outputs you see, are they what you want?
Speaker 1: Tweak the prompt if it's not what you want, and
Speaker 1: once you get it where you want, try not to
Speaker 1: mess too much with your rules file.
Speaker 3: Yeah. So, so just to finish that point check for me,
Speaker 3: what I literally did was I started without any rule files.
Speaker 3: I would pick a file, let's say, that was in
Speaker 3: a style that I didn't like, and literally gave just
Speaker 3: the one command refactor, saw what got generated, then put
Speaker 3: in some rules, did it again, saw the difference, tweak them,
Speaker 3: did it again, And like you said, it was an
Speaker 3: iterative process. What I I also discovered was sometimes even
Speaker 3: though I gave certain instructions, and even though the atherlam
Speaker 3: very explicitly stated that it was following those instructions, it
Speaker 3: still didn't or didn't fully right.
Speaker 1: And this is where having examples, like if the rules
Speaker 1: match what your code already does, then it will be
Speaker 1: it'll be better at doing that because they'll both have
Speaker 1: the English language to explain it an example of what
Speaker 1: it actually looks like. So you're right, sometimes when you're
Speaker 1: just writing in English, it won't always get it. You
Speaker 1: actually need a file that's written with that style, you
Speaker 1: can show it to be like, no, do it like this.
Speaker 3: So for example, for me, it was I wanted it
Speaker 3: to not introduce in any slint errors or.
Speaker 1: Warnings your s link configuration is.
Speaker 3: Yeah, and I obviously gave it the PAS to the
Speaker 3: slint configuration, and it would literally say I found some
Speaker 3: e s slint issues and fixing them, and then I
Speaker 3: found some more and fixing them, and even then when
Speaker 3: it was all done, it still had some issues.
Speaker 1: So yeah, and that's because you're you're putting a tool
Speaker 1: in the middle that it has to understand well enough
Speaker 1: to be able to do that, instead of just knowing
Speaker 1: enough about code in general to know like what import
Speaker 1: versus require is. Anytime you're eye in these extra tools
Speaker 1: and actual layers of indirection, that it's more chances for
Speaker 1: the LM to.
Speaker 2: Get confused and do stuff wrong.
Speaker 4: Yeah, because it has to know about es lint in
Speaker 4: its latent space because you're not teaching it.
Speaker 1: So if you had a doctor or an es lint
Speaker 1: you know file that actually has es lint contacts and
Speaker 1: explains what the s lint stuff means and your configuration,
Speaker 1: how that maps to eslint, how it works, that would
Speaker 1: be an additional piece of context you could give it
Speaker 1: that would help it figure that out.
Speaker 2: Right, then you are teaching it how to do that.
Speaker 4: So I have a question because you guys are talking
Speaker 4: about rule files and this is something that I haven't
Speaker 4: really used typically. I'm getting in and I'm saying, look,
Speaker 4: I want you to do this, I want you to
Speaker 4: use these tools. I want you to and yeah, I
Speaker 4: have to keep reminding it when I'm when I'm doing
Speaker 4: the code.
Speaker 2: So where do you put those into your tools?
Speaker 1: For me, everything goes through repomix, So this is a
Speaker 1: huge part of my toolbase. And if you're using cursor,
Speaker 1: you won't do this, you won't have this workflow at all.
Speaker 1: But for me, I just have literally, uh, the way
Speaker 1: the way reap wakes works, you just have a separate
Speaker 1: markdown file with your rules written in it.
Speaker 2: It just grabs it and depends it. I have a
Speaker 2: customs script that.
Speaker 1: Does a whole bunch of crap, but it's really it's
Speaker 1: just a It's just a hug of markdown is all
Speaker 1: it is. And that gets added to the project's contexts
Speaker 1: that repomix creates for me.
Speaker 3: And that's essentially the same way that it works. And
Speaker 3: cursor just takes it from a different location. And yeah,
Speaker 3: the whole point and the whole point is exactly what
Speaker 3: you said, Chuck, to avoid needing to manually put those
Speaker 3: in the stuff that the same stuff in the prompt
Speaker 3: again and again and again each and every time.
Speaker 4: Right, Yeah, and it's usually the ongoing stuff. Right, So
Speaker 4: it's oh, just a remind No, I'm using tailwind four
Speaker 4: not tailwind three, right, or.
Speaker 3: First of all it's I'm using Yeah, first of all,
Speaker 3: it's I'm using tailwind rather than let's say, see a sense.
Speaker 3: It might figure it out from your existing content, or
Speaker 3: it might not. Right if you're starting a new project,
Speaker 3: then how would it know? So you would need to
Speaker 3: remember to tell it use tailwind, But if you put
Speaker 3: it in your in your root five, you don't.
Speaker 2: Yeah.
Speaker 1: This also gets to know something about conversation length. The
Speaker 1: longer you talk to an LM and a single conversation,
Speaker 1: the dumber it will get. This is something that's highly
Speaker 1: unintuitive that a lot of people do not understand about lms.
Speaker 1: That's why I like repo mix because every time I'm
Speaker 1: making a change, I'm kind of one shotting it getting
Speaker 1: code back if it doesn't work. I'll have a very
Speaker 1: quick back and forth to fix the bug, and then
Speaker 1: I'm immediately going to go to a new context, a
Speaker 1: new conversation every time.
Speaker 4: So that was the thing that I wanted to bring
Speaker 4: up with repo mix, and I was going to ask earlier,
Speaker 4: but you kind of already answered it by saying repo
Speaker 4: mix and that is is you know, like when I'm
Speaker 4: starting out, it can kind of keep most of the
Speaker 4: app and in the context, but as I build more
Speaker 4: things in, it obviously gets to the point where it can't.
Speaker 1: Yeah, so it makes more like test files and things
Speaker 1: like that. You can configure it to say I just
Speaker 1: want my front end files to be in this configuration
Speaker 1: and my back end files to be in this. So
Speaker 1: if you have an appic it is very very large,
Speaker 1: you just start to scope it two different sections that
Speaker 1: will have the context it needs to make the change
Speaker 1: you need you want to make.
Speaker 4: So do you have to tell it I'm working in
Speaker 4: this section of code, and so only care about because
Speaker 4: because That's what I'm wonderings on it.
Speaker 1: I have a script where I create a bunch of
Speaker 1: different configurations that allow repomix to generate different types of
Speaker 1: context and I'll just run a command like repo back
Speaker 1: for my back end or something. It's there's a lot
Speaker 1: of ways which you can configure it. In terms of
Speaker 1: how many different ways you need to configure it will
Speaker 1: kind of depend on how larger project is and how
Speaker 1: many different sections there are, and how easily it will
Speaker 1: get confused if you give it the whole project versus
Speaker 1: just the parts of the project it needs. But since
Speaker 1: I'm vibe coding it, every time I want repo mix command,
Speaker 1: I just give it my code and say, hey, I
Speaker 1: have this repo mix command to cover this part of
Speaker 1: a project.
Speaker 2: It gives me the new command.
Speaker 3: Okay, you mentioned before that the NLM gets dumber the
Speaker 3: longer the conversation continues. Yeah, why is that so?
Speaker 1: It's just because of what context length itself is. Context
Speaker 1: length basically means that there's a certain number of tokens
Speaker 1: that the LM is able to kind of keep in
Speaker 1: its like working memory as a certain point as I
Speaker 1: guess longer longer, longer II at full. So we'll have
Speaker 1: to start bumping off text from the beginning, and then
Speaker 1: that means it will lose important context if it made
Speaker 1: some changes at the very beginning and then you get
Speaker 1: to a very long conversation, it won't be able to
Speaker 1: be aware of those at the very beginning.
Speaker 2: Why you have to keep it within the.
Speaker 1: L ELM's context window, not just for the first message,
Speaker 1: so it doesn't say this is too long, I can't respond,
Speaker 1: So it doesn't then as the claude actually does something,
Speaker 1: smart cloud will tell you at a certain point in
Speaker 1: time when your conversation is done, and they will not
Speaker 1: let you keep using They will tell you have to
Speaker 1: create a new chat. I'm not sure if any of
Speaker 1: the lms do that right now. Most of them just
Speaker 1: let let you keep going forever, and then it will
Speaker 1: just be that's where you get the hallucinations.
Speaker 2: That's where you get a lot of these errors.
Speaker 1: People think about when they think of l elms as
Speaker 1: once you exceed the context window in your conversation.
Speaker 3: So it's basically to a certain point in time, you're
Speaker 3: kind of getting lost in the weeds, as it were,
Speaker 3: with all the noise that accumulated throughout that entire conversation,
Speaker 3: all the dead ends and wrong paths remain in the
Speaker 3: context and actually bump out the more important stuff that
Speaker 3: you probably gave it the very beginning of the conversation,
Speaker 3: as you said, like the goal that you're working towards,
Speaker 3: et cetera. By the way, we have a question from
Speaker 3: the audience. Does he always try all three models Claude, Gemini, Chajipt,
Speaker 3: Which one tends to work best for which types of code?
Speaker 2: Sure?
Speaker 1: So I won't switch to different models if the first
Speaker 1: one I tried isn't working, Like if it gives me
Speaker 1: broken code and then I tell it to fix it
Speaker 1: and it gives me code that's still broken in the
Speaker 1: same way or broken in a different way. I treat
Speaker 1: most of these things pretty pretty pragmatically. And the question
Speaker 1: more so is like, so what cause if you do
Speaker 1: all three you other then check all three and if
Speaker 1: they all work, then you just wasted, you know, a
Speaker 1: ton of time.
Speaker 2: The bigger question is which one do you start with?
Speaker 1: Which is one is most likely you give be correct
Speaker 1: answer the first time, so you don't have to use
Speaker 1: another model.
Speaker 2: And that has changed a lot for me over time.
Speaker 1: I'm constantly kind of switching back and forth as new
Speaker 1: models come out because the space is so competitive right
Speaker 1: now that almost no one is able to hold onto
Speaker 1: the best model for more than a couple of months.
Speaker 2: So My go to right now is Claude for Sonnet,
Speaker 2: not Claude for Opus.
Speaker 1: This is a rare case where this quote unquote best biggest,
Speaker 1: newest model is not really the best son It is
Speaker 1: better than Opus because one, it has a longer context window,
Speaker 1: WHI I don't know why they made opens a smaller
Speaker 1: contact window. It also is slightly faster, and it just
Speaker 1: doesn't have as many kind of does it seem times
Speaker 1: much downtime. There's one time where Opus was broken and
Speaker 1: then I realized I could just switch to sign it
Speaker 1: and sign it wasn't so like sometimes if Claude is down,
Speaker 1: a Claude model is down, not Claude the whole thing.
Speaker 2: So would cloth Horse sign it is my go to
Speaker 2: right now.
Speaker 1: Then if that doesn't work, I'll try Gemini two point five,
Speaker 1: and then if that doesn't work, I'll try Chat.
Speaker 4: Should be t relating starting, Yeah, I I just kind
Speaker 4: of start with whatever I'm sitting on and then I'll
Speaker 4: just change it when I need to.
Speaker 2: That's I don't start with any one of them. I
Speaker 2: just rotate.
Speaker 4: It's like this isn't doing as well, and I also
Speaker 4: don't follow along so much with the there's a new
Speaker 4: model out. I want to try it, I just I'll
Speaker 4: wind up switching to it when it's like okay for
Speaker 4: whatever reason, and this isn't doing what I want.
Speaker 2: My question though, is how much are you paying for this?
Speaker 4: Because as you use the different models, you typically have
Speaker 4: to pay some of them. It's per usage, right, So
Speaker 4: it's like I put so many tokens.
Speaker 2: In or you know whatever. They're usually only usage based.
Speaker 1: If you're using the APIs, it's usage based in the
Speaker 1: sense that you need to buy more expensive monthly subscriptions
Speaker 1: to get higher usage caps. So I'm not literally paying
Speaker 1: like buy the token, but and this and a lot
Speaker 1: of this will have to do. It's just like how
Speaker 1: much do you use it? How much code do you write?
Speaker 1: And is that code that you're writing like work you know,
Speaker 1: related or not? So you can get away. I think
Speaker 1: most people they should start by getting the twenty dollars
Speaker 1: subscription to whatever LLM they're using, whether it's chatche to
Speaker 1: your claud or whatever. And then if you find it
Speaker 1: is useful for you but you're hitting the usage limit,
Speaker 1: then look at some of the more expensive ones. Claude
Speaker 1: has one hundred dollars one and then at two hundred
Speaker 1: dollars one where you can get five x more usage
Speaker 1: or twenty x more usage. I think chatshiw he just
Speaker 1: has the two hundred dollars plan where you get essentially
Speaker 1: unlimited usage.
Speaker 2: I've never hit the usage cap on chashivt, so I.
Speaker 1: Pay two hundred dollars for both of those because I'm
Speaker 1: billion an app that is going to like be my
Speaker 1: full time income hopefully one day.
Speaker 2: So I can kind of justify that cost.
Speaker 1: If you're someone who's just learning these things, are just
Speaker 1: starting out, I would recommend just starting with a twenty
Speaker 1: dollars a month one. I definitely recommend not using the
Speaker 1: free plan if the free plan does not give you
Speaker 1: the best model. You want to have the best model,
Speaker 1: even if it's twenty dollars a month.
Speaker 3: And there's a reason that Nvidia is not worth for
Speaker 3: trillion seriously, So for new folks.
Speaker 4: There are a couple of things we've kind of thrown
Speaker 4: in here that I want to explain. One of them
Speaker 4: is tokens. Tokens are essentially words or parts of words
Speaker 4: that give meaning to the context, and the context is
Speaker 4: what the LLM remembers about your conversation, so it breaks
Speaker 4: it up into tokens and then it figures out what
Speaker 4: it means. The other one is is you know Dan's
Speaker 4: reference to Nvidio going up.
Speaker 2: A lot of the these models are.
Speaker 4: Trained using the GPUs, and Nvidia is the largest maker
Speaker 4: of the best GPUs for the training for these and
Speaker 4: so as you get bigger and bigger models and more
Speaker 4: and more information crammed into them, they need more machines
Speaker 4: with more GPUs to feed the data in so that
Speaker 4: they can build these models. You can run them on
Speaker 4: your own machine, and a lot of times it will
Speaker 4: take advantage of your own your GPU and your computer
Speaker 4: which is probably also made by Nvidia. But at the
Speaker 4: end of the day, that's why is because they're buying
Speaker 4: They're buying the GPUs like candy because in order to
Speaker 4: get a bigger, stronger model, they need more hardware.
Speaker 3: Or put another way, all that money that's coming from
Speaker 3: both us as users and from the vcs, it's all
Speaker 3: flowing downstream into videos pockets.
Speaker 4: Right yeah, because because they're basically the big or only
Speaker 4: game in town for the hardware you need.
Speaker 1: Well, they always say in a in a gold rush,
Speaker 1: you want to be, you know, selling shovels.
Speaker 2: This is The best example of that is.
Speaker 4: What are you building and what's kind of your workflow
Speaker 4: as you build it out? And then related to that,
Speaker 4: what what do you find that you know is working
Speaker 4: or not working in that workflow.
Speaker 1: Yeah, so I'm building something called auto show. It's autoshow
Speaker 1: dot app. If you want the latest, go to dev
Speaker 1: dot autoshow dot app. If you're someone watching right now,
Speaker 1: I just can't wait. That will be in upstreams by
Speaker 1: the end of today, hopefully. But it's something that I
Speaker 1: first built for myself, just kind of as a personal
Speaker 1: tool that I thought would be useful. I explained it
Speaker 1: very briefly at the beginning where I wanted to take
Speaker 1: my podcast. So I'm a podcaster like you guys, I
Speaker 1: do lots of live streams as well, and I wanted
Speaker 1: to be able to get an m to write the
Speaker 1: chapter titles for me. You know, if most people fail
Speaker 1: us to do a podcast like at your Lex Friedman's
Speaker 1: or your Joe Rogan's or whatever, you'll get Actually Joe
Speaker 1: Rogan doesn't do this, but let does. You get chapter
Speaker 1: titles and time stamps for each so you can click
Speaker 1: to a certain point and they'll jump to that point
Speaker 1: in the conversation and you can kind of read that
Speaker 1: over a guess as of what is the guest going
Speaker 1: to talk about on this show. But that takes a
Speaker 1: lot of time to have a three hour podcast gallists
Speaker 1: to the whole thing and find those times. So I
Speaker 1: found that if I used WHISPER, which is open Eyes
Speaker 1: open Source transcription model along which gives you the transcription
Speaker 1: and the time stamp for each line, I could give
Speaker 1: that to chat Shept and say, hey, I want chapter titles,
Speaker 1: read this, chunk it up in topics, and then give
Speaker 1: me where the topic starts.
Speaker 2: And that was the first thing I did, and.
Speaker 1: I was like wow, Like just that alone saves me
Speaker 1: a lot of time and it is very useful. So
Speaker 1: then I created a scripting workflow to do all that myself.
Speaker 1: Instead of running whisper, copy paste the transcription into chat schpt,
Speaker 1: writing the prompt or you know, saving the prompt somewhere
Speaker 1: on my computer and copy past see it and then
Speaker 1: giving it to the LM and then getting the output back.
Speaker 1: I created, ah, just a command or CLI to do
Speaker 1: all those steps for me. So you would write NPM,
Speaker 1: run auto show, give it the RL, and then you
Speaker 1: would have the full show notes in without doing any
Speaker 1: other effort. So I was like, wow, that's pretty cool,
Speaker 1: and I started expanding it out. I started adding more prompts,
Speaker 1: you know, things like summarize the whole episode, or give
Speaker 1: me the key takeaways, or write frequently asked questions based
Speaker 1: on this, or write a rap song based on this,
Speaker 1: or write a blog post based on this.
Speaker 2: I just kept adding more and more prompts and more
Speaker 2: and more.
Speaker 1: Things you could do, and then I was like, okay,
Speaker 1: I need to So then I started showing it to people.
Speaker 1: You know, i'ld go on streams with my friends and
Speaker 1: I'd be like, hey, look at this thing up bill,
Speaker 1: And after showing it to people, I just kept being
Speaker 1: told over and over and over again.
Speaker 2: People would be like, dude, you should charge for this.
Speaker 1: And I'm like, okay, well, if it's people really think
Speaker 1: it's useful, they think it could be a useful app
Speaker 1: that I should try and productize this. So I've been
Speaker 1: working on building the front end of the back end
Speaker 1: so there'd be kind of a nice user interface that
Speaker 1: people could use. And so yeah, so now you have
Speaker 1: a you know, click and interface. You can just drop
Speaker 1: in a link to the YouTube video you want or
Speaker 1: upload a local file from your computer, You select the
Speaker 1: transcription service you want, you select the prompts you want,
Speaker 1: and then you select the ll M you want, and
Speaker 1: then it gives you the show notes back. So yeah,
Speaker 1: that's the that's the go on, like a whole product.
Speaker 5: So, before we're going too much farther, I want to say,
Speaker 5: comparing us to Joe Rogan was a very appropriate comparison,
Speaker 5: I think.
Speaker 4: Of course, right, I mean, you guys aren't the podcast
Speaker 4: in my he's almost as he's almost as pretty as
Speaker 4: we are.
Speaker 2: Yeah, yes, I also want to time.
Speaker 4: Yeah, so with these tools, I mean I've used some
Speaker 4: tools that do some of the things you talked about,
Speaker 4: not all.
Speaker 2: Of them, but yeah it Yeah.
Speaker 4: And then the other thing I was going to point
Speaker 4: out is I'm actually working on kind of the other
Speaker 4: end of things where I want kind of a podcast assistant.
Speaker 4: Of course, I plan to monetize the platform that we
Speaker 4: host the shows on, but I want to build a
Speaker 4: LLM based system in there where it's like, hey, this
Speaker 4: is how we do the scheduling. Can you schedule an
Speaker 4: episode with so and so? Can you invite them to
Speaker 4: the podcast? And you you know, they said they want
Speaker 4: to talk about vibe coding. Can you give me three
Speaker 4: or four resources that I can go check out before
Speaker 4: the episode in order to talk to help.
Speaker 2: You build that if you want, right, let's talk afterwors. Yeah, definitely.
Speaker 4: And so it's funny because the two kind of yea,
Speaker 4: you know, they kind of blend in the way I think.
Speaker 2: Yeah.
Speaker 4: And the other thing that to be interesting is then
Speaker 4: you know, can I license auto show?
Speaker 2: Right?
Speaker 4: And so it's like, hey, for all of the process
Speaker 4: stuff on the other end instead of building it myself,
Speaker 4: you know, say hey, we're going to send your episode
Speaker 4: over to auto show and we're going to get all
Speaker 4: the metadata back that we need in order to publish it,
Speaker 4: and so a lot of that just anyway, it'd be
Speaker 4: really interesting to kind of compare notes and see where
Speaker 4: this is going.
Speaker 2: I'm doing most of mine in Ruby, but.
Speaker 1: Yeah, anyway, Yeah, it would just be a back end
Speaker 1: end point that you could hit and access if you
Speaker 1: want to just use the auto show part.
Speaker 2: Yeah.
Speaker 1: The only reason why I like having so many friends
Speaker 1: who are content creators and why I like going to
Speaker 1: your shows and explain it to them because most people
Speaker 1: are like, hey, I could use that.
Speaker 4: Yeah, I've seriously about doing that stuff. But I want
Speaker 4: to focus on the other stuff because that's where I
Speaker 4: spend most of my time.
Speaker 2: And so yeah, if you'll do other stuff, cool.
Speaker 3: Yeah, And so a question about that. So you're building
Speaker 3: this whole thing, as you said, using vibe coding. If
Speaker 3: you were to have done it three years ago, you
Speaker 3: would have probably written it manually by hand. Yeah, how
Speaker 3: much of a difference has the vibe coding aspect of
Speaker 3: it made?
Speaker 1: It just completely accelerates, Like it makes such a huge
Speaker 1: difference in terms of the speed at which I could
Speaker 1: build new features, new functionality, fix bugs. It's just it's
Speaker 1: just a huge, huge accelerator because you think about all.
Speaker 2: The things you had to do when you didn't have this.
Speaker 1: You would have to forfare out what you want to do,
Speaker 1: what tech you're going to use, You have to go there.
Speaker 2: You have to then try it out.
Speaker 1: I mean, if you get to the point where you
Speaker 1: know all your tools, you're already very experienced with it,
Speaker 1: then you're just you know, writing the code. But even then,
Speaker 1: you know you have to figure out what the future
Speaker 1: you want is, how you're going to implement it. You
Speaker 1: have to then to write all the code to implement it,
Speaker 1: you then have to test it, you have to write
Speaker 1: new code, it is broken.
Speaker 2: So for me, it's just a huge, huge accelerator.
Speaker 1: And as I've done it more and more and I've
Speaker 1: learned how to do it more efficiently, how to you know,
Speaker 1: anticipate the weaknesses has and how to mitigate those, and
Speaker 1: I'll continue to accelerate my development speed even more as
Speaker 1: up and continuing to do this. So yeah, I just
Speaker 1: think it's It doesn't necessarily make you a better deb
Speaker 1: but it makes you a much, much, much faster dev.
Speaker 4: So the thing that I can see people thinking is
Speaker 4: are people going to lose their jobs because of this?
Speaker 2: Well, no, because there still had to be me to
Speaker 2: think of the app, to then prompt it, to build
Speaker 2: the app, and then test it, to use the app. Yeah,
Speaker 2: I mean, but I don't.
Speaker 4: Know my employer could hire me to use tools like
Speaker 4: this and not have to hire two or three other people.
Speaker 2: Maybe sure they get to that point.
Speaker 1: Yeah, or it's a question of you know, but if
Speaker 1: they think of if they then have success and they're
Speaker 1: making money and they want to do more things, then
Speaker 1: they'll have to hire more devs, even if they're AI enabled.
Speaker 1: I think that is kind of like an economics question.
Speaker 1: Will there'll be a point where people would be like, well,
Speaker 1: I'm making enough money, so instead of trying to expand
Speaker 1: and make more money, I'm just gonna keep making the
Speaker 1: money I make and then cut you know, workers. I
Speaker 1: just I just don't think that's really how it happens
Speaker 1: in practice. I think in individual cases companies may make
Speaker 1: that decision, but on like the scale of the whole
Speaker 1: economy just hasn't how it happens throughout history, So this
Speaker 1: could be different. I'm definitely not saying that that's not possible,
Speaker 1: But I say, if you look at technological advances throughout
Speaker 1: history that has never happened.
Speaker 3: Before, there's another aspect here, and go to the whole
Speaker 3: testing aspect of it, think about it. I'll give a
Speaker 3: different analogy. Now, like you said this might yeah, you
Speaker 3: think about pilots with the autopilot. I mean, if you
Speaker 3: think about pilots flying example a plane, commercial jet, the
Speaker 3: autopilot does like ninety something percent of the actual flying
Speaker 3: people don't know, but even the takeoffs and landings these
Speaker 3: days are pretty much automated. But that does not mean
Speaker 3: you don't want a pilot in the plane's cockpit because
Speaker 3: occasionally you have situations that the autopilot can't properly handle
Speaker 3: and you want a person in the loop.
Speaker 1: And like, I've never heard that that example before. That's
Speaker 1: part I'm gonna start using that.
Speaker 3: Well, I mean, I'm going to charge you for that.
Speaker 5: This past weekend, I got a chance to drive a
Speaker 5: Tesla and the guy who owned it was friend of mine,
Speaker 5: and he's like, dude, check this out. And you said
Speaker 5: on autopilot, and he was driving and steering and stuff,
Speaker 5: but it says right there on the screen, be there
Speaker 5: ready in case something happens. Right, you don't just sit
Speaker 5: back and take a nap and okay, wake me up
Speaker 5: when we get to where we're going, because something could
Speaker 5: obviously happen. So you know, as you were talking, that's
Speaker 5: how I'm thinking. It's doing a lot for you, but
Speaker 5: you're still there sort of keeping your eye on it.
Speaker 2: Make sure it's to.
Speaker 3: Be there, happy, be there ready. Sorry, I don't want it,
Speaker 3: because I'd be much more stressed out having my hands
Speaker 3: hanging over the weed rather than simply just holding the weed.
Speaker 4: I don't know, but well, my my thinking on this
Speaker 4: is much more in line with what Anthony explained, And
Speaker 4: you know, I asked the question because I want to
Speaker 4: hear what he thinks. I don't want to tell him
Speaker 4: what I think and then go, you agree.
Speaker 2: You think your idology, right.
Speaker 4: But I look at it and a lot of the
Speaker 4: other technological advances that we've seen where people were like,
Speaker 4: you're going to put people out of work because you
Speaker 4: automated a factory, right, you know, with an assembly line,
Speaker 4: or with you know, with robots or tools or things.
Speaker 4: I mean in some of those cases with the physical products,
Speaker 4: I mean, yeah, you're only going to sell so many
Speaker 4: widgets and so right, yeah, you kind of see that there.
Speaker 4: But with a lot of the other technological advances, and
Speaker 4: especially in software, my experience has been that our backlog
Speaker 4: is longer than we can do in fifty years. Right,
Speaker 4: We've got a zillion things that we want to put
Speaker 4: in there, try out, run with whatever. And so now,
Speaker 4: if you've got developers that cost you more or less.
Speaker 2: What they cost you anyway, and you can give them these.
Speaker 4: Tools to accelerate, you just wind up doing more things
Speaker 4: more than you wind up laying people off. You know,
Speaker 4: that may not always happen in every case, right, There
Speaker 4: may be people that go, you know what, we've cornered
Speaker 4: this market. We're pretty comfortable where we're at, and so yeah,
Speaker 4: they wind up doing the other thing. But my experience
Speaker 4: is is that the cost of making software that does
Speaker 4: what people need is going to wind up going down,
Speaker 4: and that's going to reflect to all of the other
Speaker 4: areas of economy, and the companies that fail to innovate
Speaker 4: with this stuff are going to wind up.
Speaker 2: Getting left behind.
Speaker 4: And you're not going to let Yeah, you're going to
Speaker 4: accelerate all the people you have and make them way
Speaker 4: more efficient so that you can stay competitive.
Speaker 3: Also, look, do I think that we might eventually get
Speaker 3: to a point I don't know when it will be.
Speaker 3: You know, people talk about AGI and stuff like that
Speaker 3: where you don't need a person in the loop. Maybe,
Speaker 3: But when that happens, it won't stop at software. So
Speaker 3: if you're saying you know your job is at risk,
Speaker 3: well I could argue that eventually every job.
Speaker 1: Who made the l M then and them.
Speaker 3: At a certain time.
Speaker 4: If you're talking about a GI that's actually a different
Speaker 4: animal than what we're dealing with here, where it's it's
Speaker 4: more capable of actually making decisions where right now, the llms,
Speaker 4: they kind of do need a human running them, and
Speaker 4: so the idea of an AGI or as superhuman intelligence,
Speaker 4: the idea behind those is that you don't need the
Speaker 4: human behind them, and.
Speaker 2: We're just not there yet. It's a different thing.
Speaker 3: I do think that it is changing what it means
Speaker 3: to be a developer and the skill set associated with it.
Speaker 3: Oh absolutely, although again I'm not exactly one hundred percent
Speaker 3: sure in exactly how because like you said, at the
Speaker 3: end of the day, for example, Anthony, you said, you're
Speaker 3: still going into the code and fixing various things by hand.
Speaker 3: Now maybe with better models you would do it less frequently,
Speaker 3: but you still kind of need to be able to
Speaker 3: do it. It's also interesting for me that at the
Speaker 3: end of the day we are generating code in react
Speaker 3: or generating code in solid and you have to kind
Speaker 3: of think of to ask, like why if at a
Speaker 3: certain point in time, if it's not the person interacting
Speaker 3: with the code, why does it need to even be
Speaker 3: human readable code at.
Speaker 1: Least some of the browser can interpret. That's going to
Speaker 1: be the thing. You'll not be able to go beyond that.
Speaker 1: If you're building for the web, the platform you're building
Speaker 1: with will to kind of define unless the platforms change
Speaker 1: and start accepting English language, then have them spin up
Speaker 1: code on.
Speaker 2: The spot to Yeah. Probably that's just a lot of issues.
Speaker 3: That's probably not the energy efficient. Once you have the
Speaker 3: task worked out, you probably want something more automated.
Speaker 1: I'm just glad we all agree now that React is
Speaker 1: the only thing we'll ever write for the rest of
Speaker 1: our lives.
Speaker 3: No, because we did have We did have an interesting
Speaker 3: conversation recently about the fact that eventually you might get
Speaker 3: to a point in time where if you're talking about
Speaker 3: an agentic web kind of like you know, think about
Speaker 3: Google now, where you put in a query in Google
Speaker 3: and instead of searching necessarily the search result you're you're
Speaker 3: looking at what Gemini generates for you. And currently what
Speaker 3: Gemini generates is mostly text, but you could theoretically think
Speaker 3: about the future where Gemini effectively generates a web page
Speaker 3: for you based on what you requested.
Speaker 4: Hang on, I've got to take off, so I'll let
Speaker 4: Anthony answer, but I've got to go.
Speaker 2: So yeah, really interesting to see how this wraps up.
Speaker 3: Bye, guys. So Anthony, now it's just it's going to
Speaker 3: be just the two of us, I guess.
Speaker 2: Yeah, it's all get out of talking. Dan the same here,
Speaker 2: where are you working these days?
Speaker 3: If we're taking a detour, we still have audience. So
Speaker 3: just so you know, this is not a part of conversation.
Speaker 3: I'm actually working for the past year. I've left the
Speaker 3: previous company that I worked at, Next Insurance, but year ago.
Speaker 3: By the way, they just recently got sold, which is
Speaker 3: nice because I kept my stock. Hell yeah, yeah, And
Speaker 3: now I'm working at a company called size Sense, which
Speaker 3: does analytics, and we are very much impacted by AI.
Speaker 3: Both in the development process. We are kind of doing
Speaker 3: the AI revolution inside like it. Basically managements came basically
Speaker 3: gave a mandate that all development, I won't say it's
Speaker 3: VIBE coded, we're not there yet, but all development is
Speaker 3: now AI assisted and even AI driven.
Speaker 2: That's super interesting. So this is relevant to the conversation then.
Speaker 3: Yeah, for sure. So for example, all the Typeescript JavaScript development,
Speaker 3: because we still have some legacy stuff even written in JavaScript,
Speaker 3: all of that stuff is now being done with cursor. Interestingly,
Speaker 3: a lot of our back end is implemented in Java,
Speaker 3: and Java people are having a hard time with it.
Speaker 3: They've tried to use cursor and it's I don't know
Speaker 3: exactly why. I haven't looked into it personally, but they're having.
Speaker 1: Tell exactly why because the models weren't trained on Java.
Speaker 2: They were trained on Python and JavaScript code.
Speaker 3: But I think it's even beyond that. They're even getting
Speaker 3: you know, Cursor is essentially vis code with stuff, and
Speaker 3: they're getting it. They're facing all sorts of challenges to
Speaker 3: work with the Java tooling, stuff like.
Speaker 2: That tool is all divine for it. Intelligent, yeah, stuff
Speaker 2: like that.
Speaker 3: So they literally even have you know, some of the
Speaker 3: developers literally tried to work by having both Intelligent and
Speaker 3: Cursor open at the same time working Cursor, but do
Speaker 3: all the builds from Intelligent and you know, having them
Speaker 3: sink and they're not having fun.
Speaker 1: Yeah, well that's how That's how I always felt what
Speaker 1: I had to write Java, So now you know how
Speaker 1: the rest of us felt.
Speaker 3: Well, look, I've gone through all through all the programming languages,
Speaker 3: just so you know, I've started the.
Speaker 2: Worst, right, no comment, I don't hear Java is the best.
Speaker 3: Well, let's put it this way. When I moved from
Speaker 3: I had a certain stint using the visual Basic and
Speaker 3: move moving moving from Visual Basic to Java was actually
Speaker 3: pleasurable move because I prefer the see the curly bracket
Speaker 3: syntax over you know, if and if and stuff like that.
Speaker 3: But going back to our original topic, so you're saying that,
Speaker 3: let me put it bluntly, would you have been able
Speaker 3: to do this project without this whole AI assistant development?
Speaker 1: Probably not, I would say, because you know, it's kind
Speaker 1: of a question of I could, but it would have
Speaker 1: taken so long that almost wouldn't have been worth it
Speaker 1: for me for me to do it, you know. So
Speaker 1: I do think it has been a step change in
Speaker 1: enabling me to build stuff that would have been very
Speaker 1: challenging for me to have built in the past in
Speaker 1: a reasonable amount of time.
Speaker 2: You know.
Speaker 1: And this is partly fully admit, this partly do with
Speaker 1: my level of experience. You know, I didn't start coding
Speaker 1: until my late twenties. I've been a professional dev for
Speaker 1: about five years now. Someone who has been a professional
Speaker 1: dev for fifteen years. It'll be very different in terms
Speaker 1: of what an LM enables them to do before and after.
Speaker 1: I think it will speed them up if they use
Speaker 1: it correctly, but it will be less of a thing
Speaker 1: where it will be a step change in enabling them
Speaker 1: to build brand new stuff. And there's actually there's there's
Speaker 1: academic research to support this that shows people who are
Speaker 1: you know, junior to intermediate gain the most from LMS.
Speaker 1: That's not just in software development, that's across all like
Speaker 1: legal and stuff like that.
Speaker 3: So I'm having an interesting experience right now. As I mentioned,
Speaker 3: we're using it with a lot of existing legacy projects.
Speaker 3: So for example, we have a legacy project which is
Speaker 3: implemented in JavaScript with React and class components, and manually
Speaker 3: transitioning from class components to functional components and hooks is well,
Speaker 3: it's very it's labor intensive and and and but fairly boring.
Speaker 3: Not a lot of creativity involved in that. Let's put
Speaker 3: it this way, and it's definitely something that you can
Speaker 3: tell an LLM to do. You'll probably need to fix
Speaker 3: the results, but maybe do as tests to the test. Well, obviously,
Speaker 3: whenever you're doing the factoring, well, let's put it this way,
Speaker 3: when you're doing factoring, it doesn't really matter what you're using,
Speaker 3: manually or at LM or whatever. You need to have
Speaker 3: robust tests as as a baseline. You can't. I would
Speaker 3: never start to major a significant refactor with out good
Speaker 3: test coverage. But it's really effort intensive to do this
Speaker 3: kind of thing, labor intensive, and it's it's not very
Speaker 3: interesting work, it's not very rewarding work. So if you
Speaker 3: can jumpstart this process within LLM, that's a significant upside.
Speaker 3: So it's not just for let's vibe code a new project.
Speaker 3: From my perspective, it's also very very useful when it's
Speaker 3: let's refactor an existing project and get it to where
Speaker 3: we would like it to be, something that otherwise might
Speaker 3: be so labor intensive that we might never actually do it.
Speaker 2: No, I totally agree.
Speaker 1: I'll tell people the same thing, and I think this
Speaker 1: may be finally the point in time we like rewrite
Speaker 1: all those cobol apps, you know, or get off of
Speaker 1: Java so that you could then have a better dev
Speaker 1: experience with llms.
Speaker 2: So I agree, refactors.
Speaker 1: Now are you can do a lot larger refactors a
Speaker 1: lot faster with LMS. For sure.
Speaker 3: That'll interesting telling it telling an LLM here's the Java application,
Speaker 3: rewrite it in a node or something like that and
Speaker 3: see what happens.
Speaker 2: Yeah, that'll be hard.
Speaker 1: The React class composed to functional composed would be a
Speaker 1: little easier because you can do you know, business pieces
Speaker 1: at a time. But if you just have to switch
Speaker 1: the entire language, you almost have to refactor like the
Speaker 1: entire thing.
Speaker 3: Yeah, that is true, but so an interesting point that
Speaker 3: you raised about being an experience rather than a relatively
Speaker 3: less experienced developer. I can see it working both in
Speaker 3: favor and against both types of developers. Like let's consider
Speaker 3: the junior developer. On the one hand, you might say
Speaker 3: that you using that an LAM that if you've got
Speaker 3: a team that let's say in the past you might
Speaker 3: have a team with one senior developers and two juniors. Well,
Speaker 3: now you might just give the senior an LM and
Speaker 3: tell them you don't need the juniors anymore. You can
Speaker 3: effectively get at the LM to do the junior stuff
Speaker 3: for you, and then you're under You're going back to
Speaker 3: Chuck's question before you're potentially undercutting the work of junior developers.
Speaker 3: Do you think there's a risk.
Speaker 1: Of that potentially? It's I think it'll be an economic
Speaker 1: question for the company. Do they get more value out
Speaker 1: of having their senior dev have an LM do the
Speaker 1: junior dev work, or would be better to have the
Speaker 1: two junior devs use an LM and get closer to
Speaker 1: senior work, because then you would have you know, you
Speaker 1: think of it has having a senior and two half seniors.
Speaker 3: But you would still need the senior, or could you?
Speaker 3: So it works both ways. It could be maybe I
Speaker 3: just keep the senior and have the LLLM instead of
Speaker 3: the two juniors, or maybe I could have the two
Speaker 3: juniors working as semi seniors and doing without the senior,
Speaker 3: or maybe with fewer seniors.
Speaker 1: That gets back to what Chuck said though, is that
Speaker 1: you do have a finite amount of work for them
Speaker 1: to do, or is it once they've done their work
Speaker 1: you have more work for them to do, in which
Speaker 1: case having more means you do more work.
Speaker 3: My opinion, by the way, is that you would still
Speaker 3: need the senior, but for a slightly different thing like
Speaker 3: what from my perspective, at the core of software development
Speaker 3: is the ability to take complex problems and break them
Speaker 3: down into several simpler problems that you can then take
Speaker 3: the way the results and bush them together and get
Speaker 3: the solution for the original complex problem. And you do
Speaker 3: this recursively or iteratively until you get to such simple
Speaker 3: problems that are relatively straightforward to implement, and even if
Speaker 3: you're using an LLM, you'd still need to have a
Speaker 3: person kind of driving this process. I mean, think about
Speaker 3: you developing your app. You couldn't tell the l here's
Speaker 3: my idea. Now go develop an app for it and
Speaker 3: do all the development process and just send me a
Speaker 3: text when you're done.
Speaker 2: You know.
Speaker 3: Again, maybe we'll get there one day, but we're totally
Speaker 3: not there yet. So that's what I think you need
Speaker 3: the seniors for, and in a lot of ways, that's
Speaker 3: what you need the seniors for with juniors anyway.
Speaker 2: Yeah, no, I agree.
Speaker 1: So I think I think that the argument you're making,
Speaker 1: and what I agree with is that seniors are probably
Speaker 1: going to be sticking around. If people are being replaced
Speaker 1: because of lms, it's probably that's going to be harder
Speaker 1: to break in if you're.
Speaker 3: A junior, which will raise an issue for the industry
Speaker 3: because if you don't have juniors, well with, where will
Speaker 3: the seniors come from?
Speaker 2: Yeah?
Speaker 3: So, how so you know when when you're vibe coding,
Speaker 3: how do you know when you're done?
Speaker 1: Well, the it is for me, it's just how I
Speaker 1: built the feature that I wanted to build. You know,
Speaker 1: Like you were talking about how the point of the
Speaker 1: seniors to kind of have this vision, what is the
Speaker 1: problem you're trying to solve and how do you get there?
Speaker 1: So for me, it's like I first had this initial
Speaker 1: vision of a workflow I wanted where I could generate
Speaker 1: show notes without any manual steps along the way, and
Speaker 1: then from there I've just been adding on more features,
Speaker 1: like oh, I wanted to be able to work with
Speaker 1: not just audio files but also video files so it
Speaker 1: can extract the audio. Or I want additional prompts so
Speaker 1: it could do more, or oh, I want to be
Speaker 1: able to run it twice on different lms, or oh,
Speaker 1: once it gives me the output, I then want to
Speaker 1: run text to speech so I could listen to the
Speaker 1: show notes, or oh, I want to now generate a
Speaker 1: cover image, so I need to text to an image.
Speaker 3: You should just release it.
Speaker 2: Well, it is released, That's what I'm saying.
Speaker 3: It is released. Yeah, can use it. Cool, So obviously
Speaker 3: I think you are right. You gave the link both
Speaker 3: to the production version and to the development version that
Speaker 3: people can try out.
Speaker 2: Yeah, people should go to I could screenshat and I
Speaker 2: can show you if you want.
Speaker 3: Yeah, well maybe we'll do it quickly. Although again for
Speaker 3: people listening on the podcast.
Speaker 2: That's yeah, I can.
Speaker 1: I'll speak through what's that's kind of happening, so's it'll
Speaker 1: be quicker. We'll take me very long to kind of
Speaker 1: go through it. So so you have interface where you just.
Speaker 3: Start before you continue to our listeners. Again, Anthony will
Speaker 3: be describing what he's showing. But if you really want
Speaker 3: to see you can always find that. You'll be able
Speaker 3: to find the video on YouTube because we always release
Speaker 3: the episodes also on YouTube as actual videos as well.
Speaker 2: Yep.
Speaker 1: And then how do I hope shure, how do I
Speaker 1: get this off screen? Are you able to see the
Speaker 1: riverside thing right now?
Speaker 3: Yeah? Yes, I am, okay, I just track it a
Speaker 3: little bit. Yeah like that.
Speaker 2: Okay, great.
Speaker 1: So you start with selecting either a file from your
Speaker 1: computer or you give a video you arel link.
Speaker 2: It doesn't just have to be you.
Speaker 1: It could be something like Twitch or Vimeo, any kind
Speaker 1: of service works. And then after you select the thing
Speaker 1: you want to process.
Speaker 2: Oh wait, that's good.
Speaker 1: Yeah, then it gives you the available transcription services and
Speaker 1: you select which one you want. There's a credit system,
Speaker 1: so depending on whether you use a more expensive transcription
Speaker 1: model versus cheaper, you'll have different credit options, and you
Speaker 1: just it's just per usage, so there's no subscription. It's
Speaker 1: it's pretty simple. After you select your transcription service, you
Speaker 1: select the prompt you want to use. There's a ton
Speaker 1: of prompts right now. Things based around content, so different
Speaker 1: length summaries, and chapters. You can pull out quotes. You
Speaker 1: can create social media posts, blog posts. You can do
Speaker 1: business related stuff, create email campaign series, press releases. You
Speaker 1: can do creative stuff like songs and short stories. You
Speaker 1: can create educational material, and then stuff like personal professional development.
Speaker 1: So I'm going to add what you have over them.
Speaker 1: It will show you a quick preview of each so
Speaker 1: you can kind of tell what is actually going to
Speaker 1: give you. That's just something I haven't done quite yet.
Speaker 1: Then you'll select your LLM.
Speaker 3: Do you have a question, No, just a thought or
Speaker 3: suggestion that eventually you may want to implement some sort
Speaker 3: of a plug in mechanism which will make it both
Speaker 3: easier for you to add new features without having to
Speaker 3: release new versions, but also make it possible for third
Speaker 3: parties to add their own plugins into your system.
Speaker 2: So what would be a plugin that would.
Speaker 3: Like all those services that you showed before, would be plugins.
Speaker 1: Okay, but that would still have to something would have
Speaker 1: to deploy and then.
Speaker 3: Yeah, they would need to be somehow deployed securely into
Speaker 3: your system. I'm not saying that it's a trivial, but
Speaker 3: it would make the system a lot more or extensible,
Speaker 3: both make it. Generally speaking, whenever something is a service
Speaker 3: that you can invoke from your system, you should always
Speaker 3: think about whether that can or should be a plug in,
Speaker 3: because a it kind of decouples the infrastructure itself from
Speaker 3: that particular type of processing and also again makes it
Speaker 3: possible for somebody else to effectively extend your system. Now,
Speaker 3: then you get into other interesting questions about what you know,
Speaker 3: Like you said, how do I do something like that securely?
Speaker 3: How do I prevent data leaks? How do I monetize it?
Speaker 3: Stuff like that. But it's still it opens up a
Speaker 3: lot of possibilities.
Speaker 1: Yeah, and I am planning on having the kind of
Speaker 1: back end API of this be exposed to other people
Speaker 1: like so of like Chuck, if he wants to use this,
Speaker 1: you wouldn't have to go straight through the front end.
Speaker 3: Yeah. Yeah, but that's using you as a service. I'm
Speaker 3: talking about you using other services to perform particular operations.
Speaker 2: Yeah, it's possible for sure.
Speaker 3: Now now, So one of the issues that I recall
Speaker 3: people bringing up, you know, when people have that had
Speaker 3: no experience in software development at all, vibe coded like
Speaker 3: services that actually that they actually sold or provided, they
Speaker 3: ran into all sorts of security issues, like silly things
Speaker 3: like putting the AWS keys on in the front end
Speaker 3: code or stuff like that, because obviously the LLM doesn't care.
Speaker 3: How do you, given that you effectively are not writing
Speaker 3: a lot of the code that you're generating, how are
Speaker 3: you preventing these sort of things from happening.
Speaker 2: Yeah, so you can actually finish the flow first, and.
Speaker 1: Then I'll answer yeah, sorry, sorry, Yeah, that's all good.
Speaker 1: So then you select the model you want. We have
Speaker 1: chat Schibt, Claude and Gemini, and then it gives you
Speaker 1: the show notes this this styling needs to be fixed.
Speaker 2: He'll be a little nicer.
Speaker 1: I actually ran this on a Java javas jams first episode,
Speaker 1: so we can kind of see what the output is.
Speaker 1: So we see here we have an episode summary. I'll
Speaker 1: just read like the first sentence this inaugural episode. JavaScript
Speaker 1: Jobber introduces the podcast and panel members featuring aj O'Neil,
Speaker 1: Peter Cooper, Jamison Dance and Charles Ball.
Speaker 3: The old school guys.
Speaker 1: Yeah, and then it gets you the chapters and then
Speaker 1: if you keep scrolling, you'll see the prompt that gave
Speaker 1: it to you. When I first shared this with my
Speaker 1: friend Scott, he thought that was a mistake. He's like,
Speaker 1: you know, you're showing people the prompt, right, And I'm like, well, yeah,
Speaker 1: I want him to see the prompt that was used.
Speaker 2: To generate He's like, but that's the secret, sauce.
Speaker 1: Why would they use your service and they can just
Speaker 1: use the prompt And I kind of get they're coming from.
Speaker 1: But there's all this other stuff beyond the prompt that
Speaker 1: the app does, Like it's the the uses that it
Speaker 1: you know, takes, processes the video and connects to a
Speaker 1: transcription service, and connects to an LM service. It does
Speaker 1: the whole thing. So I think there's still value to
Speaker 1: the app even if you do include the prompt.
Speaker 3: That might be I agree, because also people use these
Speaker 3: sort of things in order to save time and effort.
Speaker 3: If if you know, they could copy the prompt and
Speaker 3: they could get some of the functionality, but at the
Speaker 3: significant expense of time and effort, the process would certainly
Speaker 3: not be a streamline, so for sure.
Speaker 2: And then this is a bug the transcript should be here?
Speaker 2: Is that something for me to fix?
Speaker 1: And so the transcript will be included along with the
Speaker 1: show notes, and then you can see some configuration like
Speaker 1: what model did you use? How many credits did it
Speaker 1: cost you? And then metadata includes like the title, the
Speaker 1: YouTube linkt came from the YouTube channels connected to you
Speaker 1: can see the cover and from the show as well.
Speaker 1: So a lot of this you could kind of take.
Speaker 1: You could turn this straight into like a markdown file
Speaker 1: with front matter that can be a web page for
Speaker 1: each of your episodes or something that's kind of what
Speaker 1: I do on my website for all my videos I do.
Speaker 3: It seems that NLMs have really been revolutionary for content creators,
Speaker 3: and that's yet another great example, like at the end
Speaker 3: of the day, it's a person creating the content, but
Speaker 3: it's the NLM doing a lot of the chores and
Speaker 3: all these sorts of things around the actual content, stuff
Speaker 3: that otherwise would have taken away time that could have
Speaker 3: been spent creating even more content.
Speaker 2: M yeh. Yeah.
Speaker 1: So going back to your security question, So for me,
Speaker 1: I do have enough experience to know, basic security things
Speaker 1: like don't put API keys in your front end stuff
Speaker 1: like that. So that is where you know, just having
Speaker 1: some sort of de experience us in handy. If you're
Speaker 1: not a dev at all, you're trying to launch a
Speaker 1: whole app, that it's very risky, and I would recommend
Speaker 1: trying to find someone you could pay some sort of
Speaker 1: small amount of money to at least you a very
Speaker 1: very baseline security check for you. If you can't do that,
Speaker 1: spend a lot of time prompting your LM to have
Speaker 1: it give you instructions for security testing your app, so
Speaker 1: for higher level stuff like pros sise scripting and stuff
Speaker 1: like that. I am in the process right now of
Speaker 1: kind of hardening the application. I didn't roll my own
Speaker 1: off I didn't roll my own payments, so that also
Speaker 1: I'm kind of.
Speaker 2: Leaning on the services to do some security for me.
Speaker 1: Banking on Clerk and Stripe handling, you know, their end
Speaker 1: of the security, and that I have to just make
Speaker 1: sure that the app itself can't get hacks. So someone
Speaker 1: could then have access to like your your credits and
Speaker 1: your credit card that's attached to Stripe and things like that.
Speaker 3: And the main advantage is obviously, aside from you know,
Speaker 3: reducing that effort is the fact that there are a
Speaker 3: lot of examples out there of people integrating with Clerk
Speaker 3: and with Stripes, so the LLM is not short of
Speaker 3: for usage proper usage examples.
Speaker 2: Yeah, totally.
Speaker 1: And this raises the value of these third party services
Speaker 1: and leans even further into the don't roll your own
Speaker 1: off kind of argue, which which I see both sides there.
Speaker 2: For sure.
Speaker 1: I'm not saying no one should ever roll their own off,
Speaker 1: but for for me and what I'm doing, what I'm billing,
Speaker 1: it definitely makes more sense for me not to roll
Speaker 1: my Okay.
Speaker 3: Then we are running towards the end of the of
Speaker 3: the show, so before we wrap up, is there anything
Speaker 3: else you would like to speak to say, either about
Speaker 3: the service you're created, or about vibe coding in general,
Speaker 3: or anything that we might have missed. Yeah.
Speaker 1: I mean, I just encourage devs or even non devs
Speaker 1: to try and work with lms as much as they
Speaker 1: can and try and really understand how they work, what
Speaker 1: you can do with them to get the most out
Speaker 1: of them, what or weaknesses are, and a lot of
Speaker 1: this you're only really going to get through experience. I
Speaker 1: personally find it really fun. I'm having more fun developing
Speaker 1: now than I ever have. One of my friends was like,
Speaker 1: it's so boring the code LM. You just sit there
Speaker 1: wait for the LM to write the code. And it's like, well,
Speaker 1: you know, do some dishes in the middle.
Speaker 2: That's what I do.
Speaker 1: I literally do chores while I code. I'll do a
Speaker 1: prompt and ask this writing code. I'll like do like
Speaker 1: a minute or two of chores and then come back
Speaker 1: to my computer.
Speaker 2: That's kind of It.
Speaker 3: Kind of reminds me of the old days when we
Speaker 3: would be running compilers like you know, yeah, a lot
Speaker 3: of coding and C plus plus and stuff like that,
Speaker 3: and the and in the old computers way back when
Speaker 3: you know, before we had the end ones will take
Speaker 3: a while to run, and we would like sit there
Speaker 3: and you know, surf the web or whatever while the
Speaker 3: compiler was running.
Speaker 1: So is that those XKCD comic or two do just
Speaker 1: like sort fighting in the office and like, hey, what
Speaker 1: are you doing, Like we're waiting for code compile.
Speaker 3: He's like, okay, yeah, I got so now we're it's
Speaker 3: we're waiting for the L and M to finish.
Speaker 1: Yeah, no, I've actually I've made that same comparison actually
Speaker 1: for sure. So yeah, I would also say try out
Speaker 1: different models, you know, see which ones you feel like
Speaker 1: work best for you, and don't feel like you have
Speaker 1: to like dive headfirst into the entire AI space. Really
Speaker 1: the most important thing is just, you know, finding a
Speaker 1: model that works for you and can be useful for you,
Speaker 1: and try and work it into like your day to
Speaker 1: day stuff, even if it's not coding. If you have
Speaker 1: some sort of other tasks that you feel like could
Speaker 1: be faster automated, just throw into an LM and see
Speaker 1: what happens. And they're getting better all the time. They're
Speaker 1: connecting to more external services all the time. I would say,
Speaker 1: don't worry abou jumping into MCP yet. Like MCP is
Speaker 1: cool and it's going to be revolutionary, but it's super
Speaker 1: new and it's probably not something that people should really
Speaker 1: jump into unless they like working with new tech when
Speaker 1: it's kind of in changing breaking states, you know.
Speaker 3: Yeah. Cool. So we usually have picks, but to be honest,
Speaker 3: I don't have any special pick today. Do you have
Speaker 3: anything that you would like to shout out as a
Speaker 3: pick before we finish?
Speaker 1: I mean, the things I mentioned throughout the episode. Repo
Speaker 1: mix is cool. Check out Claude definitely. If you're looking
Speaker 1: at a code, I think that's probably the best one
Speaker 1: right now in terms of you know, price and features
Speaker 1: and speed and all that.
Speaker 2: And then check out auto Show. Let me know what
Speaker 2: you think.
Speaker 1: I just launched it like a week ago, so it's
Speaker 1: still pretty new and there may be some bugs and
Speaker 1: things like that. Just hit me up online if any
Speaker 1: of that happens. I'll use some free credits to test
Speaker 1: it out.
Speaker 2: If you want. Ajac webdev everyone on the.
Speaker 1: Internets x YouTube LinkedIn GitHub, So yeah, check it out.
Speaker 2: Let me know if it's useful for you.
Speaker 1: Let me know if there's features you want me to
Speaker 1: build or prompts you want me to add. You'll have
Speaker 1: the ability to write your own custom prompts pretty soon
Speaker 1: if you don't want to use any of the regular prompts.
Speaker 2: And uh yeah, that's that's pretty much it.
Speaker 3: Excellent. Thank you very much for coming on the show.
Speaker 3: I think you shared a lot of super useful information.
Speaker 3: I think we're literally watching our revolution and your case
Speaker 3: in point. So thank you again, and to all our listeners,
Speaker 3: thank you for listening in and see you next. Time
Speaker 3: bye