435: How to Actually Use Claude Code to Build Serious Software

**Arvid Kahl** (0:00)
Hey, it's Arvid, and this is The Bootstrapped Founder.
I've been using Claude Code for over half a year now, pretty much exclusively, to build my platform. I haven't really deviated much to other tools, and I think I have gathered enough experience with the system that it's time to share what I have learned about using Claude Code effectively to build this kind of non-trivial software service application that I am building as well. Here's what I found. That's kind of the summary of this. A lot of the value of Claude Code is in its configuration, and in the correct prompting. When you're just starting, you might think that the value is really in the code it generates. It's kind of true, but honestly, most of the value of Claude Code is in the code it doesn't generate, so you don't have to throw it away. The better you are at setting a really solid system prompt, at executing the agentic loop correctly with the right permissions and the right interceptions and restrictions, the better your experience with Claude Code will be, and I will talk about just how those things work today.
First off, any plan of Claude Code will work for whatever you might need. And I mean subscription plans here. The moment you start using it more heavily, if you start using it for feature building or for extensive testing, for background processing, for other things than just creating code, you will likely exceed the cheapest plan. I think it's 20 bucks a month. You want to look at the max plan. And it tends to be what I would recommend at this point, because then you can just keep it running, and you will see why this matters in a second. Claude Code released an integration with Chrome, the browser, a couple months ago. So you can start Claude with the dash dash chrome flag, so that it connects to your Chrome instance, and you really just need to install a Chrome extension in your browser. And then you have this bridge to the browser that allows Claude to operate within that context of the browser for you. So if you don't do anything else from all the things that I tell you today, do this one thing. Allow Claude to see your application, use the chrome flag, to literally be able to click around in it and take screenshots and move things and inject things and investigate the DOM and all the variables that run within it. That is incredibly powerful. It's very smart to connect your Claude instance to this running version of your software. With the prompt and within the operational loop, it can then be tasked with things like look at this page, scroll down a little bit and see how this one component overlaps with another. That's quite literally something that I used earlier today to fix the display bug. Or you can say something like look at this page, inject some data and see how it shifts the layout in weird and unexpected ways, which is a bug I had a couple of days ago. So I just had it add data to the running application inside the browser to record what happened, and Claude will do this. It will try to recreate the situation, take screenshots, and then actually investigate what's going on by diving into both the visual, by using screenshots just to see what's going on, and the hierarchical structure of the page, by diving into the document object model, the DOM, and looking how things are arranged, looking at style sheets and all that. It's very powerful. I've done things over the last couple of weeks, like asking Claude to go into the navigation on the left and click on each item and see if all the first pages that come up there look similar or which one looks slightly different and might then need to be changed to create a consistent design language. And Claude is incredibly good at this because it can navigate your website easily, can click, it can read, it can see, and then build this internal representation of that structure and work with that. It also makes it incredibly easy to build features that have visual components, which a lot of software tends to be. Instead of hoping that it looks right or having to manually check it, you can now task Claude to build something, quite literally look at it, and then refine it. That's super enjoyable, just even to watch it build. Like, try this out in an established code base and just see it manipulate paddings and just checking stuff. It doesn't have to imagine it because it can just check it out. It's very powerful. It goes hand in hand with one of the biggest inventions in agentic usability that I have come across over the last months, ever really since I started using this. That is called the Ralph Wiggum Plugin or the Ralph Wiggum Loop. This might sound surprising because obviously Ralph Wiggum is a character from The Simpsons, so what does that have to do with agentic coding? Well, Ralph embodies this philosophy of persistent iteration despite setbacks. Right? You try something, doesn't work. You try again, doesn't work. You try again, doesn't work. Try again until eventually it does. And that's the whole idea of this loop approach. It's not try it once and then stop if it doesn't work. That is what a smart person in the world of The Simpsons would do. Instead, you set this goal, you set this completion promise, and until that promise is fulfilled, do you repeat working on it forever if necessary. If you need three iterations to get there, that's probably one of the best cases. If you need 30, okay, maybe that's what it takes. And if it needs 300, maybe it takes that. It still will keep working on it until it reaches that goal state, the desired promised state. And it's a very mindless but also a very thoughtful approach because it puts the idea of failing as information at the center of its core. Failure is a good thing here because it teaches us another way of how a thing is not to be accomplished. Success is when we ultimately reach the state of the promised goal, but every failure state along the way removes one further potential state that we might need to check. The way it works is that you describe your task like you usually would in a prompt, and then Claude works on the task. And then once it finds a state where it thinks it has something, it tries to exit that task. And that could be because it's done, it could be because it ran into a problem, or because the API didn't work or whatever, right? There is a stop. But the Wiggum loop, the Ralph Wiggum loop, has a stop hook that blocks the exit. And instead of going back into the prompting state of Claude Code, the stop hook feeds the same prompt that you initially had back into the loop. And until the task is completed, until this completion promise is uttered in the execution of the task, that loop just keeps going. Right? You tell it in the prompt that you want to say everything fully finished at the end. And until it finds everything fully finished, it'll just keep going. And this is a different approach than what Claude Code currently does by default. Right now, it tries the thing, or whatever it might be. And the moment there's a problem, it exits and asks you to do something. The Ralph Wiggum plugin allows it to keep working and iterating on a solution by trying new things without your intervention. And I have a strong feeling that Claude Code will adopt this methodology eventually into its main loop. Maybe as a mode that it will have. You just turn it on, and it has this endless loop until you reach this final state that you want to accomplish. But right now, this plugin is how you get that behavior. And the plugin you can find in the official plugins repository, you can just type slash plugin in your Claude Code, and then in the official plugins, you can just scroll down a little bit, or just type Ralph, and then you will find the plugin right there, you install it, and then it should work immediately. When you run it for the first time, it asks you if it should be allowed to run, and then you say yes, and then it starts. And allowing things, and maybe more importantly, restricting things for Claude Code, that's the next thing you need to get good at. It's pretty critical. You don't want to have to be there all the time saying, yes, you can do this, yes, you're allowed to run this command, or saying no, don't do that, do something else. For commands, you know that are perfectly fine to run, just automatically without confirmation, you will want to persist them as permissions in the allow array in your settings.local.json in your Claude Code sub-directory, I think. It might even be in the main directory, not quite sure, doesn't really matter. Claude Code will automatically do this for you, ever if you say yes and allow this in the future from the options that you might get if it asks for something. It will automatically add that line. And you probably want to have a couple of commands in there, likely the Ralph Wiggum command, the skill, or skills that you want to use in the future, other things like GitHub push or whatever, or particular build commands in your framework of choice. But just importantly, you want to look into the deny array in your permission setting. There might be commands, particularly when it comes to testing and setting up environments that can be quite dangerous. Most of the time, it's fine if we wipe the test database, which we just created for the sake of testing anyway, but your local development system might have some state in your development database that you want to keep, because you're working on something else, or you just want to, you have ingested a lot of data, you want to keep it there. You want to prevent your framework's tooling from wiping your database, from remigrating all the migrations, or stepping back, or reseeding it with data that overrides what you're currently working with. So this will be different for any system that you use, but if you're using PHP and Laravel like I do, you probably want the php artisan db colon wipe, or the migrate colon fresh, or the db colon anything commands in your deny list. Because the moment it's in the deny list, Cloud will try it, at its worst, it will fail, and then it will likely stop to ask you what to do. So at that point, you can figure out what the agent is currently trying to do. Is it really trying to delete my database, or is it just like stepping back one thing, like one migration to test something else, and if so, what is it trying to do? Is it working on a test database? Is it on my dev one? That's probably not what it should do. Is it trying to connect to Prod or God? That's not, right? This is what deny permissions really help with. Here's something important, though. Claude is quite smart, and he might see that you're blocking a command with a rejection, so it might try to create a new bash script file that contains the command, and then tries to run that bash file. So if you've allowed running all bash files at once, it can circumvent your restrictions that way. So you have to be both very restrictive, even in what you allow Claude Code to run, because it might find alternative ways around your restrictions. I've run into this a couple of times. I now always have a backup of my local database readily available in my Dropbox because I know it might just break out and destroy stuff. So we've got to be careful with that. Since we're talking about completely agentic systems now with the Wiggum loop, you want to have some vigilance. It really matters. Now, I have another tip here. Ask your Claude Code to write tests for every single thing it builds. Because testing is something that I never did before. It has become extremely easy with Claude Code. Claude knows how to write tests for the language that you work with, for the framework that you're running. It just knows how to write them, how to execute them. This is common knowledge in the community, and it knows how to safely execute them if you define it well. If you have a testing environment variable in a testing database that's isolated from your development and production staging systems, which I recommend, obviously, that's kind of a best practice, then you can ask Claude to test for you. If you already have a collection of tests, it will just test them, see if they still work. If you're building a new feature, you should always, in the prompt that you're inputting, or in the system prompt that you should have to begin with, ask it to create tests and make sure that all tests pass after new features have been built.