AI Basics For Developers

[00:00:00]

Matt: AI coding tools are getting faster, better, and just coming out every single day. They just keep coming out. Mike, you just mentioned there's a new model that just dropped as we're recording this. Crazy. But cut through all that noise if you're a developer just getting started, the hard part is not figuring out which model is the smartest or specifically which one you should use or all that nonsense.

The hard part is learning how to actually work with these tools without giving up control of your code base. So in this episode, we're breaking down the tools, the terminology, and the step-by-step workflow that we'd use to go from basic AI assistance to letting agents plan, build, review, and verify real development work.

Ooh, spicy. 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 learn how to code, you wanna take some [00:01:00] courses to do that, you can do so on Scrimba.

They got some great courses on there, front end and back end support. They even have a fancy media player code editor where you can actually pause the lesson and play with the code that the instructor was writing right on the screen. And they have a Scrimba Pro plan that you can pay for, and we have 20% off if you use our link.

That link will be in the RSS description as well as in the show notes with details on how the link works in the show notes on htmlallthethings.com. So Mike, I wrote the first... We have kind of a trio of these AI basics episodes, and I'll include links to the other two inside of the show notes as well.

But we have kind of just AI basics, which is sort of like, hey, if you're completely new to AI and you don't wanna frame it or silo it to, like, developers or small businesses, then that's your episode. And then we have AI basics for small businesses. There might be slight, slight, uh, differences in the title, but basically AI, AI basics for small businesses, which is, you know, sort of more toward my side [00:02:00] of the business, which is I deal with a lot of small businesses, and so I see a lot of their needs, and we run a small business ourselves, and so a lot of small business experience.

And then of course, AI basics surrounding that. And then now, Mike, you do a lot more of the sort of web app development side of things, and th- this is your episode, AI basics for developers. So why don't you take it away?

Mikhail: Yeah, there's gonna be a lot here. One thing I wanna mention right away is that the show notes to this are gonna be quite heavy. Uh, so when-- If you're confused about something, if you wanna learn more, I highly recommend you to go to htmlallthethings.com and search for this episode, uh, on there, because the show notes are gonna be quite packed.

I'm not gonna cover everything in the show notes. That's to be clear. I'm gonna try to give you a good idea of kind of the tooling, the, the, the terminology, the tooling around where AI is today, right? So we're in, you know, September of 2020, uh, 6. So this could be, uh, slightly in flux depending on when you're [00:03:00] listening to this, because as Matt mentioned right before, models are coming out literally every single day that are eclipsing each other or being worse than each other, whatever. so do your own research when you're, when you're checking this out. But I want this to be a very foundational episode in the sense of we should-- you should get the terminology. That terminology should stick. There should be-- There might be other stuff you need to learn, but at least this base terminology should stick. The tooling, the ideas of the tooling should be sticky. And then especially you're a traditional developer, if you're a junior developer, if you're just getting into development vibe coding, the process that I would use to start trusting AI to actually develop good at the end, that's gonna be very sticky as well, right?

De- regardless of where AI gets to, at least in the next couple of years. So having said that, I think the first thing that we kind of need to get out of the way here is the, some of the terminology I did quite a bit of, like, research for this stuff. Uh, I'm only gonna be talking about really three things: models, [00:04:00] agents, and harnesses. But even then, it-- even just those three kind of core term- terms for developers, there's some real haziness. Like, this is early, early, early times in this space right now, so there's stuff that overlaps, there's stuff that doesn't make any sense. But if you have a general idea of these things, I hope that it'll make it easier for you to pick the right tool, to be able to interact with that tool better, right?

To understand what's going on. So that's why I wanted to talk about these three things, the first one here being model. the model is the underlying LLM, essentially. So we're talking about your, you know, Claude, uh, Claude models. There's the Opus model, there's the Fable model. Uh, we're talking about your ChatGPT models, right?

There's the GPT-6.1 Sol that just got released yesterday, which replaces 6.0 Sol, which got released a week ago. I don't-- it-- million models, but it's the underlying intelligence [00:05:00] of, of the system that we're gonna be talking about, right? So this is the intelligence, okay? With that-- With just the model, you're talking about just essentially a chat, back and forth chat. So when, when ChatGPT-3.5 released, or 3, 3 released to the world, that was essentially us talking almost directly to the model. It couldn't, you know, look at our documents, it couldn't look at a picture, it couldn't do anything, really. It was basic, "Hey, here's, here is some text. Give me some text back that, you know, would make sense around the question that I'm asking." That's what a model does. The next thing here that builds on top of a model is an agent. So this is the thing that actually gives the model the ability to perform work, and it does this by making, like, kind of like a decision-making loop with tooling, right? So the model is able to go in and think to a certain degree [00:06:00] through an a, through agentic str- structure, and also have a certain a- ability to go through and decide if what it's done is enough, right?

Like if-- So if you ask a model, uh, if you ask, you know, something to, uh, parse a picture and figure out what, what are the details in that picture, and in that picture, there's a website with an, with a phone number on it and a, a map, whatever, right? The model itself, if it's not multimodal especially, doesn't have the ability to parse that picture. But if you give it-- if it's an agent, then what it would do is, "Okay, I need to parse that picture." Then it has a decision-making, uh, point where it's like, "Okay, what do I need to do to parse that picture?" It goes in, checks the tools that it has a-access to, then it uses a tool that it has access to to parse that picture, and then goes down through that tool, uses it, parses it, figures out if...

D-Does another, you know, essentially autocomplete, you know, [00:07:00] LLM structure. Then if it decides, "Hey, is this enough?" Is this what the... It, it asks again, "Is this what the a- user is asking for?" yes, output. If no, do another loop. Okay, what other decision needs to be made? What other decision ma- nee- needs to be made? So an agent is able to, you know, read files, edit files, run commands, search a code base, run tests. That's kind of the basic functionality of an agent. It's able to do much more than that, but that's what an agent is. The next thing is a harness, and this is where it gets-- starts to get fuzzy. A harness is the infrastructure and rules around that decision loop that the agent is using. So for example, right, if an agent needs to make a decision, oftentimes it will ask the harness being built around the agent what tools are available It will also ask, hey, if it, if it, if the decision is to, like, write a script and [00:08:00] run a script on the machine, the harness is the thing that's telling it if it has permission to do that or not.

So the harness is the permissions, tool context that it has, and a verification process, because at the end of the day, once something is done, the agent can determine that itself, or the harness could tell it, "Hey, when you're finished, this is what you have to run. These are the tests you have to run." So the harness is kind of the infrastructure, the, the thing that binds the agent together with the model to make it be more useful

Matt: So let, you c- I was gonna say, could you, could you give us an example maybe of just like a run through and then just, you know, talk about the different, what the different parts are using those three kinda key terminology pieces?

Mikhail: Yes. So the first thing I'm gonna talk about is a tool here in this example. Read file, so a read file function is a tool. A model, like an, a model can't really read a tool without this read file tool. Claude, the [00:09:00] model, is deciding to call read file, edit file, and then run tests. That's an agent behavior. So it's deciding to call three tools, it's becau- it's behaving as an agent in this case. The system deciding that Claude is only allowed to edit specific folder and must run tests before finishing That's a harness. It's, again, it's not super, super clear because we're still in the, in the flux of this being defined. I think that's the problem here. that's the best way I could kind of lay it, lay it out for you.

So a model running, like, tools and calling tools be- makes it become an agent, and a harness is the thing that kind of gives it the rules on what tools it should call for what instance

Matt: could I, could I take a stab at this to, like, take it out of the AI sphere and then connect it to the AI sphere in the s- at the same time?

Mikhail: Mm-hmm.

Matt: So what I would say is a model would equate to the [00:10:00] human brain. So in real life, again, kind of separating it but still connecting it to the AI, you would say, "What's the model of a human?"

It's the human brain, you know, the intelligence center, whatever. So there's that. The agent would be the, the person's skill set. So you would go to a plumber to get a leak fixed. Okay, fantastic. So they're a human brain, right? And they have the agency to fix that leak 'cause they've been trained as a plumber.

So there's your agent, right? They make decisions. I'm gonna use this tool, I'm gonna use this and that. The harness would be society or their workplace or the laws. Let's just t- to sim- simplify it, let's say the construction code. So the plumber may look at the leak and say, "I could solder that with lead solder."

That is illegal. So they have the agency to, to know I could use lead solder here. The code here, the construction code, the laws state that I cannot do that, so I will use [00:11:00] this other method of fixing the leak. The harness is those laws, the construction code. The agency is them going through their own skill set that they've made, and the baseline of everything is the human brain powering it.

Would that be a good sort of, like, for someone who's very new to this, a good sort of, like, out of AI experience, I guess?

Mikhail: I think, I think that's perfect, yeah. Uh, I think like the, the, the, the construction code or even a contract that you agree with on, with a contractor could be a harness, right? Like, 'cause the contractor could be like... The contract could say like, "Hey, you're allowed to go into this room, into this room, into this room.

You're not allowed to go into this room." So that's, you know, a harness telling, telling the person that it has the capabilities, obviously can go into those rooms, but don't go in those rooms, and we're actually putting boundaries up to, to

Matt: Exactly. C- the, the actual first idea I had was, like, a tech worker. Like, if, uh, one of your competitors is solving a problem you can't, I mean, you could go in... Technically, you could, you know, if, if society didn't have rules and companies didn't have security. I could just walk into that competitor, go take their prototype, bring it to my [00:12:00] company, and then start f- you know, fixing my issues.

But the harness is, "Hey, that's a competitor. We can't be doing that. That's trespassing. You can't be d- you know, you can't be doing that. You're gonna be breaking through their security. You can't be doing that." So there, there's your harness. But, like, if it was allowed, I mean, that would be, "Oh, they've, they're already 70% of the way through.

Let me just go over there and take it from them

Mikhail: Mm-hmm. I agree. That's exactly it. So now let's equate these to the tools that are available right now, right? So there's a bunch of AI coding tools. I'm not gonna cover every single one of them because that would take literally this entire episode and I would still not be able to cover them all. We're in a bubble in terms of there's too much of this crap around. Not from a capabilities perspective. The bubble I, I believe is something very similar to, you know, the dot-com bubble where, like, we just have too much crap, but there's core-- the core ideas of agents and, and, a- and LLMs is very, very, very foundational. It's not gonna go away. These are the tools that I [00:13:00] deem good right now, um, that you should look into without overwhelming you. one here is Cursor. So if you're more used to VS Code, Cursor is a good transition because it's a VS Code fork, or was a VS Code fork I should say. I believe they've rolled out their own version without any sort of dependencies on VS Code since then. But it's essentially a IDE, like a, a, a, a ba- a, a simple...

Not a simple IDE, but it's a code IDE, so you can have your code there and you can have an agent pane there. You can do the same things that you would do in VS Code traditionally. the-- It is starting to transition its way, so it has a separate, like, agent view, which I think is good because when you're starting to get into development, uh, when you're starting to get in, you can kind of stick to the VS Code style editor, and then as you start to get more comfortable with agents, you can switch to the agent view in the same tool.

Kind of nice. They have a subscription model where you can use a bunch of agent, a bunch of different, uh, models, plus you can use the, the Groq models now, like the... I think there's a Groq 4.7 that [00:14:00] just came out which is a decent model. 4.6 was a decent model. And you can use, like, Claude models in there too under a certain amount of, uh, usage. So it has a, it has a subscri- All of these tools will have subscriptions. It'll have, they'll... Most of them, some of them will have free tiers. Mo- I would-- If you're a g- developer, you're gonna lean towards having to pay for it, and you're gonna lean towards paying a higher amount as well than you're used to.

If you're used... You know, it's going to be probably closer to the $100 a month at least range, but in a lot of these, there's like a $200 a month plan as you get more serious So Cursor, Cursor has agentic, so it has agents inside it, and it has the ability for you to work inside their harness. This is, this is the confusing part. agent is, again, a lot of times a combination of a model with a bunch of tools and the ability for that model to run those tools, and the harness is something that's provided by Cursor. it provides this, like, set of rules out of the box that you [00:15:00] can then edit yourself, right? Like, you can go in a- and give it more strict rules, less strict rules. You can go in and give it more tools, less tools. So you control the harness a lot more. The agent you don't really control. The harness is something that you can sort of control, but you get a baseline in all of these tools. Claude Code is very similar to that. Claude Code is less an, uh, a, you know, a traditional IDE and more of just a chat box where the, the first thing that you see really is just being able to i- input some text. There's an app version, there's a terminal version, right? It, it's up to you what you're more comfortable with. And your i-- the idea is, is that you have just a plain text box. You input information into that text box of what you want the agent to do, and it does it. And here is the same thing. It gives you a...

It's an agent, it gives you a default harness that you're able to then control. So I ho- hopefully that start, it's starting to click here, right? Codex is the same thing, but on the [00:16:00] ChatGPT/OpenAI side. So they're, both Claude Code and Codex are interchangeable. Cursor is a little bit different in the sense that it has a little bit more of the IDE functionality, but is also sort of interchangeable with the three of them. At this moment in time, I'm using all three because of the fact that models are moving so quickly that I need to test the models out, and I can't rely on one subscription or one agent provider to always have the best experience. if you're listening to this a little bit further out i- in the future, you ha- it, it's solidified now, and it's a little bit easier for you to lock into, like, a Codex subscription and just use that for a year be, and know that you're at least getting close to the top

Matt: Let me, let me actually just like, like question or q- question or stop you there because like a lot of these, a lot of these tools, like you said, like the Cloud Code and the Codex are interchangeable in terms of terminology, but they are competitors in the marketplace. And so my, my question there is, is there's gonna be someone out there listening to this who's, you know, trying to [00:17:00] f- trying to start their, their web development AI coding journey and, or just development in general really journey, and they're gonna, they're gonna do a Google search, and they're gonna find a whole bunch of different options.

And that includes things like there's Gemini inside of... If the person listening is an Android app developer using Android Studio, there's Gemini in there. There's a, there's a bunch of AI capabilities in there, agent or otherwise, right? I- in- inside of, uh, inside of Android Studio. And so they're gonna start getting kind of confused.

And so my take, and I've mentioned this in the, in one of the other AI Basics episodes, is my take is you should do a little research. You should choose one And complete something with the one and stop researching because if you start going in and being like, "Let's do this, let's do that, let's, let's, let's automate this, let's automate that.

I- this one's actually better. Oh, this one just dropped a model and this one's [00:18:00] 60% better," and this and that, this and that, what you start getting is on... In, in most cases, unless some model has come out and completely just destroyed everything and just ma- you know, made everything super, uh, e- everything else that came before it is just, is, is, is nonsense.

Well, like, like what you're saying, like that is the problem right now, but I'm gonna say this though. In the hands of a beginner, I think you're still gonna have diminishing returns. So I'll give an example outside of AI.

Mikhail: Sure。

Matt: This is an argument I've had with people, potentially even you as well, not a serious argument, but this is like a, a debate that we've had where going from a hard drive to an SSD of any type of SSD is like a miracle drug for computers.

It's radically, it's radically faster. It helps with performance a lot, especially with Windows startup, 'cause I'm a Windows guy so I don't know anything about Mac. But regardless, it's, it, it's like a miracle drug that actually works for computers. Okay? Then you start, start getting M.2 drives which are faster than I'm gonna call it a traditional SSD in like a two-and-a-half [00:19:00] inch laptop hard drive form factor more or less, right?

Where it plugs into where the hard drive would. Like if you had a hard drive in your laptop, it's usually a two-and-a-half inch hard drive. You would take that out and you could take a two-and-a-half inch, uh, SSD which is very similar sized and pl- you know, p- basically plug it in. Usually it'll screw right into the same drive sled and you're good to go, right?

Now the argument there is the M.2 drive is so much faster and it's revolutionary and it's all this stuff, but you start getting diminishing returns in my opinion. Like going from a regular SSD to an M.2 is not a miracle drug anymore. It is, it, it's great, it's cool, and I upgraded when I upgraded my computer to M.2 drives, but if it was like M.2 drives are sold out across the planet and SSDs are available in, in two-and-a-half inch, I would be fine.

It'd, you'd be fine. Games would still run, computers would still run. Like your, you'd still have a fast boot-up, you'd be fine. So my point there to bring it back down to Earth is If you choose something that's good today, like AI has been going for a few years now. If you choose something that's good today, let's say you [00:20:00] are trying to make a website, just small, like just a small business website, just to take it in, in a context.

You, you wanna develop it though. You wanna develop it. So you wanna have, you wanna have your own code base and do all these things. And so you decide, okay, I'm doing my research on whatever day you're listening to this, and Codex is the best one, or, you know, close to the top. I wanna use Codex. Okay, great.

You choose Codex, you're a beginner, and then all of a sudden Claude comes out with the new model, whatever it is at the time that you're listening to this at, and it's, it, it blows, you know, Codex out of the water. How much though? Is it 10X? Is it 2X? 'Cause you're a beginner, so your prompts and everything else are still not at the point.

And I'm not saying for you to stick to Codex for a year, 10 years, 10 months. What I'm saying is stick with Codex to learn prompting, to learn skills, and choose a task. Maybe your task is I want my MVP. Codex is good enough to make your MVP of your, of your small business if you've done the research and you've decided that.

Even if the other one's gonna do it a little faster, I... My opinion [00:21:00] is you stick with Codex and you learn, make, learn, learn valuable decisions, and then you move on. 'Cause if you keep going, "I'll do a little here, a little there, a little here," you're not gonna g- you're not gonna learn nothing. You're gonna learn how to switch AI tools.

You're not, you're not spending time learning the tools I don't know if you disagree with that

Mikhail: I, I, I want to agree with you because it makes so much sense. The problem right now, specifically this is, this might be a very specific moment in time right now, is I'll give you the example. Codex and, and Claude Code, th- exactly what you said happened just happened

Matt: Okay. S-

Mikhail: The problem is, is that Codex and Claude Code both release new models.

So if you're on Codex, you're using a new model. You're-- On Claude Code, you're using a new model. The Codex new model is actually worse than the, the one that was used before. And so now you're using... And then, and then the Claude Code model is 10X better than the one that was there before. [00:22:00] So now you're using a worse model than you were using yesterday, and the latest competition released a model that's 10X better than the model you were using yesterday, but now you're using even, even worse model than that. And so, like, it's because they have a tr- they have problems evaluating and keeping costs in a, in a relative, in a, in a

Matt: Yeah

Mikhail: so many different things that they're fucking around. Like I'm, I'm sorry to swear, but they are screwing around like crazy right now internally and, and they're releasing garbage sometimes, they're releasing gems sometimes, and they're removing those gems for whatever reason. Now, say even the diminished Codex model probably fine for what

Matt: It's, it's learning

Mikhail: So maybe this doesn't matter for the first little while. I th- you're probably right in te- in terms of like do your research now, and for the next three months use the same model. Like us-use the same app.

That's probably good advice, honestly, because then you're not constantly looking around. But [00:23:00] you get comfortable with it, you really need to start experimenting with the models that are out there. the thing is, is that it's not that hard to go from Claude Code to Codex because at the end of the di- like, like I said, they're interchangeable.

They are very interchangeable. You can use them on the same project

Matt: Yeah

Mikhail: time and nothing really changes. Now that they've actually aligned their like skills files, which we, we have a whole episode on skills, we can link that in the description. I don't wanna go through it right now. Right? But that they've aligned how skills work or align, especially aligned how their like, uh, you know, context file, claude_agents.md, claude.md work, even becomes not an issue.

So if you're set up for one, you're set up for the other essentially right now.

Matt: M- they

Mikhail: I agree with you, Matt. I think using it for

Matt: Right.

Mikhail: is not gonna

Matt: I'm not even saying three months though.

Mikhail: not some

Matt: I'm, I'm saying you choose a goal. So if you decide I wanna make a f- a s- a, a five-page small business website, and you, and you like what you're doing, whatever, [00:24:00] the allure is always there. What I'm saying is, is to complete a goal. Don't set it to be a five-year goal.

Set it to be a, a manageable goal because my point is, is like you're right, the diminished returns. But if you have to take a look at the output, like if we're looking at something that's like relatively, a, a relatively well-sized goal, so something that is reasonable, you say, "I wanna start... I wanna, I wanna spin up a small business website," or, "I wanna improve my personal website," would be something that a lot of developers do.

"I wanna improve my personal website." Even if Codex, you know, today is running at, let's say 1X no buff, to talk in gamer terms, and then Claude Code comes out with a new model and he has a 10X buff, fantastic. But how much better is the end game? How much better is, is the por- is my personal website, my portfolio website, or whatever it is I'm generating for myself, how mu- how much better is my personal website going to be generated at the end of the day, the actual website itself, on Codex with no buff and Claude Code with a 10X buff?[00:25:00]

Now, the, the grass is always greener, so after you do your task, you may wanna do a little research and then be like, "Ah, Claude Code came out with something cool. Maybe I'll try that over there." That I think is more organic, but the point is, is I want people who are learning to be in the prompting, to be in the file management, to be in the agents, to me- mess around with the harnesses are and stuff more than researching AIs all the freaking time and worrying about, "My God, I could have had 5% more efficiency."

Yeah, but you wasted 7% looking around all the time on AI blogs and Reddit, right?

Mikhail: Y- you're not, you're not wrong. I, I, I think that that's good advice. I honestly think that that's really good advice for right now. Um, yeah, it, it's just, it's always tough

Matt: Yeah, it sucks

Mikhail: the, y- because the models are moving at such a rate you could be losing not, you know, 1.5X or 2X, you could be losing a whole breadth of [00:26:00] capability.

But said that, it's more-- Like I, I, I'm gonna be talking about right now, like the process of how you become better at devel- at, at AI development doesn't really apply to this. Like even a 10X better model is not gonna change this process, at least right now, until you get to the very end, until you understand top to bottom how to verif- how to make sure that you're, you trust the agent.

The process is really about trust and building, building the tools and the systems around trust. So going to a, a 10X better model even right now is not going to change that process. So I think, Matt, I think your, your advice of just sticking to the tool after you've done your research, finishing the entire project of what you're working on, and then doing a little bit more research is a good,

Matt: For, for beginners especially.

Mikhail: Absolutely,

Matt: a beginner, so when, when you said, "I'm, I'm using all three," you're not a beginner at using the thing or researching the thing. But we don't wanna overwhelm people, 'cause we also gotta remember that there's gotta be [00:27:00] some coding knowledge before all of this. So now we're starting to like, oh, that's i- too many layers.

Like, I think we need to, we need to, we need to start frigging cutting down these layers as much as we can here especially for beginners

Mikhail: Absolutely. So the next couple things that I wanna talk about are going to be the other tools. So the-- I've talked about Cursor, Claude Code, Codex. These are the three, let's say, agents with harnesses. Now there's like har- agent harness plane tools. 'Cause like I said, I'm using all three. It would be a nightmare for me to manage all three if I was just opening up three different apps. That's a pain in the ass. There's tools called Orca IDE, which is actually like a, it combines a similar like VS Code IDE into it as like a tertiary thing. It's very much not primary. But it also has the ability to open up any of your agents inside there, control your agents across, like so you can ha- actually have one agent control the other agent, however you wanna do it, and then be able to actually see your code.

So it's kind of [00:28:00] like a thing that combines agents and makes it easier to run multiple agents and, and run term processes and stuff like that. It also gives the ability to, uh, use like all these agents from your phone, right? 'Cause before, like if, if you were just using just the regular apps, you would have to essentially have three different apps on your phone and then remote control them from your computer, like to, to your computer, and that's kind of a pain.

This unifies all that. So it just makes managing multiple agents easier, and T3 Code, by the way, does the exact same thing, uh, slightly differently. It actually has a better user interface for that, whereas Orca just runs the CLIs, which I'm okay with. Like, I like the CLIs. They're fine. T3 Code has its own UI layer on top of the CLIs, and it does like a better job, especially for beginners, in my opinion, of, uh, of, of making it easier to control these agents.

So wouldn't, again, as Matt was saying, I wouldn't jump to these tools right away. I would stick to a Claude Code or Codex [00:29:00] or a Cursor, depending on which one you pick, use that for a little while until you get gra- you grasp the whole end-to-end of how an agent works and how you can verify it, and then I would jump into, okay, now I have to use multiple agents.

I'll pick one of these Orca or T3 Code

Matt: Do you think that if you take the obligation of or the, like, the, the FOMO out, do you think that you, that you would naturally outgrow tools? So for example, uh, I was using ChatGPT for a long time, and I was just using that for everything. Like, using my ChatGPT. I'd sometimes use my Copilot 'cause they, they gave me Copilot Premium for a while, so I was using that.

I, I had to upgrade my Gemini for a bit, this was, like, maybe a year ago because... Well, I still have it because I, uh, took about 14,725 pictures, and that's probably not an exaggeration. And so I literally needed more Google Photo space, and so they're like, "Here's Gemini." And I was like, "Cool." So I'm playing with that.

My point is, is not not to tell a story. My point is, is that I'd slowly [00:30:00] started naturally outgrowing the stuff, and then that slowly led me to Codex. Now obviously I'm not advancing in the AI coding stuff as fast as you 'cause you do this more. I deal with a lot of, like, the marketing and, like, the small business guys are...

I'm talking a lot to them, converting their needs to, like, technical requirements, and then, and then going o- go, you know, going away and doing that. So it's a bit different. But the point is, is that I'm naturally... I don't feel obligated to go check out Cloud Codeless and that. I didn't also feel obligated to go check out Codex.

It was an, a gentle nudge from you because I was kinda, like, hitting... I was talking to you about what I was doing, and I was starting to hit the limitations of what ChatGPT could do for me. And then you were like, "Hey, like, maybe you should try this." And then I started also getting, you know, bad results on...

or j- uh, results that weren't as good as what ChatGPT was getting on, on Gemini at the time. This is, like, a year or so ago. And so I was like, "Okay, like, I'm kinda done with this Gemini game. Let me go back to ChatGPT," blah, blah, blah, blah, blah. The point is, is I naturally outgrew just [00:31:00] prompting, then I started going to agent stuff.

Then I started tu- messing around with, well, what if my agent could do stuff without me sitting there watching it? So then I start messing with permissions, like, and it's natural. It's not I could've done this 10 years ago. It's whoa, whoa, whoa, like, let's become more efficient, but, like, in an efficient way.

Slow is smooth, and smooth is fast, kind of.

Mikhail: And, and, and that's actually a perfect transition to how I would start using AI as a developer, because what you've described is essentially the process that I would recommend to people. I think there, there should be this natural progression because it builds trust. The process really is about you figuring out what system works for you to build the most trust to get the most out- the best output that you can get.

Now, gonna say this right off the top, the output might not be as good as you doing it yourself manually. have to learn to be okay with that to benefit from these tools. long as it reaches the end [00:32:00] goal of the results that you need at a quality level that you're okay with, that should be your initial goal, and then you can tweak it to become better and better and better and better quality, right? You wanna, you wanna output as good quality code as you possibly can. It might not be as good as you would write it yourself. I push back on that a little bit 'cause I think most people value themselves a little bit too high. I think models right now are writing code at better than 95% of

Matt: Mm-hmm

Mikhail: there. ago, that was probably closer to 80%, so it's slowly, like, taking up and getting better and better and better. Obviously, there's still people better that-- at, at writing certain things than others, than the models, but it's starting to get to the point where it's gonna be at 99% probably by, you know, end of next year or something like that. Regardless, I sa- it doesn't matter because you could, you could ver- you could think that your code is better and therefore that would limit you from using the, the models. You need to start to learn how to dial that back to be able to build that trust. And to do [00:33:00] that is exactly what you're saying, Matt.

It needs to be a more natural progression. You can't just jump into, well, g- have it, have it generate the entire code base and deploy it and, uh, and, and get it out there and, you know, wish, you know, wish, wish for the best. That's not how it would work. You're gonna run into issues in that, in that sense, and you're gonna be burnt out-- Like, you're gonna bump out of AI coding.

That's what I've seen happen. Be like, "Oh, it screwed up this, so I can't use it now for

Matt: Yeah, yeah

Mikhail: That's not what we want. That is not what we want. You need to slowly build that trust in a more progressive manner. I will say that, like, before, when you were starting out, I think your process was the exact process of, like, ChatGPT prompting, Gemini prompting, and then going to this.

Today, for a developer, I would go straight to Codex. Don't skip ChatGPT. Right? Like, you just u- you just use Codex or use, uh, Cloud Code. So there's a little bit more of a streamline there to get you up, up to, up to speed a little bit faster. But, you know, that's

Matt: Would [00:34:00] you want exposure to ChatGPT be on their personal side? So for example, I will use ChatGPT on my personal side. The reason why I mention that, it sounds like it's outside the realm of developers, but what, what ends up happening is, is I actually use ChatGP- ChatGPT a lot for like a sanity check on something, where I'll go and be like, "I don't even know if this is frigging possible," 'cause I just have an idea, right?

And then I'm like kinda running it, I'm kinda chatting with it, and it's like, "Oh, all right." And then I, and then I end... What ends up happening is I end up having it generate me or it allows me, 'cause I've had the conversation, to have a better prompt to Codex later

Mikhail: So I think the ideal situation is a user has listened to our AI for beginners, both the episodes before, so they have used these things. They understand the concept of a chat, like

Matt: That's a fair point, yeah

Mikhail: before they jump into Codex, right? That's the ideal. Uh, that's the ideal user that I'm talking to right now. If you're, if you're that person, you're in a good spot

Matt: Okay. I [00:35:00] gue- I guess it makes sense, like people generally aren't gonna jump to AI with developer right away, developing right away. That makes a lot of sense. Yeah

Mikhail: I'm thinking. Yeah, that's exactly it. So stage one, what do you wanna do? You're a developer. You've developed before. You've done like, you know, a bunch of junior, like maybe even senior developer work, right? You've done, you know, you've created features, you've made bugs, you've written code yourself. The first thing I would do is jump into a Codex or, or a Claude code on that project. Learn how to do that. I'm not gonna talk about how to do that on a podcast. That's ridiculous. Um, there's plenty of guides online how to install and spin it up. And start with a small piece of work. There's a bug that was raised by someone, you know, look at your backlog.

Something that's not super, super important, right? Something that you, you, you would trust a junior to do if you're a senior developer, or if you're a junior, something that been in, you know, something that's a low-hanging fruit. [00:36:00] And give it as much information as you possibly can about that bug or that, or that feature that you need to build. Make sure that it's, you know, pointed at the right code base, and just let it do its thing And press Enter. Once it does its thing, what you'll wanna do is you'll want to read what it changed, 'cause you're used to that. This is, again, assuming someone that's new to AI development. You'll wanna read what has changed. You'll want to verify similar to how you would verify a, you know, a junior developer's pull request or, you know, someone else's pull request if you're just a junior starting out, and make sure that it's right, and if it's not, then you wanna re-prompt. You don't wanna abandon. This is really, really key right now. might not get everything right on the first try. You don't have skill set up. You don't have anything set up properly. It doesn't have the context of your code base. There could be many things that are wrong. Do not bounce out at this point. Re-prompt. Ask it to fix those things. [00:37:00] Look at the fix. Look at how it fixes them. Is that... Is it good? Good. Move on. Next thing you wanna do is run it. Run the app. Make sure that it didn't break anything else. Test it, end-to-end test it. Run your test suite. Run it-- Test it yourself. Log in. Do the thing that it's supposed to fix, like actually verify the behavior it, that it fixed. Once you have that process down end to end, you'll start to build a little bit of trust. be like, "Oh, it was able to do this feature. It was able to fix this bug," right? End to end. Now, I had to fix it here and there. I had to rerun. I had to re-verify. That's fine. That's part of the process. You've built a little bit of trust here. The next thing here to building trust is make sure to teach the AI how to verify it, because what was missing in this, in this first step, you were doing the verification alone. You were reading the code. You were spinning up the app. You were looking at the app. What [00:38:00] happens if you ask the app, ask the agent to run the tests? Ask the, the agent to run a linting. Ask the agent to run the application and test the code, test the actual feature that it's building. If you ask that in the prompt, that's-- you're, you're, you're creating kind of a loop situation here where it's going to ru- It's going to do its best first guess at how to fix it. It's going to then run all the tests itself, verify that, and then check if it, if they, if they fixed it. If it didn't, it's going to do those steps that I had talked about before, where it's gonna re-prompt itself to fix those issues that it found, and it might do that two times, it might do that three times, and then it'll output you an already tested piece of code an already tested fix.

Now, at this point, you still wanna gonna ver- You still wanna verify this, because this is where you're... Again, you're building trust in the verification. [00:39:00] Once you understand how that verification loop works and what works and what doesn't, like maybe running the test is enough for your application because it's just a backend API, great. you need a more extensive test suite that you need it to run. So maybe you need to develop an end-to-end, an end-to-end suite of like actually running the UI or, you know, do- having like a, a fake API call, a- ask it. Like figuring out what parts of the process need what, need tests and don't need tests the thing that's going to make you trust the process more, right?

You're gonna read the code at this stage, you're gonna make sure that everything's verified, and once you're happy with this, gonna move on. But if you're not happy with it, this is when you go back and re-prompt. It's okay to re-prompt at this stage, obviously. It's okay to re-prompt at every stage. That's the important thing. You're not gonna go back in and try to redo the code yourself. That's another thing. Don't do that. Try to re-prompt and see if you can prompt it to fix the things that you would [00:40:00] have fixed yourself in the process, and then do it again. Okay? This isn't something you do, like, in a day, by the way.

This isn't something like you go from one stage to another stage to another stage. This is something like where you spend a little bit of time on each stage, right? Like, you might build, like, multiple features first and verify everything, then you might build multiple features with, you know, it running the tests and you verifying after the tests. And then as you start to learn that process, and as you start to trust it, you get to stage three, which is starting to trust the review process more. So here you're s- you stop doing manual line-by-line reviews. You're reading less of the code. You're not stopping reading the code, you're reading less of the code.

You're only reading the mo- the important parts. Has it implemented this architecture correctly? H- you're checking for security boundaries. Hey, had, it, you know, we added an admin section. Did it actually make sure that the admin section was gated properly, right? I don't care about this, like, random UI [00:41:00] crap.

Like, it verified it itself. Who cares? You're starting to, you're starting to discard things from your review process. So this is very much a gut thing and a trust thing. You're building that trust line-- like s- step, step by step. So you start to lean, you start to learn more about how testing frameworks work.

You start to experiment with test-driven development. Maybe you write, you have, you have the model write the test first before it actually builds the feature, so it can run that test over and over again as it's building the feature. That's what test-driven development is. It was kind of useless. Not useless.

I shouldn't say useless. It was kind of, um, obtuse, uh, when, when you were doing it manually. A lot of times this was used in, like, very robust system development stuff, where your really, really critical systems need a test-driven development to make sure that everything runs exactly correctly. But in, like, a web development perspective, we hardly ever use test-driven development.

Now, it's kind of free. Yes, it costs a little bit of, uh, tokens, but in, in some cases, you might wanna [00:42:00] have test-driven development to start, and then you can rip out those tests later if you want. again, tr- experimentering, experimenting with different tests, experimenting with static analysis, experimenting with all the different types of testing that you could fi-figure out to see what tests your level of trust enough. This is not a science. is a you thing, a developer thing. Is your level of trust raised enough that you've now done this 15 times and you've caught two things? You've wasted, you know, eight hours to catch those two things. Well, maybe at this point you can start to read less and read less At this point, what you'll wanna do is, in stage four, is let the AI plan a bigger feature, right?

We were talking about smaller features before. Now you want-- you-- it might be planning a whole section of your application and using this verification process to, to plan it, test it, deploy-- uh, not deploy it, sorry. To plan it and test it and submit it for review, right? So you're, you're giving AI more scope and more scope at this point [00:43:00] And the ne- the next stage would be, you know, do this ex- exact same thing. Plan, build, review, and fix all in one loop. So the AI will plan a big feature. If you're, if you're happy with the w- w- with the planning from the stage before, you can let it plan, you can let it implement, you can let it verify, and then you can do the final verification pass here to make sure that it, it, it understood your intention as a, uh, you know, a business user the, from the initial prompt. Here, you might wanna still review the plan here and there, especially depending on the feature. I, I do, I do end up going back and forth on a plan quite often. a skills episode where I talked about Grill, Grill Me with Docs or Grill with Docs, where it kinda generates the plan after asking you, like, 15, 20 questions. I haven't given that up yet, so this is, this is even, like, maybe past my stage of where I'm at right now. But if you start to figure out a way to prompt it to the point where you're happy with the plan that it generates [00:44:00] initially, you could start experimenting with the full loop end to end as long as you're okay with the verification process, right?

You're still verifying at the end by just using the application here. And again, at the end of this, at the end of this, you're, you're really only verifying, only defining the verification process. That's your most important goal. Now, again, I'm still not quite there yet. This is something that I'm working towards, but I wanna have it so that my v- for whatever app I'm building, I have a solid verification process that I can trust almost wholeheartedly, right?

It, it does everything from all the unit testing properly to verifying the app running in a staging environment, right, before it does any sort of production builds, and then verifying it, uh, in production as well, while also maintaining like a log infrastructure where it actually checks the logs to make sure that nothing has regressed. That's what I, that's what I mean by full verification here, that's what you would do, [00:45:00] Like if you're re-releasing a feature, you can review it all you want, but you still need to verify that it works at the end of the day, and sometimes you're gonna release bad code into production, and you would probably have to have triggers in your, in your code that will send errors and alerts. Those triggers can now go to AI to verify that situation, and it can have-- You can have the loop go not just from development, but all the way to deployment and fixing in deployment, right? This requires trust and a lot of it, and I don't... Again, I'm not really there at this point. I'm not doing this in production production.

I'm doing this in the pseudo production for like new applications before they're released, right? So this takes time, and it's okay for you to be hesitant to get to this stage. But this is where it's going, I wanna be clear. This is where your trust level will start to go as you start to believe it. And I think it's really hard for you if you're just starting out to picture this situation 'cause you're like, "Oh, these things make mistakes all the time." You're right, they do. But so do you. How do you verify your mistakes? [00:46:00] Build that in. Build the verification processes in. Learn how to verify.

Matt: I was gonna say it's very similar to something you said in the beginning where the thing makes one mistake and then, you know, you're unhappy with it or you're unhappy with its output, you think you could do better. I feel like that's also the case for people who delegate to another person. If you take AI out of the situation entirely, the person that you delegate to is gonna solve the problem different than you, they're gonna code different than you, and even if you give them a whole bunch of guidelines and a, you know, a, a harness, let's say, a bunch of rules to follow, they're still gonna do things slightly different than you.

It's just the way, the way it is. It's, it's two different, two different brains working on it, so it's, uh, different, different ways of approaching the problem, different ways of problem-solving, different ways of messing things... Like, messing up things or doing things well. It's all different. It's all different there.

I would like to say also as a, as a question, I'm sure that, uh, there's gonna be people listening to this who are mostly manually coding right [00:47:00] now and who are gonna start getting into this. The question I think that they're gonna have is, or I guess an observation really, is this process that you mentioned has six stages.

It's outlined in the show notes by the way, htmlallthethings.com, go check that out if you wanna read through it. But the real question I think is this seems to be replacing somebody writing any syntax at all.

Mikhail: It is

Matt: that's weird, right? It's kind of a more d- in deep c- like in-depth conversation, and I'm sure we've had it several times and in, you know, in piecemeal. I don't know if we've had a, an exact episode on it, but there's de- it's definitely come up in the past. But someone who's specifically listening to this, you know, six-stage process that you've come up here, come up with here, it's like, okay, well, where do I start opening the IDE and start writing the functions and, you know, writing the variables and stuff?

And, and, you know, you're shaking your head, like for the, for the li- the audio listener, you're shaking your head no right now. You know, you don't

I [00:48:00] guess, uh, uh, the very first follow-up question I have is how sustainable is that? Because we have a bunch of coding knowledge in our head and we're like, "Yeah, verify. Just go in and verify this, and I verify that, and then verify this." It's very strange to say to someone who's new at coding... Someone listening to this right now is gonna be new, new at coding.

Maybe they just have the context on what coding is, and they're likely gonna be new at AI as well. And it's a heck of a thing to say to them, "Well, go learn how to code for three years and then not- don't use any of that other than in verification and then do this." So then some people would say, "Well, let's not-- Let's skip that.

Let's just get right to the AI," which many people are absolutely doing, which is why we're seeing such an influx of, uh, of GitHub usage, which is why GitHub is having literally, like, a throughput issue, and it goes down all the time and has all these issues because it's-- Uh, their, their growth plan is unsustainable in the face of how many people are actually pushing code now, writing code, and how many code bases are being created.[00:49:00]

Maybe the- maybe these are, are, are questions that are gonna be outside the context of this episode, 'cause this is, like, kind of an evergreen episode. Maybe some of these issues would be, would be solved. Because what I do a lot of the time is I code or work alongside the AI. I get the AI to do something and then I do a task, even if the AI could do it.

I think, "Okay, I'll let this thing run for fifteen minutes or however long the task is gonna take, and then I'll do this for fifteen or twenty, and then, you know, once the fifteen or twenty minutes is up, now I have two tasks complete. I've done one, it's done one. Now let's move on." Maybe the task I did could've been done by an AI in five minutes, but, I mean, I was waiting on my AI anyway.

Yeah, I could've spun up another AI. See, like, you can kinda go down this rabbit hole of, of automation FOMO and g- kinda go nuts with it. But I've been kinda working organically beside it. I don't know if that's necessarily the right way to do it. I, I don't know if this is, again, the episode to ask that question, but this is...

You know, this all-- Like, the whole, the whole, all the stages and everything sound great, but I feel like [00:50:00] many people, I don't know if you're-- You know, correct me if I'm wrong here, Mike, are gonna be like, "Okay, now what do I do other than verify things?"

Mikhail: No, no, no. I, I, I think that is a, it's a very good thing to bring up in this episode because I'm, I'm battling with the same thing that everyone else is battling. I'm giving you the to put yourself in a situation where you're using the tool to its mo- the best of its advantage. But I struggle with the same thing that you're saying.

Like, where, where do we fit into this to this loop? And right now I can say that, yes, we still fit into it by, you know, being able to run it and knowing where to run it and knowing what to do in terms of, like, the code smells. So when something is wrong, you have the ability to steer it in the right direction.

That's what it's called, it's steering, But I, I al- like, I, I always think back on like, okay, as, as they get better, will they be able to steer themselves with all the outputs? Like, I'm giving it the a- ability to see where the issues [00:51:00] are by creating these verification loops, right? Like, I'm essentially putting myself out of the loop. As we, as we go to stage six, really that-- what that means is you're out of the loop for this specific feature, and you're moving on to the next feature to, to create an- another loop to get out of that loop. So yeah, I struggle with the same thing, and I don't... The problem is I don't have a good answer for this, and I don't know if anyone does.

Like, I heard Elon recently say about like, "Oh, like, it'll... You, you'll get more jobs. Um, more jobs because people will still need to run these loops and stuff like that." And maybe that's the case, and hopefully it is. Uh, but I don't know. I don't think any of us can predict the future in this specific scenario. I think that we have to start thinking differently. I don't think we can continue down the path of just being blind to AI, like, and not, you know, going at it from this perspective. I think if you perfect the [00:52:00] workflow of all six stages, it's gonna make you more useful for your company and therefore less likely to lose a job, at least in the interim. That's where I'm coming at this from is, is making you a better developer in the current stages, and that's all I can really think about. Like, I don't have a good-- I don't have a crystal ball. I can't predict if this is going to end it. And if, if you think that we're-- you're doing this to, like, you know, not gonna do this so you're gonna protect your job, in my opinion, that's folly. if you don't use these tools to the best of your advantage, the person beside you will, and they're going to push you out. Because right now, the space is competitive as hell. are very much AI-pilled and AI psychosis whatever, and the people that are not going to be adapting are the people that will be left behind.

And this is my, again, my opinion. Take it with a grain of salt. That's what I'm seeing in the industry, and [00:53:00] I'm not doing this from a perspective of I love this. I'm doing it on a perspective of I think this is the right s- steps for you to be able to become a, a AI developer at this stage. Like, this is, this is where AI development is going.

Matt: Yeah. Yeah, not, not, not to make, you know, the near end of the episode kind of solemn, but it is, it is weird when you hit the end of it. It's not like, "Stage seven, now you code up a function and have the, you know, have the AI do it." It is, it is strange Uh, I think, uh, I think to kinda almost double back or to, uh, I don't know, make things more cheery, we get, uh...

Like, you, you were mentioning that you're kinda working on, like, this last step, this stage six kinda part, right? Um,

Mikhail: Yeah,

Matt: s-

Mikhail: six is,

Matt: yeah, stage five, six, that's, that's roughly where you're, roughly where you're finding yourself.

Mikhail: Mm-hmm.

Matt: I'm, like, to, just to kinda talk to personal experience a bit, like, I'm definitely at, like-

Probably stage three-ish, I would [00:54:00] estimate.

Mikhail: Okay.

Matt: I don't really... I- Stage two-ish as well. Like, I don't really have it, you know, run tests and, and do all kinds of things. Like, I still do a fair bit of that. Um, uh, however, I do do it in a little, like a little bit, 'cause sometimes I'll think of criteria and be like, "Hey, we should test this, we should test that, we should verify this, we should verify that.

What parts, you know, don't allow this bad thing to happen," et cetera. And so it is kind of like self-check, self-checking, self-testing, reflecting. And so stage two is kind of where I am at. The reason why I even wanted to bring this up is, you know, not only to kind of get out of that solemn, you know, sort of like question at the end, but also to bring up the point that everyone's gonna reach these stages differently, and these stages are not hard cut.

Like, "Hey, I'm on stage two, man." You know, it's not that. You know, the, these stages, these stages are kind of like in, in flux. You're gonna... Your own work processes, your own work needs are gonna define these things, and it's gonna be different for everybody, and that's kind of the point

Mikhail: Yeah. And it's [00:55:00] okay that it takes longer in certain situations, and we might not even be... You know, for your specific, you know,

Matt: Yeah

Mikhail: like let's say you're in medical equipment and you're doing firmware for medical equipment, you might not be able to ever get to stage five or four. You know what I mean?

Like, you might have to always stay in stage one, two, three, or like not always, but like at this point in time with the models that we have right now. So it's not going to be-- It's-- The stage one to six is not gonna work across the board. I wanna be, make that very clear for today. It's just where everything is going right now.

And for s- for certain things, like for, you know, low-risk application, web applications, certainly you can do up to stage six today. Certainly. problem. larger code bases that are, you know, massive domains, like an AWS for example, yeah, you're not, you're probably not gonna get to a full stage six for that.

Like, it's just not gonna

Matt: Yeah

Mikhail: soon, 'cause it's just so much. Like, the agents don't have enough context to be able to deal with that shit, [00:56:00] right? Like, so you still need people that have massive domain expertise to be able to steer these agents and probably stick to like stage three for the most part for a whi- for a little while

Matt: Well, also I was gonna say that stage six isn't necessarily a finish line either. I- I-

Mikhail: Yeah,

Matt: gonna be so many domains out there where th- you know, there may be like a, for lack of a better way to say it, almost a fork of these stages where they have to go in a different direction and their end game is somewhere else, right?

Some place that's extremely security conscious. You mentioned already the like y- like mission critical stuff like firmware on medical equipment, which is literally life and death. Like, they may have their own, uh, their own thing. This is sort of just like a, a framework for beginners to roughly follow and is, you know, following the trends of today in general, but there's gonna be so many niches and so many different places to take code.

Like embedded, you know, embedded programmers are gonna have a much different experience than somebody like a web developer to somebody who is, you know, just doing a bit of front end code to someone who [00:57:00] is just doing, uh, DevOps primarily and just doing a bit of code here and there. There's so many different places.

Some people might start on, you know, stage two or something where they only want the thing to run the test 'cause they, they're not allowed to generate the code or what have you, right? There's so many different things out there.

Mikhail: Absolutely.

Matt: But

Mikhail: But

Matt: I was gonna say, I think, I think that is, that's largely it. Um, do you have anything else to add, Mike, before we run the old conclusions?

Mikhail: Oh. Yeah, only that again, like in the show notes, there's a lot more here. There's a section on why this changes software development. There's a section on advice for developers starting today. some takeaways. Like, there's going to be quite a bit of information in the show notes that I did not cover that's specifically to help you out as you're going through the journey.

So just t- check our site, htmlallthethings.com for that in- info. Hopefully it helps you out. And yeah, don't get discouraged. Uh, this is-- [00:58:00] Some of this stuff is very exciting and very cool to see in real, in real time. Like seeing a agent loop check production and verify that there's a bug, and then fix that bug, and then deploy it. When I saw that for the first time, I was like, "Oh, damn, like we won't have to do on-call in the future." Which is, is scary to a certain degree, but also like a shitty part of the job. I don't wanna do

Matt: Yeah. Yeah, no, I don't think, I don't think un- unless you're, you're just, like you're just after the bag, I guess, literally the money, like I don't think you'd wanna ever be on, on non-call rotation.

Mikhail: Yeah

Matt: But I think that is it. Remember that we are gonna have those other links to the other episodes. We're gonna have our AI skills episode. There were two other AI basics episodes, uh, that we'll al- we'll also link there if you wanna go and check out those as well. And if you wanna support episodes like this, we are on Patreon via patreon.com/htmlallthethings, just like these $3 tier [00:59:00] patrons, and you could be one of them.

Tim from The Web Hacker on thewebhacker.com, Jason from Geek Life Radio via geekliferadio.com, Garrett Segall, Level Up Financial Planning via www.levelupfinancialplanning.com, Magnus from Yes Web via yesweb.se, Syntaxify from the HTML All the Things Discord server, and Stacy Mosteller from the website swoonworthydesigns.com.

And remember that we have a contributing author on the HTML All the Things website. His name is Michael Larocca, and he is the author of Self-Taught: The X Generation blog at selftaughttxg.com. Feel free to leave a comment or review on the platform that you are listening to this on, and we are signing off