1017, We Need to Stop Calling It “AI”  🔗 **Source:** [1017, We Need to Stop Calling It “AI”](https://share.snipd.com/episode/ef818d57-6ae0-41d9-a7d2-5af0b26d15eb) ## Highlights - **Own ShadCN Components By Copying Them In** - Copying ShadCN components into your codebase gives you full ownership and predictable UI behavior. - Accept responsibility for updates and fix upstream library vulnerabilities yourself or apply patches as needed. Transcript: Wes Bos Okay, so if you've never used ShadCN, the way that it works is that when you install a ShadCN component, it literally is just putting the component and all of its code into a folder inside Of your workspace. There's no NPM dependency where you're like importing the component from ShadCN and then you're like kind of changing it and literally just like copy and paste the code in it. And like this, this approach has been kind of a favorite of mine since like the WordPress days. Do you remember WordPress? Not remember, but WordPress has this idea of child themes, meaning that like you could take like a parent theme and then you could sort of like modify the bits that you want. And I never liked that approach. I like simply just like taking a theme, copy pasting it, and then just being able to get into the code and edit it. There's no like weird dependencies. There's no black box behind that type of thing. And I can see why that is a little bit weird. I think the benefit to that is that you are simply able to own 100% of the code. Similar to like a CSS reset, you're not like getting updates to a specific component. When you bring in a component, that is the component that you are going to use. And if there is a new or updated or bug fixes to any part of that component, then you have to either manually apply them or use some sort of AI to apply them. But typically you just say like, yes, this is the component that I want. And like vulnerabilities, a lot of the ShadCN stuff is not implementing its own logic. It's using other libraries that it leans on. And those libraries can continually be updated. And it's just like if you were to write the component by hand, it's simply just like a bit of a headstart in a standard way of creating your component. So I absolutely love that. ([Time 0:02:33](https://share.snipd.com/snip/dc06b609-10c6-4908-b3d8-7e16aedc75ae)) - **Switch To PNPM For Faster Secure Installs** - Prefer pnpm for faster installs, a global store, and workspace support. - Use pnpm's patching, interactive update, and post-install approval features to improve speed and security. Transcript: Scott Tolinski Next question after this is going to be from Michelangelo. Okay, from Raphael, why choose PNPM over NPM? Okay, so PNPM is an alternative that many people love, myself included, primarily just because of speed. Now there's a number of other features that make PNPM cool, which I'll mention. But the big one is, is that PNPM uses a global store and then SimLinks the package version. So that way, if you install, you know, the same package in five different projects or whatever, it's still just referencing that one package on your computer system, making it so you Don't have to have 10 billion copies of every package you use if you use similar packages throughout projects. Other than that, it's really just very fast because of that. It only has to download what it needs to download, and therefore you're not going to have to grab everything all the time. And in addition, PNPM, like they pioneered a lot of features in package managers that like, for instance, PNPM made it so that you have to approve post install runs of things. Therefore, that's giving you more security because if I install a bunch of stuff, it can't just run a bunch of code for me after install, I have to approve that it's allowed to do that gives You options to limit how, like when a package was last published, if you want to go ahead and install that and not it has baked in update functionality. So pnpm update il you an interactive picker to pick which updates you want which again npm and node there's things for this it's not like there isn't but like it's all just baked in yeah Wes Bos It works really well and it's fast and i just like it yeah patching is a huge one for me is the pnpm patch yeah where if you have a dependency and like there's like some bug upstream it's really Easy to simply just patch that and have it install for you right the workspaces are a lot easier it's faster it's just it's like npm is not necessarily bad but there's just a lot of little Paper cuts and and security issues as we've seen in the last couple months as well where these things are simply just way easier way better I like I don't even I don't even think about this Type of stuff anymore it's just like yeah I just use PNPM and it just works and I'm like I'm not fussing over how frustrating it is I don't want to have to spend any any amount of time on on Fussing with any of this stuff. I just know PNPM is the best and I don't have to mess with it anymore. Same with like yarn was that for a long time. But like I never got into yarn because it was just just weird and half the stuff didn't work. PNPM is just fast. It always works. I know it's it's going to be secure. ([Time 0:08:13](https://share.snipd.com/snip/ce5247d3-f56b-49c8-b723-74242b82ac49)) - **How Web Standards Actually Become Features** - Standards live in different committees with stage gates that guide adoption into runtimes and browsers. - TC39 handles language; WHATWG/CSS Working Group handle web APIs, and features appear behind flags as they progress. Transcript: Wes Bos How do we follow the process and keep up to date with the happenings? Yeah. So every single language or browser has like a different process for proposing new APIs, right? Like, so with JavaScript, there is a committee called TC39, and they are simply just concerned with what does JavaScript, the language look like? This is, I want, I want here, or I want a sync await, or I want functions to be able to return streams, like when we got generators, things like that, right? So they're not like, oh, should we get HTML and canvas? That's not what TC39 is about. They're simply just like, what does the language look like? And what you do, where you implement the language is totally up to you. You can stick it on the server. You can put it in a browser. You can put it on a microcontroller. Whatever you want to do with it, we're just building the language. You figure out where it goes. And TC39 has several different stages from stage zero all the way up to stage four. We've done many episodes in the past as to like what features. And typically when things start to hit stage three or even like state, they have like a stage 2.7 now, which is when it's been approved, then you know things are going to be starting to Be put into the browser. So there's, you can take a look at the TC39 active proposals and you can look at them on GitHub. They also have meetings and whatnot that they'll go through a lot of them. Typically when things hit stage two, they'll start to be behind a flag in Chrome and you can play with them. And that's the point where if you like a complaining person, that's the point where you should start using them to like HTML and canvas is exactly that right now, where it's, it's just A proposal. We're trying to figure it out. And so many people are playing with it and figuring out what the edges are, which is beautiful because now we're all saying, Hey, I wish it did X, Y, and Z. That feedback is incredibly important at that stage versus when it actually gets shipped, right? Scott Tolinski Yes. It's a fascinating process. Not one that I have the patience for personally. I'm more of a, I like this. I don't like this kind of guy. Wes Bos The people that do the standards process are amazing. So a browser as well, like CSS has the CSS working group. The browser itself has the what WG, the what working group, and they are responsible for like features that actually get implemented in the browser. Um, so like for example, fetch, um, fetch was not a JavaScript feature. It was a initially just a, a browser feature. And that's why we didn't have fetch and note for so long. Um, and it, it was standardized, um, and it has been implemented everywhere now. But if you want to look into that, look at the, what working group, CSS also has a CSS working group you can go into. ([Time 0:23:44](https://share.snipd.com/snip/1c95b40d-5b28-4bbf-8c50-50a0ae7b8b86)) - **Use LLMs As Tools Not Oracles** - Treat modern LLMs as powerful tools, not mystical minds. - Learn how token prediction works and use that knowledge to craft prompts and verify outputs (Wes Bos and Scott Tolinski discussion on LLM nature). Transcript: Scott Tolinski Okay. Not bike shredder. Bike shredder. Bike shredder. Those are both actually bike shredder. It's a pretty cool name. One of my most recent pet peeves is when people talk about AI like it's actually AI. It's not. It's an LLM. It mathematically predicts the next most likely token all based on the previous set of tokens. My opinion is that the more you understand this, the better you will be at using the tool. It's impressive and it's very good at text based tasks like coding, but it's not AI. What do you think? Am I bike shedding? Probably bike shredder. I got to ask for you, like, what does that mean to be AI then? If it's not just token prediction, like how much of what we're doing in our brains is just token prediction or you have your knowledge that has been gained over time and your brain is working Out the next most probable thing to do. I mean, like, I'm not saying it is or it isn't, but like, at what point does it matter the means at which it is giving you the answers? Now, you could argue like sentience or the Chinese room stuff or any of that. Like, there's so many different angles that you can look at like what ai actually is but like for me i i don't i don't necessarily think the transport really or like the the technology Of what is ai matters as much to me as long as it's able to act artificially in that way. So to me, it being an LLM, I don't personally doesn't disqualify it for me, but I'm not a scientist. Wes Bos Yeah, it is statistically probable, meaning that like if you, the LLM providers have to put randomness into it so you don't get the same output every single time. I'm working with Flux images right now and it gives you it literally gives you the same image every single time that it output not exactly the same but almost exactly the same image every Single time with the same input um and the same like seed value as well um and that's because you start with the same thing and it will statistically try to to guess what it is that you want. I like I get it. We get it. We get it. Like this is just math at the end of the day. But holy hell, is it good, man? Scott Tolinski You know, like it's doing exactly what I want. Everything isn't reality, just math. Like it's all math. Wes Bos It's all math all the way down, right? Except for choosing colors. That's that's taste but i don't know i think like the people that are taste is math i think that that whole trope of like it's not actually artificial intelligence like who gives a shit It it made a website that is exactly what i wanted in like six minutes or like it I told it to write something in a specific way I took in the inputs of what I wanted what people wanted what Uh what I had available to me example code it took all of those inputs and it it gave me the output that I was looking for right it statistically did a great job so I I think yeah those annoying Tropes of like it's just um it's just sand that can think is is kind of like yeah we get it and it's it's funny and everything but it's also it's a fantastic technology it's very good i think Scott Tolinski It's funny i was almost like to me like when when you say that like early in, I remember saying something about like what the AI knows and people are like, AI doesn't know anything. Yeah, no, it doesn't know anything. Wes Bos Like sentient where like it has reasoning. Yes. Cause it goes back and forth and it just puts the prompt back into itself. And, and those steps of saying, Hmm, maybe I should think about X, Y, and Z that prompt is, is great because then it will figure out exactly what you want. ([Time 0:28:31](https://share.snipd.com/snip/cf36e3d4-8c03-4924-b300-fd3cb5c11e6e)) - **Design Systems Lag Native HTML Adoption** - Large design systems often avoid native HTML like dialog or anchor because older libraries predate these APIs and swapping is costly. - Native elements offer accessibility and less JS work, but adoption awaits updated base libraries. Transcript: Wes Bos So what I figured out is that they use very little of the modern native web elements such as dialogue, details, etc. Even though their browser support is way good enough already. Are they missing out on the built-in benefits and baked-in functionality? Yes, this is a question that I have myself as well. Where are the design systems using css anchor and dialogue and like scott just had an entire talk at react saying this exact thing right like tell me rattle off a few of the things that Scott Tolinski The react developers are not using yeah react developers they're not using you know one thing that i think a lot of people aren't using scroll swipe api or scroll snap api in css is so much More powerful than a lot of people use it for like instagram reels or swipers or this or that people are just thinking about these scroll snap apis being for like carousels but like the The thing that's great about these is so many react components implement that stuff with javascript that is like you know changing a translation value when you're you're clicking And dragging you're always going to get worse fps than native scroll um sorry my dog's huffing and puffing in the background oh he's gonna he's gonna yeah um she's gonna um but yeah it Is so funny the accordion stuff like details in summary are really good. Popover anchor. People don't realize that anchor can even swap when you get close to the edge of the screen, really reducing a ton of extra JavaScript you might need. Where are the libraries for this stuff? Man, I don't know. I've been trying to do some of this with my graffiti library to make it like a basis for other things. But again, that's like a whole thing, you know? And yeah, I don't know. What are people missing out on? In the past, it's often been animation. So like the native dialogue doesn't animate, the native details and summary doesn't animate. There's like little things here with the modals, this or that, but like all this stuff can be augmented with JavaScript or even better now that there's at starting style or allowed discrete For animations like you can progressively enhance. It's it's like people look at it as two lanes. It's like you can either use the react component or you can use the browser APIs. They're not like, oh, you can augment the browser APIs with JavaScript to make what you want. Like that's that's the world that i live in so i don't know with ai it's like gotten way easier too like we were talking about with the shad cn stuff to own your components and build them Wes Bos Based off browser standards i think we have to wait for this these new things to make their way into like the into base ui or or shad cn because right now it's it's a hard place but a lot of People simply do not care about a lot of these new features because they just boop boop boop ai does it all for you and it it works oh it does exactly what you wanted so it the we are on the spot Where like we're finally at a spot where all of these things are in the browser. They're fairly well supported. But a lot of these like lower level libraries, they were built when these things didn't exist. And and they're not necessarily just want to have to swap it out. You know, it's it's kind of tricky to have to swap it out. They're not always one to one feature parity. So it would be a lot of work. And I think the people that are doing those things don't necessarily care because they're everybody's head is just on AI right now. We'll see a lot of these new component libraries come out that are using them under the hood, using scroll snap and anchor and dialogue and all these good things. And then you will, and because of that, everybody will simply just start to use those, which is very frustrating. So I think if you were building a design system yourself, I would hundred percent use all of the new stuff that you possibly could, given what browsers you need to support. ([Time 0:34:04](https://share.snipd.com/snip/9748d98c-9bb1-4b05-8880-46342417c8cc)) - **Prefer Native Elements Then Enhance** - Use native elements like details/summary, dialog, popover/anchor to reduce JS and get built-in accessibility. - Augment them with animations or JS only when necessary to preserve progressive enhancement. Transcript: Scott Tolinski Popover anchor. People don't realize that anchor can even swap when you get close to the edge of the screen, really reducing a ton of extra JavaScript you might need. Where are the libraries for this stuff? Man, I don't know. I've been trying to do some of this with my graffiti library to make it like a basis for other things. But again, that's like a whole thing, you know? And yeah, I don't know. What are people missing out on? In the past, it's often been animation. So like the native dialogue doesn't animate, the native details and summary doesn't animate. There's like little things here with the modals, this or that, but like all this stuff can be augmented with JavaScript or even better now that there's at starting style or allowed discrete For animations like you can progressively enhance. It's it's like people look at it as two lanes. It's like you can either use the react component or you can use the browser APIs. They're not like, oh, you can augment the browser APIs with JavaScript to make what you want. ([Time 0:35:29](https://share.snipd.com/snip/46902f65-2a44-4773-890a-ff62ad1da7d9)) - **Learn Fundamentals And How To Direct AI** - Combine fundamentals with AI fluency: learn deep debugging, architecture, and how to direct models. - Use domain knowledge to validate AI suggestions and reach solutions faster, not just rely on prompting. Transcript: Scott Tolinski As AI gets better at execution, I keep seeing two camps emerge among early career engineers like me. One camp is trying every new tool, model, framework, and AI workflow to avoid being left behind. They're shipping more than ever, building lots of projects, and moving incredibly fast, but often with a shallow understanding of what's happening under the hood. Any question you ask leads to the reply, why ask me, just ask AI. The other camp is using ai more like senior engineers accelerating implementation while still focusing on the fundamentals architecture debugging security and developing deep Expertise in a smaller set of technologies but that means moving slower and potentially missing some trends and being caught in fomo that everyone's ahead of you sorry my dog is losing Her mind i'm gonna send her outside it's like driving me sorry Let's see. What are we hopping about? There's nothing going on. If you want to leave, you can leave. You don't need to do anything. Thank you. Wes Bos Can we keep that part in? Scott Tolinski Oh, all right. Okay. Sorry, folks. So they're either in one camp where they're putting everything to the AI or the other camp, like senior engineers, where they are focusing on fundamentals, architecture, and debugging. Which approach do you think is more sustainable over the next five to 10 years? As AI continues to improve, does it make sense to spend a significant time mastering programming fundamentals? Or is the higher leverage skill becoming the ability to direct AI effectively to get a working solution as quickly as possible? I'm going to take the worst possible answer here and say both of them, because I do think there's different skills there that you should probably learn. Now, how we work with AI models and AI in general is going to change as the models evolve over the next few years, et cetera. But understanding the fundamentals, the architecture stuff, being able to debug and really have a good understanding of what the issue is without having to rely on the AI will save You a ton of time and money. I'm trying to think of like, okay, so last night I got a robot. He's currently shut off, which is why he looks like this, a Reaching Mini. And the Reaching Mini app was crashing, and the camera was intermittently working. And in general, there was something odd going on. You could prompt to infinity to check the logs and do all this. And trust me, I had an AI prompt going about reading the logs. And it kept saying, well, there must be a problem with the servers crashing for some reason. And why is the server crashing? I don't know. It could be these following reasons. And it's just trying stuff. Me being the smart guy i am i said what if there's just something running on the port that the thing is trying to access it on and there i was like great idea so obviously i checked the port And there was something running on it it was a process that i had started a while ago, and I killed it. And then the whole thing just worked. So the story is, is that I could have prompted until infinity and maybe it would have gotten there. But the fact that I was able to have the fundamental understanding to know why these things might have been crashing, allowed me to direct the AI and validate that so much faster. So I think you need to get both because people who are good at prompting and can get something that looks great at the end of the day works well. That's a whole skill in itself. But you'll get there faster if you know what the heck you actually want. Wes Bos I think I tend to agree with that because on one aspect of it, like the people that are so nitty gritty into something like I think about the the pure computer guys that we had on where they Were so obsessed with the performance of a diff and so obsessed with the performance of a tree of like a sidebar of files, how quickly that could be rendered, that they just went low, low, Low, deep on that. And you, you would think like, with AI, do we need to care about how like a sidebar renders these days, you know, but they, maybe the opposite is true. And they were using all these AI tools to figure out how do you make this thing even faster. So I think on some regard, like, yeah, like going deep on specific aspects to get the best performance. But then at the same regard, like the higher level architecture things are going to be super important as well. Man oh man i have made a lot of these like vibe coded apps and i'm just like not happy with them after spending three or four days on them and at that point like probably all of you listening Have done this as well where you're like i have this awesome idea i'm build this. And then it's just not very good. You know, you didn't really spend a lot of time on like, yes, it's very good at writing. It's disposable. Yeah, it's disposable. And it's very good at writing the actual code. But what you want it to do, how you want it to function, what the UI looks like, what the flow for this thing is, what the architecture looks like for performance and how much it costs to Host this thing. ([Time 0:39:22](https://share.snipd.com/snip/e17502d6-d82e-4705-9166-8fb00846f758)) - **Killing A Stubborn Port Fixed A Robot Camera** - Scott debugged a Reaching Mini robot by suspecting a port conflict and killing a lingering process. - That quick systems intuition fixed the intermittent camera issue faster than repeated AI prompts would have. Transcript: Scott Tolinski I'm trying to think of like, okay, so last night I got a robot. He's currently shut off, which is why he looks like this, a Reaching Mini. And the Reaching Mini app was crashing, and the camera was intermittently working. And in general, there was something odd going on. You could prompt to infinity to check the logs and do all this. And trust me, I had an AI prompt going about reading the logs. And it kept saying, well, there must be a problem with the servers crashing for some reason. And why is the server crashing? I don't know. It could be these following reasons. And it's just trying stuff. Me being the smart guy i am i said what if there's just something running on the port that the thing is trying to access it on and there i was like great idea so obviously i checked the port And there was something running on it it was a process that i had started a while ago, and I killed it. And then the whole thing just worked. So the story is, is that I could have prompted until infinity and maybe it would have gotten there. But the fact that I was able to have the fundamental understanding to know why these things might have been crashing, allowed me to direct the AI and validate that so much faster. ([Time 0:41:33](https://share.snipd.com/snip/bf679fea-935e-4177-bc86-83eafc1bd433)) - **Don't Trust Unknown Repos In Your IDE** - Never open unknown interview repos in your IDE without verifying them first. - Attackers can embed auto-run tasks that exfiltrate ENV variables when VS Code or Cursor asks 'Do you trust this folder?'. Transcript: Wes Bos For anyone who didn't hear that one, there was some people who had been going through interviews and part of the interview was you had to do like a coding challenge. And they said, all right, just clone this repo and whatever. And he thought, that seems a bit odd. Let me just ask Claude if there's anything weird in this repo. And there was like all kinds of malicious stuff that was trying to steal your secrets. And it looks like simply, you know, when you open up a new folder in like a VS Code or Cursor, it's like, do you trust this folder? I'm assuming that is because VS Code has these tasks, right? And I didn't even realize this, but they could probably run automatically like on Lint or on something like that. I didn't realize. I always wondered that. Like, why are you asking me if I trust this code? Like, what are you doing with this code? But I, like, I guess, yeah, there could be tasks that automatically spin up like Docker images or whatever, and, or just like CLI scripts that will try to steal everything. ([Time 0:50:00](https://share.snipd.com/snip/2c9d043a-00a1-4263-9741-6eff191117a0)) - **Painting Miniatures As A Focused Father Son Hobby** - Scott and his son painted Warhammer 40k miniatures as a creative father-child hobby. - The activity improved his son's focus and provided a rewarding shared creative experience. Transcript: Scott Tolinski These are things that we find to be sick. Things that we really like or enjoy that we're having a good time with. Yes. Sick picks. Man, you know what? I'm going to sick pick, Wes. My son and I have been getting into Warhammer 40k. And there's like painting miniatures. I played Warhammer when I was in high school. But if I know people are like often looking for things to do creative things to do with their kids. I gotta say painting little miniatures, even though it's an expensive hobby, man, it's been a ton of fun to do with them. So like it's whether anything, whether that is 40K or Warhammer, whatever, we went into the store, we got to go pick out a box for his birthday and it had like a basic kit in it. And then we're sitting down with the little tiny paintbrushes and painting these little figurines. And like I said, I used to do it when I was a kid and my God, it's been a lot of fun to do with him and see like creatively what he wants to do. ([Time 0:53:37](https://share.snipd.com/snip/973ff408-a2aa-4277-a9e0-46b3018b67ef))