is incredibly effective at quickly building up new applications. This is, of course, super useful for any programming task, whether it be working on an existing legacy application or a new codebase.
However, from personal experience, I feel that coding agents such as Claude Code are vastly more powerful on completely fresh code bases because of how effectively they can go from 0 to 1.
This ability to quickly build an application is incredibly useful to make hyper-personalized products, such as internal tooling. In this article, I’ll take you through how I use Claude Code to quickly build completely personalized applications, which previously would have taken weeks to build but can now be built in less than an hour.
Why build internal tooling
Internal tooling has always been useful. It’s typically built by engineers within a company to simplify repetitive processes. This is, of course, super useful as it makes these repetitive processes far more effective because they can simply be run with a single script or similar. This has two main benefits:
- You can complete the process more effectively with internal tooling than without
- The internal tooling makes the handling deterministic in contrast to an engineer coming up with a custom solution to the problem every time
However, it typically takes some time to build this internal tooling (especially if you don’t have access to a recording agent). This time has prevented you from building internal tooling on any task that isn’t repetitive enough or doesn’t take enough time.
However, this game has completely changed with the release of Coding Agents. The cost of building internal tooling has come down drastically, which enables you to build far more internal tooling to become far more effective.
I’d argue that since the cost of building internal tooling is so low, you should definitely be spending time on building internal systems that can make you and others in your company more effective. It’s also good at making processes more deterministic. If two different engineers were asked to solve a task, they would likely come up with somewhat different solutions. However, if you already have internal tooling to solve this task, the result is naturally deterministic because it’s handled by a piece of code. This increases the value of internal tooling even more.
How to build internal tooling
If you’ve gotten this far, you hopefully know why you should have internal tooling. It simply is a way to make you and others at your company more effective, and ensure that cases are handled deterministically.
However, you still need to know how to build internal tooling. I’ve split this section into two main parts, which I believe are the pillars for building internal tooling:
- Finding where you need to build the tool
- Building a reusable tool that is easily accessible to everyone and that everyone is aware of. You can often build a single script to achieve something, but making it reusable, generalizable, and available to everyone can be more of a challenge.
Finding a need for the tool
Step one is always find the need for a tool. You can probably find this everywhere throughout your company. You should essentially be looking for bottlenecks, processes that take the most amount of time and that hinder your growth. An internal tool should also be built for tasks that are done repetitively.
If you have a process that comes up time and time again, you should definitely build internal tooling for it. This could be:
- Checking if document processing is finished
- Automatically routing customer requests to the right person
- Writing documentation for your API.
All of these are processes that are typically repeated many times per week and that you don’t want to do manually every time.
You should always be on the lookout for these kinds of tasks. Tasks that you do repetitively, repeatedly, and tasks that a piece of software can easily solve. Of course, some tasks require a human touch. For example, answering emails or responding to bug reports.
However, you should try to open your mind up to what kind of tasks can be solved automatically. With the release of LLMs, more and more tasks can be automated. You can have intelligent systems such as OpenClaw, which automatically handle incoming requests or similar, and can automate a surprising amount of work.
I just urge you to have an open mindset to which tasks can be automated, and always keep it in the back of your mind, as we see coding agents become more and more intelligent and can automate more and more tasks.
Building a reusable tool
After you find a need for a tool, which you should be able to do several times a week at this point because of how effective coding agents are, it’s time to build a reusable tool.
When I build a reusable tool, I try to keep the following things in mind:
- It should be generalizable, so it should apply not only to your exact problem but also to some variations of it.
- It should be easily accessible to everyone (for example, through a shared GitHub repository)
- Everyone should be aware of it.
The last part can actually be trickier than you think. If you have built a lot of internal tooling, it’s impossible for every employee to keep track of all the tooling that is available.
That’s why I try to always update files such as CLAUDE.MD, AGENTS.MD, WARP.MD, or similar, to make sure the agents themselves are aware of the tooling.
The tooling should then, of course, be made available through a shared GitHub repository that every agent has access to and is aware of.
If you follow these steps, you’ve already gotten a long way into building a reusable, effective internal tool.
Another very important part that is a bit harder to achieve in my opinion, is to build a generalizable tool. Of course, you can build a tool that solves the exact problem you are working on right now, which is typically relatively simple.
However, the typically more challenging part is building a tooling that handles different variations of the problem and is more generalizable. It can be applied more broadly and by more people to any problem that is similar to your original problem.
The reason this is harder is that you don’t necessarily know the different variations of the problem that can come up. However, a simple fix to this is to prompt the LLM to build the internal tooling to think about the different variations that you can encounter and discuss them with the LLM.
I highly recommend using heavy usage of plan mode to discuss with LLM the problem you’re dealing with, how to solve it, and how to solve different variations of it to make your script as generalizable as possible. In many cases, simply prompting the LLM with this will have it create a better script that can be applied to more variations of the problem you’re dealing with and will make the tool way more reusable.
Specific tooling I have built
It’s great to know how to discover problems that require tooling and knowing how to build a tool. I also think it’s really important to know about some specific tooling to better understand how you can build tooling for yourself.
I believe the best tooling you can build is the one that’s hyper-customized to your needs, which in turn means that it’s hard to suggest to others what kind of tooling they should build. However, I will provide some examples of the tooling I have built as inspiration.
Examples:
- A bot that checks my emails and calendar and gives me a report daily. It also auto-reads emails that I’ve trained it not to care about, so that I only have to read the relevant emails.
- A GitHub review bot that notifies me every time I receive a review request, providing an explanation of the pull request. Described exactly how I want it described
- Scripts to check the processing of documents
The way I come up with these scripts is simply to think about what my main bottlenecks are or things I’m spending a lot of time on. For everything that I spend a lot of time on, I then start thinking about how this can be fully replaced with a tool. Or at least be made far more effective using a tool.
For some use cases, this will not be possible. Some things, like writing a particular piece of code or dealing with different stakeholders, are hard to outsource to an internal tool. However, for other use cases, it can be pretty easily simplified using a tool.
The tool that checks my email and calendar reports back to me, for example, is a simple OpenClaw model setup that has a cron job run daily before I come to work. This was quite a simple thing to come up with since I often spend time in the morning reading through emails or checking if there’s anything I need to prepare for my calendar. And I figured this could be more easily automated.
For the GitHub review bot, I also noticed that I started spending more and more time discovering and reviewing pull requests. Considering how much more code is being written with coding engines now, reviewing pull requests became a bigger part of my day than I preferred.
One simplification was to receive an alert on Slack every time I was tagged in the pull request and have a specialized summary generated for me describing the pull request. I also made the agent look for typical errors that I found in previous pull requests by scanning my GitHub review history. This setup already saved me around 50% of the time I spent reviewing poll requests, where some requests could be automatically approved, given it was a simple change and passed all my tests I set the agent up to run. While others, typically larger poll requests, I still had to review myself, but the review was more effective given I had a descriptive summary of the review request and knew what parts of the code I needed to look at.
Conclusion
In this article, I’ve discussed how to build effective tooling for internal use using Claude Code or any other coding agent. Coding agents have made it a lot simpler to build internal tooling to become even more effective. While you previously were constrained to only build internal tooling for super repetitive problems that took a lot of time, the bar has now dropped so that you can build internal tooling for less important problems. This has the incredible benefit that it will save you a vast amount of time. Every time you notice any problem that you think is likely to repeat, you can build internal tooling, make it available to everyone in your team, and thus make everyone more effective. Internal tooling has the potential to be incredibly powerful, and you should always keep in the back of your mind how we can solve a problem by building internal tooling that will handle different variations of the problem you’re solving.
👉 My free eBook and Webinar:
🚀 10x Your Engineering with LLMs (Free 3-Day Email Course)
📚 Get my free Vision Language Models ebook
💻 My webinar on Vision Language Models
👉 Find me on socials:
💌 Substack