Last week, I went to a friend’s house for dinner. He asked me to grab a charger from his study.
I asked where it was. He said, “Just look around, you’ll find it.” I walked in and faced an entire wall of drawers. I had no idea which one to open. Eventually, he came in himself, scanned the room from the doorway, walked to the bottom-left third drawer, and pulled it out. Ten seconds, maybe less.
Here’s what struck me: he didn’t have a mental inventory. He didn’t “remember” the charger was in the bottom-left third drawer. He walked in, looked, walked over, opened. That’s it. No map. No index. No system.
The most efficient search engine in his house wasn’t a catalog — it was a pair of eyes and a willingness to just look.
I work in interaction design. My职业病 — my occupational reflex — was immediate: his process for finding things was smoother than most navigation systems I’ve designed for users.
Because in my field, there’s an article of faith that goes basically unquestioned: good information architecture is planned in advance. You build an app, the first thing you do is draw the IA diagram. Which feature goes under which tab. Where the secondary menus hang. How breadcrumbs trace back. You want to have everything categorized, labeled, and path-connected before the user even opens their mouth. The user shouldn’t have to “rummage.” The user should “arrive directly.”
I believed this for years.
And then the AI coding tools got popular a few years ago, and they used the exact same philosophy — just more extreme. Tools using RAG (Retrieval-Augmented Generation) would read through an entire codebase, slice it into chunks, compute vector embeddings for each piece, and store them in a specialized database. You ask a question, it matches your query against the database, and pulls out the most similar chunks. The entire space, pre-categorized and pre-indexed. Just like drawing an information architecture diagram.
But here’s the problem I’d been avoiding for years.
Information architecture is fixed at launch. But products never stop changing.
That beautiful IA diagram you drew? Three sprints in, it starts to warp. New features don’t fit anywhere clean. Old entry points you can’t bear to kill. Eventually your secondary menu has eight unrelated things crammed into it. Users are still navigating by your original taxonomy, but the stuff isn’t there anymore.
It’s exactly like those drawer labels your friend slapped on three months ago — the label says “cables,” but the cables moved out two reorganizations ago. The label stayed. The contents didn’t.
RAG has the identical disease. You renamed a function today; the index still remembers the old name. You deleted a file yesterday; the database chunk is still sitting there. It’s navigating with an expired map — and doing so with tremendous confidence.
So the team behind Claude Code did something that sounds almost reckless. They threw out the map.
In their early versions, they used standard RAG with a local vector database. Internal testing revealed that a much “dumber” approach worked better. No index. No embeddings. Just three brutally simple tools given to the AI: glob, grep, and read.
Glob narrows by category — “the charger is probably in one of these electronics drawers.” Grep rummages through them, trying different search terms if the first doesn’t hit. Read pulls out a promising result and checks if it’s the right one. Scope, search, confirm. Done.
My first reaction was the same as watching my friend open that drawer: Isn’t this just… going backwards?
But then I thought about it from a design perspective, and it clicked. In our field, there’s a term — “exploration cost” — and it’s always been treated as a dirty word. Making users explore is treated as a design failure. But I’d been thinking about it too narrowly.
Whether exploration is expensive depends entirely on whether the thing you’re exploring is stable.
Library books sit on shelves for a decade without moving. Pre-building a catalog for that? Absolutely worth it. But a product that ships every two weeks? A codebase that changes daily? You’re maintaining a map that’s wrong the moment you finish drawing it. And users getting lost following a wrong map is worse than users just looking around.
There’s another benefit to real-time search that I care about deeply as a designer: what you see is what exists, right now. The user opens a drawer and whatever’s inside is inside. There’s no menu item that promises something and delivers nothing. This “what you see is what you get” property — the thing we spend enormous effort trying to engineer — the AI achieved it by being dumb.
I thought about my own Obsidian knowledge base. Initially, I built it following the Karpathy wiki methodology: meticulously categorized, tags everywhere, every note filed into its proper place. The moment I finished, it felt incredible. Neat. Professional. Like a real knowledge base.
Within weeks, it fell apart. Most of what I note is scattered — half-thoughts, rants, unfinished conclusions. They don’t belong in tidy categories. Worse, with so many categories, I couldn’t find anything. I knew I’d written something, but couldn’t remember where I’d filed it. Seven folders deep and still nothing.
Organization isn’t the opposite of chaos. Sometimes it’s just a more respectable form of it.
I eventually tore most of that structure down. Minimal tags. Write first, file never. Search when I need something. The room is messier, but every note is something I tossed in myself, recently. I know where things are because I put them there, not because a system told me where they should be.
Now — does this mean information architecture and indexing are dead? Should we burn every taxonomy?
Of course not. I’d be firing myself.
Look at my phone. WeChat, Alipay, Camera — all on the first screen, never organized into folders. I use them constantly; one tap opens them; categorizing would add a step. But I also have a folder called “Government” with tax and housing fund apps sitting neatly inside. Why? Because I use them maybe twice a year, and when I need them, I need them fast. I don’t have time to swipe through screens.
So here’s the dividing line I now draw for myself, two questions: How fast does this thing change? And can the user afford to rummage in the moment?
Slow-changing and can’t-rummage? Build the structure. Help centers, compliance docs, anything that updates once a year but needs to be found in seconds when it matters. There, I still draw my IA diagrams without compromise.
Fast-changing or easy-to-rummage? Stop forcing it into rigid hierarchies. Make entry points more alive. Make search stronger. Let users — or AI — find things in real time. Your AI can scan the files you wrote this week in seconds. Why pre-build a database that’s always stale?
The most beautiful structure in the world becomes a lie the moment it stops matching reality.
That charger? My friend came in and got it himself. Not because his memory is good, but because he knows his own stuff — a glance is enough. No inventory needed.
But I noticed something. By his study door, there’s a small whiteboard. On it, in slightly faded marker: “Important Documents — Right Cabinet, Top Shelf.” The handwriting looks a few months old.
I stared at it for a couple of seconds. Didn’t say anything. Some things really do deserve to be written on the door.
The rest? Just open the drawer and look.
FAQ
Q: But doesn't RAG still work better for large, stable codebases?
A: Yes. If your codebase rarely changes and is massive, RAG's pre-built index saves real time. The argument is context-dependent: when the system evolves faster than the index can update, the index becomes a liability, not an asset.
Q: So should I stop organizing my knowledge base entirely?
A: Not entirely. Use structure for things that are stable and urgent (compliance docs, reference material). Use search-first for things that are fluid and exploratory (notes, drafts, fast-iterating code). The dividing line is: how fast does it change, and can you afford to look around when you need it?
Q: Isn't this just an excuse for lazy design?
A: It's the opposite. Designing a search experience that handles real-time, messy, evolving content well is harder than drawing a static taxonomy. The lazy move is building a beautiful structure once and pretending it stays accurate forever.