Advanced Claude Code techniques: context loading, mermaid diagrams, stop hooks, and more | John Lindquist

26:57John Lindquist:and cursor so when we're gonna excuse me when working on a project um often when the ai is generating code it'll often build out mistakes and so even it will say it's done you're like wait a second there were a ton of mistakes there why did you stop just fix it until the mistakes are done. So for example, let's say it wrote out this code and there was this error in here. And this error is something that you usually catch with tools such as TypeScript, or maybe it's formatting or linting or any sort of complexity tools. That there are code quality tools that you run before you think the work is done.

27:42John Lindquist:So you would run something like bon type check and you would see that it has this error but your Claude code and the other agents don't know that this error exists. What Claude has and what Cursor and a few others have is the concept of hooks and what this can do is so inside of of claw, let's go here. You can set up what are called hooks and I'm going to set what's called a stop hook and hit add new hook. And just, it shows you a bunch of examples. I'm accepting responsibility for all of this, a bunch of warnings, because it can run scripts that aren't checked by the AI. and I'm going to say the command for now is just going to be echo which does nothing and I'm going to add it to my project local settings and now we have this echo hook and this is defined in this settings local dot json file and this is for this is a local file for me if you want it to with your team would be settings.json settings.local.json.

29:01What we're going to do is instead of running this command, we're going to run a custom

29:10John Lindquist:clodhook, which I've defined inside of clodhooks. And I called it index.ts. You could call it stop or whatever. So from this script, which is in this directory, I need to run this install for this package because I don't have it installed right now. So I'm going to bun install Anthropic. And this is their Claude Agent SDK. Now in the SDK, they have what are called hook inputs and other types you can use. So that when you're dealing with hooks, you have a lot more information. So like on this input, you have all of this information around what the input name is. And then what the session ID is and the current working directory permission mode and all that.

29:55John Lindquist:and you can use that to customize your hook. But what we are going to focus on is we're going to see step one, were there files changed when we stopped? And a stop is once Claude has kind of finished its conversation and it's now waiting for you to do something. So we're going to check, are there files changed? And we're going to, if there's files changed, we're going to say, okay, then let's go ahead and run that bun type check. And if there is a type check, then we can say back to Claude, we can say, hey, there were TypeScript errors. This is the report and then send them back the output that we showed in the terminal before.

30:39John Lindquist:And it'll continue. Otherwise, if there were files changed, then we can tell Claude to please, there's a prompt way down here, it says please commit essentially uh the files don't commit anything anything sensitive and go ahead and commit it so we set up this workflow of once a conversation is finished check to see if any files have changed if they have you check to see if there's any type script errors which could be a type check or build errors or any sort of other code quality guards you have in place and if there are none then go ahead and commit and this saves you a lot of the overhead in your mind of here's all this extra stuff I have to do when something's done.

31:22Yeah. And what I want to call out for folks that are maybe listening and not seeing this code here is it's really what's nice about this is it's a combination of commands that you would run in the terminal to just generate errors and see them yourselves. But then you can feed those back into cloud code in a more natural language way and give natural language instructions on what to fix or again default to some command that's different which is this github commit command and so i like this combination of kind of like structured commands in in the terminal combined with natural language calls back into clod to then kind of put the bow on the end of any work that this ai system does is that kind of how you think about it

32:10John Lindquist:Yeah, exactly. The gotchas you have to think about here are when you're communicating from a hook back to clod, you're essentially using console log, which is one of the first things any JavaScript developer learns, and you're sending back a JSON object. So it's going to find that first console log, whatever it gets back, that's what it's going to see as its input, its standard input. So you have to be careful if you're running commands like this, you tell this one, please be quiet, because if it's not quiet, then it would log back to the console and maybe interfere with something. Or if you want other logs or you're debugging the script, just use console error or any other way of showing logs.

33:00John Lindquist:Otherwise, console log turns into this feeding instructions back to the agent. So it's one of those gotchas that everyone falls into when building this out. And just to demo it real quick, I'll just turn on Claude. And I'll say, well, actually, for this to work correctly, let's make sure we have everything staged and set up so that when it does the git check, let's just generate a message. So yeah, let's please create a foo.ts file on the root of the project. And we'll go ahead and accept this. And you'll see that it says stop hook returned a blocking error. And that error return is please fix the TypeScript errors.

33:51And here's our prompt right here with this block.

33:54John Lindquist:And it says I'll fix the TypeScript error. So this is when it would have stopped. It would have stopped right here, but we hit the stop hook. Now it sees these errors. So it's going to go ahead and read that. It says, oh, I found the mismatch quote. I fixed it. And now behind the scenes, there's a clod running, which should it commit that fix. You make this a bit smaller, show our graph here. And you'll see, this is the fix that it made was correct the quote syntax. This is what the little haiku did in the background. So the stop hook ran twice. It ran once where it found the error and had files changed.

34:35John Lindquist:And then the second time there were no more errors. And so it ran the commit. And so that saved us all of that work of both passes. And now we have a completed task that has been error checked, fixed, and then commit. And conditionally inscripted in a way where this will be different for every single project based on your requirements, based on your code base. So this is definitely something that you have to like think through and set up yourself. It definitely saves so much time where you don't have to go back in and say, well, please fix this or please run this command or please do this. When you know part of your workflow is always like if these things should always run, you might as well run them automatically.

35:16And something I have to say is I get so much pushback from software engineers saying these tools don't really make me faster. The quality isn't as good. And I think if you make the investment as you've shown us in, okay, well, what things would it do to make the quality better? Or what things would it do that you can automate that would make you a little bit faster? And you put that effort in to understanding all the things that these tools can do for you, either programmatically or through prompting. I think you can actually see a lot of those efficiencies. And then I want to call out something that you said, which is you have this local settings, but you can create settings that are shared across your team for anybody that's working in the repo.

36:02And that's for our engineering leaders out there or larger engineering teams to really think about if you haven't created these hooks for key repos or key projects where everybody is benefiting from this when they're using something like Claude Code, then you're missing out on some of the scaled leverage, I think, of these tools. And so I'd love to put somebody in charge in an engineering organization of figuring how stuff like this can work inside your code base and then scaling it out either through training or through configuration into all the other engineers so that everybody's getting this baseline quality and this baseline efficiency.

36:39Amazing. Well, okay. Other than, you know, type TypeScript errors, just prattle off a couple other use cases. You deleted a bunch of stuff from this hook. So what are the things you think that people should bake into a stop hook like this for CloudCode?

36:55John Lindquist:Definitely formatting. There's kind of the mindset we've always had before of like pre-commit hooks or pre-push hooks, things that operate on the CI. And these are a lot of things that can be fixed before those are even run. So whether it's, there's a lot of tools around with linting it could constrain the length of files there's things like circular dependencies where I could check the imports to make sure that files don't reference each other there's code complexity there's tools that say does this code look like any other code in the code base where this could be extracted into a function or something because it was like duplicate code throughout the code base and there's all sorts of analytics and tools you could run.

37:43John Lindquist:Um, uh, some of them probably not as often as others because it's more expensive and you just have to make those, um, decisions based on, you know, the size of your team, the size of your application. But there's just, just put into an AI prompt of chat GPT or any of them to say, what are I'll make a long list of developer tools people run on pre-push or on pre-commit, and you'll see a huge list of them that you could pick and choose from. Well, and I'm going to take a tiny detour for our very patient, non-technical audience members that have maybe listened to this, which is these post-tool call hooks or post-stop hooks in Claude can also be used when you're working on non-code.

38:31So we have so many people using Claude code to write documents, to do all sorts of things. And so you could just think about, what do I want automated after this tool is called? Or what do I want automated after Claude finishes writing my document? And you could think about ways to use something like this, not even for code quality review, just for a post kind of task completion check. So I think just the general framework is really useful. It's obviously highly applicable to software development, but I think people can think of other creative use cases for this as well.

39:05John Lindquist:Yeah, absolutely. The diagramming stuff, create an image of what we just did and send it to my mom to show her I'm working hard. Like anything you want, right? The sky's the limit. Okay, so just to wrap up, these have been super useful use cases. I want to call them out. One is using documentation and diagramming, specifically mermaid diagrams, to preload as a system prompt in your Cloud Code instance so that you don't have to waste the time of doing context discovery. And you can really make sure that that context is preloaded. It's a little more expensive on the token side, but a lot faster.

39:47And these diagrams are much more easily read by machines than by humans. so it's a good format to get things in. We looked at aliasing some of your favorite Claude code instances and settings so that you can pop into your Live Dangerously mode. You can pop into your You Have All My Diagrams mode. You can just pop into those with one or two letters, which I like. We got a little side preview that we didn't call out, but just how casually you use voice and transcription to enter in and out of these tools. What I like about the way you use AI is you were just like highly efficient. You're like the minimum number of things I could type, the better.

40:30And you're pretty fluent in switching between voice and typing. So we saw we saw a little that. You encouraged us to create in particular little command line tools to build one off ideas or tools. Yours was a website design generator using Nano Banana. And then you showed us how to use clawed hooks and in particular a stop hook to do some quality and other checks on code written by these AI tools and automate some of the processes that you might do as a software engineer that you want our little AI software engineers to do instead. Just that in, I'm looking, 40 minutes. We did it pretty fast.

41:13John Lindquist:Nice. This is great. Okay, well, I'm going to ask you a couple lightning around questions and then we will get you back to your very efficient AI coding. My first question, again, you're like me. We love Cursor. We love Cloud. We love VS Code. We have all of them open. You know, I think everybody's, I think there's interface wars happening right now. Are people going to love these terminal UIs and command line tools like Cloud Code? do people want the the ide i i noticed that you're on cursor 2.0 so you have the agents view which is very simple and abstracts away some of the code and you're in the editor view i'm going to give you two two wars i want your quick opinion right now we won't hold you to it of what you think wins for i would say real software engineers you know writing real code out there um the friends that I talk to, you know, terminal UI, IDE or both.

42:11And then do you have any hypotheses on, I think particular in the VS fork world, VS code fork world, are there any moats or, you know, what do you think, how do you think people can compete in the IDE world? Yeah.

42:27John Lindquist:So I think you need both. I think you need an IDE and there are so many use cases for the CLIs. The reason being that the CLIs have a lot of configuration and a lot of settings where, as you saw with aliases, I could launch a version of Claude that loaded up a specific set of MCPs or a specific set of prompts and preload a bunch of things and do that in a single terminal command and be very quick and fast with that and then set it off in the background and just have it running. currently inside of inside of a cursor inside of any of these idees there's usually a lot of okay open the ui navigate to this and then navigate that then switch over to this then switch over to that and they try and streamline as much as possible with slash commands and whatnot but it's just not quite the same but if you have an ide and you're reading through the files and you're selecting lines and you want to modify certain bits like focused work.

43:32John Lindquist:There's so many use cases for IDEs where there's a recent cloud tool where it has a IDE integration where it can check the diagnostics from the IDE. And you'll see that with VS Code as well, like the extensions you put into an IDE can be fed back into the agent. So there's a whole robust extensions ecosystem from IDEs because people build on top of these things their own workflows. And I don't think we've quite reached, like we build our own CLIs from AI. I don't see a lot of people building their own cursor extensions or ES code extensions, which is very possible. And you could feed those errors and warnings and company rules and everything in very complex ways back into the agents.

44:20John Lindquist:So that will happen as well. And I think for one IDE to stand out above the other, they have to separate themselves like Cursor is doing with their agent mode. They have to make something unique and user-friendly that once, like people are not going to give you a bunch of time to convince them. You're going to have to open the agent and you're going to have to like see that click on browser mode and it's going to have to launch your dev server and you're going to have to click on the element and say, I want this to look with more pink or purple or whatever. And then they want that to just work.

45:01John Lindquist:We'll see any sort of friction or frustration from any AI tool anybody puts out there is just instant dismissal from so many people. Like there's just the bar for quality is so high in the AI landscape because everyone can build anything that you have to focus on the UX and you have to make that experience better than everyone else. And that's where you can see Cursor making the bold moves of like, okay, let's go full on agents. Like you have to make those leaps. Yeah, I agree. And, you know, just talking about this skepticism and high bar, what I love about this episode that we recorded today is it's really most relevant for software engineers with more experience who are shipping high quality code and who want to write production level code more efficiently using some of these tools.

45:56This is not, you know, I hope you all hung out and listened to it, but it's not for our vibe coders and our non-technical folks. And so what would you tell kind of senior principal software engineers, engineering leaders? I get asked this a lot about how do I sell the value proposition of these tools into very skeptical organizations? and what are, as a more advanced software engineer, the things that have just changed your life in the last year, which say you should never go back to doing it this way. Kind of how do you make that pitch?

46:31John Lindquist:The first thing that jumps to mind is any time an issue is opened, like you can set up streamlined workflows that someone opens an issue and you can have Claude automatically tackle it. You can set up triggers for linear GitHub, whatever, that once something happens, you can get that first pass to see, okay, can we at least find this without doing any work? Can we at least get that initial review in there of what's going on? So that once we jump into the task, I mean, for my entire career, someone throws an issue at you, you spend the first you know probably day or two orienting yourself to like okay i didn't write this code this is legacy from let's you get blame let's do all this stuff like all of that busy drudgery that you're going through to even get started on the issue um it can wipe out so much of that it can find who touched the files who did this like if if you have a diagram set up what are the risks the impacts are there potential security things are there like it it's so great at surfacing the you don't know you don't know sort of scenarios where you hire so many contractors you hire so many people who are new to these things and then you throw them into these tasks and they just don't know like they haven't spent time with the code base and then you ask them to fix these things they just have zero idea what sort of impact their change is going to have the AIs can surface a lot of that and they can just be like okay we need to be super careful This is, you know, in production and, um, this is cost going to cost us money if this goes wrong.

48:17John Lindquist:Just tell me everything I need to look at, like find every single debug path, find every single, um, uh, every, why has this file changed over the course of history? Like write a summary of everybody who's touched this file so I can know why this function is the way it is. Like there's just so much work that is just not writing code. Um, and all the exploration work is just so much easier to just say, like everything I just said over the past 30 seconds is a prompt, which I could have just dictated. Right. Um, and you just have to walk up to your computer and say, I have this issue, like guide me through all this stuff.

48:57John Lindquist:And, um, it's just, it blows my mind that people be hesitant for those sorts of tools i understand if they're like okay maybe some of the code isn't perfect we still have to do code reviews we still have to like check for quality we still have to run our tools to validate things but if you're not using it to do to like inspect and investigate and write orientation and all that stuff then like you're really missing out like in the enterprise space yeah and on the other end if you're not using it to document so the next time somebody has to do that investigation you have a little bit of an easier time um you're also missing out so i do think on that that front of the back end and what i often tell people is a good way to think about how to design your AI workflows is do not think in a task level orientation, like I'm going to write code.

49:53I say, think about if I gave you infinite junior to mid-career talent who is always available, who would do the work you would do if you had unlimited amount of time and no meetings, what would you do when a ticket came in? Like, what would you do? And you'd say, well, I'd go trace who wrote the code. I would go figure out the history. I would make myself a really good tech spec. I would call out the risks. I would publish this in a way that my team could review it. I would have a senior engineer look at it and give me some really hard feedback. All of that could just become a prompt. And then, you know, but so many people are just constrained by their time and cognitive capacity.

50:36And so they just go, well, I'm going to read the issue and bounce around in the code a little bit. And I guess I'm going to start coding. And so you can kind of get to this model of optimal, not perfect, but like optimal workflow, and then figure out how you can prompt or build workflows or hooks that would replicate that at least in an 80 % way, which is a lot better than not doing it.

51:03John Lindquist:And something as simple as the commit messages are so much better than they used to be because developers don't have to write them. so much better for for people who are new to programming um commit messages used to be like second attempt or like please work or swear words like my my favorite one is just like 17 f's like or like trying this trying that trying this other thing yeah not please work plz yes yeah you know if anybody wants to vibe code a product i always thought that startups would want a printed book of all their first years commit messages with like calling out the really funny ones oh if somebody wants to vibe code a little uh github api powered print uh business i'm sure you could get a couple startups to print those out okay last question yeah this is probably challenging for you because you do a lot of dictation so you're probably actually pretty polite to ai given you would have to say frustrating things to it if you wanted to be mean but when our little friend Claude is going off the rails or you're really not getting what you want?

52:14What is your prompting, reset, start over technique? Have you found any tricks that work particularly well? Yeah, it's really the take the conversation, export it.

52:29John Lindquist:A lot of them have the export commands. Drop the conversation with some of the code files into the um into chat gpt pro 5 or whatever it's called or a gemini uh deep think i believe is the and have a have them do a second set of eyes on it and then kind of start over rather than like if things go off the rails and you can't fix it in about maybe one prompt or like where you see what's going wrong and just revert to the previous commit and kind of start over because there there's always this underlying ai is trying to go somewhere and you want it to go over here and you keep on telling it to to join on your path but it still wants to like get somewhere else that you don't quite understand and so starting over from ground zero and like revising your original prompt is better than like trying to steer it to where you are when you've like drifted so far away um and that has to do it's so different with every model it's so different with every prompt and all the context and project that it's like i can't give you like the here's instructions that work every time but like starting overworks every time tossing a second set of eyes on the entire conversation where that AI isn't invested in that conversation.

53:57John Lindquist:It's instead critiquing the conversation. Those are my two. I think that second workflow is so funny because I think as somebody who's been a manager and a leader so many times, sometimes I feel like I'm the reasoning model being brought in to mediate the misunderstanding between too smart but misaligned resources. And so it's really funny to hear the idea, okay, like I'm having a debate with my AI. Let's bring in like the third party. Let's mediate this conversation, have an objective set of eyes to see where we maybe are misunderstanding each other or going wrong, and then reset and start over.

54:39So again, I think, this is the moment for folks with a lot of organizational and social skill thinking to apply this to how you might design some of these flows for AI, even though there are beep-boop machines that we're really using.

54:55John Lindquist:Yeah, and I would say, kind of last thought on that, is the recent planning modes that have been released with Cloud Code and Cursor and all of them have eliminated a vast majority of that drift. So they've been fantastic releases, which I strongly recommend for anything beyond like a small file change planning is awesome. Yeah, I love those features too. Okay, well, John, this has been great. Where can we find you and how can we be helpful? Yeah, I'm on egghead.io. I have tons of courses on AI tooling. I teach workshops through egghead.io. I send a newsletter out every week called AI Dev Essentials.

55:34You can find me on X and other platforms as well under my name. And that's it.

55:41John Lindquist:I love to talk with anyone about all this stuff. My workshops are fun and we talk, go way deeper into this super advanced stuff. So, yeah. Great. And then maybe some of us can shop your possibly to be created Christmas and holiday decorations night. So you let us know. You let us know if that goes live. We'll drop into the show notes. Thank you so much for joining us and sharing your workflows. Thanks, Claire. Thanks so much for watching. If you enjoyed the show, please like and subscribe here on YouTube, or even better, leave us a comment with your thoughts. You can also find this podcast on Apple Podcasts, Spotify, or your favorite podcast app.

56:23Please consider leaving us a rating and review, which will help others find the show. You can see all our episodes and learn more about the show at howiaipod.com. See you next time.