is incredibly effective at quickly build up recent applications. That is, in fact, super useful for any programming task, whether it’s working on an existing legacy application or a brand new codebase.
Nevertheless, from personal experience, I feel that coding agents akin to Claude Code are vastly more powerful on completely fresh code bases due to how effectively they’ll go from 0 to 1.
This ability to quickly construct an application is incredibly useful to make hyper-personalized products, akin to internal tooling. In this text, I’ll take you thru how I exploit Claude Code to quickly construct completely personalized applications, which previously would have taken weeks to construct but can now be inbuilt lower than an hour.
Why construct internal tooling
Internal tooling has all the time been useful. It’s typically built by engineers inside an organization to simplify repetitive processes. That is, in fact, super useful because it makes these repetitive processes far simpler because they’ll simply be run with a single script or similar. This has two primary advantages:
- You’ll be able to complete the method more effectively with internal tooling than without
- The interior tooling makes the handling deterministic in contrast to an engineer coming up with a custom solution to the issue each time
Nevertheless, it typically takes a while to construct this internal tooling (especially in case you don’t have access to a recording agent). This time has prevented you from constructing internal tooling on any task that isn’t repetitive enough or doesn’t take enough time.
Nevertheless, this game has completely modified with the discharge of Coding Agents. The associated fee of constructing internal tooling has come down drastically, which lets you construct much more internal tooling to turn out to be far simpler.
I’d argue that since the price of constructing internal tooling is so low, you need to definitely be spending time on constructing internal systems that could make you and others in your organization simpler. It’s also good at making processes more deterministic. If two different engineers were asked to resolve a task, they’d likely give you somewhat different solutions. Nevertheless, in case you have already got internal tooling to resolve this task, the result is of course deterministic since it’s handled by a bit of code. This increases the worth of internal tooling much more.
Methods to construct internal tooling
In case you’ve gotten this far, you hopefully know why you need to have internal tooling. It simply is a method to make you and others at your organization simpler, and make sure that cases are handled deterministically.
Nevertheless, you continue to have to know tips on how to construct internal tooling. I’ve split this section into two primary parts, which I consider are the pillars for constructing internal tooling:
- Finding where it is advisable to construct the tool
- Constructing a reusable tool that is well accessible to everyone and that everyone seems to be aware of. You’ll be able to often construct a single script to realize something, but making it reusable, generalizable, and available to everyone could be more of a challenge.
Finding a necessity for the tool
The first step is all the time find the necessity for a tool. You’ll be able to probably find this all over the place throughout your organization. It is best to essentially be in search of bottlenecks, processes that take essentially the most period of time and that hinder your growth. An internal tool must also be built for tasks which can be done repetitively.
If you could have a process that comes up time and time again, you need to definitely construct internal tooling for it. This could possibly be:
- Checking if document processing is finished
- Routinely routing customer requests to the best person
- Writing documentation in your API.
All of those are processes which can be typically repeated over and over per week and that you just don’t wish to do manually each time.
It is best to all the time be looking out for these sorts of tasks. Tasks that you just do repetitively, repeatedly, and tasks that a bit of software can easily solve. In fact, some tasks require a human touch. For instance, answering emails or responding to bug reports.
Nevertheless, you need to attempt to open your mind as much as what sort of tasks could be solved routinely. With the discharge of LLMs, increasingly tasks could be automated. You’ll be able to have intelligent systems akin to OpenClaw, which routinely handle incoming requests or similar, and may automate a surprising amount of labor.
I just urge you to have an open mindset to which tasks could be automated, and all the time keep it behind your mind, as we see coding agents turn out to be increasingly intelligent and may automate increasingly tasks.
Constructing a reusable tool
After you discover a necessity for a tool, which you need to find a way to do several times per week at this point due to how effective coding agents are, it’s time to construct a reusable tool.
After I construct a reusable tool, I attempt to keep the next things in mind:
- It ought to be generalizable, so it should apply not only to your exact problem but additionally to some variations of it.
- It ought to be easily accessible to everyone (for instance, through a shared GitHub repository)
- Everyone should pay attention to it.
The last part can actually be trickier than you’re thinking that. If you could have built lots of internal tooling, it’s not possible for each worker to maintain track of all of the tooling that is on the market.
That’s why I attempt to all the time update files akin to CLAUDE.MD, AGENTS.MD, WARP.MD, or similar, to make sure that the agents themselves are aware of the tooling.
The tooling should then, in fact, be made available through a shared GitHub repository that each agent has access to and is aware of.
In case you follow these steps, you’ve already gotten a great distance into constructing a reusable, effective internal tool.
One other very necessary part that could be a bit harder to realize in my view, is to construct a generalizable tool. In fact, you may construct a tool that solves the precise problem you’re working on without delay, which is usually relatively easy.
Nevertheless, the typically more difficult part is constructing a tooling that handles different variations of the issue and is more generalizable. It may be applied more broadly and by more people to any problem that is comparable to your original problem.
The rationale that is harder is that you just don’t necessarily know the several variations of the issue that may come up. Nevertheless, an easy fix to that is to prompt the LLM to construct the inner tooling to take into consideration the several variations which you can encounter and discuss them with the LLM.
I highly recommend using heavy usage of plan mode to confer with LLM the issue you’re coping with, tips on how to solve it, and tips on how to solve different variations of it to make your script as generalizable as possible. In lots of cases, simply prompting the LLM with this can have it create a greater script that could be applied to more variations of the issue you’re coping with and can make the tool far more reusable.
Specific tooling I actually have built
It’s great to know tips on how to discover problems that require tooling and knowing tips on how to construct a tool. I also think it’s really necessary to find out about some specific tooling to higher understand how you may construct tooling for yourself.
I consider the most effective tooling you may construct is the one which’s hyper-customized to your needs, which in turn implies that it’s hard to suggest to others what sort of tooling they need to construct. Nevertheless, I’ll provide some examples of the tooling I actually have built as inspiration.
Examples:
- A bot that checks my emails and calendar and offers me a report each day. It also auto-reads emails that I’ve trained it to not care about, in order that I only should read the relevant emails.
- A GitHub review bot that notifies me each time I receive a review request, providing a proof of the pull request. Described exactly how I would like it described
- Scripts to ascertain the processing of documents
The best way I give you these scripts is solely to take into consideration what my primary bottlenecks are or things I’m spending lots of time on. For every thing that I spend lots of time on, I then start fascinated about how this could be fully replaced with a tool. Or a minimum of be made far simpler using a tool.
For some use cases, this can not be possible. Some things, like writing a specific piece of code or coping with different stakeholders, are hard to outsource to an internal tool. Nevertheless, for other use cases, it may possibly be pretty easily simplified using a tool.
The tool that checks my email and calendar reports back to me, for instance, is an easy OpenClaw model setup that has a cron job run each day before I come to work. This was quite an easy thing to give you since I often spend time within the morning reading through emails or checking if there’s anything I want to organize for my calendar. And I figured this could possibly be more easily automated.
For the GitHub review bot, I also noticed that I began spending increasingly time discovering and reviewing pull requests. Considering how far more code is being written with coding engines now, reviewing pull requests became a much bigger a part of my day than I preferred.
One simplification was to receive an alert on Slack each time I used to be tagged within the pull request and have a specialized summary generated for me describing the pull request. I also made the agent search for typical errors that I discovered 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 possibly be routinely approved, given it was an easy change and passed all my tests I set the agent as much as run. While others, typically larger poll requests, I still needed to review myself, however the review was simpler given I had a descriptive summary of the review request and knew what parts of the code I needed to take a look at.
Conclusion
In this text, I’ve discussed tips on how to construct effective tooling for internal use using Claude Code or another coding agent. Coding agents have made it so much simpler to construct internal tooling to turn out to be even simpler. Whilst you previously were constrained to only construct internal tooling for super repetitive problems that took lots of time, the bar has now dropped so which you can construct internal tooling for less necessary problems. This has the incredible profit that it’ll prevent an unlimited period of time. Each time you notice any problem that you’re thinking that is more likely to repeat, you may construct internal tooling, make it available to everyone in your team, and thus make everyone simpler. Internal tooling has the potential to be incredibly powerful, and you need to all the time keep behind your mind how we will solve an issue by constructing internal tooling that can handle different variations of the issue 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
