1019: LGTM, Ship It: The AI Code Review Problem  🔗 **Source:** [1019: LGTM, Ship It: The AI Code Review Problem](https://share.snipd.com/episode/6ba376fd-5290-45cb-92f0-37e697d2f372) ## Highlights - **Force Deterministic AI Output With Rules** - Ask the AI to add terse inline comments and strict style rules so generated components read like your codebase. - Wes enforces rules like “no effects” in Svelte and gives example prompts to keep AI output predictable and easier to audit. Transcript: Wes Bos 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. 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 brain 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 in line with the code just like one It's it's documenting the code 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 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. Yeah. 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 ([Time 0:01:01](https://share.snipd.com/snip/84504f7b-f880-425d-9cc0-c4aa478e2de2)) - **Review UI Changes In Small Increments** - For UI work, review AI output in smaller increments and prefer manual edits or tab-completion for pixel-level behavior. - Scott drills into UI changes more than backend logic and accepts larger autogenerated backend code with less line-by-line review. Transcript: Scott Tolinski Yeah, I think with UI code specifically, because that often dictates how it looks, I find myself drilling in a little closer with the UI. Whereas like I'm writing some backend functionality, I have no problem for it to generate several hundred lines or maybe even a thousand lines of functionality. You got your database and everything. Your is object function. Yeah. Your is even function. It's pretty good at 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 is 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, there's 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 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 you have two things that have somewhat overlapping functionality. And in some cases, you want to simply 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 factor it out into some reusable thing. In other cases, yeah, you want to 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. Yeah. Wes Bos I mean, on the UI tip or on the utility tip, you know, one thing that I have in all of my agent's is 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. Yeah. Scott Tolinski 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 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 line of code. ([Time 0:02:59](https://share.snipd.com/snip/1de65ea0-6e60-4cbc-bd20-f0c2e2a4ffb2)) - **AI Turns Slow Technical Debt Into A Speed Run** - AI accelerates old problems: teams can now speed-run feature churn and tech debt instead of gradually accruing it. - Wes warns that codebases can become unrecognizable after months when many AI-driven PRs duplicate or bloat logic. Transcript: Scott Tolinski Yeah. This is kind of interesting because we have these new superpowers and you're seeing teams do one of two things. 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 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. You have these new feature canons. What's going on? And what a lot of those companies are doing is they are saying, wow, we have this 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. We've been saying for so many years that I want to be able to get this in a 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 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 we could talk all day about like, oh, yeah, you should implement 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 still applies, right? And you're just doing it on, like, you're just speed running it on, like, fast mode now, where it might have taken you six years previously to get to a point where your code base is a mess And things are duplicated. The problems you're describing here are not new at all. And the solutions to these problems are not new either at all. ([Time 0:07:47](https://share.snipd.com/snip/c275fac4-6fa9-4908-9faf-ca7e45ab1ff5)) - **Don’t Drop Engineering Discipline Because AI Is Fast** - Insist on the same software engineering practices as before: tests, architecture reviews, and standards to prevent AI-driven bloat. - Wes and Scott emphasize that proven solutions still apply even if PR velocity increases massively. Transcript: Wes Bos I think one thing that the prompt bros don't realize about this stuff is because 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 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 going to come out again and the the the clouds will part and you'll say hey make it better. And it'll make it better. 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. ([Time 0:10:30](https://share.snipd.com/snip/afc9c8c2-2575-4d7e-9441-e49db13628b2)) - **Confirm A Model Is Truly Local Before Trusting It** - Run models truly locally to get privacy and avoid remote API calls; check whether code actually runs on your machine. - Scott highlights many people mistake local UI clients for local models when they still call remote APIs. Transcript: Wes Bos 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 yeah all these people are like just use a local Scott Tolinski Thing it runs a local so use open code and deep seek for local like that's not local it's going to china yeah so it's literally running running on your machine and i will point you to the Wes Bos Cj did a really incredible video called your guide to local ai and so instead of just recreating that here, because, you know, we could I could just recreate CJ's awesome video on the Fly here. Right. I'm just going to point you to that because it's really super good. And he even uses a piece of bread to show you how big his computer is. So that's fine. Scott Tolinski Yeah, the local model stuff is really interesting. 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 private and whatever. It's on my machine and whatever. And then there's the actual like you don't realize like, again, I'm saying people don't know what local models are. 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 uh that is of of the the quality Wes Bos That you're expecting from like an opus 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. Scott Tolinski 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. ([Time 0:11:31](https://share.snipd.com/snip/dd6c51c3-3d8e-4f7a-8049-8729428b7262)) - **Local Models Are Task Specific Tools** - The local AI ecosystem is a patchwork of small purpose-built models, not a single general model replacement. - Scott points to browser-friendly models (speech, TTS, vectorizing) and libraries like Transformers.js for targeted tasks. Transcript: Scott Tolinski 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 Xenovah 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 speech, tagging things, categorizing things, Vectorizing, all of that stuff. So the local AI space is not a monolith that does absolutely everything. ([Time 0:13:20](https://share.snipd.com/snip/fbd0211e-fbaf-4eb1-ab96-af0855f6fbfd)) - **Use New VCS Tools For Agent Workflows And Undos** - Consider alternatives like Jujutsu or Delta DB when you need fine-grained operation logs, easy undos, or agent-centric workflows. - Scott notes JJ is Git-compatible and offers an operation log and undo, while Zed’s Delta captures every edit delta. Transcript: Scott Tolinski Have you guys ever used it? I am in the same spot. I've had people come to me and try to tell me about jujitsu. And I'm just like, I don't have those problems. Wes Bos But Scott, have you looked into this? I've looked into it a bit. You know me, I'm always looking into this type of stuff. I have not used it because it felt like a thing I had to spend a lot of time on that I don't necessarily have right now. But the key bullet points for people who are interested in this thing is that, one, it is fully Git compatible. So it can use Git as a normal.git directory. And even to the point where you can use, Wes, you can use Git in a project. I can use JJ that same project, and there's not going to be any issues, right. So it's a personal choice if you want to use this strategy or not. It's not like a full team buy in unless you like 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 get to use it. An operation log of all revision logs including like your snapshots your merging all commits and everything exist in one giant uh operation log so at any given point you can just like Run an undo command which god man having an undo command and get how many uh stack overflow posts would that have saved right i still do it i'm like shoot how do i like i like i've been using Scott Tolinski For what probably 20 years or 15 years something like that and i still i'm like oh no i added something yeah that i shouldn't have and it was not in my get ignore now i have to like ask ai to Wes Bos Do that 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 bookmarkmark 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 or um uh conflicts are easier to resolve and things like that i'm gonna 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 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 is too much of a brain shift for me. ([Time 0:16:49](https://share.snipd.com/snip/9b6a4092-9274-4b8c-8372-6e503e53c4dc)) - **Charge Freelance Clients Based On Value Delivered** - Price freelance work by value delivered, not time or token costs. - Wes argues clients pay for results; spend on tooling or token bills shouldn't reduce the value-based fee you charge. Transcript: Wes Bos 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, estimated 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 whatever 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 place this work. Scott Tolinski I have charged hourly 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 those are okay arrangements, right? Like that's similar to just 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 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, that shouldn't be factored into how long it takes you. Right? You should be billing based on how much value delivered to the client at the end of the day. ([Time 0:22:20](https://share.snipd.com/snip/fc8a64fd-99bb-421b-9b73-e50530e3cc92)) - **Framework Lock-In Can Reduce Dependency Risk** - Fewer external libraries can be a feature, not a limitation, because AI can implement targeted utilities and reduce dependency bloat. - Scott and Wes note Angular teams often avoid third-party libs to limit long-term maintenance risk like stale HammerJS versions. Transcript: Wes Bos But that isn't always the emphasis. In fact, on Level Up 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 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. 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's the perspective of somebody who's often kind of largely chosen to do it themselves for, you know, I would say a benefit, but other people might argue the opposite. Scott Tolinski I think with, like Scott said, with AI, you don't necessarily need to bring in libraries. Your utils 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 don't hear about Angular a lot inside of the JavaScript community because we love piecing together everything ourselves. But for people who are coming from Java or Rails or whatever, just 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 Lodash and HammerJS. HammerJS is a touch library. Last release seven years ago. And Lodash, still some use cases here and there, but in many cases, you don't necessarily need Lodash. 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. ([Time 0:29:12](https://share.snipd.com/snip/3c71bc8a-c3f6-4cb4-b618-a38ce04e8b04)) - **Wes Built A Programmable Hugging Face Robot With Kids** - Wes built the Hugging Face Reachy Mini robot with his kids over ~2 hours and connected it to Hermes for speech interactions. - The kit required assembly, contains cameras, mics, motors, and can offload compute to a laptop or run on an optional Raspberry Pi. Transcript: Wes Bos Hopefully, I'm going to try not to drop him while he does a dance here. I'm going to have him do a dance because I'm holding him by the base, which I'm not sure how intense that will be. Explain what this is. This is a... He's going nuts right now. He's doing a little dance. So this is a robot. It's by Hugging Face and Pollen. Sorry, he's still making noise. I'll set him down. Are you done? Okay. So this is 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. Scott Tolinski Really? Wes Bos Like to give you all the pieces you snap together 100 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 um cameras and microphones. And because I did it with the kids, I was having them do a lot of 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, 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, you know, text to speech, speech to text. I'm still getting into it. Like I have a ton of fun app ideas. It just arrived last night and we just finished building at like 8 p.m. 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. Scott Tolinski So it has Wi-Fi, has motors, has cameras, has speakers. Yes. And it's cute. So you could like you could and you could build 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 such a good way to put it. Yes, I think that's what it feels like to me. Wes Bos But what I'm going to use it for is I'm going to hold up our kids' spelling list, and then I'm going to make an app that they can practice spelling with it and use 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 like try to remember like will will help them be engaged a little bit more than just like oh let's try again you know um so i'm gonna build a spelling App for them i'm gonna build uh like i said i'm connecting it to herme so that will be fun and then i'm gonna try to build an app that helps us learn warhammer 40k uh so that way you could like Scott Tolinski Look at the battlefield and tell us like what to do next and stuff that is cool very stoked you know what like anyone listening like another cool thing you could do is you could throw um What's the model i made like a like a barbell detection a couple years ago every single time you like did a rep it counted um that was using why am i forgetting the name of it it's like a um Tensorflow no not tensorflow no media pipe that's it it was using media pipe and there's there's three or four models so you could there's like a hand tracking media pipe 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. Wes Bos 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 you're not comfortable with assembling, 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. And it's definitely more technical. But yeah, in 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 it 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 on just all on robot itself. Scott Tolinski Okay, I see that. That's what I did with my Roomba as well, right? Like I, yes, I put, no, I didn't actually. No, I put the, I put the code on on ESP 32. But when I was first doing it, I was communicating wirelessly from my computer. And so I could I could do the more intensive stuff. That is sick. I want one of these. Wes Bos I'm going to 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. ([Time 0:33:29](https://share.snipd.com/snip/42ff1b80-1b35-4a42-83d6-669a172eaba7))