The topic Claude Code is the best productivity tool I’ve installed this year, and you… is currently the subject of lively discussion — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
Most people’s folder systems are a bit of a mess if we’re being honest. You know the feeling of going in there and finding a screenshot from four months ago you meant to do something with, or a note that trails off mid-sentence because past-you gave up. The bigger the folder gets, the less inviting it is to actually go in and sort out. And no productivity app I’ve tried has actually helped me stay on top of any of it for longer than a week or two.
Then I started using Claude Code, which isn’t really the tool most people would reach for here. I don’t write any code, but pointing Claude Code at a folder and letting it work directly on what’s inside changes the whole way I approach digital productivity. And it’s ended up being my most-used productivity tool this year without me really planning for that.
My productivity system has been a folder of plain text and markdown files for a while now, sitting locally without proprietary formats or subscriptions tied to it. I like it that way because nothing about it can disappear if a company pivots or a plan gets more expensive. What was always missing, though, was any kind of intelligence sitting on top of the folder itself, and that’s the piece Claude Code ended up giving me. The folder became the productivity tool thanks to Claude.
The thing that makes it feel different from every other Claude surface I’ve used is how it treats a folder. Regular Claude reads whatever you paste in. The filesystem connector opens one file at a time. Even Cowork tends to move through files as a sequence. Meanwhile, Claude Code holds the whole folder in its head as a system, which is different to all the other local workflows I’ve tried. It notices relationships between files, catches inconsistencies I wouldn’t spot on my own, and understands whatever weird structural convention I’ve set up as a rule of the folder, not just as a fact about one file inside it.
So the productivity payoff for me is that the folder system I already had gets to keep being the folder system I already had. Nothing gets migrated into a proprietary app. The structure lives in the folder, the intelligence lives in Claude Code, and the whole setup is the same either way.
Once Claude Code can see a whole folder as one thing, the next move is asking it to write down what’s actually in there. I’ve done this for countless of my folders now, and always end up with a single markdown file at the root that acts as an index of everything the folder contains. Not summaries exactly, more like a card per item with the details that would matter if I ever came back looking for something specific. One of the benefits of this is that I don’t have to go through the folders manually anymore to sort them – and an organized folder is still nice to have, but it doesn’t need to be organized for Claude to know what’s going on and query it.
One example is the folder that holds my local LLMs. Claude Code went through the actual metadata inside each GGUF file and built me a card for each one, covering architecture, params, quant, context length, use-case notes, and the little things I never remember to note down myself. Now I can ask questions like which of my models handle vision, or which one has the longest usable context, and get an answer grounded in what’s actually on my disk. This works for me because I have so many local models at this point, so it might not be useful to you, but it’s just an example of how useful the Claude layer is in any type of directory.
Also, an index like this remains honest, which has always been my problem with reference docs. I’d write one, use it for a week, forget to update it, then stop trusting it, then stop opening it. But when the folder is the source of truth and the index is downstream of it, I can just have Claude Code regenerate the whole thing whenever the folder changes. Same pattern works on a screenshot folder, a downloads folder, an article archive, literally anything that matters to you that you open every day.
Claude Code is faster when it remembers past decisions, not just the files in front of it.
The other thing I didn’t expect with this setup is that when a job is too big for Claude Code to just read through, it doesn’t try to muscle its way through it. It writes itself a small script, runs the script against the folder, and uses the output to do whatever I actually asked for. I don’t write the script, and I don’t run it myself, but the script exists in a “tools” folder afterwards, and if the folder ever changes, I can just have the same script re-run. Small thing, but it means the same work gets cheaper every time I repeat it.
Subagents are the same idea one level up, and they’re the newer piece of the puzzle for me since I haven’t started using them until recently. Instead of a script, Claude Code writes itself a whole separate specialist, a Claude session with its own instructions and its own dedicated context window that lives inside a “claude/agents” folder in whatever project I’m working on.
The marketing of subagents really confused me about what they actually were at first – something about “a team of experts”. When really all it is, is context isolation. The heavy reading happens in the subagent’s own window, and only the clean final result comes back into the main session. So my main conversation doesn’t get bloated with the raw files the subagent had to sift through to answer me. Everything else people say about agents, specialisation, tool restrictions, running things in parallel, is decoration on top of that one point.
My subagent is called model-picker and it reads through my local model library to tell me which one to load for whatever task I’m about to do, taking my 8GB VRAM into account so I don’t have to keep re-explaining that part. That’s it.
I went from avoiding Claude Code because I don’t know a thing about development to now relying on it every day, and still not knowing much about development. That’s because it’s a productivity tool in disguise. It took over admin work I was giving to Cowork, replaced a couple of paid apps I don’t miss, and now sits on top of my folder system doing the work I never really had the patience to do myself.