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.

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.

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.

Cutting the steak up

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?

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.

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.

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.

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.

And you can just ask it

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.

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.

Renting someone else's brain

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.

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.

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.

Solving the previous problem

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.

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.

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 as central as ever. It's just moved from a pipeline you build to a capability you expose. Which is a tooling problem, and a much more interesting one.

Workflowing away

When models were weaker, you got better results by choreographing them carefully. A whole generation of libraries grew up to express that choreography, and some of them are genuinely well made. Capable models now build that workflow themselves, often better than the hand-rolled version, because they can see the whole problem at once.

This is the part that gets misread: it does not mean turning a capable model loose on production and heading to the pub. It means the workflow itself — the decomposition, the sequencing, the choice of approach — is no longer the thing worth obsessing over. The guardrails are more important: what tools the model can call, with which arguments, at what permission scope, validation, audit trail, halting conditions, and with what escalation when it all goes sideways.

The old approach scripted the workflow in detail and treated the guardrails as an afterthought — "and then the LLM does the right thing." The newer approach lets the model handle the workflow and spends the engineering effort on the edges of what it's allowed to do. The choreography is free now. The fence is where the work is.

Where’s the action

So: if you're an engineer wondering where to spend your finite professional-development hours, the answer is increasingly boring and increasingly right.

Learn the APIs properly, a working grasp of streaming, tool use, batching, caching, error modes, and cost behaviour. The people who understand the monthly bill keep their budgets.

Learn MCP: the right tools, schemas, and permission so that the model does less — cheaper and harder to break. It's the durable surface where capable models meet your systems, and it doesn't need a manicure every time a new model lands.

Learn hooks and interception. Where you validate, check, redirect, halt. The plumbing of guardrails. Unglamorous. Compounds.

Learn evaluation that matters to your problem: does your system fail safely on the inputs you actually care about? No leaderboard is trying to answer that for you.

Learn integration patterns that survive a model change. Timeouts, retries, idempotency, audit trails, observability — the dull discipline that keeps every other distributed system upright.

It’s been emotional

None of this is trending, and it's firmly a minority view. But read the people actually building, or just ask the model what works, and the same thing keeps surfacing: once the hype burns off, the new world looks a lot like the old one. The fundamentals didn't move. What changed is that we can build faster, for less — and hand the robots the dull work, which leaves the interesting part to us. That was always the good bit.