Ron was doing everything right.
He was prototyping. Dusting off technical skills he hadn't used in years. Building things and learning by doing. Exactly the kind of energy you want to see when you're trying to build an AI-capable organisation.
So when I noticed his Claude usage was unusually high, my first instinct wasn't to intervene. I assumed it was the cost of good work.
I was half right.
We ended up on a call about something else entirely, but the meeting topic came second. He walked me through his process.
He was using the Claude web interface for software development. Every iteration, he'd make changes locally, zip the project folder, upload it to Claude, describe what he wanted next, receive updated code, unzip, review, and repeat.
Functional. Entirely self-taught. And very, very expensive in terms of tokens consumed.
I've done something similar in the past - building a deck or an interactive tool the same way - and when I realised what it was costing, I wanted to understand what was actually happening under the hood.
Every time he uploaded that zip file, he was adding everything - all the existing code, all the unchanged files, the entire project state - back into the context window. Claude was reprocessing the whole thing from scratch. Each cycle, the context grew, the cost compounded, and the results got harder to interpret. But the task wasn't getting harder. The process was making it feel harder.
The fix was straightforward: switch to Claude Code. With direct file access, Claude doesn't need to reprocess what hasn't changed and context stays lean. Each interaction becomes surgical rather than sweeping. He made the switch and immediately found the outputs were more accurate and the whole thing was faster.
I'm not saying everyone should use Claude Code. But if you find yourself uploading, re-uploading, and looping repeatedly while getting increasingly worse results, a tool with direct file access is almost certainly the better choice for that kind of work.
That's not the interesting part of the story, though.
Claude Code makes usage more visible. You can see the cost of each interaction more clearly, which means you start thinking about each interaction more carefully.
Ron described a shift in how he was working. Instead of dumping a long, ambiguous brief and hoping the model would figure it out, he started breaking tasks down. One clear request at a time. Smaller prompts. Choosing the right model for the complexity of the job rather than defaulting to the most capable one for everything.
The quality of what he was building went up. His speed went up. His usage cost went down.
What changed wasn't the tools. What changed was the thinking behind the tools.
At OAG, we give everyone access to Claude and encourage broad usage. I believe you can't build AI capability through scarcity.
When usage is frictionless and cost is invisible, most people optimise for comfort rather than craft. They build habits that work well enough and never develop the underlying judgment.
Ron didn't set out to become a more deliberate AI practitioner. He became one because the constraints of a new tool forced him to think about what he was actually doing. What he needed from Claude. What Claude needed from him to do it well.
There's a reasonable argument that some level of friction - having to think about what a request costs before you make it, being prompted to choose the right tool for the job - produces better practitioners than an uncapped, invisible resource ever would.
This isn't an argument against giving people the tools they need. It's an argument for building genuine craft alongside access.
The specific lesson here is about matching the tool to the task. Claude's web interface is excellent for thinking through problems, exploring ideas, drafting, and iterating on text. It's not built for iterative software development, nor for working across multiple files simultaneously.
Claude Code and Cowork are. They were built for exactly the workflow Ron was approximating with zip files. Direct file access. Persistent context. Surgical edits. Faster, cheaper, and more accurate for that use case - not because it's more capable in some abstract sense, but because it's the right tool for the job.
The bigger lesson is about attention. Every interaction with an AI system is a decision about what you're asking for and what you need it to do. Most of the time, most of us aren't deliberate enough about either. Token limits, used thoughtfully, can be a useful forcing function - they make the invisible visible. And once you can see it, you can improve it.
Not "are people using AI?" Most of them are. The better question is: are people using it well?
The gap between someone who uses Claude and someone who uses Claude well is mostly a question of habits. The right habits - breaking tasks down, choosing the right tool, making one clear request at a time - aren't complicated. But they need something to prompt them.
Sometimes that something is a colleague asking the right question at the right moment.
Sometimes it's running out of tokens.
The Builders Blog is a practitioner-first publication on AI, aviation data, and building things that actually work. Subscribe to The Builders Blog LinkedIn newsletter here.