Choosing the Right AI Model for the Job

[00:00:00]

Matt: Why pay for Opus to rewrite a three-line email? Why would you do that? And why would you spend an hour arguing with a cheaper model when a stronger one might untangle the problem faster? Today, we are talking all about which model we would actually reach for task by task. Now, we're gonna-- we kinda designed this episode to not mention specific models much, although they may naturally come up in the nature of the conversation, 'cause the idea is that even if you're listening to this in, let's say, a year, two years, whatever, this episode will still hopefully be as relevant as possible.

We're trying to make this as evergreen as possible. We'll see how that goes. So if this sounds interesting to you and you wanna support the show, you can go and check us out on that Patreon, leave a review or rating in your podcast app, join us in our Discord server, or share this with your friends. And if you wanna take some coding courses and learn how to code, you can do that on Scrimba, and they have a pro plan that you can net up to twenty percent off if you use our link.

That link will be in the RSS description and in the show notes with full details on how it works in those [00:01:00] show notes. Mike, you're on this call,

Mikhail: I am

Matt: we have a segment that we occasionally do, and I wanna

Mikhail: mhmm

Matt: once again, and it is this week's takeaways. So Mike, why don't you let us know what you took away from this week?

Mikhail: I'm gonna talk about like a, a random tech thing. The MacBook Pro was just announced, the, with the OLED touch screen, so it's gonna be the first Mac with an OLED touch screen

Matt: Well, that was confirmed. I heard the rumors last night, and then I was away at a family birthday party, so I have not looked at the tech news literally at all

Mikhail: Yeah, that was confirmed. Yeah, they announced it. They had a full, like, showcase and, press w- press was able to play with it and stuff like that. It looks cool. I don't know why, but in general I'm just not excited about any releases anymore. I think we've had multiple web news on this topic where, I'm pretty sure it starts at, like, five grand or something like that, something ridiculous.

And okay, like it has a touchscreen. All right. It's a really cool device, no doubt [00:02:00] about that.

Matt: What's the price that are, that's bringing the

Mikhail: I think,

Matt: of your sails for everything, right?

Mikhail: I think so that and, like, specifically with MacBooks lately is they're not that good at AI workflows, which is weird to say, but, from my understanding, however they handle file creation and compression and all of that, like it's just different than how Linux handles it.

And apparently there's, a significant, like I'm talking 5 to 10X time difference for spinning up a project and running it, like an agent running a project and spinning it up versus macOS versus Linux for, like, a $5,000 top-of-the-line MacBook is still gonna be slower than some shitty old $700 IdeaPad, um, or like a, you know, a ThinkPad, a ThinkBook.

So, like -- And everything is AI workflows now. Like, it's just, it's just how everyth- everything is done in business. So, like, you can put all the compute you want into there, and it's great for running local [00:03:00] models, which we can talk about actually in this episode a little bit. but, like, they're not really that useful yet.

Like, I don't know. You're spending ridicul- Like, to run a local model you're gonna need, like, the, you know, 15 grand version of this thing, c- US by the way. So, like, you know, $100,000 Canadian or whatever it is. just, I don't know. It

Matt: literally that for

Mikhail: No, it's not. It's not. I, it's -- Yeah, it's not, but, like, it's, it feels that way.

It, like there really is no difference to me. Like, I'm not buying it. So, like, I don't know. It's cool. I've actually been waiting for a touchscreen MacBook for a little while because I've been -- I, like, I kinda like touchscreens for specific things. But Just, yeah. I don't know. What about you, Matt?

Matt: my main takeaway, that's a good question. We've been kinda hitting the, the lead generation pretty hard. So we do a lot of lead gen for our small business clients as it sits, so we help you make CTAs and help you with your SEO, help you with your copy, help you with all your kinda [00:04:00] stuff to get people leads. But our business has been largely referral, meaning our business as in our web dev agency, has been largely referral for the better part of a decade, and we're just trying some outreach now. So we're kinda learning the ropes that way. I know how to sell once someone else has kinda introduced me, like, "Oh, hey, and this is Matt, my web guy," and then I can talk to you and get a sale and help you out properly kinda thing.

But I don't know how to kinda get that initial meeting, 'cause it's been so long and we just haven't needed to, and I haven't had, haven't had the, I guess the reason or whatever to, to try. So we're trying to grow the business a little bit, and so we're, we're learning that stuff. And so I'm, I'm learning a lot about looking at how to get leads, going into Facebook groups, watching Reddit, watching Reddit threads, watching social media. I'm seeing what other people are doing, what's working, what isn't, where people are kinda piling on. You'll see kinda classic keywords such as, "I need someone to design me a logo," and then that person, who is a person who rarely [00:05:00] uses Facebook, is suddenly getting 2,000 up votes and 500 comments and people are all like, "Oh, call me, call me, call me, call me," right?

And so you're thinking, "Okay, how do I stand out, you know, in a crowd like that, magnitude, of that volume?" So it's been kind of interesting and kind of fun. We've been putting ourselves out there, talking to our existing clients about how we're trying to expand a little bit and things like that, and it's been, it's been interesting.

It's been an interesting journey, and it's still going, obviously. We've, haven't been doing this that long. But it's, it's, it's cool. I mean, if anyone out there is listening and they, they have any, I guess tips or tricks or anything on how to drum up some business, I mean, I'm down to have that conversation, because I'm starting to generate my own opinions.

I'd love to hear from other people that are doing it as well, and it'd be a cool kinda little meeting or a little chat. That'd be, that'd be kinda, kinda neat. But we're not here for that. We're not here for the main takeaways, although we kind of were, but we're not here li- here for that no more. Actually, that's a little, there's a little in-joke there.

I got a little [00:06:00] in-joke for you. This is pretty funny. Uh, at least it was funny to me. So I have a couple of friends who went to a summer camp, and they were older, so I think it might have been end of elementary school, maybe beginning high school or something. But they went to this summer camp or this summer workshop of some sort, and they were going for some sort of filming.

It was either, like, movie camp or, you know, movie workshop or something like that, uh, or filming or whatever. And they went into this community center, and there's multiple boardrooms, and presumably they went into the wrong boardroom because they sat down in amongst a bunch of people. They're sitting there, and this guy goes up to the front of the class, and he's talking about something else that's completely unrelated. And so one of my friends kind of puts his hand up, gets the attention of the instructor, and says, "Oh, hey, hey, sir," like, "we're here for film, film camp, film, film workshop." He just looks him dead in the eye and just says, "You're not here for that," and then continues the lesson onward, and that was the end of that chapter, so

Mikhail: GG, I guess. Like

Matt: [00:07:00] so, uh, that's one of our in-jokes

Mikhail: mm-hmm

Matt: friend group is just, "You're not here for that." If we, if we show up to some place where, "Hey, you know, this, this movie's supposed to be amazing," whatever, then the movie sucks, and you're like, "Man, I came here for a good movie." Someone will also always come in and be like, "You're not here for that."

Mikhail: Mm. Pretty good

Matt: it's a little bit of, little bit of lore. Mike, I'm gonna pass the microphone figuratively to you because you wrote up this episode. Please, sir,

Mikhail: Absolutely. Absolutely. So this episode kind of came to me from a lot of my personal experience on, trying to maintain my subscriptions so that I'm able to get the most out of them in terms of, like, AI workflow usage. Because I pay, I pay for some of these, or my company pays for some of these subscriptions that are, like, $200, $100 a month, and even with that, if I'm doing something heavy, I can burn through it pretty quickly if I'm using the biggest, best models.[00:08:00]

And a lot of times it's just a little tweak of a system and a little bit of, like, a knowledge of what model to use at what time can s- literally save me from not having access to these things to having infinite access, pretty much. And I, I wanted to pass that on from my own personal experience on, like, where I use the big models, 'cause I think the big models are amazing, and there's certain things that I would never do with a small model, and when I would lean on the smaller models, because sometimes a smaller model will actually perform better than a big model for certain tasks, and I'll, and I'll get to that as well.

Before we d- go there, what do I mean by big model, small model? So when I talk big model, I'm talking, Astra, Fable. Those are the biggest. I hardly use those. So that's not really the ones that I'm gonna be talking about on this, 'cause unless you have literally infinite budget spend for your tokens at work, which some companies do, which is [00:09:00] great, if you don't have infinite budget spend, I would almost never use them.

those you can keep for the really difficult debugging issues that you just can't solve. Like, you're, you've already ran into i- limitations of, of the other model, and you can't do it. So that, you know, you pull for the bigger model. Or if you're trying to, you know, process a bunch of data and it's very complicated and you have to get some sort of outcome out of it, like, yes, you would maybe reach for the top model to get you an idea of how to even attack that, that process, right?

So I'm leaving those mostly aside, the Fable and Astra level, really, really expensive models that aren't really designed for the everyday user. What I-- Big model that I'm talking about is Opus or, like, 5 point or 6.1 Sol, right? Like, who cares about the number. Like Matt said, we're not gonna be talking about too much about, like, the actual versions of these things, but a Sol-level model from Codex or ChatGPT and an Opus-level model from Anthropic.

Those are big models. They're not the most [00:10:00] expensive, but they are still pretty damn expensive. Uh, and they are really, really smart, especially Opus these days. And again, if you're listening to this three months down the line, the differences between them could have flip-flopped, and Sol could be the smartest now.

Who cares? So that's big models.

Matt: the idea behind this whole i-

Mikhail: Mm-hmm.

Matt: is ultimately you're not gonna use a scientific calculator for basic arithmetic, is, is kind of an analogy for this.

Mikhail: Yep

Matt: you can buy a very expensive, let's say $100 scientific calculator that will do a million things, and it will also do one plus one in there, or you could go to the dollar store, pay a dollar and get,

Mikhail: I,

Matt: a calculator that will do one plus one just fine

Mikhail: So the, the complicated part there, Matt, though, is that what if you already have access to that massive calculator, the $500 calculator, and it's just sitting on your desk, right? Would you go to the dollar store to buy the, $5 calculator? Probably not.

Matt: not. Of

Mikhail: Yeah, but so that's similar situation to here is like...

And this is why I see people leaning [00:11:00] on these massive models because they already have-- It's just a prompt. Like it's just you're putting text into a box and they're like, "Well, I'll just always prompt Opus," right? "I'll always prompt Opus." And like that can work if you're not doing anything serious. Like if you're not running agentic workflows all the time that are like, doing a bunch of research and spinning up sub-agents, you can get by by just prompting Opus, and I would say maybe that's even okay, like if you're not doing anything crazy.

But as soon as you start to get into the, "Hey, I need to run five different agents at the same time. I need them to run multiple sub-agents," you're gonna have a problem, just flat out. You're either gonna have to have multiple subscriptions or you're gonna be, you know, just stuck on not being able to do anything because you're reaching your limits, whatever, and this is where this advice can, can help you.

And the other thing that where, where this can help you is if you're building a workflow internally for a specific thing, and that's what I'm gonna talk about right now. So if you're building something like a tool internally that needs to use an LLM, like a smaller workflow, a lot of [00:12:00] times in that specific case, doing it with an Opus model or like building it with an Opus model is okay.

But actually using a smaller model might actually not only save you a lot of money and time, but might actually lead to better performance, and I've seen this a couple times For example, let's say that you have a workflow designed for redacting sensitive copy from a document before giving it to a client or before another model ingests it, let's say, right?

let's say you have a in-house model that's more privacy-oriented that costs a lot of money, and that's what's driving the redaction process. Having that model be smaller, and as long as you're defining the workflow quite heavily, like you're defining the inputs and the output criteria, like the verification criteria quite heavily, a smaller model typically is better at following step-by-step instructions.

That's just what I've found. And small models, like I haven't actually defined what those are. I'm talking the Lunas, [00:13:00] so Codex, the Codex ChatGPT side, Luna, Lunas, uh, and Haikus on the, on the Anthropic side. And as well looping in here like something like a DeepSeek or a GLM, those kind of smaller, cheaper models, right?

if you're defining exactly how to do something, that almost always should be leaning, leaning towards a smaller model. If you do that with a big model, it'll work usually, but what ends up happening is big models tend to think a lot longer, and they tend to improvise a lot more.

And sometimes that's amazing, and that's what you need. when you're doing a complex task, you want them to improvise, you want them to think longer, you want them to do more. But when you're doing something with a deterministic output, you want less of that. You want them to follow instructions, you want them to do those instructions efficiently, and the current small models are actually very good at doing that.

Luna, Haiku, they're both solid at being able-- at, at getting a good [00:14:00] design prompt and executing it pretty accurately. You'll still need some verification at the end, but as long as you have that verification, that's another part of this. we talk about how to verify, we talk about feedback loops in another episode that I'll link in this, in the show notes, AI Basics for Developers.

But if you have that set up, then a small model will do the task cheaper, definitely, a lot of times faster, and again, sometimes more efficiently and a- as in like it will actually perform better

Matt: Well, you're giving, and correct me if I'm wrong here, Mike, when you talk to some- to a more complex model or a more capable model, you're gonna introduce basically overthinking in

Mikhail: Yes.

Matt: It, it overthinks these tasks, it improvises these tasks, it goes in... You could even think of this as something very, very simple from a legal perspective.

Two people may come to an agreement, but if you were to give it to a lawyer, the lawyer's gonna get hung up on this sentence and that word and this and that. Sometimes you want that. [00:15:00] Sometimes you, you want and need that for legal protections. Meanwhile, other times it's just a roadblock. You were fighting over the word 'the' that was capitalized weirdly, or the sentence ended prematurely or something when the result was always gonna be the same.

Mikhail: mhmm.

Matt: So sometimes you want that extra thinking, and sometimes you don't, is effectively what you're saying. And then, of course, because you're employing a lawyer versus not employing a lawyer, you're gonna have to pay that lawyer a lot of money versus not employing a lawyer, you know, you're effectively paying, I guess, yourself if you're a part of this agreement and you're shaking hands with whomever you're having an agreement with. less or even no salary involved in that one case. And so that kind of goes hand-in-hand with this, where those more advanced models are gonna cost you, whatever, $10 an hour. the more advanced is 10, the least advanced is five or something. Those aren't real numbers. It's just to sort of package this in a way that maybe someone who's new to AI and AI workflows would understand it.

Mikhail: Mm-hmm. That's right. No, [00:16:00] that, I, I think that that's the right, the right correlation and the right kind of mindset that you have to have, is like if you can get away with a very structured step-by-step process and you're okay with it not being this over-engineered, you know, over-thought thing, input and output, then a smaller model is almost always the better route.

When you're building inside of an, in- internally in an app, right, when you're building a workflow internally in an app and you need, you know, an LLM to do something, and that's, that's becoming more and more common, it's almost always going to be a more specific like, you know, workflow that you have tested and tested and tested with a smaller model.

That's how most of these apps work, not just for cost savings purposes, but also for the fact that it's more repeatable, it's more deterministic nowadays, and it's a lot of times faster, right? And you want those kinds of experiences to be as fast as possible, whereas again, great, you can put Astra in there if you want, like to, to, to redact your documents or to do a check on, comparing two different, you know, [00:17:00] files or comparing two different pictures.

You can do that with Astra, obviously, but you, you might not like the output, and you definitely won't like the cost

Matt: Overthinking is

Mikhail: yeah

Matt: is not always what you want out of a human, so it, it naturally is something that you may not want out of an LLM. However, somebody... I- if you want someone to go through something with a fine-tooth comb, then of course you want the overthinking, and I... And that's largely what is being employed here.

I mean, from personal experience, I've gone back to old conversations in my ChatGPT, and it'll bring up 5.6. So lately I've been using 6, uh, with, uh, me- it set to medium if I'm in

Mikhail: mhmm,

Matt: mode. They

Mikhail: mhmm

Matt: fix this whole chat mode and all this stuff. It's starting to really get to me 'cause I'm, I'm on medium over here, I'm over here.

Like, in, in different apps I'm, I'm in work mode. No, I'm actually in chat. Oh, chat can do it, but sometimes work mode... Anyway, off topic, but just come on, boys.

Mikhail: Mm-hmm.

Matt: We gotta work on the UX a little bit. But I'll go [00:18:00] to some old chats, and I'll be on 5.6. I think that might be 6- 5.6 Sol if

Mikhail: Mm-hmm

Matt: correctly, and I'll just leave it, and I'll continue my conversation.

I just need some follow-up. And I'm like, man, this is a, a much direct, less overthought answer

Mikhail: mhmm

Matt: uh, what I would've got out of my 6 Astra set to medium

Mikhail: Yeah. Yeah, exactly. And, and sometimes you need that overthought answer, and sometimes you don't. And the next thing I wanna talk about is like when is that, stronger reasoning or the more thinking and the higher end models, when is that worth it? So what are the examples there, right? So if you're looking at vague requirements, like you don't know exactly how to build something, you're looking at something that needs to be kind of engineered a little bit more differently, you're looking at something that needs to be a bit more secure.

It's, it's a bigger task, right? Like, it's not, "Hey, fix this button." If the task isn't fix this button. Fix this button, that's a perfect use case for a Luna model, like a small [00:19:00] model, right? Like, that's a great use case. If you have a specific task of like-- or you have even like a list of like, "Hey, this is all the things that are wrong with the site.

You know, here's like the copy that needs to be fixed, here's like, buttons, button colors, here's some design stuff." Those lists of tasks are great things to pass to a small model, right? Like, you can, you can get a big model to pass it to a small model if you want it to like verify everything for you, or you could just pass it to a small model one by one and it'll, it'll do it.

Like, it'll do it, no problem. It can, it can do all those things because they're defined, well-defined small tasks that don't take, a genius to figure out how to implement these things. Now, if it's something that's not that. Let's say you're trying to decide between using Postgres or, SQL and you have like, a certain amount of metrics that you're already-- you've already been analyzing or you need analyzed and need to decide based on those metrics on like the trade-offs between these, this kind of architectural decision, that to me is always going to be an Opus level question.

[00:20:00] Always. It's always going to be a big, a big model question, right? As soon as it's something that I'm not fully aware of I, I rely a lot on these bigger models to, first of all, figure out some, which one to use based on the, based on the inputs that I give it, and second of all, to explain it to me and then verify it, right?

I'll get them to do the research themselves. I'll get them to choose the right path forward, and then I'll get them to explain that choice to me, and then I'll go through and make sure that it makes sense, right? Like at, at the, at the end of the day. So that is almost always going to be a big model task because I've done this with small models, and the problem there is that they just don't work long enough.

They just don't go deep enough. They just... They go very surface level. They rely on their knowledge too much. They're, they're not usually getting the same kind of output, and they're not explaining it the same way that these larger models explain it to me, right? Now, sometimes they'll have-- Like I even did-- Before, before this podcast, to be clear, I, [00:21:00] I actually did some, uh, comparisons, side-by-side comparisons just to get, just to refresh myself on some of this stuff, and sometimes the smaller models will come up with the same answer depending on the question that, that I asked it.

So that like, you know, that throws a wrench into things, but sometimes they don't. Like out of the five times, out of the five things I did, three out of five it, it got the same answer as the big, as the big model. But those two it didn't, and the, the big model had a better answer and a better understanding of those other two that I was doing, that I was asking.

Matt: I think you said something interesting in there which says, "I needed the model to explain something to

Mikhail: Yeah

Matt: And I think that there, at least for me, there's a key distinction there. So I will use a, a sort of higher end and even a higher mode. I'll go from my low to my medium, maybe even my

Mikhail: Mm-hmm.

Matt: right, in ChatGPT. I will do that when I need something explained to me, but I can go back to s- to another older model or a cheaper model or turn down that dial to [00:22:00] instant or something when I'm the one doing the thinking

Mikhail: Yes.

Matt: one doing more of the task.

Mikhail: Yep

Matt: pr- a primo example is I've gone into a web page recently, and I already had the design in my head. I already knew what design I wanted to put together, so I put it together first draft very, very roughly, and then I took all the technical stuff because the page was fully dynamic and made sure all the connections were working and that the data was being pulled in dynamically. So that's all well and great. Now that that worked, now I go and I say, "Hey, this is generally what I want. Clearly this is a first draft. Let's touch up this design." And it came up with, in an, in instant mode, it came up with maybe 10 to 15 pointers. Very, quite a large page with, like, a lot of typography and stuff 'cause we're trying to make it look like an analog surface, so there's a lot of that going on.

This isn't, let's toss Roboto on there and just [00:23:00] leave it. This is, like, very, this needs serif, this doesn't, this needs a shadow, this doesn't. Kind of emulating an analog environment. And I went through there, and because I already did the thinking and I'm just bouncing ideas off of it, I go in and I go, "Oh, that's a good idea. Stupid, stupid, stupid. That's a good idea. That's dumb. I'll try that. Don't know about that." And I'm just using it as a quick reference, but if I were to ask it a question about something that I do not understand or have not done, and I say, "Hey, I've never coded an add-on to WooCommerce before. I need you to take a look at where I should learn to do this and how I would do enter in name of add-on here And a way it would go, and it better give me a good answer.

It better not just say, "Go to the d- documentation," and then walk away. It better say, "Go to this documentation, go to this YouTube channel. This is why this person teaches this way, this person teaches that..." Because then I'm gonna also go [00:24:00] down that list, and I'm gonna have my own ideas on, okay, that person teaches in a way I don't care about.

I actually don't wanna watch YouTube right now. I wanna read. I'll do these things. And it's giving me enough of, of a context there where I'm thinking, I don't have-- I can't literally think about how to do the add-on 'cause I've never done it. I can't think in that exact context. I'm offloading some of the thinking to the AI in that particular context, and then I'm... the contrast of having it just do the task versus having it do the task and I have no idea what's going on. I need it to also explain it to me

Mikhail: Yeah, I, I think explaining it is totally valid. The thing that I'll push back on a little bit is going deeper into understanding the explanation. So I've s- I've really stepped back from that lately. I'm starting to trust these models probably 10 times more than I was six months ago because they've proven me wrong more than I've proven them wrong lately.

[00:25:00] That's where my trust level has started to shift. And to think that...

Matt: Like, what do you mean? In

Mikhail: Yeah, from a technical perspective, like from a choice, like an architectural choice perspective, from an implementation of code perspective, they've done a better job than I would have done more often than I would have done a better job than they.

And that's shifted pretty rapidly in the last, again, six months

Matt: This is gonna sound weird, but how defined were your goals in those, uh, instances?

Mikhail: Not, not super defined or less, less and less defined as well

Matt: mean in your prompt, mean in your task. So for example, that thing I was doing where I was trying to make it look like an analog thing, that was d- that... I came up with that idea. I had looked up other examples. I figured out what I wanted to do. I looked up real examples. Again, we're emulating something in the real world. I looked up those examples. I looked up how they make it look, 'cause it's kind of like an elegant, uh, wall. It's, it's a granite wall with a bunch of names and a bunch of, like, kind of content boxes, [00:26:00] but in the real world, and I needed to emulate that on a website. And so what I had done there was I said, "Okay, like, what makes these walls look elegant?

Oh, it's this color difference. It's this, it's the background looks this way. It's the contrast in this way. It's this and that, this and that." So my goal is very clearly defined. Very, very, very clearly defined. So that's my question. Because if my goal was not clearly defined to me and I just went, "You know what?

I need to make this thing look like a granite wall with some writing on it," could hand that to the bot and I'm sure it would come up with something half decent. in my instance I did not... or because I did have such a defined idea, I was able to go in there and say, "Out of your 15 ideas, I like five or I like seven.

The rest of them,

Mikhail: It,

Matt: it out of here

Mikhail: it, yes, I, I, I see what you're saying. You're right. When you have a very, very clear expectation of an end result, it changes the way you prompt completely, and it changes how you use these models. Agreed. What I've--

Matt: changes the trust because

Mikhail: [00:27:00] absolutely

Matt: so many things to a person even

Mikhail: Yes

Matt: manually, you would have so many things. That's that... I think it's probably where that

Mikhail: Yeah

Matt: comes, "If you want it done right, you gotta do it yourself,"

Mikhail: Yes. Yes, exactly. W- what I've noticed more often now is that the le- the less defined the goal, you're right, like, you're saying, the less defined the goal, the more trust I'm giving it, and the more-- the better output I'm getting out of it as well, right? And I talked-- So, like, giving it more trust has gotten better results on my end in the past, again, maybe in the past couple months even is, is really where this change has happened.

Really, honestly , the latest Opus model, what, what's come out, what's out right now, Opus 5.5, has completely changed the game, like just foundationally. It's significantly better at just doing the engineering work and coming up with the right result at the end of the [00:28:00] day. Now, do I still correct it when I go to verify?

Absolutely. But the point where I'm going in to verify it and checking the output is already better than what I could have done if had I given it the constraints that I used to give. That's where the, the change has happened

Matt: So you're saying that your constraints would've held it back

Mikhail: Yes, that's correct. That's exactly it. Yeah. My constraints, my lack of knowledge in the fields that it has way more knowledge in hold it back.

So giving it less constraints and being more informal with it and relying on the larger model, this is, coming back to the episode, when it's a large model, it completely changes the way I prompt it, completely.

Matt: I'd

Mikhail: On a small model, on a small model, on a dumber model, I give it as much detail, or I ask the model to give it as much detail as I possibly can 'cause again, you need those constraints for a small model to get the right output.

But for a large model, it's less and less and less and less [00:29:00] constraints. The more in- the more indirect almost, like the more you can allow it to improvise, and it'll improvise incorrectly. Let me be clear. It'll improvise incorrectly, but sometimes those incorrect improvisations can actually lead to a more interesting, a better result at the end of the day 'cause it can be like, "Oh, you did this really weird thing that I would have never thought of to do.

Maybe we could do that here, but not here." You know what I mean? you get these outputs out of it that aren't one-to-one what the world is always expecting. It's almost like a, a new, a new version of something you hadn't even thought of before. That-- And, and you're o- it's okay to get those bad outputs because you'll just toss them aside and ask it to do it again.

So accepting the fact that it's going to give bad outputs as long as you're verifying yourself allows you to get a better result at the end of the day as well. So, like, just, you know, abandoning this idea just because it gives you a bad result in the first prompt [00:30:00] is the wrong method here. It's taking what it gives you back and being like, "Oh, sh- this is cool, this is cool, this is bad, this is bad.

Hey, what about this other site that I looked at before? That has some good elements too. Let's pass that on." Very, like, you know, "Here's a copy, here's a, here's a URL, or here's a screenshot of that site. Like, maybe you can implement these elements with these elements." Like, just having that more casual conversation and treating it more as an expert in the field at whatever you're trying to do is, is the new meta.

And I might get flamed for this, I wanna be clear, and I'm okay with that. Come at me, @htmleverything on X. I'm totally okay with that. Rip me apart on YouTube. This is the result-- I'm seeing better results using this lately, and I think as the models get smarter, the hubris of us being smarter than them is going to pull us down.

And the faster you accept that at a lot of things it's going to be better, and, and even if it's not better, it might come up with something different than you would've thought, and it's worthwhile to go down that path just to [00:31:00] see that difference

And that's where the big models shine, obviously. even the Astros and the Fables, those, those things can do some crazy stuff that you would never have done in a million years. And sometimes it's really dumb, like extraordinarily dumb, but you're like, "Oh, why did it do this dumb thing?" And then you can query it too.

you can further question like this, its, its dumb decisions to find its reasoning, and sometimes that'll either change your mind or you'll learn something new in, in that way too. I'm learning way more about architecture and engineering than I ever was going down this route because I'm starting to see that these things are better than it, than, better at it than me, for the most part

Matt: Uh, 'cause I, okay, I have a question there though, 'cause I'm, so I'm, I guess I'm confused a little bit. I understand what you're saying in terms of you use a, a larger model that has more reasoning power, yada, yada, and you can give it a more abstract idea and have it come to a pretty good conclusion. But

Mikhail: Correct

Matt: mentioned there that it might do really incredibly stupid things, and you

Mikhail: Yep.

Matt: it out of there[00:32:00]

Mikhail: Mm-hmm

Matt: So it's hallucinating on the small stuff because it's doing so much

Mikhail: I don't know if hallucinating is the right word. It's misinterpreting certain things that you're not, that you're not defining. And again, that's maybe a negative of doing smaller, more generic, conversations with it. But more often than not lately, the misinterpretations are leading to better results.

So the fact that I'm not giving it direct constraints, it's able to do things that I would have never been able to query it to do. it's able to, you know, come at, come at it from a different perspective. It, it knows that, hey, this isn't gonna be viewed by a million people, so we can make this really, really small module really efficient and really simple, rather than over-engineering it and putting it on Kubernetes and all that crap, right?

where as if I was doing the engineering of it, I might have been like, "Hey, put this on distributed systems in a Vercel" like, whatever, and it would, it would have done it, obviously, but [00:33:00] that would have been the wrong choice

Matt: I, I get what you're saying in terms of they're not necessarily hallucinations. They seem like weird choices.

Mikhail: Yeah

Matt: My one concern is they seem like weird choices only because you're an informed user, And this kind of goes outside of the parameters of this episode, but I think it's important to bring up.

One of my concerns right now is that out there who's gonna be completely uninformed in any field, let's just say website creation, website development, they're gonna prompt an advanced website, let's just say even web app, into creation, they're not gonna notice these weird decisions as weird because they're completely uninformed.

This has always been concern of many people, and that's

Mikhail: Exactly. Yep

Matt: "Oh, you should be informed about how to code in order to do it." But then there's the other people that say, "Well, why would I learn to code only to then not code and have the thing code?" I get it, but as these things become more capable and they're able to do more things, [00:34:00] they're able to also do more damage. And so I'm a little concerned in that you're noticing that it's weird. I'm not super concerned about that. You're going in there and you're asking it questions and you're discovering and you're learning, and that's fine and that's cool and everything. But the thing that I'm concerned about primarily is that if it's consistently doing weird things to you, and there's gonna be people out there that are not capable of identifying that it's weird due to their skillset Is that not concerning?

Mikhail: So what it's doing less and less of is introducing open-ended admin endpoints and open databases and all the crazy security stuff that it was doing en masse a year ago

Matt: security concerns that it was doing before,

Mikhail: Yeah, when it's not do- it, it's no longer doing those on a very consistent basis. Like, it's [00:35:00] being much better from a generic prompt to releasing, to releasing something, it is being much better.

I wouldn't say it's perfect. I have caught things here and there. So at this point in time, while we're recording this episode, I think 100% what you're saying is correct. because I'm an informed user, it's a lot easier for me to catch these things, and I was able to catch some of these. And a lot of times the weirdness that I'm talking about is just the end result not being what I need, right?

if I needed to collect a database of companies, for example, that have the specific, the, the sp- these specific properties, and I ask it to do something like that, and then I, it-- in my head, I-- 'cause I didn't, I didn't write a really extensive prompt. I just asked it, "Hey, get the best companies for this specific thing."

I didn't tell it, these are the metrics that you need to decide, what these companies are, right? 'Cause I didn't give it, those metrics. It will misrepresent some of those metrics. It'll, it'll assume things that I didn't intention-intentionally think of that it [00:36:00] would misunderstand, and it would, like, be-- it'll rate the companies by, like, I don't know, its debt score or some random thing like that, and I'll be like, "Well, I would've never,

Matt: type of

Mikhail: I've n- I would've never thought to do that."

I was like, "Why, why would you do that?" Like, it's just making that, that assumption is something that's weird to me, and then I was like, it... You know, again, lately, those assumptions that it's making that I would've never thought have actually led to better results for me. But sometimes I have to be like, "Okay, well, that doesn't make any sense."

Like, just here, here's a little bit more information That's what I'm trying to say with, the weirdness, right? Like, it's just making the assumptions, not like from a security perspective or for like even from a user, like UX perspective, like a broken UX perspective, I should say. It's just like the output is different.

So if you're a generic user that doesn't understand development but understands the output that it, that they want, you could still probably get something pretty decent now, just by verifying the output and being like, "Oh, this isn't exactly what I said." Like, you know.[00:37:00]

Just being okay. Again, I, I've said this many times in many episodes, it's going to fail. It's going to screw up because it, it, the human interpretation, like just talking to an engineer one-to-one, they're gonna understand things differently than you. And these machines do the same thing, they mis-misunderstand you on many levels.

But from now, allowing them to think through their own misunderstandings or generate their own assumptions is starting to result in better results versus assuming that you know all the assumptions yourself from the get-go because you're this, you know, 10X engineer that's a genius and you know how to design every possible system, so you're gonna give it a spec of like 3,000 words for the prompt.

Yeah, it'll come out-- It'll probably do it decently well, but it also has the chance of like overextending its context and, putting it into a box and not letting it do its thing a lot. And like these things have started to become extremely good at engineering, like extremely good.

So I'm starting to rely on them more. I'm [00:38:00] starting to trust them more, and the trust is... It's just making it easier to work with them, obviously, 'cause I'm not checking every line of code anymore. I'm checking the output and I'm checking the basic stuff, and I'm throwing it back at them to check the, the surrounding security areas if there's anything related to security that I need to check.

Sometimes it's just a result that I need, like a CSV, then I don't care

Matt: describing not over, what would you call that? Uh, micromanaging. You're, you're,

Mikhail: Yeah

Matt: It's almost like you're treating the bot more like a, employee, like especially one of

Mikhail: Like a really smart employee, yeah.

Matt: You're,

Mikhail: Like a really smart employee

Matt: you do not wanna over... You don't wanna micromanage.

I keep saying over

Mikhail: Yeah

Matt: for a reason. That's not right. You do not want to micromanage an employee that is capable.

Mikhail: That's right

Matt: And so that's kind of what you're doing here. 'Cause if you give them too many parameters, then it's gonna become a, a web of overthinking

Mikhail: Mm-hmm.

Matt: tr- an over, I don't know, submission, I suppose you could say, to the specification, detriment of the [00:39:00] overall output

Mikhail: Mm-hmm. That's exactly it. So that's, again, that's big models, right? Like, that's when you really want to lean on big models, and that's how you want to talk to big models, is less structured, more ambiguous, more indirect. just asking it like you would an engineer exactly what you're saying, a good engineer.

The other reasons to lean on the bigger models, I have a few here. Longer workflows. So something that you expect that needs to run potentially for hours, like a long research project with some sort, sort of outcome at the end. Almost every time I'm going to at least get the larger model to be the orchestrator of that, right?

So it's going to be the one that verifies the work. It's going to be the one that assigns the work to the sub-agents. The sub-agents themselves, they can be small because again, the or- the larger model understands this concept. If you, if you tell it, and I mean just blatantly tell it in your prompt, "Hey, spin up some sub-agents of dumb models," you can say that.

It'll [00:40:00] understand what you're saying. You can also say small models. You can also say the direct model that you want it to talk to, Haiku, whatever. Spin up some sub-agents of s- of small models. It's going to know that it has to constrain them. It is gonna know that it has to write them a very detailed prompt and then verify their outputs.

That's built into the systems at this point. So for longer workflows, orchestrator always has to be a big model because the smaller models just lose context too quickly. They don't understand their, complex results. They, don't recover from failures as well. They try the same thing over and over and over again, and then they just fail over.

Whereas the lar- larger models can see the fail path and then try something drastically different from the fail path, then try something different. they'll recover from failures a lot faster and a lot cheaper. And it's- It's tough sometimes to know if, if a workflow is going to be long enough to, to warrant a big model.

But my rule of thumb usually is, is that like, hey, [00:41:00] if you were to research this yourself, how many paths do you need to go down? is it just like a Wikipedia search? Then it's a small model, obviously. But if you have no idea what you're talking about, again, going back to the ambiguous case, and you need, you know, 10 citations in this report back to you, yeah, that's gonna be a big model.

Like you're gonna need the strength of a big model to get you that output

Matt: How much guidance do you give these longer workflows? Because you know how if you're using something like a Codex, you can say send a prompt and... I mean, a classic one is you send a prompt, you realize you forgot a little thing, and so you can steer it a different direction. But I know that some of these workflows will go on for more than a couple minutes.

Many are only a couple minutes, but there's many that will go on for 10, 20 an hour, 10, 20 minutes, an hour, whatever, et cetera, et cetera, for length. How much are you, I suppose, steering these longer workflows? [00:42:00] actually, a better way to ask this question is The length of workflow, is it dictated by how much you would normally steer the thing?

So for example, you gave it a prompt and you expect this thing to have to be steered 10 times, or you think that there's many sort of inter- like certain points in there, that's when you would go, "Okay, I need a big model to do this to reduce the amount of steers that I'm doing"?

Mikhail: Yeah, exactly. Like if you're relying on a big model, you're gonna steer much less, if at all, right? And really the-- what dictates the results is the outcome criteria that you set. So what's the result? Is it a application that you're building at the end? Is it an HTML page with results? Is it a CSV, right?

And w-what does that CSV contain? Does it contain 1,000 companies with all of their information? Like, th-that's gonna dictate the length that it's going to run, right? whatever the output criteria is that you have for this task, if it's a significant enough output [00:43:00] criteria, if it's a full application that has to, authenticate and all that, yeah, you're gonna need a bigger model.

If it's a, a single line or a single paragraph of summary, probably not a big model. And it-- the steering side of it is, I do steer, but again, something that's happened less and less often now is the need to steer them as much. I'll only steer if I forget something, right? if I, message something and then, um, all of a sudden I'm like, "Oh, shit, I forgot to mention this and this and this," and then I'll, like, I'll throw that into the e-extra chat.

A lot of times I won't just be staring at a model's outputs as it's, doing its work. A lot of times I'll be doing other work in parallel, like whether it be another agent or just, you know, doing manual work, like regular, you know, code review or output review or whatever, like whatever I'm doing that day.

Um, and then w- and then coming back to it and seeing the results [00:44:00] and how it got there. And I won't, like, scroll up and see how it got there. If I need to know that, I'll ask it a follow-up question and be like, "Okay, how did you get this result?" Like, to verify sometimes, 'cause sometimes, you know, you just like it, it just seems wrong.

Like you're saying that, th-this company is worth $10 billion. How do you know that? Like, where did you get that number from? It just seems weird. And you'll ask it that directly, and it'll give you the result, rather than like looking, scrolling up in through the thinking process and being like, "Oh, this is the website," and you go to the web...

You know, that's what I used to do, to be clear.

Matt: Well, I guess I'm thinking more from the transitionary person, the person that may be using, a lesser model right now, and they're thinking, "Okay, should I reach for something that's larger that's gonna eat more of my usage up?" Especially those that are budget conscious. If, basically, if they're prompting in a certain way or prompting for a certain type of project or a certain type of workflow, and they have to steer a bunch, that's a...

It sounds like that is a good to say, "Hey, let's

Mikhail: Mm-hmm[00:45:00]

Matt: one model up," or whatever it is, on your own context. But let's reach for that larger model in order so that I, it

Mikhail: Mm-hmm

Matt: start making assumptions for me, and I can always ask follow-up questions, as you just said. But I don't have to constantly sit there and have it steer.

I can more or less delegate said workflow to it, leave, and just wait for my output in 10 or 20 minutes

Mikhail: That's exactly it. Like, the transitionary phase is very direct, I think, in the sense of as y- when you're, when you're first starting out with the smaller models or even large models, you're probably writing too much, right? Like, the small models, you're probably writing a good am- like the, the right amount because they need to have those constraints, they need to have the scopes, they need to have the more direction, the more flows.

But as you go up the models, it's, it's... And it's not easy to do. I don't wanna s- I'm not saying that this is like, you know, you're an idiot or something like that for doing this. No, this is like building the trust in these models takes [00:46:00] time, and it's not something that you can just do all of a sudden and just like 100% trust the model.

You have to slowly drop this verification, drop this scope, and see if it works out. Like, you know what I mean? And then maybe add it back in, see if it doesn't work out. Like, the more you use it and the more you're querying it and, like, the, almost the lazier you get at the end of the cycle because you're starting to trust it more, the more you'll realize what model will benefit in which task.

But initially, I think the right constraint is, yes, you're right. Like, if the task requires a ton of steering and knowledge that you don't have and you know it's going to be a slog, that's a good, rule of thumb to like start going up a model and giving it the trust that, hey, let's, let's get it to at least start this for me, right?

Like, that's the other thing is like you don't have to one-shot everything. One-shotting everything is not the goal here. It's like, hey, maybe you just get the first part started. Once you have a more clear, defined scope that the bigger model gives you, then [00:47:00] you can maybe even go down it. Like if you're price conscious, that's a good way to go down a model.

Have the big model start it, give you some structure and some, you know, some constraints around it, and then you pass those constraints to the smaller model because now you have that understanding.

Matt: The one-shotting I think is almost like a curse in a way,

Mikhail: Yeah

Matt: the issue is because we're automating things, we're using a machine to do a lot of these tasks, everyone is constantly thinking of how many things they can automate, how efficient they can make it, and everyone is almost officially, unofficially working toward the one-shot silently. When in reality, at least at this stage of the game, we're still doing work. 'Cause I've asked people that we work with, colleagues or just friends who are in different industries, they'll say, "Oh, I use ChatGPT for this. I use, I use this for this. I use Claude for this. I Grok for this." And I always say, "Well, are you still busy? Do you just have it doing everything?" And they're always, they're almost [00:48:00] always their answer is, "Yeah, I'm still super busy."

Mikhail: Crazy busy

Matt: still in phase of work is still being done. We're not at the point where I woke up, I typed in a prompt and told it to do all my work for the day, and then I went to bed. I went back to bed or I went to the park or we're

Mikhail: Yeah.

Matt: stage

Mikhail: No, it's, it's not even close, in my opinion. we still have to make sure that the work is good. We still have to verify it. We still have to check outputs. We still have to go back and forth. if anything, we're doing more work. There is this, balance of, hey, some of the stuff that I've been doing with AI could probably be faster done by just me doing it manually.

That is 100% true. I am acknowledging that, and I'm still going down the AI path to perfect that workflow stubbornly, right? Most of it, I, I would say most of it is, is probably faster with AI, to be clear. It's not like a, you know... It's, it's not [00:49:00] ev-every task. But maybe one-fourth, one-fifth of the tasks, yeah, I could probably do faster without AI.

But I still choose the, choose the path of doing it with AI because I think that it's worthwhile to invest in, in those skills and learning how to do it and making sure you can verify outputs and stuff like that. It's a personal choice. You know, I'm not saying you should do that. I'm not saying anyone should do that.

It's just for where I'm at in my career, I think that's will work out better for me than just going and doing these, simpler tasks myself

Matt: It's an interesting episode topic, honestly, and possibly Web News, because I do not do that. In

Mikhail: mhmm

Matt: I, I use AI 100%. it every day 100%. However, every day I'm working, I should say. Sometimes on the weekend I just don't, I don't need to talk to that bot. But, but the thing is, I also treat it like a coworker. "Hey, you do this while I do this," [00:50:00] largely is my workflow. And if my way I think is better, or if I just want to do it, or if my code or my manual installation of something is gonna be faster, then I'm gonna do it. So it's a, it'd be an interesting little debate, compare, contrast topic, I think

Mikhail: Yeah, definitely. I, I thi-- yeah. The, and there's, again, there's definitely positives and negatives to both. I wanna make that clear. That's why I'm not saying like you should just go dive deep into my method. there's some negatives to my method for sure, 'cause like you're, you're almost like losing your skill.

I mean, well, we'll have this debate in another episode, but like there is a good debate to be had there because it's not a clear one-to-one, answer. But yeah, that's... I don't have too, too much else to add here. one cost thing that I do wanna say before we wrap this episode up is it's not-- don't just compare like the cost per [00:51:00] task.

compare the total cost. Because cost per task might be cheaper with the lower models in s- in a lot of cases, but if it takes you longer to write that task, if it takes you longer to verify it and go back and forth with it, if you need to string together five or six of the same prompts that could've been solved in one more expensive prompt, that's gonna give you a lower total cost.

And again, factoring in your time there as well, look at it from that perspective to make the decision. And this might be difficult to do, but one great thing is that you can actually ask the models themselves questions on their outputs and how much it costs, and you can ask it to build you even a little dashboard for keeping track of cost for a certain project.

That's what a lot of people do. That's what I've done, so that I can analyze what I, what models I'm using more often than not, what models lead to more, accepted [00:52:00] results, less accepted results, the time between queries, et cetera, et cetera. It, it contain, it holds a lot of data that's at your fingertips.

You just have to ask, right? Like there's no tool that I'm suggesting. I'm ask- I'm telling you to literally ask your Codex or ask your Claude Code about the, the metrics to define if something is, you know, costing you more or less In whatever output you want. Like, you can have it, you can have it create a dashboard, an HTML page, a PDF, just to see it, whatever.

Matt: bit of this though too that it couldn't, it couldn't measure, I would

Mikhail: Yes

Matt: out there that will say, "I got and such a bot to automate such and such part of my code because I only like coding this up, but this other part is a necessary evil. And so I'm gonna do the part I enjoy, and I'll delegate out this part that I do not like to the bot." an analog value. [00:53:00] The person may get stressed out by coding in that other language or that other method or connecting the APIs or whatever piece that it is they got stuck with, they got stuck on. And so that's benefit to their life, as an example. there's also other analog things that could be potentially measured in CRMs and things, although it would be difficult to distill the data down. But it would be something such as, before when I used to go to a meeting, I would come in not all that informed, but now my bot is giving me a report on... that's related to the meeting topic a day before, and I'm coming in more informed, and now the meeting is going smoother and the meeting's going better.

You might have some metrics there such as maybe the meeting's ending shorter, m- is going, going not as long. Maybe there's less tasks at the end of the meeting or things like that, but there is also those things to consider. there's also things like straight up anxieties over things. If you notice the output on things that you hate, if you [00:54:00] really hate, I don't know, writing, privacy policies for s- for some reason, if you really hate writing privacy policies and you get a better result by turning on the better model and, you know, turning it to high or what have you, then that's great.

Y- you go and do your content writing, it'll write your privacy policy, you know, and away you go. That's a really weird example, but the idea, I think is sound, is that there's gonna be some people that are just absolutely regretting and procrastinating. that's actually another thing is if you can get the bot to do the things you would normally pro- procrastinate because those are the things you prefer not to do, and then you're o- you're doing most of the stuff that you actually like to do, that's an enhanced, work state for you, and then you might end up producing more work.

And, and many of these things, again, are very difficult to measure

Mikhail: There's gonna be a lot of those things too. for example, your own review time and output time, output verification time, you can't really track that. Um, the, the time it takes you [00:55:00] to write the prompts and stuff like that, and th- th- it's not perfect. It's not perfect. But it does contain a lot of data is all I'm saying.

I'm not gonna lay out all the data that it contains 'cause I don't even know, but you're able to access that data by asking it. So if you want to evaluate, small models versus large models, you can evaluate it at least somewhat accurately using the data that it stores, knowing that, yes, it's not, definitely not perfect.

Matt: No, cer-

Mikhail: Yeah. And it's worth evaluating. It's worth at least checking what it has. I found it really interesting to like just ask it, "Hey, you know, how many prompts did I write in the last six months?" You know, like it, it can, it can check that kind of data. what's the length of the prompts that, prompts that resulted in something?

I don't know, like the a- approved results. Like, I don't know. There's, there, there's correlations you can have. There's, just trends that you can monitor your- in yourself. Again, like my trend, my trend to monitor [00:56:00] would be like me writing less structured prompts. I could probably get some data around that if I wanted to

Matt: I mean, this is a personal thing, but I want prompts that... I like to do things step by step, and one thing I absolutely hate is when it's like, "Okay, we have three steps left, Matt," and then it'll give me three steps, the steps are quite detailed. And then I need to ask a bit of clarification, or I need to change something in the first of

Mikhail: Hmm. Yeah, yeah. I hate that. Yeah

Matt: then I go, "Okay, now I need this. Now I need you to clarify, you know, step one," or, "I need you to change step one." So now it's like, okay, maybe step two and three didn't change, but now I gotta scroll up the conversation, and it's like, "Dude, you're giving me too much information.

Mikhail: Yeah

Matt: And so I end up re-prompting it. I, and I always, I always text it this.

I'm always, "Okay, now the next step." I, I'll say, "Okay, I did this. Now the next step. Okay, I did this. Now the next step." And it just never gets it through its head, stop giving me these massively detailed reports almost of what I should be doing, instruction sets of what I should be doing [00:57:00] one step at a time, 'cause there's always gonna be little quirks.

Or

Mikhail: I

Matt: I kinda want that to be left aligned,"

Mikhail: I,

Matt: doing a lot of UI stuff, you know?

Mikhail: I th-- I, I, I think if you put that in your agents.md file or in your, like, instructions, your ChatGPT instructions or whatever, it might work. Because what I'm assuming it's doing is because you're just telling it, you're asking it what's the next step, it's like, "Oh, do you like this process? This is...

Matt: Ah.

Mikhail: this because you like it.

You keep doing-- you keep do- asking the same things. You're not telling me anything." You could probably just tell it and to add it to memory too. Be like, "Hey, stop doing this. Just stop, stop putting it..."

Matt: of usage 'cause I'm

Mikhail: Yeah, absolutely.

Matt: those steps over and over

Mikhail: Every time, yeah

Matt: don't wanna keep scrolling. I could scroll up. Yes, the

Mikhail: Yeah

Matt: been given to me. If I hit my limit, I could just scroll up and see it, 100%. But in terms of work organization, I prefer to go, "Okay, do this, do this, do this."

Mikhail: Mm-hmm.

Matt: a very detailed person, so I go, and I look, and then I do it, and then I check, and sometimes I check [00:58:00] again,

Mikhail: Yeah.

Matt: I go to the next step

Mikhail: Yeah. It should tell you the next step after it does the, the work it's doing for the f- the, the step that it's on. And then it, then you can prompt it to do the next step if you want or something like it should... The, the, yeah, definitely something you can correct, I think

Matt: I had an example of I was working with the Code Snippets plugin on WordPress, and code, the Code Snippets plugin has a, a safe mode that you can launch into, and it's been a long time since I've had to use it. but from memory, it allows you to boot up without the snippets running.

Mikhail: Mm-hmm.

Matt: I think all the snippets running or some of the snippets running order to allow you to recover from a crash, and then you can go in there and sort of, toggle things off and on, toggle on and off your custom code, which is great. then I was working with it and it, w- we were talking about this large snippet that we had, and then it said, "Well, th- this could potentially, this could potentially cause a crash." It didn't say that directly, but it was kind of talking about how maybe we should use a staging environment and stuff like that, and I just had to do this kind of [00:59:00] quick change and I thought, "Well, hang on a second.

If it's talking about this, that means there's a risk involved here." So then, classic, that was step one of, like, three. So then it's, okay, how do you get into the safe mode? It's been, months. I don't remember the URL. I don't remember the methodology to get into the safe mode. It's like, oh, the safe mode is this, this, this, this, this, this, this, this. Okay.

Mikhail: Yep.

Matt: Okay. Sure. Next step please. Like, I just... You know what I mean? And it's

Mikhail: Yep

Matt: for a problem. It's burning CPU, I mean, tokens or usage in my case with my ChatGPT plan. It's

Mikhail: mhmm

Matt: for no reason. for really no reason. I just don't need it to be that detailed, just let's do step by step.

So I think I, I will try that. I will...

Mikhail: Okay.

Matt: I'll install a skill or something that's called, I'll call it slow the hell down. Stop. Like, hold, hold on there, Sparky. Let's,

Mikhail: mhmm

Matt: uh, I like to be detailed. Let's go one step at a time.

Mikhail: Yep.

Matt: One more, one more prompt like this or one more [01:00:00] output like this and I'm going to Copilot.

Mikhail: That's the thread you should send it. Th- then, then it'll be in line. So I can't, can't let you do that. Can't let you do that, Dave.

Matt: Okay, I was gonna say, I was gonna

Mikhail: yeah.

Matt: Dave, aren't you?

Mikhail: Well, yeah, that's it. I think that's it for this episode. I have a little bit more in the show notes on htmlallthethings.com, but, I think we're good to roll up the old conclusion

Matt: Yeah, there's a whole bunch of links I should, note as

Mikhail: mhmm

Matt: that will be in the show notes as well if you want to, take a look. There's articles, and little pieces in there such as the Claude Models Explained, Choosing the Right Model. Both of those are from Anthropic, or about Anthropic. there's some DeepSeek information in there and, and things like that, and there's also a related, HATT episode, AI Basics for Developers.

You can go and check all that out. That'll all be linked in those show notes if you want to just kind of a quick reference go in there and then you can find your way around. But if you want to support episodes like this, remember we are on Patreon. That is on... That is via, excuse me, patreon.com/htmlallthethings.

And many thanks to our $3 tier patrons, Tim from the Web Hacker on [01:01:00] thewebhacker.com, G- Jason from Geek Life Radio via geekliferadio.com, Garrett Seigle, Level Up Financial Planning via www.levelupfinancialplanning.com, Magnus from YesWeb via yesweb.se, Syntaxify from the HTML All the Things Discord server, and Stacy Mosler from the website swingworthydesigns.com. And remember that we have a contributing author, and that is Michael LaRocca. He's the author of Self-Taught: The X Generation blog at selftaughttxg.com. And remember that we also have a Scrimba link. You can get up to 20% off their Scrimba Pro plan. That link will be in the RSS description and in the show notes with full details on how it works in those show notes on htmlallthethings.com. Feel free to leave a comment or review on the platform you're listening to this on, and we are signing off