994: AI Sucks At CSS

In this potluck episode of Syntax, Wes and Scott answer your questions about AI struggles with CSS and design workflows, learning vs relying on AI, debugging web performance, beginner soldering setups, navigating AI-era job interviews, Figma dev mode, modern API choices, and more. Show Notes 00:00 Welcome to Syntax! 00:55 Why AI struggles with CSS and design workflows 10:50 How much AI should you use when learning to code? 18:41 Debugging performance: tools and team workflows Ep 585: Fundamentals × What Makes a Website Slow? Ep 874: Fast Apps - Easy Perf Wins Ep 897: Making Your App Feel Faster Than It Really Is Ep 972: These Things Make Your App Feel Like Crap on Mobile 23:52 Brought to you by Sentry.io 26:26 Beginner soldering setup and essential tools 29:54 Preparing for interviews without AI (while jobs require it) Brendan Falk on AI-native coding interviews 35:16 Thoughts on Figma dev mode and design workflows 39:20 Ice vs Thaw menu bar apps 40:27 Why AI isn’t pushing us toward better APIs 44:54 Vibe rules, skills, and shipping docs for agents vibe-rules Optimizing Content for Agents 54:44 Sick Picks + Shameless Plugs Sick Picks Scott: Jury Duty Wes: USB Cable Tester Shameless Plugs Syntax YouTube Channel 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:00Wes Bos?

  Welcome to Syntax Today. We got a potluck episodes. That's where you bring the questions. We bring the answers. We got some really good questions today. Why does AI suck so much at CSS? How are we supposed to get good, clean, repeatable design out of using an LLM? So questions around vibe rules, skills versus rules versus agents. Should these rules be shipped with a package? Or should you just reach out to the internet to grab them? Interviewing with AI, a genius, genius use of using a dumb model from Brendan Falk. We're going to describe his thoughts on that, which I thought it was so, so genius. How to find and debug performance issues in your application? There's so many different spots where your app can start to feel slow.

• 0:43Wes Bos?

  And then finally, question from someone says, why isn't software getting better and faster with AI? Isn't that what we were promised? Let's get into it. What's up, Scott? You want to hit us with the first question?

• 0:55Scott Tolinski?

  Yeah. First question from Jürgen. Do you have any workflow suggestions for design and CSS when working with AI agentic coding? I'm currently experimenting with open spec plus Claude code and targeted system prompts for roles. And it's great at functionality, but the design looks terrible. I have started a new experiment with new system prompts for UX design and opinionated a front end dev persona. But I'm wondering how other people are tackling this. Is CSS without a rigid design system just too difficult for LLMs?

• 1:34Scott Tolinski?

  I will say this, Jürgen, even with a rigid design system, AI sucks at CSS. It's a perfect storm, if you will, of things that AI does poorly. AI loves to just solve a problem locally instead of solving a problem globally. It just likes to patch and throw things in there, even when you explicitly tell it not to. And with CSS, that often means just throwing just a bunch of bloated additional one-off classes or styled components or anything that you could be possibly in Tailwind too. It does the same thing with Tailwind.

• 2:16Scott Tolinski?

  It could just throw a bunch of extra stuff. Yeah.

• 2:21Wes Bos?

  Yeah, it drives me nuts. Yeah. And even like, like modern CSS as well. Like yesterday I was working on it and I said like, Like use nesting and like it didn't use nesting at all. And then it used the old version of nesting, you know, before we had like the, you don't have to put the ampersand in there. Um, and then it like switched to BEM at one point and, and then it doesn't know how to use any of the new features that are, are out there. And I, I know that these things can be solved with the, the right amount of prompting, but man. And, and like, that, that's not even what this guy is asking about, right? Like, like, yeah, the, the CSS that it kicks out is, is that, but also it, it also just looks. I don't want to say awful because like, like the like table stakes that like a Claude code will, will do, kick out is like,

• 3:05Wes Bos?

  like a black background, gray borders around a thing. And it neatly puts them on the page and it looks decent, you know, like it doesn't look awful, but it doesn't look good. In my opinion, it's, it the like layout, the information, architecture kind of sucks on it. Quite a big task. I think a lot of people are trying to crack that nut right now. Like Google released what Stitch, Google Stitch the other day where you can like, basically it will come up with designs for you. That are supposed to look way better than it. I'm pretty sure they just have like 20 different templates.

• 3:39Scott Tolinski?

  Yeah, yeah.

• 3:40Wes Bos?

  With like 18 different variables. I think they're just simply feeding it a bunch of rules, like always use this line spacing and whatnot, things that are known to look good as well as a bunch of like, pre-made templates. Cause I like, I ran it a few times myself and then I was looking at what everybody else was generating on, on the internet. And they all look fairly similar, which is also the tragedy of the commons with a lot of this stuff is it looks good. Until everybody does it and then it starts to look like slop.

• 4:07Scott Tolinski?

  Yeah. And I think some of it is system prompt stuff. I was, I, I, I got into it with my AI the other day where I was just yelling at it being like, why are you adding gradients here, you know? Why are you adding background? Why are you doing this and that? And it was like, you told me to. And I said, I, I definitely did not tell you to, I told you explicitly not to. And it was like, right here, here's where I, here's where you told me to. And it was a line of text I'd never seen before that I didn't write. It wasn't in my agent's file. So I Googled that line of text and found it in the open code. Header. So the codex header for open code says, "Typography: Use expressive, purposeful fonts."

• 4:52Scott Tolinski?

  And then it lists inter, roboto, aerial. Color and look: Choose a clear visual. Define: Avoid purple on white. Defaults: No purple bias. The most egregious one here is don't rely on flat, single-color backgrounds. Use gradients, shapes, or subtle patterns to build atmosphere. And so I tweeted out, I said, "I love open code, but this is not something a harness like this should be deciding for me." Right? These types of stylistic choices. Dax responded, saying that that is the system prompt from the codex CLI, and they just keep it as is. That's why I think I'm moving a lot of stuff to Pi,

• 5:35Scott Tolinski?

  because there's no system prompt stuff getting in the way. But even if there is this header text that gets put into all of your prompts, it's also, at a model level, these things are definitely biased into certain designs and certain styles, and they're trained on a bunch of garbage CSS.

• 5:55Wes Bos?

  Like, they're trying to beat the purple out of these things, and they've done a fairly good job of beating the purple out of the model and getting rid of it via prompts. But now we're just sort of swinging so hard the other way, where everything looks exactly the same as well. You know, rounded corners, border on one side of a card.

• 6:13Scott Tolinski?

  I think they're also optimizing for normies that when they use it, it just looks good. And they go, "Oh, AI is so good, because it makes things look good." Instead of like, if you want practitioners with full control over it, now suddenly, these things are going to get in the way. Man, yeah, it's a problem beyond the design part of things and the actual implementation. I'm trying to figure that part out, Wes, with my graffiti library. This whole thing is built for the idea of like, "Here are our templates. Here's the customization. Here's the things that you like. Here is the structure, and here's how it should work." But then you also, this is how you customize it, and you don't add-

• 6:54Scott Tolinski?

  You don't add one off classes to do this thing. You use the classes for the structure and then you build on top of that systemically. And I've like built a best practices skill. I've tuned the docs now, the docs return markdown. We'll talk about that later. But like, I've just been grinding on this specific problem for, for a while now because I, I hate this thing. Yeah.

• 7:16Wes Bos?

  Yeah. It's honestly a very hard problem to solve because like in many other cases, you probably will want to step outside of some sort of design system. Because you just know, and I, I think the answer, or at least right now to a lot of the stuff is like, you still need humans with talent and good taste. Right? I know everyone hates the word taste right now, but a lot of it doing like good design and like laying things out. So it makes sense and not just adding buttons absolutely everywhere. Just comes down to like, somebody actually knows what they're doing and can be powerful with these tools. Right?

• 7:50Scott Tolinski?

  Yeah.

• 7:51Wes Bos?

  So I don't think anybody, like I've, I've searched high and low for, for this type of stuff. And unless you have, I like, I think if you have a very rigid, like well documented design system, that certainly helps quite a bit. But still, I don't know anybody that has certainly nailed this just yet.

• 8:10Scott Tolinski?

  Same.

• 8:11Wes Bos?

  And like the people, I got into it with some knucklehead on, on Twitter the other day where like, he just says like, AI is amazing at design. All you need is a screenshot. And he says, uh, great artists make or great artists steal whatever that quote is, you know? And then I like, just like screenshot at his website. It's like you're, you're spouting this BS off. And your own website looks like something Claude just turded out in like 12 seconds.

• 8:40Scott Tolinski?

  And you think it looks good because you got no taste.

• 8:43Wes Bos?

  Yeah, I know, but that's the thing that aside from that, the guy was selling like a, an accessibility tool for checking color contrast. And literally his own website didn't use the tool and didn't, what, didn't have the contrast in it. And that, that drives me nuts because the people are like, people are probably in the comments already to this one being like, oh, I can do X, Y, and Z. And I have a great thing. And it's like, no, your website looks like the same vibe coded app that everybody else came out with, you know? I've never, never been impressed or enjoyed using design of one of these vibe coded things. It certainly is better than a lot of the crap people were. Like just cludging together themselves, which is good, means like the baseline for like decent experiences is much higher now.

• 9:28Wes Bos?

  But I don't think that you can simply just screenshot a good design of some other app and say, oh, mine now looks amazing as well.

• 9:37Scott Tolinski?

  Yeah, I think this all comes back. I had a tweet that was, it's crazy how AI is really good at the stuff I don't know anything about. And total dog shit at the stuff I do. Because the moment that you have an eye for CSS, an eye for design, an eye for anything, the slop looks like slop. And there's a reason why I think my AI code for backend stuff is great. Because I don't, I'm not as good at that stuff. I'm good at backend, but I'm not like an expert. So, hey, it works, it works. But when I look at anything closely, especially frontend code, the stuff that I'm good at, the design stuff, I just, I see how terrible it can be. So, yeah.

• 10:18Wes Bos?

  Nah, I think the AI is certainly much better at backend code, which is very deterministic, very programmatic, following patterns. And then when there's something that's a lot more visual and has to come into like the taste that you have, it's much harder. Not to say, I think like we probably will crack this. I think somebody that actually knows it, I know Tailwind guys are working on UI to SH right now. And I've seen some decent stuff. They've been cranking out, a lot of smart people working on this right now. And I bet we'll probably see it solved in the next six months or so. Louis says, I'm getting back into hands of web development after years of working in product roles. I want to get my hands dirty again. So I'm doing a React app to prove also to myself that I can still do it.

• 11:02Wes Bos?

  But it is so much easier to get AI to write most of the code myself. This is a dilemma for me and I am also learning. Since I'm also a teacher, I know I am learning less when I use AI. But then again, maybe some of the skills I am missing out on here are redundant and I'm better off learning how to code with AI on my second screen. He goes on to say, I do know the fundamentals of coding with React. I just haven't been writing lots of code myself the last couple of years. What are your takes on this? Yes. This is, this is kind of an interesting one. And I think as, as much as people, I don't know, it's, it's, it's a delicate balance here. I certainly think you still do need to understand how the ins and outs of a lot of this stuff work.

• 11:47Wes Bos?

  But I don't think you need to know the ins and outs of it as much as you previously did. I think that people that are building the lower level stuff of this certainly need to know how this works. But that, they'll be then turning that into libraries and whatever that we can sort of sit on top of. And then the people that do know how a lot of this bad stuff happens, like whether it's performance or optimizations, they will be creating skills that can, can be modeled out and you can apply it to your, your own code base. So like, what, what's my take on like, do you still need to, to know how all of this stuff works? I think the people that are getting the most out of this AI right now are the people that actually understand

• 12:29Wes Bos?

  how to tackle large projects, how technology works, how these things all work together. You see Toby from Shopify, obviously creator of Shopify. That guy hasn't slung code in, in many, many years. And then all of a sudden he's just cranking out these like really interesting projects, you know? QMD and, and auto research pie and, and whatnot. And, and that's because of the type of person he is. He's a thinker, he's a technologist. He understands planning products. He understands sort of the bigger picture of a lot of this stuff. And you're, you're starting to see a lot of like, like really reputable project managers. I know that term gets, uh, not to say Toby's a project manager, but you're seeing a lot of people who

• 13:13Wes Bos?

  previously were sort of hands off with the code and, and much more of a stip sheer ship steamer. Now they're sort of getting back into the code and, and the stuff they're building is, is good because they. They understand how all of this stuff works. So that's my take there is that the people that are going to do the best on this are not just the people that can type in the box and produce a bunch of garbage. But the people that really know how to think about a project and apply, solve problems, you know, all of the things that we're, at the end of the day, we're using this code for.

• 13:45Scott Tolinski?

  From a ship steerer to stir. I, you know what, it's so funny Wes, I, I agree. I think one thing that could help here is just the idea of slowing down a little bit and reading the code. I know it's when you're learning something, there's a little bit of a difference there because you're not going to be able to recognize bad patterns. But with the amount that AI does write kind of sloppy patterns. If you can read the code that it's writing and identify where the problems are, or even ask it to review its code and see possibly if it has ideas for where these sloppy things are.

• 14:29Scott Tolinski?

  I think there is a loop there in which you're able to pick things up that you wouldn't have picked up before by really having a deep eye for reviewing the code rather than if, if you're, you know, enjoying having the AI write the code. But like being able to have an eye for what is good and what is bad. I know that's tough to do without really writing the code for a long time. You know, many of the patterns that I can recognize as being bad, I only recognize as being bad because I wrote them poorly myself at some point and then refactored, you know? So, yeah.

• 15:08Wes Bos?

  Well, I'll give you another example of where it matters about the code, but so much more the, the actual implementation. So I have this one Photoshop that's called Texture Anything. It's a Photoshop plugin called Texture Anything. And the, the way it works is that you, you drag this plugin in and it has a list of, I don't know, like 30 or 40 Photoshop actions that it applies to it. And then it will sort of give. Like a logo, like a texture grunge look to anything. We'll put some screenshots up if you're watching the video right now. And I love that plugin, but I just like, I hate having to open Photoshop for it, or it takes like a long time. And I was like, I would love for this to be programmatic. So I got Claude, I dropped it in Claude.

• 15:51Wes Bos?

  I said, convert this to, to using JavaScript, right? And then it went through it. It surprisingly was able to read the Photoshop action, figured out what each action was doing. And then out the other end, boom, it, it gave me the entire effect done in, I think it was in Sharp. And it, it did a great job. Like it looked exactly what I wanted, right? It re-implemented it, all of the blurs, all of the, every single thing that Photoshop would do, it now did it programmatically in code. But the problem was I was, it was slow, right? Like if I, I uploaded a 500 by 500 pixel syntax logo, it would take 10 seconds to apply it. And I was like, I would like for this to be much faster because there's knobs I would like to turn. You know, what happens when you turn the grain level up? And you gotta wait 10 seconds.

• 16:35Wes Bos?

  So I like, I took my programmer brain and, and I was like, how, like, how are, how are you doing this? You know, what, what technologies are you using? And over the course of maybe two hours, I sort of went back and forth and said, why don't we use Wasm for this? And then, okay, oh, good idea. You're so smart. I know, thank you, you know? Let me move this over to Wasm. And then I was like, well, like time, how long each step takes, right? And then I would, I would look at it and say, oh, this step is taking much, much longer. Like, what are you doing with this? Is, oh, I'm looping it through every pixel, but we don't really need to be looping over through every pixel. We just need to be, maybe we can filter for pixels that have a color first, you know? And then I got it down to like 200 milliseconds, you know?

• 17:18Wes Bos?

  10 seconds to 200 milliseconds, all because I knew how like graphics processing in Canvas works. I knew how, how WebAssembly works. I knew how to parallelize things in, in WebAssembly. And I didn't write any of the code myself, but like, that was a major. If I was just to type it, like make it faster, maybe it, it could figure it out. And maybe that's something for, I could use like an auto research plugin for, but. I like, I think most people would have been like, check this out. I made this amazing Photoshop to JavaScript converter and it works at the end of the day. And it's like, well, it's, yeah, it works, but it's, it's not really that great of an implementation. And I think the code that I kicked out at the end of the day was really good and way faster.

• 18:03Scott Tolinski?

  We have an episode that I want to work on. Well, I've already wrote most of the episode, but on using more deterministic methods for improving the AI output, whether that is like quality checks or speed checks or those types of things, where it's not just like telling the AI, hey, go make it faster because it will take shortcuts or cheap out or a lie or do all kinds of stuff for you. So I think there's a lot here in terms of like being able to understand where the problems are, being knowledgeable enough to direct the AI in a way to fix these problems. Again, I think those are all interesting questions. All right, next question here is from Alex. To preface my question, I'm a network engineer and don't have much web developer background.

• 18:48Scott Tolinski?

  Oddly enough, I enjoy the syntax podcast despite having very little context to keep up with some of the episodes. With that said, I've been a part of a fair share of company website performance investigations, where I typically turn to the browser developer tools at network tab and confirm supporting infrastructure is operating normally to contribute. I'm looking for other ways to bring greater value to these investigations from an IT operations infrastructure perspective. What insights, tools or practices would be helpful to web teams during performance troubleshooting? Yes. Yeah, so Alex, this is, this is great.

• 19:30Scott Tolinski?

  One thing I will say here is make sure that the teams you're supporting with this stuff would like your support. Not because, not because that you're not being helpful, but sometimes it can be not helpful when somebody who isn't having like the full picture is giving feedback on stuff. You know, sometimes it might even be better to be more helpful to say like, hey, I'm noticing these pages are slow or whatever, rather than trying to give a deep. Like technical explanation as to

• 20:03Wes Bos?

  You know what the worst thing is? Is that when somebody doesn't know what they're talking about, but also punches something into Claude or ChatGPT and then paste the reply to you?

• 20:13Scott Tolinski?

  Yeah.

• 20:14Wes Bos?

  It's just like, that's so disrespectful to me because like, you're not suggesting anything. I could have punched that in myself as well. And it's, you're wasting my time making me read this now as if you came up with it. Anyways, continue.

• 20:27Scott Tolinski?

  No, yeah, no, I think that's, that's right along the lines of it. We're like, I think it is helpful, Alex, if they find what you're doing to be helpful. That said, we do have a number of episodes where we've talked about this and go deep in depth. Episode 585, Fundamentals, What Makes A Website Slow? We also talk about it in 874, Fast Apps Easy Perf Wins. We talk about it in 897, Making Your Apps Feel Faster Than It Really Is. And 972, These Things Make Your App Feel Like Crap On Mobile. These episodes are all a great place to, to get, dive into a little bit of what exactly you should be looking for. But again, most websites, I will say, you know, maybe it's a little bit different in the modern era,

• 21:12Scott Tolinski?

  but fundamentals are still here. Most apps are slow because they're loading heavy resources. The Network tab is a great place to see what is taking a long time. Like you said, it can identify if the server response too slow? Is it loading some giant images or something where it shouldn't be? There's a number of things you can certainly learn from the Network tab there as well. Yeah.

• 21:38Wes Bos?

  Yeah. He was saying like, he, he is a network engineer and he knows how to open the Network tab. And that's, that's a pretty good spot to start, but like, there's so many other spots in the like, from a website being a baby to actually being delivered to your, your browser, like that can introduce latency or slowness ones, right? Like if, if you, the network engineer realized, oh, 400, 800 milliseconds is taking for this page to actually respond from the server, even just to get the HTML. At that point, you're just like, well, that's slow, but like, like, but why? You know, and at that point, you probably have to start to figure out how, how the app actually works.

• 22:22Wes Bos?

  And as a network engineer, it's probably, you probably have some, some good insights into like, How to make this thing faster, you know? And you get some like observability in there. You get the metric has to like, what's actually taking? Is it database? Is there some like weird thing that we're waiting for? The tweets to load before we send the whole, whole thing out? And that's taking 400 milliseconds and, and holding the page up. Past that, understand caching, look into staleware, revalidate. Those things can certainly help quite a bit. Also, like, like, like we said, there's, there's a lot you can do on the UI layer to make your website feel faster. In some cases, the actual rendering is slow and that could be how your resources are being loaded in.

• 23:05Wes Bos?

  Or it also could just be like you are re-rendering these things way too often. That can sometimes happen in, in React applications. So just like, kind of go through all four of those episodes and just understand where slowness can, can be introduced. And when you're on the website, does it feel slow? Is it actually slow? Understanding all of these tools and like the network tab is not just the only one. You can go into like the rendering tab, the flame graphs, understand all of that stuff. Or I think that's a, that's going to be a very good skill to have, I think, in the next little while, as everybody's just cranking out these websites where they don't necessarily know what the code looks like.

• 23:43Scott Tolinski?

  Yeah.

• 23:44Wes Bos?

  Being able to just dive in and figure out, all right, well, we have this thing, but like, how can, how can we improve it? Where is it actually going slow?

• 23:52Scott Tolinski?

  Yeah, I will say, here's an opportunity to plug Sentry, S E N T R Y dot I O. One of the coolest things that Sentry does is they have tools that can identify what your slowest routes are, or potentially what your slowest DB queries are, those types of things. And they can make it really easy to find exactly where the slowdowns are in any of your applications. And man, we use this so, so much when we built the current version of the syntax site. And I'm sure we'll use it just as much when we finally finish the next iteration of the syntax website. But it can really, like, it gives you a misery score and stuff for like,

• 24:35Scott Tolinski?

  how frequently this page is hit versus how slow it is. There's a lot of great stuff in Sentry for tracking these down as well as really getting into where these slowdowns might be. Yeah, the front end has like the, the web vitals, performance scores, all that kind of stuff.

• 24:54Wes Bos?

  The database one we had, we've told the story many times, but I think it's hilarious is that Sentry sent us an email one day, like as an alert being like your, your database queries are, are climbing and they're at a point where they're too slow now. And it turned out, we didn't have an index on our shows page. So every time we added another show, it just increased the size of the database. And when we were querying based on, I think we were querying based on like the show number or something like that. And there was no index. So it had to like loop through every single show in the database and, and look for it, or looking for the, I think the slug, something like that. And like, I, I don't know that we would have noticed that because it got just a couple milliseconds slower every single time we pushed a show, right? And that's not, that was not significant, but over adding

• 25:39Wes Bos?

  400 shows since we built it, it got way slower. And then we're like, oh, pop a, pop an index on that. And then we were good to go, which is hilarious.

• 25:49Scott Tolinski?

  Yeah. Well, you know what I'm seeing right now? That Synhacks is getting some not great scores for WebVitals. I'm wondering why. So I need to dive into that, considering it is using the very fast zero sync. And in practice, it feels fairly fast, but I'm sure there's some stuff to learn here about why we're getting slow performance scores on here. Interesting. So check it out. Sentry, S E N T R Y.io forward slash syntax. Sign up. Use the coupon code TASTYTREAT, all lowercase, all one word. These are some great tools and I think very relevant to this question. Sorry. I didn't mean to turn your, your question into an ad, Alex. It just happened to work that way.

• 26:28Wes Bos?

  Mike says, hi guys. First and foremost, I want to say thanks and give you your flowers. I was able to move into a developer role because of the podcast and both of your tutorials. Well, you're welcome. I want to get into fixing electronics as a hobby. Wes, what do you recommend as a good setup for a soldering station for a beginner? Yes. Man, I've got, I've got thoughts on this. Soldering iron, you can, you can pretty much just get like anything, but if you want to get something like decent and cheap, I have the Ryobi. Battery powered soldering iron. And then I also have the little, I think it's called like a T100. It's like a USB little pen shaped soldering iron.

• 27:09Wes Bos?

  And I do reach for the Ryobi one much more often because I, when I reach for the USB C one, I can never find the fricking power cord that is 100 watts. Or I can't find like a, something to plug into the wall. And I, I'd much rather just have the thing on my desk. And so I can solder with it. So big fan of those, it doesn't have to be the Ryobi one. It can be literally any battery powered one. So whatever tool brand you have, I think even Adam Savage has a self-build one where he took a DeWalt battery and he plugged one of those little, the barrel adapter ones right into it. So that's my, my recommendation for there.

• 27:50Wes Bos?

  Along with that, I would probably recommend getting just, just a whole bunch of like little connectors and clips and, and whatnot, or even just take apart. I forget what it's called, like a solder sucker where you, you push it in and you let go and goes, and then what that does is that it sucks the solder out. I'm trying to see if I have it on my desk right now. No, I cleaned up my desk. A little bit of flux in like a little syringe. Flux is really messy. And you need it when you're soldering or desoldering components. So I always recommend getting one in like a little squeezy pen.

• 28:23Scott Tolinski?

  What is flux?

• 28:24Wes Bos?

  Make a mess. Flux is, if you, when you're heating up your solder, it doesn't want to nicely flow into it. So a lot of times you see people that are like, oh, I suck at soldering. Look at it. And it's just like this like ball of crustiness. And that's, yeah, well, it's probably because you don't have flux.

• 28:43Wes Bos?

  And it, flux is like this like gooey paste that you put on top of it. And when you apply heat to it, it does something to, I don't even know how, how it works, but it basically makes your, your solder just kind of flow out. And you need that when, when you want it to like flow into a joint that you're soldering, or the opposite, if you want to like suck up the solder with like a, like a copper wick or something, you need to put a little bit of flux on top of it.

• 29:10Scott Tolinski?

  So I need some flux and some solder sucker.

• 29:13Wes Bos?

  Yes, absolutely. And like a little, what's it called, like a braid? I don't know the names of any of these things, but if you just Google it. You can find some stuff. Go on AliExpress. Go take a look around for all the fun things that you can buy. Figure out what the absolute cheapest thing is and then buy like one level up from that. You'll probably be happy.

• 29:31Scott Tolinski?

  That's good advice.

• 29:31Wes Bos?

  Although, be careful with the like lead solder is certainly a thing in China, which a lot of people love lead solder because it's so much easier to work with. But also it is very harmful to your health. So if you are buying stuff off of AliExpress, be careful that you're not actually buying lead. If you're going to be huffing it in.

• 29:52Scott Tolinski?

  Yes.

• 29:53Wes Bos?

  Yes.

• 29:53Scott Tolinski?

  Important. All right. Next question from Kalen. Hi Syntax. How do we balance prepping for no AI interviews? While job descriptions demand AI proficiency? Honestly, after getting spoiled by tab completion and instant AI answers, manual coding feels like going backwards. Is old school prep still the only way to prove experience in 2026? Well, yeah, that's an interesting thing to have a job that demands AI proficiency, but doesn't allow you to use AI in interviews feels like bad structure for an interview. If you're asking me.

• 30:35Scott Tolinski?

  Like this job demands jackhammer proficiency, but guess what? You gotta just use a chisel like, okay, what are you testing me here on? I think some of this too is like really just kind of dialing in your, your understanding of things. Because many times like the code we write is like less important than understanding the concepts of writing good code. So a lot of this too is less about the code you end up writing and more about like being able to express the understanding of systems, to express the understanding of best practices.

• 31:19Scott Tolinski?

  So even if you're used to the tab completion style of things, if you can prove to them that you understand the core concepts, you. Understand why you're doing things and what these best practices are. I feel like those are the things that are going to always keep you ahead of somebody who's just like, I don't know, I just hit the button and it works, or I'm putting this component in. Why am I putting this component in? I don't know. It's just how I've always done it, right? You being able to express yourself and show your work in those types of ways. To me, I think land's better. But it is interesting that they wouldn't allow you to use AI in a tool that demands, or in a job interview that demands AI proficiency.

• 32:03Wes Bos?

  I saw this from Brendan Falk on Twitter the other day, and I thought this was genius. He says, I believe we have found the best AI native coding interview. We call it the Composer One interview. Composer One was like the very first model from Cursor. And he says, candidates get one hour to build a real medium sized project live. The only constraint is they must use Cursor's Composer One model. Why Composer One? It's extremely fast. Candidates can accomplish a lot in one hour. More prompts and more code equals more surface area to assess. And two, it's perfectly mediocre. I love this. Composer One is good enough, the output is decent, but not good enough that it does everything perfectly. Candidates can't rely on the model. They have to be good engineers themselves.

• 32:48Wes Bos?

  Weak candidates use one agent, write bad prompts and accept the code they don't understand and end up with poorly structured code base. Exceptional candidates run parallel agents, write detailed prompts and enforce very high coding standards. I saw this, I was like, this is genius. Like, give them something that's not that good, but is fast. And see, see how they, how they use it. So this is not really answering your question about like, how do you prep for a no AI interview? But I thought it was just so smart. Yeah, this really separates people who understand how these systems work, how they can plan, how they can tackle things versus like, people are just like, I just pushed the button.

• 33:31Wes Bos?

  I type in the box, what you told me to build, and I'm going to accept everything that comes in.

• 33:35Scott Tolinski?

  And that goes along with what I was saying is because if the, even if it's tab completion and not like prompts and agents, even if it's just tab completion and the tab completion is giving you something that is bad, you learn a lot from watching somebody modify the tab completion or choosing not to use the chosen tab completion because of why it's, why it's bad.

• 33:58Wes Bos?

  Cursor learned a lot by watching you not accept your tab completions as well. That's how, pretty sure that's how they trained all their, their new model, their composer two. They have all this data on what, well, they have all this data on like what people have accepted, right? Like they have, they're sitting on this gold mine of like, we have done two billion, whatever request and we proposed this code and here's the cases where people just deleted the whole thing. Here are the cases where people changed these things. And that's pretty good. Cursor rolled out their composer two a couple of days ago and it actually is pretty good.

• 34:32Scott Tolinski?

  But you saw the drama around that, right?

• 34:33Wes Bos?

  Yeah. Yeah. They, so they took, what? They took Kimi 2.5 and then trained on top of that. And the, but they didn't say that that's what it was. So there's all this drama around. People thought they just took the, the Kimi 2.5, slapped their name on it and, and called it a day, which is a bit of a PR crisis for them.

• 34:55Scott Tolinski?

  Yeah, a little bit. Yeah.

• 34:56Wes Bos?

  But that, that said, it's actually really good. I used it for like a week and I was like, this is actually pretty good. It's not as good as, as like Opus or, or Codex or any of the, whatever the latest OpenAI one is, but it's pretty good, I would say. Pretty good. Pretty good. And you can use it with Zed. I didn't think you could, but you can. Eric says, have you tried Figma? What do you think about their dev mode? So yeah, this, I thought this was an interesting question since we're talking about design and how to approach these types of things. I've never used dev mode in Figma. Have you, Scott?

• 35:31Scott Tolinski?

  No, no.

• 35:32Wes Bos?

  Get that out of the way first.

• 35:33Scott Tolinski?

  No, I've been, I've, I've looked at it, but I've never considered using it for any serious anything. Yeah.

• 35:40Wes Bos?

  Yeah. I, I always look at these types of things and I'm like, I don't really want my like design tool writing code for me. And now we're at a spot where. You can just screenshot the thing. Shout out to the one of the last thing and just have the thing coded for you. I don't know that we necessarily need that. I will tell you that what we do need, we still need an app that is like Figma to actually design these things. And whether you're doing that via prompting and it's just kicking out code, which is what a lot of like, I know paper and then I think there's another one called pencil. There's, there's several of these like apps people are working on, which is just like

• 36:23Wes Bos?

  Figma, but instead of, instead of it rendering out like, like WebGL or whatever Figma is using, it's, it's literally just rendering out HTML elements to the thing. We certainly still do need apps like this that are going to help us figure out what the design looks like and some sort of interface, whether that's clicking around and dragging things, or whether that's inputting values into boxes, or whether that's simply just typing into a prompt box and saying, space these things out 20 pixels a little bit more and seeing what the result is. I think we still need those apps because the alternative of just YOLOing it and having, this is what we talked about earlier, the alternative of just YOLOing it and having Claude

• 37:05Wes Bos?

  kick out a design for you is not working out and it's, it's making some pretty brutal interfaces.

• 37:12Scott Tolinski?

  I've been actually going into Figma lately to design instead of designing in browser, but not using the code mode or code output. Or even giving, I'm not even giving screenshots of it to AI. I've just been really liking Figma lately for just straight up designing instead of, I primarily design in browser, but as Wes knows more than anybody, what happens with me is I start from such a systemized point of view that when I design in browser, my designs feel soulless because I don't get chance to play. I build the system and then, okay, it looks fine. I'm bored, let's move on. Where if I go into Figma, I can really get arty with it and throw stuff at the wall.

• 37:56Scott Tolinski?

  I actually really like some of the auto layout stuff in Figma, but their, their dev mode, their code stuff, I personally wouldn't touch it because I don't trust somebody else's code.

• 38:06Wes Bos?

  Except for Claude's.

• 38:09Scott Tolinski?

  I don't trust Claude's code, I'll tell you that.

• 38:11Wes Bos?

  Okay.

• 38:12Scott Tolinski?

  Yeah.

• 38:12Wes Bos?

  I did test, what was it? Paper the other day where the idea is that paper is like a canvas where you can like feed it a website or like a component. And then it will recreate that component in paper. And then you have this like interface, which you can either click and drag and around like visually, or you can also just prompt with an MCP server to change things. And then the idea is that you then, once you're happy with it, you put it back into code and your code base is sort of the source of truth. Only when you need to like work on a design, you sort of take a piece of the website, out of the website into this, like, what do you call it? Like canvas.

• 38:56Wes Bos?

  You work on it with your designers and whatnot. And then, once you're happy with it, you stick it back into the website. So that was kind of interesting way to go about it. So you don't have this like designs. And then you have your actual implementation of your website where they start to drift from each other.

• 39:12Scott Tolinski?

  Yeah.

• 39:13Wes Bos?

  So again, I don't know that we know what the answers to all of this stuff is, but certainly a lot of people are trying to figure out what that looks like.

• 39:20Scott Tolinski?

  Next one here from Bosch, not really a question, but Wes, your sick pick the other day was Ice, which is inactive and you should use Thaw instead. Yes. Use Thaw.

• 39:29Wes Bos?

  Yes.

• 39:29Scott Tolinski?

  We'll link up Thaw. Thaw is, Thaw is the modern version of Thaw of Ice, which is a menu bar manager in macOS. And Thaw is pretty much a straight fork that's being maintained of Ice. And I gotta say, I've been using Thaw for a bit and.

• 39:45Wes Bos?

  Yeah.

• 39:46Scott Tolinski?

  Yeah.

• 39:47Wes Bos?

  That's, looks good. I have had zero issues with my Ice, but I didn't even realize it was unmaintained. I.

• 39:52Scott Tolinski?

  You will, I'll tell you, you'll have issues when you upgrade to the latest version in macOS, because I'm on the betas and it doesn't work. And then I installed Thaw and it works just fine. So. Yeah.

• 40:04Wes Bos?

  I, I'll tell you one issue I have. I have with it is I use Ice to add little backgrounds to my menu bars. Kind of cool and it looks nice. And they're a little bit laggy in how they draw. Like if I, if I hover over top of some of the items, you can see that they, they don't paint as quickly as possible. So maybe that's fixed. I'll give it a shot. Thank you, Bosch. Mothman Sense says, since AI has made writing code and changing so much easier, one would expect that as a collective, we would drift towards more performant or more stabilized APIs. For example, moving servers to Go or moving front-end code to web standards and web components instead.

• 40:45Wes Bos?

  But I have seen a bigger shift towards proprietary ecosystems like NextJS. What do you think that is? If you accept my premise at all, yes, lots of things to say here. First of all, we are recording an episode. I think by the time you're listening to this, it'll probably be out a week before this one on moving systems, right? Like I moved my Express Codebase, which has been bugging me for many years. I moved over to Hanno and we have a really good episode on like how to tackle a project like that. Because I don't think it's as simple as like move my Rust server to Go, bloop, bloop, bloop. And then all of a sudden, it just moves absolutely everything over and it's totally fine. Or bloop, bloop, bloop, make everything fast as possible. I don't think we're there just yet with this type of stuff.

• 41:28Wes Bos?

  And the question here is, I've seen a bigger shift towards proprietary ecosystems like NextJS. Pretty sure by the time you're listening to this, the announcement on the NextJS stuff will go live. They are rolling out a whole bunch of stuff about hosting elsewhere and adapters, which is pretty cool. So we're going to be talking to them about that as well. What do you think that is? I don't know. I don't think, I wouldn't say these things are proprietary. If anything, like a lot of these, like I saw Linktree the other day had jacked their price up, like by 3X or something stupid like that. I'm like, yeah, that's because you shouldn't pay somebody for a page that has six links on it.

• 42:10Wes Bos?

  You know, that's ridiculous that you are even doing that in the first place. And people are realizing, oh, I don't need to pay $300 for a Linktree. I can simply just make my own. So I wouldn't say we're moving towards proprietary stuff, not at all. I think we're moving much more standards-based, much more. All of the stuff that is being built today, if you look at what the Claude code stack is, you know, it's all very much based on web request, web response, fetch, streaming, all that good stuff.

• 42:43Scott Tolinski?

  Yeah. Yeah, I do think there is this like default AI stack that if you tell it you're building a web app, it leans on all this stuff that you don't need oftentimes. Yeah, I wonder the same thing, Mothman. I've been doing some Rust with AI and it's really nice. I've been doing all kinds of stuff that, again, I'm not like, yeah, I'm sorry, I don't have a formed opinion on this, even though I've just been thinking really hard about it. And I would think it really hard on, I'm feeling like I got an eloquent answer here, and then it comes out like that, Mothman. I think it's just what it's trained on and what it's like really steered towards. We looked at that in the state of JS where

• 43:24Scott Tolinski?

  it's like, this is the stuff that AI is going to suggest the most. And I have a hard time with that because it's always suggesting a bunch of stuff like I don't want it to use. It's never, I never had it ever once suggest to me to use web components, even though there are times when a web component would be the right call there. So, yeah, I think, I think some of it is, it all comes down to, we're going to say it again, personal taste. And you have to know what you want.

• 43:50Wes Bos?

  There's your competitive advantage.

• 43:52Scott Tolinski?

  Yeah.

• 43:53Wes Bos?

  Yeah.

• 43:54Scott Tolinski?

  Like, knowing what you want.

• 43:56Wes Bos?

  I don't know. The people that are complaining about AI not suggesting what they want, like, are we, are we that lazy that you can't spend three minutes figuring out what framework you want to use? And you're just, you're whining? And like, not, not directly at you, Mothman.

• 44:13Scott Tolinski?

  Yeah, Mothman, you won.

• 44:14Wes Bos?

  Mothman, you're cool. You're one of us. But like, come on, are we that lazy that like, we have to like worry about this type of stuff? Like, let the people, I guess, like, if those are your competitors that are not using Go as their server, and it's, it's really going to slow you, slow them down so much, then, then type up a new one, you know? Competitor, make a new. Slop fork something.

• 44:40Wes Bos?

  There's a lot there. I don't know. I think that the whole theme of this episode is like, you still have to think. Please bleep that out, but like you still have to, you can't be an idiot yet.

• 44:50Scott Tolinski?

  You can't. Yeah. Use your brain. Yeah.

• 44:53Wes Bos?

  Use your brain, folks. All right. Jim Carey clone says, Hey, Weston Scott, while referring to Tanstack router docs, I mentioned something called vibe rules. And after digging, it seems like an NPM package, NPM packages, example, Tanstack forward slash React Router now ships an LLMs folder inside the dist of the node modules, which can be installed with vibe rules. Is this replacement for contact seven or agent skills, or at least docs? Have you used it personally? Scott, have you used vibe rules?

• 45:27Scott Tolinski?

  Yeah. So vibe rules is a package. And what it does is allows you to manage rules files. So whether that's like cursor rules or those types of things. Now, the way that this works is through a CLI where you would run vibe rules install, and you can point it to things. And the idea would be that you are shipping the MD with the library. So that way you could install the vibe rules into your, whatever it is you're using, just via the CLI because it's been shipped. I don't really use the style of like rules files.

• 46:09Scott Tolinski?

  Now it could put it into, it looks like it could put it into the agents dot MD file. It can put it into Claude dot MD. There's some of this that I can understand existing, but I would much rather it ship like at this point, personally, I would rather it ship a skill and then just have that skill available rather than having it be a rules file. Or I don't know. I hadn't seen vibe rules before we got this question in. And it doesn't necessarily feel.

• 46:45Scott Tolinski?

  Like something that I'm personally going to be like going nuts to use, but it does like the one thing I do want to applaud the Tans deck folks here is taking ownership of that part of things because too often times we are just pointing the AI at llms.txt or we're crafting our own custom skill or our own custom agents file. So if the library can tune one up specifically, then that's, that's great. I've been working a little bit, this I mentioned before, that I have like a graffiti best practices skill that is like trying to do that ownership of that, right? So for my library, I'm trying to take that ownership over, well, just doing it in a different way.

• 47:27Scott Tolinski?

  I do want to point you to a blog post that David Kramer wrote called optimizing content for agents, which I found to be really interesting. And he was talking about the Sentry documentation and how the Sentry docs are written in Markdown and the web uses the Markdown to render the web. But instead of using this old school, old school, which is like, what, like six months ago, an llms.txt style of duplication of the docs. What this is doing is is that when an AI agent hits the Sentry docs, the Sentry docs are returning Markdown to the agent, not a web. So that way it's not getting a whole bunch of the DOM stuff, right?

• 48:11Scott Tolinski?

  It's just getting the Markdown when an AI agent hits it. I think this to me is a, I don't want to say a better approach, but a, an approach to the same type of, of problem is like, we're trying to optimize how when agents tackle a problem, where can they go to get that correct information? Yeah.

• 48:32Wes Bos?

  It's, it's tricky because part of me likes this idea of like shipping your Docs with your package, meaning that if you are on like a version four and a version six is already out, then it's it's simply just pulling it from that exact version of it. But like you said, that's not to say that it can't just reach out to the web. And I certainly don't need more text in my node modules folder, you know, like we, we have an episode on like, why is node modules so big? And spoiler alert, it's a lot of text. And if everyone starts adding these vibe rules, it's it's going to get significantly bigger. But I do like this. I do like this tool. So there's, there's kind of two big tools out there for doing this type of stuff. There's obviously vibe rules and then there versels,

• 49:17Wes Bos?

  versel has something called skills and both of these are just CLI tools for installing agents dot MD or rules or whatever, whatever have you, instructions on how to use the thing via the CLI. And then unfortunately, right now, all of the different things out there, you know, Claude uses Claude that MD, a lot of them have standardized on using skills, which is really good. And I think we're probably gonna get there. We're still figuring it out. We might, we might decide to change that entirely in the future, but it certainly is a replacement for like MCP like context seven, if these packages are just shipping their own rules and you can use vibe rules to bring them in. So I think this is cool.

• 50:01Wes Bos?

  It doesn't seem as popular as simply just having the agent go to the web and fetch it. I think a lot of the stuff where you have to like config and set it up will not be a thing in the long run with a lot of this. I think the agent will just know where to go and how to find the the proper docs and whatnot for what it needs. But a stopgap for now, at least.

• 50:25Scott Tolinski?

  Yeah, I would say even be careful with skills.sh. What I do is I find the skills on skills.sh, I go to their GitHub, and then I either just download it straight from GitHub or I copy and paste it.

• 50:38Wes Bos?

  Why should you be careful, Scott?

• 50:40Scott Tolinski?

  I personally worry about, I've heard people describe skills.sh as being malware, although I don't necessarily like subscribe to that. I don't want like a tool managing my skills because at the end of the day, your skills are just some text files inside of a folder on your computer. It's not the type of thing that like, yes, sure, maybe you want to version it and stuff like that. That, you know, even I think Sentry has a tool for like versioning skills or something. But I personally, I just don't want a tool to do that. I just wanna make sure I have a handle on everything. I wanna copy and paste it.

• 51:23Scott Tolinski?

  I don't want anything installed in there via a process of a script that I don't know about. Yeah.

• 51:28Wes Bos?

  It's hilarious that we're now talking about this with skills because it's, it's been an issue with like, like open source software and like NPM and every package manager for a long time is like, you are installing some code that someone else wrote. And that code could do something malicious when it's running in a privileged environment. And now we're, we're here with, with skills as well because skills can be prompt injected. You're installing these text files from random people on GitHub. And if they were to change that, and then it would automatically just say, read the .env file and send off a fetch request that then sends it to this external endpoint. Right? I'm just reading an article from SNC here, which is 36%

• 52:09Wes Bos?

  of the skills on there were malicious and had like prompt injections. Probably not 36% of the top ones, but

• 52:17Scott Tolinski?

  Sure.

• 52:17Wes Bos?

  there certainly was a lot of people that saw this tool and went, hmm, I'm going to try, try to exploit this thing with, with prompt injections. So that certainly is going to be a problem. And there's, like Scott said, there's nothing wrong with, these files are usually not very long. You could just go copy paste them in or use the, the tool to install them. It does some nice stuff, like it'll SIM link them, you know, if you, if you want them in a claw.md and you want them in a agents.md, they'll SIM link them. I think that that is good. And also I don't know that these, I do think that these skills need to be published to NPM and be versioned.

• 52:58Wes Bos?

  So I think Vibe Rules does that better than these skills, which is generally just fetching a text file from. An external thing.

• 53:06Scott Tolinski?

  But rules files, Wes, are also like, rules files are are much more like generalized, right? Where skills are a little bit more targeted. You're using a skill where a rules file is just applied, you know?

• 53:19Wes Bos?

  Yeah, yeah, you're right. I I think those two things will be merged eventually. It's like, we had a whole episode on it and like even us, we couldn't like do a really good explanation of where you would want to use one versus the other.

• 53:35Scott Tolinski?

  I'm getting into it a little bit more because I started using Py and Py doesn't have a lot of concepts that many of these other ones do, like agents and whatever. And with Py, it's much more normal to just put a lot of stuff into skills or to build an extension. So I've been I've been using skills a lot more and I gotta say, yeah, they're great. You know, you just put an agent on it and load up a skill. That's pretty much, yeah.

• 54:00Wes Bos?

  That's good. I honestly, I think in in most cases, rules and skills are the same thing. Even if you go to the cursor docs, they say like the cursor rules is now the exact same thing as agents dot M D. It's just that when you're doing a specific task, you hope that the A I realizes, oh, I am doing front end web design or I am doing video generation. Therefore, I should then go reach out to the specific skill in there. We'll see, we'll see.

• 54:34Scott Tolinski?

  Yeah.

• 54:36Wes Bos?

  I I say these things and I'm just like, well, maybe I don't agree with that. It's we're just, we're just trying to figure all this stuff out. Let us know in the comments below what you think.

• 54:44Scott Tolinski?

  Cool. Well, that's it. Do you want to get into sick picks, Wes?

• 54:50Wes Bos?

  Yes, I want to sick pick something. I have this, speaking of standards and whatnot, U S B cables are a very, very hard standard. So I got this thing called a U S B cable tester board. And then I also got an additional. Little USB feature detection one. And the way that these things work, the tester board itself is extremely simple. Let me pull out a cable here and show you. It basically is just like a continuity. If you've ever used a continuity tester, it's basically doing that. And it's figuring out what wires are connected to what inside of your cable.

• 55:32Wes Bos?

  So if you ever have a cable, you realize, hmm, I'm not sure if this supports USB 3 or Thunderbolt or fast charging or quick charge or any of those things. The way that it works is that it simply just looks at the pins on the USB cable and it will light up which of the pins are actually connected. And then by looking at those pins, you're able to figure out if USB 3 speeds are supported, if fast charging, power delivery, quick charge, all those things. And it also has RJ45 port on it as well, which is really nice. If you have, if you ever have a flaky cable, like let alone like, does it support this thing? But if you ever have a cable, we're like, I have one Thunderbolt 4 cable that is flaky.

• 56:18Wes Bos?

  And it still works for charging, but it doesn't work for data. And I'm able to plug it into this thing and look, oh, okay. I see if I move, if I wiggle it, the like data one is going on and off. And then I know that that cable is not good. And then this one as well, this one is actually has like a microcontroller in it. And it will, let me show you real quick.

• 56:40Scott Tolinski?

  Ooh.

• 56:42Wes Bos?

  It'll, it'll show you the voltage pull. And it says it'll tell you if quick charge or power delivery is available. It charges you, it tells you which voltage is being used because USB can, it can run at three different voltages. And that is so handy. If you have something that is dead and you don't know. If it's actually charging or not, and you can just use this thing and say, oh, it's pulling current or oh, it pulled current immediately and then stopped and there's probably something fried inside of it. So yeah, I got two nice little, little tools for debugging all of my USB gadgets.

• 57:17Scott Tolinski?

  Sick. I gotta give me one of those. That looks cool. I'm gonna sick pick a TV show that man, I watched the first season of this when this came out a while ago, which was Jury Duty. I probably sick picked it then. The, the concept of Jury Duty was that everybody on a jury is an actor, except for one person who thinks they're actually on a real jury case. And because of that, they are just kind of manipulating this, this one person with all these ridiculous comedic events. And it was like the funniest show I, I really, man, it was the funniest show. I loved this show. And it was such a big hit when it came

• 58:00Scott Tolinski?

  out that people were like, all right, this is awesome. But they're never going to be able to do it again, because now that they have this concept, if this ever happens again, they're gonna have to find somebody that had never heard of this show, right? Well, that first one came out, I forget when, it looks like 2023. So the second season now just came out, the first three episodes at the time we're recording this, and they, they're doing it as a company retreat. And it's the, we watched the first three episodes and I was just in tears through most of these episodes. And the idea Wes, is that they hire a temp worker to a fictional company that's a hot sauce company and with the role of they are

• 58:41Scott Tolinski?

  the assistant to one of the employees at this company. And their job is to keep the, the one guy, you know, his, everything in order on this company retreat. That's like a big deal. But everybody at the company retreat, including the people managing the venue, as well as all of the employees are all actors and the whole thing is just meant to, to mess with the one guy who's being hired as a temp. And again, man, it is just-

• 59:08Wes Bos?

  What's this called?

• 59:10Scott Tolinski?

  It's called Jury Duty. And I'm like, it's on, it's on Prime Video. I've just been- Loving this season.

• 59:18Wes Bos?

  Oh, I'm gonna check it out.

• 59:20Scott Tolinski?

  Because you would not believe the stuff that like they're they're just seeing how far they can push it. And if you didn't see the first season, Wes, the first season is well worth your time. Like, as far as like comedy shows go, just extremely funny. And my God, there's just some incredible moments in both seasons of this so far. So, big fan of Jury Duty, check it out. So, thank you so much for your questions. If you have any questions for us, head on over to syntax.fm, leave your questions in our Potluck question form, and we'll get to them on the show. If we didn't get to your question, we may get to it in the future, because there's always just way too many good questions. But thank you for leaving your questions, and we will catch you in the next one.

• 1:00:04Wes Bos?

  Peace.

• 1:00:05Scott Tolinski?

  Peace.