How the AI Engineering From Scratch Curriculum Enforces the "Build It First, Then Use It" Learning Methodology

The rohitg00/ai-engineering-from-scratch repository enforces a "build it first, then use it" learning methodology through a rigid six-beat lesson pattern that requires students to implement algorithms from scratch before using production libraries like PyTorch or JAX.

The rohitg00/ai-engineering-from-scratch curriculum is an open-source educational repository designed to transform theoretical AI knowledge into engineering intuition. Unlike traditional courses that immediately introduce high-level frameworks, this curriculum structures every lesson around a mandatory "Build It → Use It" split, ensuring students understand the underlying mechanics before trusting black-box implementations.

The Six-Beat Lesson Pattern

Each lesson in the repository follows a strict anatomical structure defined in README.md (lines 99-101). The documentation explicitly states: "Every lesson follows six beats. The Build It / Use It split is the spine — you implement the algorithm from scratch first, then run the same thing through the production library."

This pattern enforces a standardized folder layout across all lessons:

• code/ — Contains the implementation files
• docs/en.md — Lesson documentation
• outputs/ — Reusable artifacts generated from the lesson

Philosophical Mandate in AGENTS.md

The AGENTS.md file (lines 9-12) reinforces this methodology with explicit philosophical guidance: "You write backprop, the tokenizer, the attention mechanism, and the agent loop by hand… Then you run the same operation through the production library so the framework stops being a black box. The 'Build It / Use It' split is the spine."

This mandate ensures that students cannot progress to framework-based solutions without first deriving the mathematical foundations manually.

Phase-by-Phase Scaffolding

The curriculum organizes content into 20 progressive phases, each building upon the previous implementation. Early phases like Math Foundations require raw Python implementations of linear algebra operations, while later phases systematically replace these hand-crafted pieces with optimized library calls.

This "replace-the-toy-with-the-real-thing" approach forces learners to:

1. Debug their own implementations
2. Understand computational complexity
3. Appreciate the optimizations provided by production frameworks

Explicit Build vs Use Lessons

The ROADMAP.md and lesson tables categorize content using explicit Build and Use labels. Build lessons—such as "Backpropagation from Scratch," "Mini-Framework," and "The Perceptron"—require coding algorithms from first principles.

Corresponding Use lessons demonstrate identical computations through production libraries. This pairing repeats across all major topics including computer vision, NLP, multimodal systems, and autonomous agents, ensuring no concept is learned solely through abstraction.

Reusable Artifacts and the Output Structure

After completing the Use stage, each lesson ships a reusable artifact stored under outputs/. These artifacts—whether prompts, skills, agents, or MCP servers—are generated from the hand-written implementation rather than the library version.

Because the artifact originates from manual code, students retain the ability to replace underlying libraries without losing higher-level functionality. This design cements the build-first mindset by proving that frameworks are interchangeable tools, not dependencies.

Code Comparison: Build It vs Use It

The curriculum enforces this split through concrete code examples. Consider the perceptron implementation across two lessons:

Build It: The raw implementation in phases/03-deep-learning-core/01-the-perceptron/code/perceptron.py requires manual derivation of the update rule:

# Build the perceptron from first principles

class Perceptron:
    def __init__(self, n_in):
        self.w = [0.0] * n_in      # weight vector

        self.b = 0.0                # bias

    def predict(self, x):
        # linear combination + step activation

        z = sum(wi * xi for wi, xi in zip(self.w, x)) + self.b
        return 1 if z >= 0 else 0

    def train(self, X, y, lr=0.1, epochs=10):
        for _ in range(epochs):
            for xi, yi in zip(X, y):
                pred = self.predict(xi)
                error = yi - pred
                # gradient descent update

                self.w = [wi + lr * error * xi_j for wi, xi_j in zip(self.w, xi)]
                self.b += lr * error

Use It: The corresponding PyTorch implementation in phases/03-deep-learning-core/11-intro-to-pytorch/code/main.py expresses the same algorithm through the production library:

import torch
import torch.nn as nn

# Re‑use the same model logic via the production library

class PerceptronTorch(nn.Module):
    def __init__(self, n_in):
        super().__init__()
        self.linear = nn.Linear(n_in, 1)

    def forward(self, x):
        # torch's Linear includes bias; apply step activation

        return (self.linear(x) >= 0).float()

# Example usage

model = PerceptronTorch(n_in=2)
criterion = nn.BCEWithLogitsLoss()
optimizer = torch.optim.SGD(model.parameters(), lr=0.1)

# dummy data

X = torch.tensor([[0., 0.], [1., 1.], [1., 0.], [0., 1.]])
y = torch.tensor([[0.], [1.], [1.], [0.]])

for epoch in range(10):
    optimizer.zero_grad()
    outputs = model(X)
    loss = criterion(outputs.squeeze(), y.squeeze())
    loss.backward()
    optimizer.step()

The first snippet forces explicit weight updates and activation logic, while the second demonstrates how the same algorithm scales through PyTorch's nn.Linear and autograd system.

Summary

• The rohitg00/ai-engineering-from-scratch curriculum enforces a "build it first, then use it" methodology through a six-beat lesson pattern documented in README.md (lines 99-101).
• AGENTS.md (lines 9-12) establishes the philosophical requirement to write algorithms like backpropagation and attention mechanisms by hand before using frameworks.
• 20 progressive phases scaffold learning by replacing hand-crafted implementations with library calls only after mastery.
• Explicit Build/Use labels in ROADMAP.md ensure every algorithm is implemented twice: once from scratch, once via production libraries.
• Standardized folder structures (code/, outputs/) guarantee that every lesson produces reusable artifacts derived from manual implementations rather than black-box dependencies.

Frequently Asked Questions

What is the "Build It First, Then Use It" learning methodology?

The "build it first, then use it" methodology is a pedagogical approach that requires learners to implement algorithms from scratch using raw Python or NumPy before using high-level frameworks like PyTorch or JAX. In the rohitg00/ai-engineering-from-scratch curriculum, this ensures students understand gradient descent, backpropagation, and attention mechanisms at the mathematical level before trusting abstract library calls.

How does the folder structure enforce the build-first approach?

Every lesson follows a rigid directory layout defined in LESSON_TEMPLATE.md, containing code/ for implementations, docs/en.md for theory, and outputs/ for artifacts. The README.md explicitly mandates that the "Build It / Use It split is the spine" of every lesson, preventing instructors or students from skipping the manual implementation phase.

Why does the curriculum use 20 phases instead of traditional chapters?

The 20-phase structure creates progressive scaffolding where each phase replaces previously hand-coded components with production library equivalents. This "replace-the-toy-with-the-real-thing" pattern ensures that by the time students use PyTorch's nn.Linear or JAX's grad, they have already debugged their own matrix multiplication and chain-rule implementations, making the framework's optimizations comprehensible rather than magical.

Can I skip the "Build" lessons and go straight to the "Use" lessons?

While technically possible, the curriculum architecture in AGENTS.md and ROADMAP.md discourages this by designing Build lessons as prerequisites for understanding Use lessons. The outputs/ artifacts are generated from the hand-written implementations, meaning skipping the build phase would leave you without the foundational intuition needed to debug or modify the production library code effectively.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}