Navigating AI with paper maps - Adam
Adam
SubscribeSign in
Navigating AI with paper maps<br>Adam<br>May 21, 2026
Share
The advice economy around LLMs is such a strange thing to watch. Somewhere on LinkedIn this morning, someone with a job title that didn't exist eighteen months ago is sharing their hard-won secrets for better LLM output with forty thousand followers. They're not wrong, exactly. The techniques worked — for the model they had, when they found them. The trouble is that "what works" has a shelf life measured in model releases. The post keeps circulating long after it's relevant; the conference talk is accepted months before anyone delivers it.<br>Even the vendors' own training material runs a release or two behind their own models. Anthropic's official course videos were, as I wrote this, recorded on Claude Opus 3.x — which, in a fast-moving field, might as well be on punched cards. The fundamentals don't shift, but the models do and quickly.<br>This is the state of the AI conversation in 2026: a great deal of energy spent optimising out last year's bottlenecks, and very little spent on durable solutions. What's missing is AI solution architecture — knowing how to structure systems so they're durable, do the job and don't eat the budget. That's not in the courses, because it doesn't fit on a slide.<br>Cutting the steak up<br>Pick almost any prompt-engineering case study and run it through the only test that matters: are a couple of the right tools better than a swiss army knife?<br>The hackneyed meal-plan is an example. A user describes their dietary needs, peculiarities, and goals; the system produces a week of meals. The standard treatment is to grind out a multi-thousand-token prompt, build a training set, define a fitness function, and tune until the output stops embarrassing you. Days of work. A six-figure salary line item, PowerPoints, applause.<br>But what is it actually doing? Three things. Parsing misspelled text into structured parameters, solving a constraint-satisfaction problem and serving up the result as digestible verbiage.<br>The first part is a good candidate for an ML solution that even the browser can run; the selection part is good old-fashioned programming; and the last is where LLMs earn their keep. Doing all three with one prompt is easier at first flush, but it's not the right solution for much of the problem and doesn't scale.<br>The decomposition is just engineering. It only feels like a revelation because so much of the surrounding conversation hasn't caught up with it. And when you push back on it even a little, the very model that was helping with the prompt is more than capable of doing this too — you can even treat one stage as a working prototype for the next.<br>And you can just ask it<br>There's a content economy of people explaining, in 23-minute videos fronted by startled faces, how to use LLMs well. There are no likes to be had explaining that the model itself is better at this than they are.<br>Seriously, just ask the model, or several and compare. The advice will be current, specific to your stack, ready to answer follow-ups and doesn't ask you to smash the like button.<br>Renting someone else's brain<br>Effective prompt engineering is iterating over a string that seeds a particular version of a generalised model running on someone else's neural network until you get plausible answers to enough of your scenarios that you're happy to write the answer down in ink.<br>When the model changes, no problem — just repeat the whole process again, and hope you can do it before anyone notices the old prompt is broken. It's less of a system, more of a wish.<br>There are places it's the right call — prototypes, internal tools. But in production, where reliability and cost matter, the architecture is where humans come to rescue the robots, with or without lasers.<br>Solving the previous problem<br>Then there's the whole RAG apparatus. Vector databases, chunking strategies, reranking pipelines, embedding-model selection, retrieval evaluation harnesses. Conference talks, certifications, consultancies. This was a sensible response to a real constraint circa 2023: context windows were small, models forgot things, and you needed clever plumbing to get the right facts in front of the model at the right moment.<br>The constraint has eased. Context windows that would have seemed absurd two years ago are now routine, and caching takes the sting out of paying for them. What's dying isn't retrieval — it's the assumption that you must do the retrieving up front. Increasingly the better pattern is to give the model the tools to fetch its own context: a search call, a database query, a file read, behind a caching layer so it's cheap to do repeatedly. The model decides what it needs and goes and gets it, rather than you guessing in advance and stuffing a prompt.<br>That's the shift. Naive embedding-similarity over chunked PDFs is on the way out; the requirement underneath — the right context, in the right shape, at the right moment — is...