1019: LGTM, Ship It: The AI Code Review Problem

This episode tackles the growing pains of AI-assisted development, from the struggle of reviewing thousands of lines of agent-generated code to the mounting technical debt when teams merge PRs without meaningful human review. Scott and Wes also dig into local models, whether jujutsu really beats git, how freelancers should price work in the AI era, and getting your team on board with external libraries. Show Notes 00:00 Welcome to Syntax! 00:45 Understanding AI-Generated Code 06:24 The Challenges of Code Review in AI Development 11:21 What the heck are local models? CJ’s Guide to Local AI 16:09 Exploring New Tools: Jujutsu and Beyond 20:35 Exploring Version Control Innovations 22:18 Pricing Strategies in the Age of AI 24:52 webkit-box-reflect not in the browsers. 27:44 The Angular vs. React Debate 31:46 Sick Picks & Shameless Plugs. Sick Picks Scott: Huggingface Reachy Mini Robot Wes: Bose QC35 Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00Scott Tolinski?

  This company is merging 60 PRs per developer per week and everything is a mess. I got a robot. They are bringing in external dependencies into your projects. Is it worth it? Specific tips on AI and writing UI code. What are local AI models even? We're going to be talking about all these and more in this Syntax Potluck. That's right. This is our Syntax Potluck episode where you bring the questions, we bring the answers. And if you have questions for us, head on over to syntax.fm and ask a question for us and we will get to it on a future show. So let's get into it. Yep.

• 0:45Scott Tolinski?

  All right. So the first question today from Deep Sea Goose. I just listened to episode 1,010. Wow, this is crazy where past 1,010. Which was a Potluck episode with a lot of AI questions. The problem I'm struggling with is whenever I ask an AI agent to create a component or any large piece of code, it takes me a considerable amount of time to understand what it wrote before I can make any changes. What advice do you have to help me better understand the code it generates? Yeah, well, okay. So there's a number of things.

• 1:24Scott Tolinski?

  Sometimes the AIs, the when they write components, man, they write the craziest like rat's nest of function calling a function, calling a function, and then throw it all in like an effect brained kind of way and really over rely on things like side effects and can make really understanding the code that AI writes a little confusing sometimes because it's quite simply not good or it is good and it's just different than how you would have written it. One thing that I like personally is having it write terse comments in line with the code. Just like, one, it's documenting the code.

• 2:04Scott Tolinski?

  Two, it's, it is easier for me to reason about in English than to reason about in some other way of authoring code that perhaps I'm not used to at that particular time. So if I'm trying to deeply understand the code it's being, it's writing after it's written a large component, one, comments. Two, I like to lean on a lot of rules, particularly. When I'm working with AI agents myself, I heavily dictate the style at which they're allowed to write components in. You know, in the Svelte world, I'm saying, do not use effect. Don't even think about it. Side effects are almost never the right decision here.

• 2:46Wes Bos?

  Yeah.

• 2:46Scott Tolinski?

  But because so many things happen in effects in React, it's always wanting to lean towards that. So I have a number of strict rules that I give it when I'm prompting. So therefore, when I go to read the code, it reads like the code I want to read.

• 2:59Wes Bos?

  Yeah, I think with UI code specifically, because that often dictates how it looks, I find myself drilling in a little closer with with the UI. Whereas like, if I'm writing some like backend functionality, I have no problem for it to generate several hundred lines or maybe even a thousand lines of like functionality. You know, you got your database and everything.

• 3:24Scott Tolinski?

  Is object function.

• 3:26Wes Bos?

  Yeah.

• 3:26Scott Tolinski?

  Is even function.

• 3:28Wes Bos?

  It's pretty good at like, actual subjective functionality. But when it comes to actually building out the UI, I drill in a little closer and spend a lot more time on it and do sort of smaller changes. Because I think that's why a lot of these apps feel like crap. It's because the UIs on them are just absolutely awful. They technically work well, but how you use them, how you interact with them and what they look like is often is a lot to be desired. So my recommendation here is just drill in and use it at a much smaller. Hell, even go back to using tab completion if you must for that type of thing. Other

• 4:08Wes Bos?

  things you can lean on, like Scott says, is lots of rules in there. Example code prompts over if something should be duplicated or not. I find that that's a really interesting one where.

• 4:20Scott Tolinski?

  Yeah.

• 4:20Wes Bos?

  You have two things that have somewhat overlapping functionality. And in some cases, you want to just duplicate them. And they're different enough that I just want to be able to have the code in this component and not have to like factor it out into some reusable thing. In other cases, yeah, you want to like say, okay, here is a validation step, or here's what we do when you upload an image, right? That shares enough code that you want to bring that out and put it into a util library. I find the AI is not great at that. So in that case, you should be making smaller changes so that you are more dialed into what is actually happening.

• 5:01Scott Tolinski?

  Yeah, I mean, on the UI or on the utility tip, you know, one thing that I have in all of my agents' files is really just that, like to create shared utilities in one location. And like, here's a directory of shared utilities. Always check to make sure a utility doesn't already exist. Like, here's the place you're looking for utilities. Do not create one locally. Create it globally, import it. And you use those global utilities because that way it's easier to check. If it's creating like an inline utility function or whatever that it just uses once, it could duplicate that code 100 times.

• 5:36Wes Bos?

  Yeah, I think as you do more of this stuff, you'll get to a level of comfort knowing I'm happy with this type of thing. I'm happy to like, trust that the code generated is up to my satisfaction. I don't think you have to read every single line and absolutely know what everything is doing. But you should be prompting it in such a way that you do understand where it is. For mission critical stuff, there's certainly other projects where I just, I haven't even looked at a lot of code.

• 6:04Scott Tolinski?

  Yeah.

• 6:04Wes Bos?

  Yeah, exactly.

• 6:06Scott Tolinski?

  Yeah, and I think it is a lot of it is setting up those standards, those standards of what you want to see, those deterministic tools, whether that's the linting stuff or whatever. And like, the ways that you can have your code work that just, hmm, you don't need to have an eye on it if you have a good set of rules.

• 6:25Wes Bos?

  This next question is exactly what you don't want to happen because I love this. Yeah, let's do this. There's a question from LGTM Bro. On my team, a common workflow is an engineer asks an agent to implement a feature or fix a bug, open a PR, address automated review comments if necessary, waits for CI to pass and merges. In many cases, there is little to no meaningful human review of the actual code. This is certainly a problem right now is that the bottleneck is not in generating the code. The bottleneck is trying to review it and make sure that what is implemented is actually, not even that it has to be good code, but it actually does what you're doing and not breaking everything and all that stuff, right?

• 7:10Wes Bos?

  So it goes on to say, "Some individual contributors are merging 60 PR releases per cycle, which is about a week." So you're merging 60 PRs a week. Holy hell. "Including changes spanning 20 to 75 files and thousands of lines of code. The volume alone makes it difficult to believe that anybody is thoroughly understanding, validating these changes. The results appear to be a steadily increasing amount of technical debt, reoccurring bug, architecture inconsistencies, fragile implementations, and code bases that are becoming progressively harder to extend and maintain. The product is awful." This is kind of interesting because we have these new superpowers and you're seeing teams do one of two things.

• 7:53Wes Bos?

  One, feature canon. Any feature you want, boom. Let me just copy what you want, paste it into the box and I will sit there and watch it do it. And then the other, the other people that is like, "I'm looking at some of these apps." And I'm like, "Why am I using this app for so many years? And there's literally been no features or things that have been added to it yet." Like you have these new feature canons, like what's going on? And what a lot of those companies are doing is they are saying, "Wow, we have this super, superpower. Let's spend the next year or whatever, or six months cleaning up all of the stuff that we have been saying that we want to fix.

• 8:37Wes Bos?

  We've been saying for so many years that I want to be able to get this into spot." And I have this with a lot of my apps where I'm like, "I'd love to implement this feature, but I would love to..." Move to this database first. I'd love to clean up my utilities first. I'd love to, to do all of these things. So a lot of people are saying, ah, we got all this technical debt, which we can finally solve. So they're using AI to refactor all of that type of stuff. So I think like, we could talk all day about like, oh yeah, you should implement like, features and tools and linting and all of this stuff. But I think that this problem goes beyond the proper prompts and skills and tools that you have. And it's like, well, well, well, turns out all of the stuff that we talked about for 10 years about good software engineering

• 9:23Wes Bos?

  still applies, right? And, and you're just doing it on like, you're just speedrunning it on, on like fast mode now where it may have, might have taken you six years previously to get to a point where your codebase is a mess and things are duplicated. The problems you are describing here are not new at all. And the solutions to these problems are not new either at all. You, we know how to, how to make a good software. And the fact that you guys are just doing it on a speedrun is just making it much faster.

• 9:55Scott Tolinski?

  Man, that's crazy. 60 plus PRs in a release cycle. That's one week.

• 10:00Wes Bos?

  And some individuals, yeah. At that point, like the codebase would be unrecognizable in, in several months. Which is partially not like, like some parts of your codebase, you just don't understand. It's easy. The AI can explain it to you. But those like high level architecture, you know, if you're just adding a whole bunch of crap and duplicating it, it's going to be very tricky to sort of unwind a lot of those, especially if you don't have like tests and whatnot.

• 10:30Scott Tolinski?

  I think one thing that the prompt bros don't realize about this stuff is because, you know, most of them have never maintained old systems or long running systems or these types of things. That tech debt is really real. And tech debt is such a major problem with AI now because it's so easy to add code. And like, AI hates to remove code, even when you beg it to remove code. So like,

• 10:55Scott Tolinski?

  Yeah, I just feel like the amount of code that we be adding sometimes is going to come back to haunt teams. And sure, you know, Fable is gonna come out again and the clouds will part and you'll say, hey, make it better. And they'll make it better.

• 11:12Scott Tolinski?

  And maybe that's the case, but yeah, in the meantime, I think we're going to be seeing a lot of software and apps like barely held together. Cause that's, that's wild to me. Next question here from Sarah Chen. In episode 1009, you mentioned that nobody knows what a local model is. Can you do an explainer on what local models are? Well, local models are just, uh, models that you're running on your local machine. I think some people really disconnect that and think, oh, I'm running the software locally. Therefore it's local, but like when reality, they're going off and doing API calls. That was the whole thing.

• 11:50Wes Bos?

  Yeah, all these people are like, just use a local thing.

• 11:53Scott Tolinski?

  It runs local.

• 11:53Wes Bos?

  So use open code and deep seek for local. That's not local, it's going to China.

• 11:59Scott Tolinski?

  Yeah, so it's, it's literally running, running on your machine. And I will point you to the, uh, CJ did a really incredible video called your guide to local AI. And so instead of just recreating that here, cause you know, we could, I could just recreate CJ's awesome video on the fly here, right? I'm just gonna point you to that cause it's really super good. And he even uses a piece of bread, uh, to show you how big his computer is. So that's fun.

• 12:26Wes Bos?

  Yeah, the, the local model stuff is really interesting. We'll, we'll keep coming back to it because there's like this like idealistic thing of yes, I would love to run local models. It's, it's private and whatever, and it's on my machine and whatever. And then there's the actual, like, you don't realize like, I, again, I'm saying people don't know what local models are. And now I'm going to say like, people don't realize how much compute is actually being thrown at this stuff. Until you try to run something on your own machine. That is of, of the, the quality that you're expecting from like an Opus.

• 13:02Scott Tolinski?

  I will have. Yeah, I'll have a lot more opinions on this once I get a local AI rig and get deep into it because that's coming for me. It's just I'm waiting for some next round of hardware to be released. It's just, yeah.

• 13:16Wes Bos?

  The local AI stuff makes a lot of sense when you're doing purpose-built stuff. When you're doing toxicity detection, when you're trying to detect parts of your face. There are thousands of small models on Hugging Face that you can run in the browser. Look up Transformers JS. We had Xenova on the podcast where there is a lot of really cool stuff that you can run in real time and like that is good, very good in the browser. But they are all dedicated to specific things, you know, doing speech detection, text to

• 13:53Wes Bos?

  speech, tagging things, categorizing things, vectorizing, all of that stuff. So the local AI space is not a monolith that does absolutely everything. It's a specific targeted things that you want to do in your application.

• 14:11Scott Tolinski?

  Yeah, and it's not you're gonna get Fable at home. It's just not.

• 14:14Wes Bos?

  No, no, although there's a guy, there's a guy on Instagram right now and he's, he's saying that he's, he's coding Fable on a laptop and it's like, it's literally on a TV tray and like the psychosis that some of these people have and he's posting screenshots of Claude telling him that he is a 0.1% advanced user and like he'd like literally thinks, he's like, I've only been doing this for 30 days, but we're on to something. We just need a little bit more compute. We're building Fable at home and like he's, he's telling Claude, build me Fable and it's, it's pretending to build it. It's got all these graphs and everything.

• 14:54Scott Tolinski?

  Yeah.

• 14:55Wes Bos?

  Unbelievable, the, the amount of psychosis that goes and I feel bad because it's like they don't, he's, he's never, he's never done anything in computers before. So.

• 15:06Scott Tolinski?

  It's mental illness is really what it is and that's like.

• 15:09Wes Bos?

  It's telling him. It's telling him, you're doing a good job. We're building this.

• 15:12Scott Tolinski?

  You're very handsome. You're doing a great job. Everybody likes you. Yeah.

• 15:16Wes Bos?

  So bummed.

• 15:17Scott Tolinski?

  Yeah.

• 15:17Wes Bos?

  Yeah.

• 15:18Scott Tolinski?

  Yeah, it's crazy. I think we're, we're on the precipice of seeing an endless amount of more.

• 17:43Scott Tolinski?

  Want to do it that way. So that part of it is nice, right? You don't have to like really go nuts on it to to get to use it. There's an operation log of all revision logs, including like your snapshots, your merging, all commits and everything exist in one giant operation log. So at any given point, you can just like run an undo command, which God, man, having an undo command in Git, how many stack overflow posts would that have saved, right?

• 18:10Wes Bos?

  I still do it. I'm like, shoot, how do I like I like I've been using Git for what? Probably 20 years or 15 years, something like that. And I still am like, oh, no, I added something.

• 18:21Scott Tolinski?

  Yeah.

• 18:21Wes Bos?

  That I shouldn't have. And it was not in my Git ignore. Now I have to like, ask AI to do that.

• 18:27Scott Tolinski?

  Yeah. And there's a lot of there's a like automatic rebasing, which I, you know, there's no staging. So everything is just automatically staged. So you never need to stash anything. There's no branches. So there's a concept called bookmarks that are very similar to branches. But they're like, there's no current bookmark. You can just go back to a bookmark. And people say that this makes it really easy to go and make revisions or fix things or merging or conflicts are easier to resolve and things like that. I'm going to say this as somebody who has not used it. So if you have used it, leave a comment below and let us know why you think it's better.

• 19:10Scott Tolinski?

  The one thing that I've noticed when people are talking about JJ is that you hear a lot about from people who are currently using it, have bought in and absolutely love it. But when I started to dive in a little bit more, I found people being like, honestly, even though it is easier to go make and make revisions or this or that, not having like true branches and in that sort of style of working.

• 19:38Scott Tolinski?

  Is too much of a brain shift for me and I just want like, I don't care if I have to go into a rebase as long as I can make my branch, make my changes or whatever. So.

• 19:48Wes Bos?

  I think the next Git thing is gonna be from like Cursor last week announced, um, what was it called? Cursor Origin, which is their GitHub alternative, you know, and like, I think whatever, whoever like solves this, like what is the next Git slash GitHub is going to be building something for agents that can simply just handle the sheer amount of like committing every single keystroke or every single thought, you know, so you can roll it back and you can try six different things, you know? I think whoever figures that out is going to, is going to win this thing.

• 20:29Wes Bos?

  Making something that's like a slightly different CLI for humans, I don't think is gonna, gonna catch on anymore.

• 20:35Scott Tolinski?

  Well, I did see some arguments saying that JJ was better for agents because of that not needing to branch, right? It can just create bookmarks and versions of files and stuff really easily. That's what I, in practice, I haven't gotten to use it that way. That said, a Zed, uh, of the Zed editor did re, uh, announce, they didn't release because it's in private beta, um, something called Delta DB, a version control that's built on a single coherent abstraction that transforms your conversations with agents and the work trees they edit into shared artifacts. So, um, Delta breaks your work into a stream of fine-grained deltas where Git captures a snapshot

• 21:16Scott Tolinski?

  of each commit, Delta captures every operation in between and gives each one a stable identity. So it seems like Zed is also trying to solve this very problem. So this seems like a frontier that a lot of folks are, um, What do people do on a frontier? I should know this because I live on a frontier.

• 21:37Wes Bos?

  You explore them.

• 21:38Scott Tolinski?

  They're exploring. Yes, they're digging for gold.

• 21:40Wes Bos?

  I think, yeah, that's, that's kind of interesting as well because like you spend all this time chatting back and forth. And then you lose all of that conversation. There's often valuable stuff in the like, why, why did you do something? So maybe if compute in context and all of this stuff is not an issue, like, why not just store absolutely every single thing that has happened? If we need to ever go back and look at it or, or use that context in a new conversation. But compute and storage is certainly a problem right now. So we'll see.

• 22:16Scott Tolinski?

  Yes. All right. Next question from Phonics. As AI enables developers to build features in minutes that previously took hours or days, how should contractors and freelancers price their work fairly by time spent estimating their effort or value delivered? They should price it the exact same way they've always priced it or should have always priced it. Value delivered. Pricing, a lot of, this is something you could have gone back to episode number one of Syntax when we're talking about freelance stuff. And we're talking about like time spent or effort. Like, these aren't what makes for a good quote or anything like that. It can lead you to go off the rails a little bit in spending or, or whatever.

• 23:00Scott Tolinski?

  At the end of the day, I think value derived is the only way to price this kind of work. And frankly, for me, has always been the only type of way to price this work.

• 23:09Wes Bos?

  I, I have charged hourly in, in my career, but that's almost always where they're like, we will bring you in. What we need is maybe unknown at this point, but we just want to pay for 20 hours a week of your time. And you're just going to work on whatever it is. And, and those are okay arrangements, right? Like, that's similar to just having a job. But if you are, if somebody is hiring you to do a task, and how long you do that task should be irrelevant. It's, it's all about the value delivered. And if you spend a whole bunch of your time learning something, building out a bunch of tools, creating, I don't know, an army of agents that is so special that nobody else can do it as well or as fast as you,

• 23:54Wes Bos?

  that shouldn't be.

• 23:57Wes Bos?

  Factored into how how long it takes you, right? You just, you should be billing based on how much value delivered to the client at the end of the day.

• 24:07Wes Bos?

  Certainly, like, these things are going to change. Like, people aren't going to be paying you $600 to, like, refactor a, like, a one-page on their website anymore. When, like, I think, like, what people are willing to pay for and how much you get paid for doing stuff is going to be, or is already changing, right? But that, that doesn't make, make it that you should be charging based on your thing. Maybe tokens.

• 24:35Wes Bos?

  You know, like, at what point does your bill include how many tokens you spent on something? Because now people are saying, like, you're not talking about how much time you spent. But you're like, oh, man, I spent $6,000 with a token.

• 24:47Scott Tolinski?

  I'm spending money to develop that, yeah. Yeah.

• 24:50Wes Bos?

  Weird world. Emil Aben says, hey, folks, do you have any idea why WebKit Box Reflect, such a useful and delightful property for easy CSS reflections, doesn't get standardized, nor Firefox implements it with a vendor prefix? And this goes on for decades at this point. Yeah, so WebKit Box Reflect was something that was added in Safari to basically get the, like, glossy floor effect where you could, like, mirror an image below. And it was never, it never went through a standardization process. It was just added to Safari. Very likely, a lot of weird stuff gets added to Safari because they need it internally.

• 25:32Wes Bos?

  Or they're, they're like, they have some weird screen in iTunes that needs, that is actually built with HTML and CSS, and they need to be able to replicate that effect. Why was it never added to any of the browsers? I think that they're hesitant to add stuff that is trendy. And that whole, like, glossy floor reflection was a huge trend that Apple kicked off. And like, you know, you don't see it anymore.

• 25:55Scott Tolinski?

  Like Cover Flow and the iPods. Yeah, yeah, totally.

• 25:58Wes Bos?

  It's not all that useful anymore. And, and I think, like, your time is better spent on higher-level features that would be able to make that, like HTML and CSS, right? Now you can be able to, or not now, but once HTML and CSS is in all of the browsers, you'd be able to just wrap that component in a canvas. Flip the component, you know, like paint it and then just flip it on on its axis at the the very bottom of the X axis and you can you can replicate that feature rather than saying like this cheesy thing that has no knobs like who needs that? Nobody needs that. It's I don't know. Is it? Is it delightful? I don't think so.

• 26:41Scott Tolinski?

  Yeah, I I mean, like you said, it was a very of a time and and even though now it like feels like very useful in regards to like the CSS battle, stuff like that. Again, very trendy look. I haven't seen a site that I would consider modern use that.

• 26:58Wes Bos?

  No.

• 26:59Scott Tolinski?

  Although like now I feel like I feel like that's got to be a syntax challenge. Who can make the most modern ass looking design using WebKit Box Reflect? Like some very beautiful, modern UI using WebKit Box Reflect.

• 27:17Wes Bos?

  I tried to use it in one of our battles because I needed to duplicate.

• 27:21Scott Tolinski?

  I did do that, yes.

• 27:22Wes Bos?

  But it turned out that it it vertically flipped it and I.

• 27:26Scott Tolinski?

  Correct. I did that. I did that intentionally.

• 27:28Wes Bos?

  Yeah, I didn't. I didn't want. I didn't want that. For some reason, I just needed to duplicate it to another one. So it wasn't wasn't possible. Yeah, there's a lot of weird stuff in in CSS like that.

• 27:42Scott Tolinski?

  Yes, a lot of fun things. All right. Next one here from Moto Moto Likes You Moto Moto Moto. Hey, guys. I work on a medium scale enterprise software product as a front end dev. We use Angular as our framework of choice and it's proven itself a sound investment in the age of AI as it's very opinionated, but that comes with a cost, the cost being that Angular developers tend to rely heavily on framework provided libraries, not willing to try many external libraries which reduce the amount of code we produce and walk the same paths many developers have already walked before us. This is new to me as a former

• 28:23Scott Tolinski?

  React developer pulling in new libraries was not nearly as contentious.

• 28:29Wes Bos?

  React devs will bring a library for anything, yeah?

• 28:32Scott Tolinski?

  React devs, yes, that's the bubble, right? Do you guys have any suggestions for getting the rest of the wider development team on board with using more external libraries? Or are they correct? And we should use the framework tooling as gospel? Currently, we only use a couple like lowdash and hammer JS, but I know there's loads of places we could benefit from it. So this is interesting to me. Somebody who never made the transition to Angular 2, you know, that's when I bowed out of the Angular ecosystem like many other folks did and then spent a lot of time in the React ecosystem where you're right, that the emphasis was often on bringing in other libraries. But that isn't always the emphasis.

• 29:14Scott Tolinski?

  In fact, on LevelUp tutorials, I built just about most components on that site because bringing in libraries has a cost and it always has had a cost. So I think you might be looking at this too much with rose colored glasses in terms of just bringing in and getting easy functionality. That said, I do, I do think you're valid in saying that a lot of work could be saved. But in the age of AI, I think bringing in less libraries is probably a plus. You're opening yourself up to less things. And again, we talked about in the last episode, the last Potluck episode, we talked about the browser standards have evolved and you can lean on the browser standards to augment them with JavaScript.

• 29:55Scott Tolinski?

  So if the AI is good at writing Angular without bringing in extra libraries, that to me seems like a pro. But that is my perspective and that, that's the perspective of somebody who's often kind of largely chosen to do it themselves.

• 30:09Wes Bos?

  Yeah.

• 30:10Scott Tolinski?

  For, you know, yeah, I would say a benefit, but other people might argue the opposite.

• 30:15Wes Bos?

  I think with, yeah, like Scott said, with AI, you don't necessarily need to bring in libraries. Your util's folder can simply just make implementations of everything you know. You certainly have to spend a bit more time making sure that it covers all of your use cases, but it does exactly that. It just covers exactly what you need it to do and you're not adding a whole bunch of extra code for it. And I think a lot of devs like that because. I think that's why Angular has attracted so many non JavaScript devs. You know, like you don't hear about Angular a lot inside of like the JavaScript community because we love piecing together everything ourselves. But for people who are like coming from like Java or Rails or whatever, like just

• 31:00Wes Bos?

  give me the way to do it in absolutely everything. And I think this question has the answer to that. Currently, we only use a couple like low dash and Hammer JS. Hammer JS is a touch library last, last release seven years ago. And low dash, still some use cases here and there, but in many cases, you don't necessarily need low dash. And this is what can happen is that you build the dependency into it and all of a sudden you're stuck seven years later maintaining Hammer JS code that hasn't been touching in forever. So I think I'm going to side with your team on this one.

• 31:43Scott Tolinski?

  Yeah, wow. I'm surprised we agreed on that. So, okay, cool. Well, Wes, do you want to do a sick pick before we get out of here?

• 31:49Wes Bos?

  I do. I got one for you. I'm gonna sick pick the headphones I'm wearing here. So these are 10-year-old Bose QC35s. These are, I've had these headphones forever, 10 years, right? And I have changed out, and people are always like, oh, yeah, I have those, but like I don't use them very much anymore because A, they're micro USB, which nobody, it sucks carrying around a micro USB cable or having one on your desk when like it's the only thing. And B, the like headphone cups are shredded. Well, both of those I've fixed, right? Like I have changed these, you can change them to the ones that aren't stupid and obnoxious, but I've changed mine to cow print.

• 32:30Wes Bos?

  Just, you can just find brand new ones and they feels like a brand new pair of headphones when you put new ones on. The other thing is you can get a charging board from the Bose QC45s online and you can simply just, it's plug and play. There's no soldering or anything. You just take it out, you unclip it, you clip in the new one and boom. You do have to like wallow out the connector hole a little bit. But then i- if you find like a pair of old QC 35s online, or if you have a pair, if you upgrade the pads, make them USB C, they're still my favorite. I have other headphones that are noise cancelling and none of them, none of them are as good as the QC 35s. Still a big fan of them.

• 33:16Scott Tolinski?

  Nice. Yeah, that you, you have been riding with those.

• 33:22Wes Bos?

  For.

• 33:22Scott Tolinski?

  Crazy earphones. Yes, I'm going to sick pick my new robot, the Richie Mini. Hopefully I'm going to try to not to drop him while he does a dance here. I'm gonna have him do a dance because I'm holding him by the base, which I don't, I'm not, I'm not sure how intense that will be.

• 33:37Wes Bos?

  This is, explain what this is. This is a, oh.

• 33:46Scott Tolinski?

  He's going nuts right now. He's doing a little dance.

• 33:50Scott Tolinski?

  So this is a robot. It's by Hugging Face and Pollen. Sorry, he's still making noise. I'll, I'll set him down. Are you done? Okay, so this is a, a robot from Hugging Face and Pollen. And you have to build it yourself. So every little component of it, you have to build. So it took about like two hours to build.

• 34:09Wes Bos?

  Really? Like they give you all the pieces you snapped together?

• 34:13Scott Tolinski?

  Hundred, yes, it was a, it was a very long instruction booklet here. Yeah, 50 page instruction booklet, 50 steps, I should say of, um. Yeah, there's several PCBs in here, you know, power, battery, all that stuff, motors. And there's cameras and microphones and because I did it with the kids, I was having them do a lot of the, the screwing and stuff. So it took a long time because of that, but it was a ton of fun. You can see he's got a lot of stuff going on on the inside. He's very expressive. And the cool thing about this is, is basically you could think of it as like, one, a very expressive Google Home that can move itself,

• 34:55Scott Tolinski?

  has a camera and you connect it to any AI provider. And it has like a fully open app ecosystem with a ton of great examples. So you can download a ton of stuff for this, or right now I wrote an app that connects mine to. My Hermes. So when I'm chatting with this, it's actually using Hermes to get the response. And it has a microphone and speaker, so it will do,

• 35:18Wes Bos?

  Oh, man.

• 35:19Scott Tolinski?

  Text to speech, speech to text. I'm still getting into it. Like, I have a ton of fun app ideas.

• 35:26Wes Bos?

  Yeah.

• 35:26Scott Tolinski?

  It just arrived last night and we just finished building it like 8:00 PM. So I haven't had any chance to really play with it beyond just getting it up and running. But what a cool, cool-ass little thing here. It's pretty sick.

• 35:40Wes Bos?

  So it has Wi-Fi, has motors, has cameras, has speakers.

• 35:44Scott Tolinski?

  Yes.

• 35:45Wes Bos?

  And it's cute. So you could, like, you could,

• 35:47Scott Tolinski?

  And it's cute.

• 35:49Wes Bos?

  So many things with it. Man, my mind is just running. The fact that you made it like a Google Home that you can program is like such a good way to put it.

• 35:57Scott Tolinski?

  Yes, I think that's what it feels like to me. But like, what I'm gonna use it for is like, I'm gonna like, hold up our kids' spelling list and then I'm gonna make an app that they can practice spelling with it. And use like time repetition, because one thing that our kids get really frustrated at when they're bad, when they're like bad at a word, they get really worked up and frustrated about it. And I'm wondering if like having this cute-ass robot be like, oh, that's the like, try to remember it like, will, will help them be engaged a little bit more than just like, oh, let's try again, you know? So I'm gonna build a spelling app for them. I'm gonna build, like I said, I'm connecting it to Hermes, so that will be fun. And then I'm gonna try to build an app that helps us learn Warhammer 40k.

• 36:38Scott Tolinski?

  So that way you could like look at the battlefield and tell us like what to do next and stuff.

• 36:43Wes Bos?

  Ah, it's cool.

• 36:44Scott Tolinski?

  Very stoked.

• 36:44Wes Bos?

  You know what? Like, if anyone listening, like, another cool thing you could do is you could throw,

• 36:51Wes Bos?

  what's the model? I made like a, like a barbell detection a couple of years ago. Every single time you like did a rep, it counted. That was using, why am I forgetting the name of it? It's like a,

• 37:02Scott Tolinski?

  TensorFlow.

• 37:03Wes Bos?

  No, not TensorFlow.

• 37:05Scott Tolinski?

  MediaPipe.

• 37:06Wes Bos?

  MediaPipe, that's it. It was using MediaPipe. And there's, there's three or four models. You could, there's like a hand-tracking MediaPipe, there's like a body-tracking one, and it will like know where your elbows are. Perfect example. That thing can run on low-power hardware, media pipe. You could throw that on the robot and have the robot watch you, and you could figure out, like, count the jumping jacks, you know? Like, that would be one little example you could do with this. That would be cool.

• 37:30Scott Tolinski?

  Yeah, so there's two versions of this robot that you can buy. You have to assemble them all, so if you're not technical and can't, you know, you're not comfortable with assembling it. Like, this was not an easy build. There was no soldering, but it wasn't an easy build. Don't get it, because it's not plug-and-play.

• 37:48Scott Tolinski?

  And it's definitely, like, more technical, but like, yeah. You could, in one version of this West, there's a built-in Raspberry Pi. This version is not that, because those are not out yet. This is the one that does all compute on my laptop. So it can connect over Wi-Fi, and then the compute happens on my machine. So, yes, it communicates with the laptop to handle some things and so apps you're running. But in the Raspberry Pi version of this, it would happen just all on robot.

• 38:21Wes Bos?

  Okay, I see. That's what I did with my Roomba as well, right? Like, I...

• 38:26Scott Tolinski?

  Yes.

• 38:27Wes Bos?

  I put... No, I didn't, actually. No, I put the code on ESP32. But when I was first doing it, I was communicating wirelessly from my computer, and so I could do the more intensive stuff. That is sick. I want one of these.

• 38:44Scott Tolinski?

  I'm going to, one, I'm going to make a big, detailed video on it, on the build, assembling it, all that stuff, talking quite a bit about more about this in the future. And I think you'll see a lot from me on this thing, because I'm very inspired with it. I'll tell you that, so.

• 39:01Wes Bos?

  Sick. All right. Thanks, everybody, for tuning in. We'll catch you later. Peace.

• 39:08Scott Tolinski?

  Peace.

• 39:10Wes Bos?

  That's awesome.