I’ve developed a set of tasks where I typically leverage AI. Those are things like generating a test, explaining an unfamiliar corner of a codebase, or answering the little questions that used to cost me a browser tab and 15 minutes of an afternoon. But I’ve started to notice that other developers and I here at Atomic Object have started reaching for these tools for something a bit different, something that has slowly been becoming my favorite usage of AI: building developer tools.
The Workflows You Learn to Live With
You’re bound to run into some task on a project that feels unnecessarily painful. Whether it’s a workflow that requires bouncing between three terminal windows and a browser tab in a specific order, or a dataset where the only view available is a JSON blob long enough that your eyes glaze over halfway down. Or maybe it’s a multi-step manual process you run often enough to remember it exists, but not often enough to remember the steps.
Normally, you look for slight optimizations to help: A keyboard shortcut, a new shell alias, or a window layout that keeps all the things you need on-screen. What tends not to happen is building the thing that would actually solve it. Because as soon as you consider making a real tool out of it, you start running the math. How long will this take, and is that time better spent on the feature the client is actually paying for? These are developer-only features; they don’t show up in a demo. So more often than not, the answer is “not right now,” and the workflow stays tedious.
The Math Changed
But with AI at your disposal, that con gets a lot smaller.
Now, I can describe the functionality I want in a few sentences and hand it off, then switch back to project work while an agent takes off running with it. The cost isn’t “an afternoon of my attention.” It’s the couple of minutes it took to explain what I wanted, plus whatever tokens it burned.
Token cost is worth calling out as it can be a real dimension when balancing trade-offs of these generated tools. For me, it ends up being a mostly positive expense, as I never quite fully max out the token limit with my current subscription. These little detours are effectively free, and I’m getting more value out of a subscription I was already paying for than I was before (the midwesterner in me loves that part).
Letting Imagination Be the Constraint
What I find fascinating about this shift is there is no longer a limiting factor of speed. When the cost of building a tool was measured in hours, the question was always “is this worth it?”. Now the question is closer to “what would actually help?”. Your imagination becomes the limitation of what your workstation can do for you, rather than your calendar.
Now that the time is more flexible, it leaves room for a little back and forth to hone in on the tool’s capabilities. The first version of a tool is seldom the one you keep. You use it once, realize you want to filter by a second field, or that the output should be copyable, or that the whole thing would be more useful as a watch process than a one-off command. By leveraging AI to handle the task, each of those optimizations is a mere few sentences away.
If the tool turns out to be genuinely useful, it doesn’t have to stay only yours. Sharing the tool around the team can allow the whole group to work more effectively. Additionally, if the whole team follows this practice, you can end up with a pretty awesome suite of apps/tools that makes the job feel that much better.
Being Wrong Gets Cheaper
Granted, there will be times you build a tool, and it just isn’t as useful as you thought it would be. The workflow it optimized wasn’t actually the slow part. Or you only needed it for the one task that prompted it. Before, there would be this sense of guilt of having spent iterations on something that didn’t pan out. But as the tool only took a few minutes to put together, that sense of guilt is essentially gone. A tool that gets used twice and abandoned is a fine outcome at that price. Being able to be wrong cheaply means you determine which tools are worth keeping, instead of guessing which ones are worth building.
A Tool for Making Tools
Using AI as a tool is great, but using AI as a tool to create specialized tools is even better.
This small reframe has changed what I consider a solvable problem during a project. The tedious workflow you’ve been quietly routing around for three months might be a few sentences away from disappearing.
If you’ve used AI this way before, I’d love to hear about it! Feel free to elevate some of your favorite examples to the community below. Maybe you’ll end up making someone’s workday a little easier.