transcript

Speaker 1:
[00:01] Welcome to Syntax. Today, we're going to be talking about how to turn Vibe Coding's vibes into more deterministic solutions with facts and logic. We're going to be really getting into the depths of, what are the different tools that you can add to your setup, so that way AI is not just guessing or making assumptions or anything like that. So we're going to be talking about different code quality tools, bug finding tools, formatters, linters, etc. But also the techniques in which you can use these things. That way, you're not just like, hey, make it good, please. All right, is this good? I have no idea. I have no way of figuring that. My name is Scott Tolinski. I'm a developer from Denver. With me as always is Wes Bos. What's up, Wes?

Speaker 2:
[00:43] Man, this is great because so much of this is like people have built stuff, and now that we're, what, three or four months into people building serious stuff with it, you're starting to see a lot of the edges crack around it. People are, oh, this is not actually very good, and now I have a problem on my hands, right? There was this post in the Reddit Open Claw the other day where this guy was just saying, like, I had clients and I made all these automations for them, and I just lost all these clients because things were not working properly, they were breaking all the time. I had no way to tell that things were breaking, which is like, throw a century on there, brother. You'll be able to tell when things are breaking. Just, it's an absolute mess. And if we can have the pure functional programming renaissance that we had in JavaScript, what, eight years ago, if we can have that in this AI slop world, I think that the outputs will become a lot better.

Speaker 1:
[01:38] Yeah, it's so funny because I did my video on the G-Stack stuff, and the video was 34,000 lines of slop, I think that's what it was called. And you get comments, especially on Twitter, where there's some non-developers on there who are going to be like, you all dinosaurs are going to learn that it doesn't matter what the code quality is or if we shipped 26 test files to the user, it doesn't matter. But like, I think a lot of those people are going to wake up at some point when they just start hitting issues that are impossible to solve or, you know, you're just throwing AI back and forth at it trying to fix these things.

Speaker 2:
[02:18] You push one thing and something else breaks and it's just an absolute mess. And like, I get it that maybe the code doesn't matter as much, but we have come so far from, you have to worry about your initial paint times to, who cares if you shipped eight megs of tests to the browser?

Speaker 1:
[02:39] No kidding. Part of that too is if like that exists, then who knows what else exists? Like, are you shipping your social security number to everybody as well? Like, if you have no idea, you don't know, right? And a lot of these people give these systems full access. Yes. So what we're going to be diving into is really like what types of actually deterministic tools exist out there. And anytime you're working with AI, even if the output of these tools is deterministic, as in to give people context who might not be familiar with that word, it gives you the same results every time, right? So, you know, AI, if you ask it the same question, it depends on what the answer is going to be based on a number of things with the AI. But like with these tools, these are like analysis of your code base to output real information. The most obvious one of those that you could think of is something like a linter, right? It's analyzing the file. This is either a problem or it's not. Yes or no, output the problem, right?

Speaker 2:
[03:44] Don't use this, x, y, and z. Don't use common JS. There's just so many of these little guardrails you can put in place that could be rules, but they can also simply just be like a pure function that checks your code, and it's either a pass or a fail. Then you don't have to worry about the wishy washy vibes of an AI spitting something out where it might pass and might not.

Speaker 1:
[04:08] Yeah. A lot of people put that solution, like you said, into like an agents file, agents.md file or a cursor rules or rules file of some kind.

Speaker 2:
[04:16] Yeah.

Speaker 1:
[04:16] Then again, the AI can choose to ignore that. There's been so many times when I'm like, why didn't you do this? It's like, I didn't want to. I told you, you have to do this. If so, who cares?

Speaker 2:
[04:28] Enforceable. To be fair, a lot of times that does pass, but when you have an enforceable thing and you could put in your agents file if you're worried about the code, run it through a linter, right? And then it will see if there's any problems that pop up and it kind of learns from that.

Speaker 1:
[04:48] Yeah. So let's actually, I'm going to start off with an interesting category here, which is code quality tools, because code quality isn't something that we necessarily think of beyond like linting or something like that. We'll talk about linting and formatting later in this episode. But the code quality area is something that I think has really kind of blown up just a little bit. When I first started looking into this, I found a couple of tools. One was JSCPD.dev, which is basically something that will analyze your code to find duplicated code blocks across 150 languages. So this is the very first one of these tools that I came across, and there's a MCP server included, or an agent skill, an AI reporter, and stuff, and this tool, it's a CLI tool, that will actually scan your code and look for lines that are duplicate, because we know that AI will love to just solve a problem where it's at. I'm going to write this utility function that clearly should be a global utility. I'm going to write it in this file and use it instead of importing or looking for an actual global utility. So that helps with that because it can output, and then your tools can then self-patch, right? So it's like, oh, I recognize that this is some code duplication, therefore, let me fix it. Then there's also NIP, K-N-I-P.dev, which is an analysis for JavaScript and TypeScript projects, and this is going to find unused dependencies, exports and files. It helps to analyze your code. There's a whole bunch of different plugins, 100 and 100 plus plugins like Astro, Cypress, ESLint, etc. It's a cool tool. But I'm going to recommend actually, instead of JS, CPD or NIP, I'm going to recommend a tool that I found that does it all and does it all very fast and very reliable, which is Fallow. Now Fallow exists at docs.fallow.tools. We will have these links in the show notes. Fallow looks for dead code, circular dependencies, it looks for code duplication, it looks for complexity hotspots, code-based health, and they just added feature flag detection, which I, this Fallow is an active development, because every time I go to this page, there is another tool. And this again works with everything automatically out of the box. Like, there are tools to work with Svelte, and I didn't have to install a single thing. It just has that plugin baked into it.

Speaker 2:
[07:34] Complexity analysis finds the most complex functions, per file maintainability scores, get churn hotspots, probably like code that's often touched, and ranked refactoring target. That's cool. Man, you like look at your code base and say, ah, this is a piece of your code base that is often being fussed with, probably because every single time that you add a new feature, you have to touch that. Probably a good spot where you could refactor a lot of that out into smaller reusable functions.

Speaker 1:
[08:07] Yes, and this all outputs in a way that AI can read, it outputs in a way that you can read, it feels just like using a CLI linter or anything like that. One thing I really like about it is that you can configure it to be whatever you want. Like if you're looking for duplications, you can configure the minimum amount of tokens or minimum amount of lines that are duplicated or what those thresholds are, things like that. That's cross-language duplication where it will check between TypeScript and JavaScript files by stripping the TypeScript stuff to see.

Speaker 2:
[08:41] Yeah.

Speaker 1:
[08:42] There's a lot of great stuff in here and it's fast. It's fast, it works good. Architecture boundaries, man, there's so many interesting stuff. There's even an auto-fix feature, but to be honest, auto-fix features freak me out even though for some reason, I don't know if this is like an auto-fix to me, freaks me out more than outputting the output into AI and being like, you fix it, which I don't know if that tracks in terms and reasonability.

Speaker 2:
[09:11] I wonder if this complexity finding solves the opposite of code duplication because what I often find AI does is it will modify a function just and throw a whole bunch of if statements. Oh, you want to do this? Now, let me add this one case inside of this function, and then you end up with this just like, well, if it's this or if it's this and if it's this, and it's like, no, that's not good code at all. You're simply just handling every single possible outcome instead of making it into a, like, you could probably delete half of this function if you made it a little bit more reusable. So, I hope that that's what it does because I find the opposite as well. If you lean too hard into like, hey, make this maintainable and reusable and into a utility function, then it just starts to stuff everything into one function.

Speaker 1:
[09:58] The cyclomatic complexity, so it has a number of different complexity metrics. So, the number of linearly independent path through a functions control flow graph, that kind of sounds like exactly what you're talking about.

Speaker 2:
[10:14] Man, and like-

Speaker 1:
[10:14] Cognitive complexity, cognitive density, yes.

Speaker 2:
[10:18] How does this work? It obviously analyzes your code, but then it probably just gives scores based on different things. That's probably what the plugins are.

Speaker 1:
[10:27] Yes, there's a bunch of different scores. There's different, let's see, fellow uses binary coverage model. A file is either test reachable or it's not test reachable. So, there's different types of essentially rubrics that it's evaluating your code on.

Speaker 2:
[10:45] You love a rubric.

Speaker 1:
[10:46] Of course. Love a rubric, yes. This is the number one tool I think that people aren't using that can help their slop. Because this is the exact types of things that, like you mentioned, that AI loves to do. It loves to just solve a problem as efficiently as it can, not as efficiently as your code base should have. And then that can lead to maintainability issues. It can lead to performance issues. It can lead to bugs overall. Yeah.

Speaker 2:
[11:18] And even if you are a Vibe code, and you probably just pipe the output of this right into the AI as well and say, hey, fix it. Just being able to find potential issues in your code that are not necessarily like syntax errors or security errors, but they're simply just like bad programming. That's cool. I'm going to check that out.

Speaker 1:
[11:40] There's even a VS Code extension for it. It's written in Rust so you know that it is fast.

Speaker 2:
[11:44] Probably amazing then. It must be. Yeah.

Speaker 1:
[11:48] Here's another one. So there's also CSS, and one of the tools that I really like for CSS code quality finding is Project Wallace. Now, Project Wallace has a CLI as well. It can analyze your CSS variables and things like that. This would take a little bit more work to tell the AI, like how to interpret the results here. It's not just giving it a punch list of things to change, but I do think that it's a cool tool to have in your toolbox for when you're working with CSS, which is another one of the things AI sucks at. One thing that I want to see more of is tools like the Svelte AutoFixer, which comes in there, Svelte MCP, which will basically read your file and tell you what is not Svelte best practices. So I don't know what other frameworks might have tools like that. I'm very sure that other frameworks probably do. But you can search for those. I did a number of Googling around, but there's a lot of people talking about it. So leave a comment below if you have a specific React fixer type of deal or a view fixer for things that might be considered not best practices, that might be hard to lint about.

Speaker 2:
[13:06] Man, the Project Wallace is really good for finding, one thing that AI loves to do is set font sizes and line heights explicitly on every single thing, you know?

Speaker 1:
[13:17] My God.

Speaker 2:
[13:18] It's like, why did you set? The trifecta is line height, font size, and letter spacing on every single text element in there. Yeah. Project Wallace is excellent at hunting those out and figuring out where that's gone wrong. Generally, that's because you haven't set up anything in the first place. If you just tell it, make a cool UI, and it echoes nuts with those types of things. If you have those things in place beforehand, maybe it doesn't happen as often.

Speaker 1:
[13:47] Yeah. As we saw in the codec system prompt, in the open codec system prompt, it says, use gradients and expressive CSS and stuff. Yeah. Yeah. That stuff.

Speaker 2:
[13:58] I get because it looks better than some of the crap that gets pushed out.

Speaker 1:
[14:02] Yeah.

Speaker 2:
[14:02] But then it just does it all the time. Then it overdoes it and it becomes played out and it looks awful, it's hard to maintain, all that.

Speaker 1:
[14:11] All that. Yeah. Next one here is for finding and using components. Now, this is a tool that requires a bit of buy-in. But one of the problems that AI has is certainly looking up and finding appropriate components, knowing when testing components in isolation. We actually use Storybook on the Syntax website, and Storybook has some really good new AI tools, specifically around finding and indexing your components, testing your components. So there is a Storybook MCP server that, the thing that I like most about the Storybook MCP server, now it does require buy-in to Storybook. But if you're already using Storybook, this gives you a number of things like list all documentation, get documentation, those types of things. So that way, when you say I need this component or whatever, it's not just doing a find in your code base, looking for components and then trying to guess here. It's actually like, okay, here are all of the components, get that components, documentation. And one of the more powerful things is that there becomes canonical examples because you're using stories to show how the components used. Because typically the AI is going to use the, what, like the type signature and or maybe other prior usage of that component. But this gives it like a real, here's how you use this thing. That way it can plop it in there.

Speaker 2:
[15:48] Man, if you have a really good design system and a whole suite of components that you can then use, unstoppable with the AI stuff, especially when you're simply just clicking together a new view. You already have all the pieces for that, and you just need to wire them up, maybe write a bit of logic on how to interact with it. Great use case. So I've become more of a believer in the Storybook stuff since all of the AI. I always have enjoyed it, but now where you have a nice clean example of how it works, and you feel comfortable about how it looks on its own, and how it works and interacts, so much better.

Speaker 1:
[16:26] Yes. I find that, man, even with AI, Storybook becomes a little bit less annoying because I'm not having to hand author all the story components.

Speaker 2:
[16:37] Oh, yeah.

Speaker 1:
[16:38] I've just got to make a companion component for all this, and copy and paste, and do this and that.

Speaker 2:
[16:44] Testing is like that as well. All of a sudden, everybody loves testing because you don't have to do all those busy work of scaffolding it out.

Speaker 1:
[16:49] I love testing because with AI, my tests always pass because AI will just make them pass.

Speaker 2:
[16:55] Yeah. Well, not exactly that, but the work of scaffolding them out, and writing them, and coming up with potential use cases where things will break. Or even if you have a bug, just throw that bug in there, write a test.

Speaker 1:
[17:12] Yeah. I think testing has never been more valuable, but also more disposable in a way, where it's really easy to just be like, I don't know, test your passing because the AI wrote them, whatever. But at the same time, it's also really handy to be able to easily move through testing. Next one here is bug finding. Now, I just have these two Sentry tools, Sentry, which is, well, Sentry presents Syntax. Head on over to sentry.io/syntax, and you'll get two months for free with the coupon code TastyTreat, all lowercase, all one word. But these two tools, I think, are really fantastic. One is the Sentry CLI, which everything CLI these days, but the Sentry CLI allows you to authenticate with your Sentry. You can get the root cause of any error in your Sentry. You can see all of the relevant errors in your project directly from your CLI. The agents can connect to the CLI and therefore, the agents can look up what your errors are and get the actual root cause and then fix the thing for you. It's very seamless. So if you're using Sentry already, plug in the CLI to with whatever you're doing. And if you're not, yeah, check it out. Another tool that I think has gone under the radar a bit is the Spotlight tool from Sentry, spotlightjs.com is an MCP server. That gives you real-time local errors, traces and logs. And it gives you essentially a local interface for debugging in development. And so this is a tool that is primarily used for while you're in dev, you're talking back and forth and the agent isn't having to hunt in the browser logs. It's not having to hunt in your terminal logs. It has all of that information directly in an organized way. So that way, again, you're not copying and pasting back and forth with the agent, or you're not having to use a headless browser that then has to scoop up those errors.

Speaker 2:
[19:15] Dev tools and pasting your logs. Just a nice tidy spot for all of your info that you're probably interested in that info in prod, right? And you're using Sentry for that. But in development as well, sometimes that, or often, that info is extremely helpful, especially when you're using agents.

Speaker 1:
[19:33] Yeah. And you still get that root cause analysis, which I think is super helpful. But there's also performance. So you can get database query timing, API request, waterfall, component render times. Like you get all of this in your local Devflow. And I don't feel like enough people talk about this tool because I find it to be very helpful. So it's easy to install, works with everything, and I like Spotlight. Next step on the list is generally formatting and linting. These are tools that, again, many of us have just always used formatting and linting tools, or even type checking tools, like just TypeScript. But these things become very important when you are wanting to tell your agent to always run type checking, always run linting after completing a feature, all this stuff, and moving again these general like, is this a problem or not, out of the brain of an AI scanning your code for problems and into a checklist of fix this, fix this, fix this. One thing I really like in this regard is Vite Plus uses a VP check to run linting and formatting and type checking if you want it to. It does so with caching. It's just the best for this type of thing. If you're using Vite Plus, the VP check is the one to use. It's really great. But otherwise, using something like ESLint is just becoming more and more important. Now, one thing I think that's really underutilized here is that a lot of us, as we've mentioned, have issues that AI just continues to do. In Svelte, it's a problem where it just uses effect for everything. It's like, brother, this ain't react.

Speaker 2:
[21:16] It just coerces the value. It uses as or it just makes up its own types. Oh, I expect that this is what the template looks like, so I'll just throw a type above it. It's like, no, that should be inferred from the database, something like that. I feel like with TypeScript a lot, as good as it is as TypeScript, it cheats it quite a bit. Cheats it.

Speaker 1:
[21:38] Yeah.

Speaker 2:
[21:38] A lot of people are just like, oh, really? Test pass. There's no type errors. Yeah, because you just use assertions everywhere.

Speaker 1:
[21:45] Yeah, I know. One of the things that I think VibeCoders might do in this situation is just put it in their agents.md, saying, hey, don't do that, please no don't. But that's like a sign that says don't that you can just walk past. The AI agents won't adhere to that. They're going to consider it. But if you put it into a tool like this, then that changes things quite a bit. So I think Kevin from the Svelte team was saying that he even put in his ESLint setup, it would fail if the agent used effect in SvelteKit just because of how much it was doing. So he wrote a custom ESLint plugin just to check for those types of things. I think that's really underutilized, writing custom ESLint plugins instead of just tossing stuff into your agents.md. I think it's something that people don't do enough.

Speaker 2:
[22:37] Make it deterministic, don't write a wishy-washy rule. And the beautiful thing about that is that it is so easy to get the AI to write a deterministic plugin. And then you can write tests against it and see that it actually works. I've written like three VEET plugins in the last six months as well just because it's so easy to spin one up.

Speaker 1:
[22:59] Yes, I know it is. And then on the CSS tip of things, StyleLint is still great. It's something that is so underutilized. I think I've said that about 100 times on this podcast. StyleLint is basically CSS linting in the same type of way. It helps you find those exact type of things. Expected, custom property name, this is a loud unit. Like again, like, all right, you are assigning a background color or you're assigning a box shadow without using one of our predefined shadows. That's in a variable or you're giving a color that's not in our variables. It's gonna err on this. Then that can be used in addition to actual like agents.md files about saying what to do in those types of situations. I am working on my own because StyleLint is great, but I would rather a tool that was more effortless. So I made one using the Lightning CSS parser because I wanted it to be faster. I wanted it to be tuned to kind of modern CSS sensibilities.

Speaker 2:
[24:06] Yeah. So what's wrong with StyleLint?

Speaker 1:
[24:10] I find StyleLint to be difficult to work in. I find it to be a bit bloated. It's been around for ever. It's very full featured. But I'd rather it be like Parcel, or even like with the new VEATS stuff, right? Where it is just really smart defaults, no configuration.

Speaker 2:
[24:36] Throw it in there. As long as you're okay with it. It works fast as hell. That's what I've been telling people with like Oxlin and Oxformat and stuff. In most cases, I've put so much of my ESLint and Prettier config away, and I was like, I'll just use this. For newer projects or projects where a massive changing thing, maybe two or three changes I added to it so I wouldn't have this massive commit that just changed the entire codebase. But as long as you can just lay down and accept the defaults, sometimes that's better.

Speaker 1:
[25:13] Yes. That's really what this is about. Man, is it fast. It works with all my stuff. It's called Clint, like CSSLint, Clint. Check it out. It's still early, but it does know and known properties and valid values, duplicate selectors, duplicate declarations, empty rule sets, those types of things. I think it does so very fast and nice, so give it a try and accepting contributions to it. That'd be great. Next one here is making your browser usage headless. The king of this area is the Agent Browser from Versel. Agent Browser is great because it's very full-featured. You can tell agents to, hey, check this in the browser. It can do screenshots and those types of things. It can handle anything that a browser would be able to, really, is what it comes down to. For the most part, I don't have a lot of complaints with Agent Browser.

Speaker 2:
[26:10] No, it's great, especially because one cool thing with Agent Browser is that you can hook it up to any Electron application. All you have to do when you're starting the Electron application is you have to start it with a remote debugging port, which is an argument. So you can open Slack and pass it, dash dash remote debugging port 9222, and then your Agent Browser skill will be able to connect to it. I sent Scott, Scott's like, what were you using? I was like, I use Agent Browser and I sent him a message from, I just went into Cloud and I was like, use the Agent Browser, you have to restart Slack with the flag, but it can do that because it can run terminal commands, right? Then it just sent Scott a little message. I set that up the other day because we were doing a battle with CJ, Scott, and myself. We were doing a battle where we couldn't use the mouse, and I thought that Randy was going to post something in Slack, like a screenshot or something like that, and we weren't allowed to copy paste it. So I was like, I'm going to get my agent browser dialed in so that if Randy posts something in Slack, I'm going to be able to get that image out of Slack into my editor. It ended up working, but it ended up not being what Randy had planned for us. So I'm ready for the next one.

Speaker 1:
[27:31] Yeah. There's also Chrome DevTools MCP, which is great for this as well. The thing I like about Chrome DevTools MCP is that it pops open a little Chrome that you can see it executing your stuff on nice and easily. I think that's the default way that it works. I don't know if you can even turn that off if we're being honest, but I like that I can see what it's doing. Like sometimes the AI uses like the wrong, like it just assumes it's like, oh, this is a feed site. Of course, it's on port 5173. Okay. And then it's like the wrong site. And it's like, for some reason, the app is showing something weird here. I'm like, that's because you're at the wrong app and you didn't check the port. So, yeah, Chrome DevTools MCP, great usage for that as well. But having these tools are great because again, you can look at the, they can take screenshots and see what it looks like. It can read the console log and it can read the network panel and those types of things. Another option here is Lightpanda. Have you seen Lightpanda, Wes?

Speaker 2:
[28:29] I had this on a list for another show that I've been mulling around. So they rebuilt an entire browser. It uses V8, but it's apparently way faster for Headless. I went back and I looked at it. It says, the first browsers for machines, not humans. I was like, wow, they really are going hard on this agentic browser, which apparently makes it faster for interacting because that's the one thing about these puppeteer and these Headless browsers. They're slow as molasses because they got to take a screenshot or go to the DOM and then send a click event. Absolutely so brutally slow. So Lightpanda is like a new browser that they basically just took V8, which is like the engine. It can run JavaScript. I don't know if it runs CSS or not, but because it just needs the markup, right? Yeah.

Speaker 1:
[29:25] Where do you see that it runs V8?

Speaker 2:
[29:27] I looked into it because I was like, what is this? I was like, they didn't just build a browser from scratch. That's crazy. Ladybird is doing that, but they are crazy.

Speaker 1:
[29:36] Yeah, because it just says a browser engine. Yeah. It does say Lightpanda is written with Zig and it uses build the V8 engine for Zig.js runtime. Interesting. Yeah. Okay.

Speaker 2:
[29:48] Yeah. I looked into it. I went on Wayback Machine and I was like, this is not just something that someone vibed up in the last six months because everything has agents and they used to be a browser for scraping, which makes sense. They used to be this thing that scraped websites and got data and it was as fast as possible and I guess they've changed. I guess that still is a big use case, is visiting websites and scraping.

Speaker 1:
[30:15] Yeah. You know what there's pricing on here? Is the pricing only for their Cloud or is it just using Lightpanda in general?

Speaker 2:
[30:23] You can install this thing and run it no problem. I think the thing that nobody is talking about with these AI agents and whatever is that you need a lot of IP addresses and you need a lot of compute to actually run these browsers. Often, it doesn't make sense to run a headless browser inside of a serverless function. So you see CloudFlare has their own browser thing that you can use to take screenshots, and it's puppeteer-compatible, and then they have this thing as well. But I think the other thing that a lot of these companies that do this are not talking about is that they probably run them on either in people's houses. I don't know if this is true or not, but I listened to this really good darknet diaries about these streaming boxes, and I've also gotten lots of emails from people saying, I have residential IPs available, and it's because you can't just use a VPN and scrape a thousand websites. They're going to block you. They don't want you doing that. Many of these places don't want you doing that. So what you need really is something like Lightpanda running on somebody's illegal streaming box, and you have a nice clean IP address that you're able to send requests out on behalf of someone. I don't know that that's actually happening, and I don't know that this is Lightpanda is doing this, but I guarantee that's happening in some regard right now in our industry.

Speaker 1:
[31:48] It's very interesting, and also if you're curious out there, you can have Agent Browser use Lightpanda as the engine. So if that's like-

Speaker 2:
[31:57] Yeah, it's like puppeteer compatible, right?

Speaker 1:
[32:00] Yeah, if you want to just have your whole setup with Agent Browser that you already have and then pop in Lightpanda as the engine, it's a simple config change. Another thing here we have is tasks into do's, which man, AI loves to lift a bunch of to-do's and then not check them off or not do them, or every single AI harness has its own to-do system and they're all crazy and they don't get saved to your database. So I have a couple of tools here, and this is less for deterministically scanning your code base, but this is more for a general workflow type of thing. I use dex at dex.rip, which saves everything to a JSON file, and then there's beads, which is one that's popular that source things into a database and uses Git hooks. But either way, the thing that are nice about these is that they can be blocking. You can have tasks that are blocking other tasks. You can have a clear execution of this, then this, then this, and again, it's commits to your GitHub repo. You can take it with you. This is, again, less of a code deterministic thing, but more of a plan deterministic thing. That way, if it's saying, give me the next task to do, it's not just like, huh, what should we do? It's like, OK, this is blocked by this, which is blocked by this. Let me pick this, and then let's implement this. And then again, you can have descriptions where you're passing in actual code paths and stuff. So I like dex.rip for this, and not just because it was made by my boss. Next one here is context seven for docs. I still use context seven quite a bit, because in this whole platform of AI agents knowing what to do, you can have best practices, you can have skills that are telling it this or that. But a lot of times, just having the docs in context seven via MCP, I find to be still the best. It just looks it up, gets the answers, possibly usage patterns and stuff like that, and then is able to assess a better version of like, okay, this is what it should be done like because I have the docs. So that one's been talked about to death and again, less deterministic about your current code and your current quality. But when you're looking up patterns and examples, context seven is great.

Speaker 2:
[34:23] Did you see Tenstack had code mode they released the other day? I think this is similar to the Cloudflare code mode that they came out. Cloudflare replaced their entire MCP server, which was they had like seven or eight different MCP servers that you could hit, and what happens is that you get so much context bloat, and it has to work really hard to figure out which tools to call, whatever. They replaced the whole thing with simply just giving it a sandbox to run some TypeScript, because the LLM is pretty good at running tool calls, but it's really good at just simply writing TypeScript that can be run. It's the same idea that everybody is saying, don't use MCP, just let it run CLI. The agent is very good at running CLI calls. In the same way, the agent is very good at writing TypeScript. If you give it this sandbox where it can run TypeScript, I won't get into it. We'll do a whole show on it. But you get the schema, you can call all these different tools and then it will then execute it. It might return documentations, it might update your Cloudflare dashboard or whatever. It's a really interesting way to make an MCP server. Basically, just giving the LLM a little spot to run some code that is in sandbox. That's what the Cloudflare Dynamic Workers are. Now, Tanzstack came out with their own code mode, which is really cool, a spot to run this all. I think we should probably do a whole show on this. This is very interesting. We're all trying to figure out what all these tools are and how they best work. I think this code mode certainly hits on some of those.

Speaker 1:
[35:54] Code mode is an interesting name for that. I don't know if I get the name, but I'm keeping an open mind here. At the end of the day, how do we get AI to use these tools? We beg them. We put them into our agents.md file. We put it into skills. We tell it, hey, always. I've had good luck with saying, upon completion of any feature, always run the sequence, right? Run first run type checking or VP check, then run fallow checking, then do this, then do that. I've had good luck with that. But at the end of the day, you can run them yourself and give the output to the AI agent and say, hey, fix these things. Or you can say, in your agents, please do this. Or you can have skills, which is like my quality check skill, commands that run the quality check commands. But it's very difficult besides that. You can always wrap this all up into one quality check script that then runs all of your quality checks.

Speaker 2:
[37:02] Yeah, you can run it on like a commit, which is pretty common thing to do. You're not allowed to commit any code if these things are failing. Some of them are a little bit more annoying because you're like, it surfaced that, I don't necessarily care about that. Then I'll have to go and put this weird comment in my code to ignore that. But running it on commit is maybe a good idea. That means it will never actually make its way into your code base until things pass.

Speaker 1:
[37:27] Yeah. Honestly, I found it to be better to be in control of the output of these things rather than just being like, I'll go ahead and just do whatever you got to do to get these things passing or fixed, etc. But I think that's it for all of the tools and things that I have here. Wes, is there anything else in your toolbox that you use to make AI more deterministic?

Speaker 2:
[37:48] Just swearing, mostly. We did find out when the cursor thing leaked, we did find out that swearing at cursor does log into an internal entropic dashboard, and they have an F chart that they can see how angry their users are. So, swearing at your LM does work.

Speaker 1:
[38:09] I wonder if I'm on the leaderboard. That's all I got to say.

Speaker 2:
[38:12] That certainly is the top. Oh, that would be hilarious. All right.

Speaker 1:
[38:19] Let's get into sick picks and shameless plugs. I have a sick pick, which is a razor. I'm going to be real. I don't know if they're like straight razor or whatever people are snobbish. I would assume they are. I'm not clued into that. I have been advertised this leaf razor on Instagram a whole ton, and it's all metal. It uses single blades like half blades or whatever, and the blades are just so incredibly cheap. You can get really nice blades from different places. You don't have to buy their specific ones. It's standardized. But this razor in particular is a two blade razor, and because the blades are so cheap and standardized, the idea is that every time you're shaving, you're just popping two new blades in there. There's like no disposable plastic, anything that's getting tossed in the landfill somewhere. It's all just really great. So I had the prior single blade one called the, I believe it's called the thorn or the twig. And that's for like using like ed, like lining up things and stuff. And I liked it for so long that I was like, you know what, I'll just get the two blade one for normal shaving. And my God, it's just like a completely different experience because every single time you got these just beautifully sharp blades.

Speaker 2:
[39:47] Twice as much. Yeah. Oh man, a fresh blade. Man, I don't use razors to shave because my skin gets on fire, right? I just turn into like a red tomato. But I cut things with razor blades and fresh one, man. I bought a hunter pack for my utility blades. Nothing better. Yeah.

Speaker 1:
[40:06] Nothing better. Man, it's just like shaving. It's gotten so much nicer and it's fast.

Speaker 2:
[40:11] Do you have the old timey like, you brush it on? No.

Speaker 1:
[40:15] No?

Speaker 2:
[40:15] Okay.

Speaker 1:
[40:15] No, I'm not that snobbish about it, which is why I'm concerned that there are people who will be like, I caught you by the leaf razor. Yeah. But it works great. So really cool, really nice and I'm happy with it for sure.

Speaker 2:
[40:28] I'm a sick pick something really silly.

Speaker 1:
[40:30] Puzzles.

Speaker 2:
[40:30] We've been doing puzzles with our kids lately. Yes, I love puzzles. They're a hoot. It's fun to think about how I can't get it out of my brain that I would love to build a bot that could solve the puzzle. I know Mark Rober did it on one of his videos and ever since he did that, I was just like, man, that would be so cool. Then I look at the puzzle pieces and they're all different. I was like, what's the algorithm for making these swoops? I just want to learn so much more about puzzles, but my kids absolutely love them. It's super fun. Just generally get a puzzle.

Speaker 1:
[41:07] Get a puzzle. Yeah. My daughter, she's got the engineering brain, and she is really good at puzzles. Shockingly good at puzzles. That's one of her favorite things to do. It's so funny. I've never been into doing puzzles, but now her and I sit down and do puzzles all the time. It's such a good time to connect, and she really loves it.

Speaker 2:
[41:32] Even just the content of the puzzle. We got one which is like 20 countries in Europe or something like that. It's like the countries of Europe, and it just shows a monument and something like the Eiffel Tower and a baguette, and that's France and the flag. It's so fun to be like, oh, we've been there or that'd be cool to visit that. Yeah.

Speaker 1:
[41:53] We got an outer space one. She's naming all the planets. She's giving me facts about all kinds of stuff. But yeah, no. We push it too. So every single time we're like, we're going to go a little bit crazier with this one. She's doing some amazing puzzle work.

Speaker 2:
[42:08] We should make a Syntax puzzle.

Speaker 1:
[42:10] Oh, man. Yes. Count me in.

Speaker 2:
[42:12] Or like a code mode puzzle.

Speaker 1:
[42:15] Yes.

Speaker 2:
[42:16] Because you could read the code on the pieces and know where that goes. That would actually be funny.

Speaker 1:
[42:22] That actually would be, yeah, code puzzle. And then the code could be funny in some sort of way. Real quick before we get out of here, I do want to shamelessly plug my wife's podcast Phases.fm. Man, she's been working really hard on this. And it's just her first video episode, which is going to be on YouTube, Phases.fm, or it's on phases.fm is the website, but you can find it in any major podcast app. Just go to the website and there's links to all that stuff there. I want to also shout out the transistor.fm, I believe is the URL, transistor.fm as a podcast hosting platform. It's really good, Wes, and I know we use Megaphone for ours, we used Libsyn before. They have a really neat feature on here, which is showing you amount of downloads in the release window. So it's not just like day one downloads, it's like you can get hotspots for seeing what the release window looks like. One interesting thing that they're adding right now that you might be curious about is video distribution, where now that Apple's added video podcast-

Speaker 2:
[43:27] That's why we didn't go with them, because there was no standard for video, right? There's no standard.

Speaker 1:
[43:32] Yes. So they're implementing that, and I'm curious to see, I've signed up for the waiting list. So Justin, if you're listening, please get me on that waiting list because I want to try it.

Speaker 2:
[43:42] I went out for lunch with him a couple of months ago, so I'll get you in.

Speaker 1:
[43:48] Get me in. Yeah, because I'm interested. It's good product though, man. It's really good. So shout out to Transistor. Check it out.

Speaker 2:
[43:54] Canadian product as well, of course. All the good things are Canadian.

Speaker 1:
[43:58] I didn't even say what my wife's podcast was. It's a parenting podcast. She's a psychologist. She's a doctor of psychology. She taught master's level human development courses. So she's brilliant. And she's talking about human development, neurodiversity. She's talking about kids and parenting in a scientifically backed, lighthearted, fun way. So check it out.

Speaker 2:
[44:21] Cool. All right. Thanks for tuning in. Catch you later. Peace. Peace.