The Viral "AI Engineer" Skills List Is Two Jobs, Not One

A skills list went viral three times

A list of roughly twenty-two things you should "learn" to be an AI engineer has been circling X for a month. The version making the rounds this week pulled 221.4K views. The same text, posted by the same author back on June 4, had already cleared 4,300 engagements ^[1], and other accounts have copied it word for word since. ^[2]

It's a genuinely good list. Harness engineering, context engineering, prompt versus semantic caching, KV cache eviction, prefill versus decode latency, continuous batching, paged attention, speculative decoding, the INT8/INT4/FP8/AWQ/GPTQ quantization alphabet, structured-output repair loops, function-calling reliability, agent loop budgets, model routing, RAG chunking and reranking, retrieval evals, golden sets and LLM-as-judge, observability, per-tenant cost attribution, prompt-injection defense, multi-tenant isolation. Nothing on it is filler.

So why does reading it make competent engineers feel like frauds? Because it quietly staples two different jobs together and calls the result one title.

Two jobs wearing one title

Split the list and it falls cleanly into two piles.

One pile is model-serving infrastructure: KV cache management and memory pressure, paged attention, continuous batching, prefill/decode optimization, the quantization formats, speculative decoding. This is the work of running inference servers. If you operate a vLLM or TGI fleet, it's your entire day.

The other pile is the application and agent layer: harness engineering, context engineering, RAG architecture, evals, agent guardrails, structured-output repair, observability, cost attribution, injection defense, multi-tenant isolation. This is the work of building products on top of models.

Here's the part the list elides: if you build on Claude, GPT, or any hosted endpoint, the entire serving pile is someone else's job. You will never tune paged attention. You won't choose between AWQ and GPTQ, because the provider already did, behind an API you can't see. Treating that half as a skills gap you're failing to close is how you spend a year reading GPU papers instead of fixing your retrieval grounding.

The two clusters also reward opposite instincts. Serving work is about squeezing a fixed model: throughput, latency, memory. Application work is about an unreliable model in an unreliable world: schema validation, fallback chains, eval regressions, runaway agents. You can be excellent at one and useless at the other, and most production teams only need one of them in-house.

What's actually scarce

The application half is where shipped products break, and it's underrepresented in how people talk about "AI engineer skills." Harness engineering — the scaffolding of retries, budgets, validation, and termination conditions around a model call — barely existed as a term a year ago. Context engineering, deciding what goes into the window and in what order, is now the difference between a demo and a system. Those are the skills with the shortest supply and the most direct line to whether your feature works, and they sit in the pile that requires no GPU at all.

The serving skills are scarce too, but scarce the way kernel engineering is scarce: a small number of people do it for everyone else.

What builders actually said

The sharpest reaction wasn't technical, it was a shrug at the sprawl. @emm0sh proposed retiring the whole framing in favor of "hard engineering" for disciplines that touch atoms, joking that "I'm hiring hard engineers" beats "I'm hiring engineers (no software please)." ^[3] It landed because the list reads, to a lot of people, as software work inflating itself into a hard science with a long enough vocabulary.

The other signal is the repost pattern itself. The same twenty-two lines went out from multiple accounts within weeks, the original far outperforming the copies. ^[2] A list that travels that way is functioning as identity signaling as much as advice. It performs because it lets the poster claim the territory and lets the reader feel either validated or behind, which is a different thing from teaching anyone what to build next.

Where I'd start

1. If you ship on a hosted API, learn the application pile first and ignore the serving pile until you self-host. Harness engineering, evals, and retrieval quality will move your product this quarter; quantization formats will not.
2. Build a golden set and an LLM-as-judge harness before you optimize anything. You can't tell if a change helped without one, and silent eval regression is the failure mode nobody catches in time.
3. Only cross into KV cache, batching, and quantization when you've decided to run your own inference. That decision is a cost and latency call, not a rite of passage.

The list is a good map of the production LLM stack. Just read it as two territories, and know which one you actually live in.

Sources

Primary source: diva (@divaagurlxw) on X

1. Tweet by @divaagurlxw — @divaagurlxw · community
2. Tweet by @ByteMohit — @ByteMohit · community
3. Tweet by @emm0sh — @emm0sh · community