04 — Shiny Object Syndrome¶

Failure class: Attention risk. The most seductive killer for smart, curious people. Modal timing: Continuous. Peak risk during Phase 2 (many kernel DSLs), Phase 5 (many quant methods), and any week a hot paper drops. Aggregate probability you get significantly pulled off-plan at least twice: ~90%. Probability this alone kills the plan: ~20% — rarely a single-cause death, but a common accelerant of every other vector.

The Scenario¶

It is Aug 5, 2027. You look at your GitHub and there are seven half-finished repos. A Mojo experiment from a weekend in month 4 (“just checking if it’s actually faster than Triton”). A TinyGrad fork you were going to submit a PR to, still on the same commit as month 5. Three different attempts at Rust CUDA bindings. A MLX experiment because you got excited about a benchmark on r/LocalLLaMA. A “looking into Jax” branch. A speculative-decoding-in-a-diffusion-LM experiment inspired by a paper that dropped in month 9.

What you don’t have: a finished SGEMM ladder. The mini-engine is at 40% and stalled. The Triton FA2 was in numerical-debug hell three months ago and you never went back to fix it.

You did not lack effort. You had, roughly, the same 500 hours the successful version of you would have had. You just spent them across nine surfaces instead of three.

This is the smart failure mode. The dumb failure mode is quitting. The smart failure mode is being interested in too many things at once.

Why Shiny Objects Are Especially Dangerous For You¶

Be honest with yourself. You are the kind of person who reads deeply and enjoys new tools. That is why you are attempting this roadmap. It is also exactly the personality that shiny object syndrome preys on. Curiosity is your engine; unchanneled curiosity is your engine’s failure mode.

Specifically, the inference engineering space in 2026–2027 is a shiny-object hellscape:

New Blackwell kernel every fortnight.
New quantization method every month.
New engine feature (spec decoding variant, disaggregation scheme, KV compression) every week.
Rust GPU story evolving quickly. Mojo taking shape. CuTe-DSL maturing. Tile DSLs multiplying.
MLX, TinyGrad, JAX, PyTorch all having interesting corners.
A hot paper on arXiv every single day.

Each one, individually, is genuinely interesting and plausibly relevant. That is what makes it hard — shiny objects are not fake; they are real gems. The problem is that you have 13 months and you can only polish so many.

The Specific Failure Scenarios¶

4.1 Mojo month / TinyGrad week / Rust GPU weekend (probability ~70% at least once)¶

A new language or framework demo blows your mind. You spend 2–4 weeks getting fluent in it, at the cost of 2–4 weeks of the actual roadmap. When you come back, you have: shallow familiarity with a niche tool, a stale sprint, and lost tempo. Repeat 3 times and you’ve lost a whole quarter.

Parry: The Curiosity Tax rule (below). Also: for languages, ask “what would I be able to do differently in a job study because I know this?” If the answer is “nothing yet, it’s not production yet,” the answer to the question is later.

4.2 Paper-of-the-week pivot (probability ~85%)¶

A banger paper drops (a new attention variant, a new MoE routing scheme, a new spec-decoding method). You spend a weekend reading, then two evenings re-implementing, then it doesn’t quite work, then you’re behind on the sprint. The paper is real; the timing is wrong.

Parry: The explore-later.md file (below). Almost every hot paper is either (a) not going to survive, (b) going to be absorbed by an engine within 6 months so you’ll learn it there anyway, or (c) genuinely important — in which case there will be a GPU MODE lecture on it in 90 days that will be a better use of your time than the paper’s raw arXiv PDF. Delayed engagement with a paper is almost always the correct engagement level.

4.3 Skipping the phase order (probability ~40%)¶

You get excited about distributed serving (Phase 6) at month 4, decide to “jump ahead a little”, and end up trying to understand DistServe without having built the single-GPU mini-engine yet. Nothing makes sense. You burn a month.

Parry: The seed doc’s stack ordering — kernels → attention → engines → quant → distributed → prod — is not aesthetic. It is causal. Each phase provides the vocabulary and the numerical intuition for the next. Distributed serving papers use “KV cache pages”, “prefix cache”, “paged attention” as assumed knowledge — you cannot skim them productively without Phase 4. Do not skip. The phase order is your friend.

4.4 The AMD / Apple detour (probability ~30%)¶

You get pulled into ROCm because MI300X is cool, or into MLX because r/LocalLLaMA loves Mac Studio inference. Two productive weeks vanish. You return to CUDA slightly stale.

Parry: The seed doc explicitly makes these awareness-level topics. Read one blog post per platform per phase. Do not implement. If a real project on AMD/Apple emerges post-Aug-2027, you will pick it up in three weeks flat because your CUDA fluency ports.

4.5 Reading vs building (probability ~60%)¶

This is the most insidious version. You are not chasing tools — you are chasing papers and lectures and blog posts. You feel productive because you are learning. But you are typing very little code. Eight weeks pass and your last committed benchmark script is from month 3.

Parry: Every sprint has one code deliverable, not one reading deliverable. Reading feeds coding; coding is the artifact. If a week ends with 30 papers read and no code committed, that week is a red flag regardless of how much you learned. Your portfolio ladder is code, not a paper list.

4.6 The Meta-Trap: reorganizing the roadmap instead of executing it (probability ~50%)¶

A sneaky one. You spend an evening “improving” the roadmap folder structure, rewriting phase descriptions, reformatting the retro template. This feels like roadmap work. It is roadmap avoidance. It is procrastination in productive clothing.

Parry: Roadmap edits happen only during scheduled quarterly reviews (end of each phase). Between reviews, the roadmap is frozen. If a change is truly urgent, note it in a changes-pending.md file and address it at the next review. Do not rewrite the plan on a Tuesday evening when what you really need to do is finish the SGEMM ladder.

Early Warning Signals¶

A repo you started this month that isn’t tied to the current phase’s deliverable.
The sentence “I’ll get back to X after I finish Y” appearing more than twice — where X is the sprint deliverable.
Your explore-later.md file (see below) has more than 15 items and you haven’t reviewed it in a month.
You start a session with “let me just check X” and finish it 90 minutes later without having touched the sprint work.
Any weekend spent on a tool not mentioned in the current phase’s README.
A GitHub star spree on a Sunday night (indicator of scattered attention).
You cannot state the current sprint’s deliverable in one sentence without checking your notes.

The cleanest single test: at any moment, if someone asks you “what are you shipping this sprint?”, you should be able to answer in ten words. If you cannot, you are in shiny-object drift.

The Curiosity Tax Rule¶

Here is the operational discipline in one sentence:

You get 2 hours per week for pure exploration. Anything beyond that comes out of the sprint deliverable, never out of sleep, exercise, or family.

More specifically:

The 2-hour budget is a real calendar block. Put it on your calendar. Friday evenings work well. This is when you read the hot paper, try the shiny tool, watch the GPU MODE lecture that isn’t on the current syllabus.
Overflow is a debit against the sprint, not a credit. If you spent 6 hours on Mojo this week, your sprint deliverable gets cut in half or slipped. You make the tradeoff visible in your retro. This kills the illusion that shiny-object work is free.
The 2-hour budget never rolls over. No stockpiling. “I didn’t explore for 3 weeks so this week I get 6 hours” is how you spend a whole weekend on TinyGrad. Fresh weekly budget.
Exception: paid conference attendance, official course modules, or an accountability partner’s request are not curiosity tax — they are structural.

The `explore-later.md` File¶

Create this file right now at 13_MONTH_ROADMAP/99_pre_mortem/explore-later.md. When a shiny object appears, log it there in this format:

## [Date] — [Object name] — [One-line why-interesting]

**Trigger:** where I encountered it
**Time cost if I chase it now:** ~X hours
**Phase where this is relevant:** Phase N (or "unclear")
**Verdict:** defer

The act of logging it and closing the tab satisfies the cognitive itch. The list gives you a real thing to review during your Friday 2-hour exploration slot. Most items on the list will look less exciting after a week — that is the signal that the plan’s phase-order was right.

Review the list at the end of each phase. Anything still exciting after that long is a real signal; anything faded is confirmed noise. This is a filter that costs almost nothing and prevents dozens of hours of misallocated attention.

The Genuine Game-Changer Test¶

Occasionally — rarely — a shiny object is not a distraction but a genuine game-changer that should alter the plan. How do you tell the difference?

Run this three-question test before pivoting more than one sprint on any new tool/paper/framework:

Is it in production somewhere? Not “in a demo,” not “in a paper,” but in a shipping system used by real users. If not, defer.
Does at least one respected voice in the field (a GPU MODE lecturer, a vLLM/SGLang maintainer, a top r/LocalLLaMA contributor) treat it as a must-know? Not “has heard of”, but “is using”. If not, defer.
Does it invalidate an invariant, or does it replace a tool? If it just replaces a tool (a new DSL, a new format), your invariant-focused plan absorbs it without changing structure — update the tool in the current phase and continue. Only if it invalidates an invariant (e.g., “attention is not the dominant kernel anymore”) do you need to actually rewrite the plan.

If 3/3 are yes, you have a legitimate pivot. Announce it in your public log, take a full week to integrate the change, and continue. If not 3/3, back to the sprint.

Over 13 months you will meet perhaps 1–2 genuine game-changers, and 20–30 things that felt like game-changers for 48 hours. The test lets you tell them apart.

Decision Tree¶

Special Case: The AI-News-Cycle Trap¶

The LLM industry has invented a new kind of shiny object: the narrative shiny object. “AGI is 6 months away.” “Model X made Y obsolete.” “On-prem is dead.” “Kernel work is dead.” These are not tools or papers — they are emotional weather, and they will try to convince you the plan is wrong once a month for 13 months.

Parry: Do not consume AI news daily. It is 95% noise, and the 5% signal you’d miss will find you anyway (via GPU MODE, via r/LocalLLaMA weekly digest, via vLLM release notes). Twitter/X specifically is a shiny-object generator that runs 24/7. If you must be on it, limit to 20 minutes/day, and never during a scheduled work block.

The roadmap does not need to be updated based on hype cycles. It needs to be updated based on invariants shifting (file 01), which happens quarterly, not daily.

Escalation Trigger¶

If you finish a phase without hitting its exit criterion, do not proceed to the next phase. This is the roadmap’s built-in shiny-object filter and it is sacred.

Signs you might be tempted to skip an exit criterion:

“I’ll come back to the SGEMM last two optimizations after I read the FlashAttention paper.”
“The mini-engine is basically done, the paged KV is just cleanup.”
“I understand the concept, actually writing the kernel is just typing.”

All three sentences are the same lie in different clothes. Understanding without shipping is not understanding. The exit criteria exist to force the closing of the loop. Every unclosed loop is a shiny-object seed — an incomplete project you’ll want to come back to later, at the cost of the next project.

When tempted to skip an exit criterion, ask: “in Aug 2027, will this half-finished thing be in my portfolio or in my regrets?” Regrets are unshipped work. Ship it.

The Bottom Line¶

You are curious. That is your strength and your risk. The Viking discipline you signed up for is not the discipline of never being curious; it is the discipline of scheduling your curiosity so that the sprint deliverable ships anyway. Two hours a week is enough to feed the curiosity without starving the mission. The explore-later.md file is the pressure valve. The phase order is the guardrail. Trust them.

In 13 months, the person with three finished projects and a dense understanding of one stack will out-hire the person with fifteen half-projects and a Wikipedia understanding of five stacks. The market will be brutally clear about which one it prefers. Be the first one.