Home › Blog › AGI Researcher Foundations — The Technical Stack
AGI Researcher Foundations · Article 1 of 11 🧰

The Technical Stack: What You Must Know to Start in AGI Research

Programming, frameworks, compute, data, and evaluation tooling — the complete, sourced technical bar for getting started in AI research or landing a role at a frontier or research lab, with real scenario walkthroughs, key papers, and courses to actually complete.

FL
FrontierAGI Team

Why Tooling Fluency Is a Prerequisite, Not a Differentiator

This is the first article in a new series — AGI Researcher Foundations — that goes deeper than the Researcher's Field Guide and Day in the Life articles already on this site. Those covered papers, labs, career paths, and daily rhythms. This series covers the actual knowledge base underneath all of that: the technical stack, the math, the core deep learning concepts, and the specialized foundations (generalization, RL, interpretability, alignment, world models, systems, and methodology) that every one of the researcher profiles in this series' Field Guide had to master before their work became notable.

This first article is deliberately the least glamorous: the programming languages, frameworks, compute options, and tooling every researcher uses daily. It's tempting to skip straight to "the interesting ideas" — generalization, alignment, world models — but every lab covered in the Research Frontier Map assumes this layer is already solid before a candidate is evaluated on ideas at all. Fluency here is table stakes, not a differentiator — but the absence of it is an instant disqualifier, which is exactly why it deserves a full article of its own.

A note on sourcing: Every course, paper, and tool below is linked to a real, verifiable source. Where a source's current 2026 status could not be independently confirmed (a couple of specific course pages), that uncertainty is flagged explicitly rather than presented as fact.
Python The near-universal research language across every lab in this series
70%+ Share of recent arXiv ML papers implemented in PyTorch
56 days Length of Meta's public OPT-175B training run, with ~35 manual restarts logged
1,000+ Free Cloud TPUs available to independent researchers via Google's TRC program
Part 1 — The Core Stack

Programming Foundations

Every profile in this series' Field Guide — from Sutskever to Neel Nanda to John Jumper — built their technical credibility on top of a small, consistent set of programming skills. None of them are exotic.

1
Python fluency, not just familiarity. This means comfort with NumPy-style vectorized array operations, object-oriented and functional patterns as used in ML codebases, and enough performance intuition to know when a Python loop needs to become a tensor operation instead.
2
C++/CUDA — situational, not universal. Research scientists proposing new architectures rarely write CUDA directly; distributed-systems and infra engineers (the roles covered in this series' Lane 1 team article) frequently do, especially at frontier labs optimizing custom kernels.
3
Linux and shell comfort. Nearly all training and research infrastructure runs on Linux; SSH into remote machines, tmux/screen for long-running jobs, and basic shell scripting are assumed baseline skills, not specialized ones.
4
Git at a research pace. Branching for parallel experiments, rebasing cleanly, and — critically — writing commit messages and PRs clear enough for a collaborator to understand an experimental change six months later.

Core ML Frameworks: PyTorch vs. JAX

The framework question is less a technical debate than a signal of which lab culture you're entering. PyTorch remains the dominant framework by raw volume — well over 70% of recent arXiv ML papers are implemented in it — and is the default at OpenAI, Meta, Mistral, and Cohere. JAX has a smaller but concentrated footprint, with notable adoption at Google DeepMind, Anthropic, Apple, and xAI, particularly for TPU-heavy training workloads where JAX's functional, compiler-first design (via XLA) gives more direct control over device placement and parallelism.

FrameworkWhere It DominatesWhy
PyTorchOpenAI, Meta, Mistral, Cohere; the vast majority of published research codeImperative, Pythonic, easiest to debug and prototype quickly — the default teaching framework across nearly every course in this article
JAXGoogle DeepMind, Anthropic, Apple, xAIFunctional/compiler-first design via XLA gives finer control over TPU parallelism and large-scale distributed training

The practical takeaway: learn PyTorch first — it's the common denominator across nearly every course and paper reproduction in this article — and pick up JAX specifically if you're targeting a DeepMind/Anthropic-style, TPU-centric research role, per the lab-specific patterns covered in this series' Field Guide.

The Research Engineering Stack

Beyond the modeling framework itself, a specific supporting stack shows up across nearly every research team covered in this series' "Inside an AGI Startup Team" articles.

Weights & Biases (experiment tracking) Hydra (config management) Ray (distributed compute orchestration) Hugging Face Transformers / Datasets DeepSpeed (ZeRO optimization, MoE, RLHF) Megatron-LM (tensor/pipeline parallelism) PyTorch FSDP2 (native sharded training) vLLM (inference serving)

For distributed training specifically, three approaches compete: DeepSpeed's ZeRO optimizer (used historically for models like BLOOM and MT-530B), NVIDIA's Megatron-LM for tensor and pipeline parallelism (often wrapped by DeepSpeed, NeMo, or vLLM's training paths), and PyTorch's own native FSDP2, which shipped in PyTorch 2.6 and increasingly competes directly with DeepSpeed's ZeRO-3 stage for teams that want to stay within the core PyTorch ecosystem rather than adding an external dependency. For inference and serving, vLLM has become the dominant engine via its PagedAttention design and continuous batching, and has expanded into RL training infrastructure as well — see its 2026 "vime" RL framework announcement.

Compute Literacy

Understanding what "training on 8xH100" actually means — cost, memory constraints, interconnect bandwidth — is itself a research skill, not just an operations detail. For someone starting out, several real, current options exist at very different price and reliability points.

OptionCost / AccessBest For
Google Colab / Kaggle NotebooksFree tier availableLearning, small-scale experiments — used directly in MIT's 6.S191 labs
TPU Research Cloud (TRC)Free access to 1,000+ Cloud TPUs, rolling applicationsIndependent researchers willing to publicly share resulting papers/code/blog posts — a genuinely underused option
Lambda Labs~$1.05-2.06/hr (A100 80GB), ~$2.99/hr (H100 SXM)Reliable, dedicated instances for short training runs
RunPod~$2.99/hr (H100 SXM), ~$0.34-0.69/hr (RTX 4090)Cheaper dedicated compute than Lambda for comparable hardware
Vast.aiMarketplace pricing from ~$0.17/hr; H100 SXM ~$2.13/hr median spotCheapest option, best for interruptible or short jobs — no reliability guarantee
University clustersVaries by institutionThe default for most published academic research; often the most cost-effective for those with access

Pricing sourced from Jarvis Labs' 2026 cloud GPU provider comparison and Spheron Network's RunPod vs. Lambda Labs comparison; confirm current rates directly before committing to a provider, since GPU spot pricing shifts frequently.

Data Engineering Basics

Data literacy is as important to research outcomes as modeling skill, a point emphasized throughout this series' coverage of Sutskever's own generalization thesis in the SSI investigation — data quality, not just model architecture, increasingly determines what a model can and cannot do.

1
Dataset formats and tokenization — understanding how raw text/image/audio data becomes model-ready tensors, including subword tokenization schemes (BPE, SentencePiece) that underpin every modern LLM.
2
Data pipeline construction — building reproducible, efficient data loading that doesn't become the bottleneck in a training run, using tools like Hugging Face Datasets or custom sharded loaders for large-scale training.
3
Data quality intuition — recognizing duplication, contamination (test data leaking into training), and distributional bias, all of which silently degrade results in ways that are much harder to debug than a code error.

Evaluation & Debugging Tooling

Eval methodology has become its own specialized discipline, as covered in the Frontier Map's "unclaimed territory" analysis. Two frameworks anchor this space, though their status has shifted recently:

1
Inspect AI (from the UK AI Security Institute, formerly AISI) — an open-source framework for building and running LLM evaluations, increasingly the default across the labs covered in this series. Verify the current canonical repository directly (github.com/UKGovernmentBEIS/inspect_ai) before building against it, as with any actively developed framework.
2
HELM (Stanford CRFM's Holistic Evaluation of Language Models) — a foundational eval benchmark suite, but entered maintenance mode as of June 1, 2026 per its own documentation. Treat it as a historical reference and methodology template rather than an actively growing benchmark going forward.
3
Logging and reproducibility discipline — every serious lab treats a failed-to-reproduce result as a process failure, not just a bad outcome; this means version-pinning dependencies, seeding randomness deliberately, and logging enough metadata to rerun any experiment exactly.

AI-Assisted Research Tooling

As documented in this series' Day in the Life article, AI coding tools are no longer optional convenience — they're part of the baseline stack. Claude Code and GitHub Copilot are used daily for infrastructure and tooling code; Goodfire's Silico platform (covered in the Lane 3 team article) shows the more advanced end of this trend, where an AI agent plans and runs its own research experiments. For a newcomer, the practical skill is knowing when to lean on AI-assisted coding for boilerplate and infrastructure, versus when a research result specifically requires your own from-scratch implementation to build real understanding — a distinction covered directly in the paper-reproduction scenario below.

Part 2 — Papers & Courses

Key Papers to Read First

These aren't the deep specialized papers covered in later articles in this series (those belong to the generalization, RL, interpretability, and alignment foundations articles) — these are the papers that establish the shared vocabulary the rest of the field assumes you already have.

PaperWhy It's FoundationalLink
Krizhevsky, Sutskever & Hinton — AlexNet (2012)Established deep learning as computer vision's dominant paradigm; the practical start of the modern deep-learning era, covered in this series' Field Guide profile of SutskeverPDF
He et al. — Deep Residual Learning (ResNet, 2015)Introduces residual connections, a building block used far beyond computer visionarXiv:1512.03385
Vaswani et al. — Attention Is All You Need (2017)Introduces the Transformer architecture underlying nearly every modern LLMarXiv:1706.03762
Brown et al. — GPT-3: Language Models Are Few-Shot Learners (2020)Demonstrates emergent few-shot capability from scale alone, reshaping the field's research agenda for yearsarXiv:2005.14165
Kaplan et al. — Scaling Laws for Neural Language Models (2020)The original empirical scaling-law paper, directly relevant to the scaling-vs-research debate covered in the SSI investigationarXiv:2001.08361
Hoffmann et al. — Chinchilla: Training Compute-Optimal LLMs (2022)Revised the field's understanding of the right data-to-parameter ratio, a direct rebuttal/refinement of the original scaling lawsarXiv:2203.15556
Christiano, Leike et al. — Deep RL from Human Preferences (2017)The foundational RLHF paper, covered in depth in this series' Field Guide profile of Jan LeikearXiv:1706.03741
Bai et al. — Constitutional AI (2022)Anthropic's principle-guided alignment method, succeeding pure RLHF — covered in the alignment foundations article later in this seriesarXiv:2212.08073
Hu et al. — LoRA: Low-Rank Adaptation (2021)The standard parameter-efficient fine-tuning method — essential for anyone working with limited computearXiv:2106.09685
Fedus, Zoph & Shazeer — Switch Transformer (2021)Canonical mixture-of-experts paper, directly relevant to modern frontier model architecturesarXiv:2101.03961

Courses to Complete

These are real, currently accessible courses — not a generic "learn ML" reading list. Where a course's current-year status couldn't be independently confirmed, that's flagged directly rather than presented as certain.

fast.ai — Practical Deep Learning for Coders
Free · 9 lessons · Jeremy Howard
Confirmed current and free. Uses PyTorch/fastai/Hugging Face, code-first rather than theory-first — the best starting point for someone who learns by building.
Karpathy — Neural Networks: Zero to Hero
Free · YouTube series
Builds from micrograd up to nanoGPT, entirely from first principles. Static since 2022 but still the standard reference for understanding what's actually happening inside a neural network.
MIT 6.S191 — Introduction to Deep Learning
Free · Confirmed active 2026 edition
Stanford CS231n — Deep Learning for Computer Vision
Free notes · Confirmed active through Spring 2025
Stanford CS224n — NLP with Deep Learning
Free · Active current site
The standard NLP-focused deep learning course, covering the language-modeling foundations underneath every LLM discussed in this series.
Berkeley CS285 — Deep Reinforcement Learning
Free · Confirmed active Spring 2026, taught by Sergey Levine
The deepest freely available RL course, directly relevant to this series' upcoming RL foundations article.
DeepLearning.AI — Deep Learning Specialization
Coursera · Andrew Ng · Confirmed live in 2026
The most widely completed structured deep learning curriculum, still enrolling at scale as of 2026.
DeepMind x UCL — Reinforcement Learning Course
Free · YouTube
A deep, lab-grade RL course. Caveat: no confirmed 2025/2026 refresh found — treat as an evergreen reference rather than an actively updated course.
Two courses could not be fully verified for this article: Stanford's CS25 (Transformers United) and CS230 (Deep Learning) are both historically real, well-regarded Stanford courses, but their current 2025/2026 URLs and offering status could not be independently confirmed during research for this piece. Check web.stanford.edu/class/cs25/ and cs230.stanford.edu directly before relying on them.
Part 3 — Real Scenarios

Real Scenario Walkthroughs

🔁Scenario A — Reproducing a Paper's Result From Scratch
Andrej Karpathy's nanoGPT is the canonical example of this exercise done right: a minimal, from-scratch reimplementation built explicitly to reproduce GPT-2's training and results, stripped of unnecessary abstraction so every line is understandable. A more advanced extension, beyond-nanogpt by Tanishq Kumar, bridges from nanoGPT's simplicity toward research-level techniques through annotated, from-scratch implementations of more advanced methods. The exercise of rebuilding a known result — not inventing something new — is one of the most reliable ways to convert textbook knowledge into working intuition.
The lesson: reproduction isn't busywork — it's how you discover the gap between "I understand the paper" and "I can actually make this work."
🖥️Scenario B — Debugging a Distributed Training Run That Silently Diverges
Meta AI's public OPT-175B training logbook is a remarkable, real, citable document: 114 pages covering 56 days of training on 992 A100 GPUs, including roughly 35 manual restarts caused by hardware failures, NCCL/InfiniBand communication errors, and silent training hangs. This is exactly the kind of distributed-systems debugging covered in this series' Lane 1 team article — and it shows, in granular real detail, that even a well-resourced frontier lab's training runs are dominated by infrastructure firefighting, not algorithmic novelty.
The lesson: the distributed-systems skill described earlier in this article isn't theoretical — it's the difference between a training run that completes in 56 days and one that never finishes at all.
⚖️Scenario C — Infra-Heavy vs. Research-Heavy Role Emphasis
2026 hiring trend data describes research engineering as having become the field's "volume role" — Research Scientist positions emphasize research direction and hypothesis generation (typically PhD-gated), while Research Engineer positions emphasize training infrastructure, ablations, and reproducibility. This maps directly onto this series' lane framework: a Lane 1 frontier-scale role will weight the distributed-training and systems skills from this article far more heavily than a Lane 3 narrow-research-bet role, which weights independent research judgment and mathematical depth more heavily — the same technical stack, applied with very different emphasis.
The lesson: "the technical stack" isn't one fixed bar — which parts of this article matter most depends entirely on which lane, from this series' Frontier Map, you're actually targeting.
🌟Scenario D — A Side Project That Got Someone Noticed
This series' Field Guide already covered Neel Nanda's path — a month of daily public blog posts that helped seed the mechanistic interpretability field. A second, verifiable example: Callum McDougall built ARENA (a widely used mechanistic interpretability training program), did substantial open-source interpretability work, went through Neel Nanda's MATS mentorship stream, and subsequently joined Anthropic's and later Google DeepMind's interpretability teams. Both cases share a pattern: public, visible technical work — not a credential alone — created the reputation that led directly to a role at a frontier lab.
The lesson: the tools and skills in this article matter most when applied to something visible — a reproduction, a blog series, an open-source tool — not when practiced privately alone.

Self-Assessment Checklist

1
Can you implement a basic neural network training loop in PyTorch without copying from a tutorial, including the forward pass, loss computation, backward pass, and optimizer step?
2
Have you reproduced at least one well-known result from scratch (even a small one, like nanoGPT's Shakespeare-character model)?
3
Can you read a paper's architecture diagram and translate it into working code, rather than only using someone else's implementation?
4
Have you run a training job on a remote GPU machine via SSH, including handling a job that needs to survive your connection dropping?
5
Do you know the difference between data parallelism, tensor parallelism, and pipeline parallelism, and roughly when each is used?
6
Have you set up experiment tracking (even just Weights & Biases on a personal project) rather than relying on manually saved logs?
7
Can you explain, to a non-technical person, what "training compute-optimal" means per the Chinchilla paper?
8
Have you published or shared any of your own technical work publicly — a repo, a blog post, a write-up — rather than keeping it entirely private?
If you can honestly check most of these boxes, the technical stack is no longer your bottleneck — the rest of this series (math, deep learning theory, and the specialized foundations) is where the real differentiation starts.

Each of these eight items gets its own deep dive — the why, the how, and sourced references and videos — in Article 2: The Self-Assessment Deep Dive.

What's Missing From This Article

1
CS25 and CS230's current 2026 status could not be confirmed — both are real, historically well-regarded Stanford courses, but this article could not verify a live current-year URL or offering for either during research.
2
The DeepMind x UCL RL course has no confirmed recent refresh — it remains a real and valuable resource, but should be treated as a static reference rather than an actively maintained course.
3
HELM's shift to maintenance mode (June 2026) changes its role from an actively growing benchmark to a historical methodology reference — a status change worth knowing before building new eval work directly on top of it.

Where This Series Goes Next

This article deliberately stayed at the tooling layer. Article 2 in this series takes the Self-Assessment Checklist above and goes deep on each item — the why behind it, a concrete how-to path with sourced tutorials and repos, and videos for each — before Article 3 moves to the mathematical foundations underneath everything covered here (linear algebra, probability, optimization, information theory). From there, the series builds through core deep learning concepts, generalization and learning theory, RL foundations, interpretability, alignment, world models, systems, and research methodology, before a final capstone article ties every foundational concept back into one unified map, cross-linked to this series' Frontier Map and Field Guide.

🎥 Recommended Videos

🧭 Closing — The Stack Is Learnable, the Judgment Isn't Yet

🎯 The Bottom Line
Everything in this article — Python, PyTorch or JAX, distributed training tools, compute access, eval frameworks — is learnable through free or low-cost courses and real, citable open-source projects; none of it requires an elite credential to access. What separates the researchers profiled throughout this series (Sutskever, Nanda, Jumper, McDougall) isn't that they had access to a different stack — it's that each one built something visible with it: a landmark paper, a public interpretability tool, a scientific discovery, an open training program. The rest of this series goes deeper into the concepts this stack is used to explore — but the stack itself, per every source in this article, is genuinely within reach for anyone willing to put in the reproduction work.