Realistic for a small team (no large GPU cluster):

1. Evaluation methodology (#7). Building better benchmarks, evaluation frameworks, or contamination-resistant tests doesn’t require huge compute. Can be highly impactful and well-suited to a small focused team.

2. Agent reliability (#6). Mostly about prompt engineering, tool design, error handling. A 5-person team can build agents and study failure modes systematically. Lots of unsolved problems.

3. On-device inference (#3). Quantization, distillation, kernel optimization. Can be done with consumer hardware. Real-world utility (run on phones, laptops). High demand.

4. Long-context reasoning research (#2 partial). If you use APIs (not training), you can study how existing frontier models handle long contexts. Build evals, probe failure modes, propose fixes via prompting/scaffolding.

5. Interpretability (#5 partial). Mechanistic interp on smaller models (7B-class) is accessible. Sparse autoencoders, circuit discovery, etc. Anthropic’s work is the leader; a small team can extend it.

6. Multimodality applications (#10 partial). Building specialized vision-language or audio applications doesn’t require frontier-scale models. Lots of unsolved domain-specific problems.

NOT realistic for a small team:

1. Alignment at scale (#1). Requires training and red-teaming frontier-class models. Resource-intensive.

2. Training efficiency (#4). Requires running large training experiments. Possible to study small-scale and extrapolate, but limited impact.

3. Safety at deployment (#8). Requires access to deployed model traffic, large-scale evaluation infrastructure.

4. New architectures (#9). Without compute to train at scale, hard to show your architecture wins.

Recommended focus:

For a 5-person team without a cluster: specialise in one of the application-or-tooling areas:

• Build a specialized agent framework for a vertical (legal research, medical info, code review).
• Build evaluation tools for a specific capability that the field doesn’t have good metrics for.
• Build a high-quality on-device deployment for a specific use case.
• Contribute to open-source interpretability tools (sparse autoencoders for 7B models).

The pattern: pick problems where compute isn’t the bottleneck — your team’s reasoning, engineering taste, and product judgment are. The “infrastructure-heavy” problems are best left to teams with infrastructure.

Month 1-2: Build foundational projects.

1. Reimplement a core transformer from scratch. nanoGPT-style: read the Karpathy lectures, build it yourself in PyTorch. Train on a small dataset. Understand every layer.
2. Implement FlashAttention from the paper. Either as a CUDA kernel or in Triton. Verify against PyTorch’s standard attention.
3. Reproduce a small published result. E.g., fine-tune Llama 3 8B on a specific task using LoRA. Document the process. Compare your numbers to the paper.

Output: 3 GitHub repos showing technical depth.

Month 3-4: Specialize and build a portfolio piece.

1. Pick a specialization. Either: inference optimization (vLLM-style), pretraining infrastructure, alignment/RLHF, or applied LLM products.
2. Build a portfolio piece. Something that demonstrates real competence. Examples: a new GGUF quantization implementation, a novel benchmark for a capability the field doesn’t measure well, a working agent system for a specific task, or an LLM-powered tool that solves a real problem.
3. Write a blog post about it. Documentation is half the value.

Output: 1 substantial portfolio piece with code + writing.

Month 5: Network and contribute.

1. Contribute to a high-profile open source project. vLLM, llama.cpp, transformers, lm-eval-harness. Even small PRs build reputation.
2. Attend a conference. NeurIPS, ICML, MLSys, or smaller workshops. Meet people. Have informed conversations.
3. Engage on Twitter/X. Follow researchers, share thoughtful work, comment substantively. This is where much of ML hiring intersects with reputation.

Output: a network of 10-20 people who know your work.

Month 6: Job search.

1. Apply broadly. Don’t aim ONLY for OpenAI/Anthropic. Mid-tier labs (Cohere, Mistral, AI2, MIT-Hopper, smaller groups at Meta/Google/Amazon) have great opportunities and faster interview processes.
2. Use your portfolio. Reference your projects in cover letters. Make your GitHub the headline of your resume.
3. Mock interview. ML interviews are different from generic engineering. Practice paper discussions, system design with ML twist, coding-with-PyTorch.
4. Negotiate. Senior engineers transitioning into ML often UNDERPAY for their experience. ML salaries are high; don’t sell yourself short.

Output: 2-3 offer letters.

The realistic outcome:

If executed well: a strong senior systems engineer can land a productive role at a mid-to-top ML lab within 6-9 months of focused work. The combination of systems expertise + applied ML knowledge is valuable; the field hasn’t yet caught up to the demand.

If you don’t have the patience for 6 months of building before applying: start with smaller roles (DevOps for ML teams, applied engineering at an LLM-using company) and grow from there. Network and build reputation; opportunities follow.

The trajectory is real. ML doesn’t require a 4-year CS PhD to be productive; it requires solid foundations + recent specific knowledge + a portfolio of work. This book gave you the first two; the third is on you.

The central thesis:

Modern ML, despite its mystique, is mostly systems engineering applied to well-understood math. A senior engineer with systems background and willingness to learn the specific math can become productive at the frontier of ML in 6-18 months. The “ML transition” isn’t a 4-year apprenticeship; it’s a focused study of a specific domain.

The supporting arguments:

1. The math is mostly classical. Linear algebra, calculus, probability, optimisation. None of it has fundamentally changed. The applications to neural nets and transformers are specific but they BUILD on classical foundations.
2. The systems half is applied computer science. Memory hierarchies, distributed primitives, compilers, quantization, profiling. These are all classical CS topics applied to a new domain.
3. The architectures are simpler than they look. A transformer is conceptually: embed → (attention + FFN) × L → unembed. Each piece is a few weeks of study at most. The complexity is in scale and tuning, not in fundamental ideas.
4. The systems engineering is what scales it. FlashAttention, ZeRO, PagedAttention, quantization — these are all systems contributions that turned theoretical models into things that train and serve at scale.
5. Reading research and staying current is a skill. The field publishes too much; you must learn to filter. Once you can read efficiently, you can stay current with relatively modest investment.

The one key insight:

YOU ALREADY KNOW MORE THAN YOU THINK.

If you have systems engineering background — debugging memory bugs, optimising distributed systems, working with hardware constraints — you have the foundational toolkit. Transformer architectures are a specific application of these skills, not a separate discipline.

The mystery of ML is largely manufactured. The papers are hard to read because of jargon and notation, not because the ideas are inherently complex. Strip away the formalisms, and most “modern ML” insights are: “we found a slightly better way to organise computation in a setting where memory and compute are imbalanced.”

Once you see this, the field becomes much more accessible. You stop being intimidated by the architecture papers. You start seeing the systems patterns. You can read FlashAttention 3 and recognise that it’s “online softmax + GPU tiling + dataflow optimisation.” You can read Chinchilla and recognise that it’s “scaling-law fitting to find the optimal compute allocation.”

The book’s goal was to build you up to this point. The math from first principles. The systems from existing knowledge. The architectures as applications. The current state of the art as a snapshot.

What you do with this knowledge is up to you.

You can build LLM products. You can join a frontier lab. You can write papers. You can contribute to open source. You can teach others.

What you cannot do anymore: claim that ML is some inaccessible art reserved for people with academic ML pedigrees. The field is younger than you think, the entry barriers are lower than they appear, and the demand for people with systems-plus-ML knowledge is very high.

Now go build something.