Windows Search has always been a hit or miss, and on a busy workday, a "miss" is the last thing you want to deal with. The search bar works well enough when you know exactly what you're looking for, but if you're trying to locate a file you half-remember, like the one you were editing last Thursday or the image file with "Xbox" somewhere in the name from a few weeks ago, you need all the luck and perseverance in the world to find it.

Curious to see if I could solve this problem by building a utility that finds files by the way I describe them in plain text, I decided to bring the problem statement to Claude. I'm now convinced that I have the best file explorer, simply because it doesn't offer to search using Bing or rely on me to remember whatever absurd file name I came up with.

What problem does it solve?

I describe the file, not the filename

The key issue with Windows Search isn't that it's completely broken. Problem is, it's half-baked, which is arguably worse when it comes to usability. Locating a file on the fly can usually feel like it demands recalling the exact name, or the folder it is situated in, or at a minimum, a distinctive string of characters it contains. That's a cognitive load the search utility is supposed to take away from the user, but in this case, it transfers it right back.

Usability pioneer Jakob Nielsen's sixth usability heuristic says the user should rely on recognition, rather than recall, and that captures the crux of the problem perfectly. A search interface should ideally minimize memory load by surfacing relevant information rather than expecting users to retrieve it independently. The Python-based utility I built (or rather, ideated) works exactly this way, and it was born out of a single fleeting thought, "If I were able to describe the file I'm looking for to an LLM with wider filesystem access, it would be able to conjure it effortlessly." With a basic skeletal structure, I took the proposition to Claude.

It's like a search engine for my PC

Haiku parses the query, SQL follows up

With the design philosophy out of the way, I'll explain how it works. I can point it at a large directory, let it index the contents, and then describe the file in plain English. It takes that description, passes it to Claude Haiku to extract the intent, and runs the query against a locally stored SQLite database, leading to the results appearing in just milliseconds.

One of the reasons why it works better than a usual keyword search is in how Haiku handles the query. Rather than scanning for sub-string matches, it uses plain-text description into a filter, which it uses to extract file type, date range, size constraints, and keywords as separate parameters, and then builds a targeted SQL query from those.

To illustrate how it works better, I ran two queries against the same indexed directory, which contains a spreadsheet and an image file of a publishing schedule. Searching for "publishing schedule" surfaces both files, as expected; however, searching for "publishing schedule, saved as an image" surfaces only the image.

For anyone who wants to build it without an API key, a local fallback parser handles basic queries without making any external calls, which covers straightforward descriptions well enough for most use-cases. I do find the Haiku-enabled version more interesting because it handles synonyms, paraphrasing, and multi-condition queries that the local parser can't.

It's lightning fast, usable, and it's just 30KB

820 lines worth of code with a life-changing proposition

The earlier version of this utility that I built had a speed problem. A full index of a real Windows directory took long enough to be counterproductive. The rewrite addressed this problem perfectly well.

On a directory of 87,000 files, the search run completes in around 2.6 seconds, and every subsequent run takes approximately 0.20 seconds or less. The utility also skips Windows system folders by default, including directories like Windows, Temp, and the Recycle Bin, which helps cut the effective file count on a typical C: drive by a significant margin. The entire utility is about 30KB and fits in 820 lines of Python. For something that completely outclasses Windows Search on natural language queries, that's a minuscule footprint for what it delivers.

The fix was always going to come from outside Microsoft

For a company that has effectively made AI and Copilot the centerpiece of its OS strategy, Microsoft does seem to have a rather curious blind spot when it comes to the usability problems that create friction for users on a daily basis. There's a reason why users are mass uninstalling and looking for ways to disable AI services on the platform, and a lot of it has to do with how it's deployed. A simple application of a usability heuristic combined with a lightweight language model would address a frustration millions of users continue to talk about every day, and all it needs is pointing AI at the right problem. Somehow, Microsoft, for all its investment, hasn't managed that yet.