Where AI Should Sit in Your System
A pattern that keeps repeating across every project I build, and what it's taught me about where AI actually belongs in a system.
I was building a small project for myself: a petrol mileage calculator for my old car. Nothing fancy: snap a photo of the odometer, snap a photo of the fuel receipt after filling up, get your mileage. My first instinct was to just have Claude read both and log everything straight to a Google Sheet. Then a different question showed up: does AI even need to sit inside this system at all? I’d build it with AI, sure, but for everyday use, do I really need a live model call every single time, or can a script just handle it on its own? That question is what sent me down comparing two ways to build the same thing. The calculator didn’t matter. The choice between the two did.
Option One
Ask Claude to read the odometer photo and the fuel receipt, pull the trip km, compare it against the last reading, and keep a running log of mileage. Every single time. Forever.
It works. It’s also an app that calls an LLM on every use, for the life of the product. Fine for a hobby project I run myself a few times a week. Not fine the moment it has real users.
Option Two
Ask Claude to build the thing once: an iOS Shortcut that reads both photos on-device using Apple’s built-in text recognition, then hands the numbers to a small Google Apps Script that parses them and appends a row to a Sheet. After that, the AI’s job is done. Everything downstream runs on-device or inside Google’s own infrastructure, no model call, no token cost, for as long as I want to keep using it.
Same output. Completely different shape.
Illustrative, not measured data. The knee in the yellow line is the one-time cost of building the script.
There’s an old proverb that fits this better than anything I could come up with myself:
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
— Chinese proverb
Option one is Claude handing you a fish every time you’re hungry. Option two is Claude teaching your project to fish, once.
The Part That Stuck With Me
The gap between those two lines is invisible in a demo and very visible in a bill, the moment you try to scale past yourself.
Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.
— Antoine de Saint-Exupéry
That’s option two, applied to a tiny script. Strip out the live model call, and what’s left is the only thing that actually needed to run.
It’s not really the calculator that gave me this thought. It’s every project I’ve touched since I started working with Claude, at work and outside it, hitting the same fork: let it answer live, every time, or have it build something once that just runs. The calculator is just the smallest, cleanest version of that fork I had lying around. I still haven’t even built it. It’s sitting in my notes as a thought experiment, nothing more, but the question itself is genuinely how I think about architecting anything these days, calculator or not.
I keep coming back to it because it’s such a small example of a much bigger question I think about a lot: where in the system does AI actually need to sit? At build time, generating the tool? Or at run time, inside every single request? Those are two different products, two different cost structures, and, increasingly, two different skill sets.
The best way to predict the future is to invent it.
— Alan Kay
I don’t think AI is the answer to everything, even though it’s genuinely great at helping me build things fast. And I don’t think it’s coming for anyone’s job in some inevitable, sweeping way either. But I do feel like the engineers who get comfortable asking “does this need to be a live model call, or can it be a script the model helped me write once” are going to have a much easier time than the ones who never ask it. That’s not a rule. It’s just a feeling I have, watching myself build more of these small things.
If you’re thinking about something similar, or just want to compare notes on where you draw that line, find me on LinkedIn.