Open Source Intelligence & Learning to Learn

There is an uncomfortable truth about technology education: most of what you need to know has never been inside a course. It is scattered across GitHub repositories, blog posts, research papers, Twitter threads, and Hacker News comments written by people solving real problems at 2 AM. The challenge is not access — everything is free, everything is open. The challenge is navigation. Knowing what to read, how to read it, and how to turn reading into understanding.

This chapter is about building that navigation system. Not a list of bookmarks — a practice. A way of engaging with the firehose of technical knowledge that makes you sharper every week instead of more overwhelmed.

Andrej Karpathy, former Director of AI at Tesla and one of the founding researchers at OpenAI, learns by building things from scratch — a neural network, a tokenizer, a GPT. Not by reading about them. By typing the code character by character until the mental model is not abstract but physical, something he can manipulate with his hands. Simon Willison, creator of Datasette and one of the original Django developers, learns by blogging everything — turning every experiment, every tool evaluation, every half-formed thought into a public post that forces precision. Chip Huyen, the author of Designing Machine Learning Systems, learns by writing the textbook that did not exist when she needed it.

These are not three personality types. They are three expressions of the same principle: you do not understand something until you have produced something with it. Reading is input. Building is proof.

Part 1: How to Read a GitHub Repository

A GitHub repository can contain thousands of files. Jumping in and reading code file by file is like reading a novel by starting at page 247. There is an order that works.

Step 1: README.md

The README is the front door. It tells you what the project does, how to install it, and how to use it. A good README answers three questions in the first paragraph: What is this? Who is it for? Why does it exist?

If the README is empty or confusing, that is a signal. Either the project is immature, or the maintainer does not prioritize documentation. Both are useful information.

Step 2: /src (or the Main Source Directory)

Look at the top-level directory structure. Don't open files yet. Read the folder names. In a well-organized project, folder names tell you the architecture:

/src
  /api          <- HTTP endpoints
  /models       <- Data structures
  /services     <- Business logic
  /utils        <- Shared helpers
  /middleware    <- Request processing pipeline
  /config       <- Settings and environment

This five-second scan tells you whether the project follows a layered architecture, a feature-based structure, or something domain-specific. It tells you where to look when you need to understand how a feature works.

Step 3: Entry Points

Find where the application starts. In a Node.js project, check package.json for the "main" or "scripts" field. In Python, look for main.py or app.py or the entry_points in setup.py. In Go, find func main(). The entry point is the root of the call tree — everything flows from there.

Step 4: Tests

Tests are the most underrated documentation in software. A test file tells you exactly how the code is supposed to behave — what inputs it expects, what outputs it produces, and what edge cases the developer was worried about.

// From the test file, you learn:
// - createUser expects an email and password
// - It returns a user object with an id
// - It throws an error if the email already exists
// - It hashes the password before storing

test('creates a user with hashed password', async () => {
  const user = await createUser('test@email.com', 'secret123')
  expect(user.id).toBeDefined()
  expect(user.password).not.toBe('secret123')
})

test('rejects duplicate email', async () => {
  await createUser('test@email.com', 'secret123')
  await expect(createUser('test@email.com', 'other'))
    .rejects.toThrow('Email already exists')
})

You now understand the createUser function better than you would by reading its implementation — because you know what matters to the people who built it.

Step 5: Issues and Pull Requests

Issues tell you what is broken and what is requested. Sort by "most commented" to find the contentious design decisions. Sort by "recently updated" to understand current priorities.

Pull Requests (PRs) are where the real learning happens. A PR shows you: the problem (the description), the solution (the code changes), the reasoning (the discussion in comments), and the alternatives considered (what reviewers pushed back on). Reading a well-discussed PR is like attending a design meeting for the project.

Step 6: CONTRIBUTING.md

If you want to understand how a project is governed — how decisions are made, what the code review process looks like, what the coding standards are — read the contributing guide. For large open-source projects (React, Kubernetes, Linux), this document reveals the social architecture of the project, which is often more complex than the technical architecture.

+---------------------------------------------------------+
|           ORDER OF READING A GITHUB REPO                |
+---------------------------------------------------------+
|                                                         |
|  1. README.md          "What is this?"                  |
|       |                                                 |
|  2. Directory structure "How is it organized?"          |
|       |                                                 |
|  3. Entry point         "Where does it start?"          |
|       |                                                 |
|  4. Tests               "How is it supposed to behave?" |
|       |                                                 |
|  5. Issues / PRs        "What are the debates?"         |
|       |                                                 |
|  6. CONTRIBUTING.md      "How is it governed?"          |
|                                                         |
+---------------------------------------------------------+

Part 2: How to Read Documentation

Technical documentation is written for reference, not for learning. This distinction trips up every beginner who tries to learn React by reading the API reference and ends up drowning in useImperativeHandle when all they need is useState.

The Reading Order

1. "Getting Started" or "Tutorial": This is the on-ramp. Follow it step by step. Build the example project. Do not skip ahead. The tutorial is written in a specific order because concepts build on each other.

2. "Guides" or "How-To": These are task-oriented. "How to handle authentication." "How to deploy to production." Read these when you have a specific goal.

3. "Concepts" or "Architecture": These explain the mental model — why the tool works the way it does. Read these after you've built something, when you're ready to understand the deeper design decisions.

4. "API Reference": This is the dictionary. You look things up here. You do not read it sequentially. When you need to know what parameters fetch() accepts, this is where you go.

+--------------------------------------------------+
|        DOCUMENTATION READING ORDER               |
+--------------------------------------------------+
|                                                   |
|  STAGE 1: "I'm new"                              |
|  Read: Getting Started / Tutorial                 |
|  Goal: Get something running                      |
|                                                   |
|  STAGE 2: "I'm building"                          |
|  Read: Guides / How-To                            |
|  Goal: Solve specific problems                    |
|                                                   |
|  STAGE 3: "I'm debugging"                         |
|  Read: Concepts / Architecture                    |
|  Goal: Understand WHY it works this way           |
|                                                   |
|  STAGE 4: "I need a specific answer"              |
|  Read: API Reference                              |
|  Goal: Look up a function signature or parameter  |
|                                                   |
+--------------------------------------------------+

Reading Documentation for AI Tools

AI documentation is different from traditional software documentation because the tools are probabilistic — they don't always produce the same output for the same input. When evaluating AI documentation, look for:

• Model cards: A structured document describing a model's capabilities, limitations, training data, and intended use. Good model cards are honest about what the model cannot do.
• Prompt engineering guides: How the developer intends for the model to be used. These contain the tested patterns and known failure modes.
• Rate limits and pricing: Buried in the docs, critical for your architecture. The difference between 60 requests per minute and 3,000 requests per minute is the difference between a demo and a product.
• Data handling policies: Where does your data go? Is it used for training? This belongs in Part 4's security concerns but you find the answer in the documentation.

Part 3: How to Read a Research Paper

Research papers are written for other researchers. They are dense, jargon-heavy, and assume a level of background knowledge that most practitioners don't have. The good news: you don't need to read them like a researcher.

The Reading Order (Not Cover to Cover)

1. Abstract: A 200-word summary of the entire paper. Read this first. If it is not relevant to your problem, stop here. You have saved yourself 45 minutes.

2. Figures and tables: Scroll through the paper looking only at figures, tables, and their captions. Researchers spend enormous effort on figures. A good figure can convey the core idea faster than 10 pages of text. The "Attention Is All You Need" paper (the Transformer architecture that powers every modern LLM) has a single figure — the Transformer diagram — that has been reproduced in thousands of presentations because it captures the entire architecture visually.

3. Introduction (last paragraph): The last paragraph of the introduction typically contains the paper's main contributions — a numbered list of "In this paper, we..." statements. This tells you exactly what the authors believe is new and important.

4. Conclusion: The conclusion summarizes findings and often includes honest limitations — what didn't work, what remains unsolved. This section is more candid than the abstract.

5. Methodology: Read this only if you need to implement or reproduce the paper's approach. It is the most technical and detailed section.

6. Related work: This section is a curated reading list. If the paper is relevant to you, the papers it cites are likely relevant too. Follow the citation trail.

Part 4: How to Evaluate AI Tools

A new AI tool launches every day. Each one claims to be revolutionary. Most are wrappers around the same underlying models with different prompts and a fresh coat of paint. Here is how to cut through the noise.

Don't Trust Benchmarks Alone

Benchmarks are standardized tests used to compare models. "GPT-4 scores 90% on MMLU" sounds impressive. But MMLU (Massive Multitask Language Understanding — a benchmark consisting of multiple-choice questions across 57 subjects) measures performance on academic multiple-choice questions. Your product might need the model to generate SQL queries, summarize customer support tickets, or write marketing copy. Benchmark performance on one task tells you very little about performance on a different task.

The Evaluation Framework

+--------------------------------------------------+
|        AI TOOL EVALUATION FRAMEWORK              |
+--------------------------------------------------+
|                                                   |
|  1. Define YOUR use case precisely                |
|     Not "text generation" but "generate 3-line    |
|     product descriptions for electronics under    |
|     ₹5000 in Hindi and English"                   |
|                                                   |
|  2. Create a test set from REAL data              |
|     20-50 examples from your actual workflow      |
|     Include edge cases and failure modes          |
|                                                   |
|  3. Run the same test set on every tool           |
|     Same prompts, same data, same evaluation      |
|     criteria. Control the variables.              |
|                                                   |
|  4. Measure what matters to YOUR business         |
|     Latency (response time)                       |
|     Cost per request                              |
|     Accuracy on YOUR domain                       |
|     Failure modes (how does it fail?)             |
|                                                   |
|  5. Check the unsexy stuff                        |
|     Rate limits, uptime SLA, data policies,       |
|     pricing at scale, vendor lock-in              |
+--------------------------------------------------+

The tool that wins benchmarks is not necessarily the tool that wins in your product. Evaluate on your data, your use case, your budget.

Part 5: The Firehose — Filtering Signal from Noise

The technology ecosystem produces more content daily than any person can consume in a lifetime. Twitter/X, Hacker News, r/programming, YouTube, newsletters, podcasts — the volume is paralyzing. The solution is not to consume more. It is to build a filter.

The Sources

Hacker News (news.ycombinator.com): The comment section is often more valuable than the linked article. Engineers and founders discuss tradeoffs, share war stories, and point out flaws in the original post. Filter by reading only posts with 100+ comments — that threshold tends to correlate with genuinely significant or controversial topics.

Twitter/X: Follow builders, not commentators. Follow people who ship code, publish research, and write postmortems. Unfollow anyone whose content is primarily reactions to other people's content. A useful heuristic: if someone's feed is 80% original work and 20% commentary, they are probably worth following. If the ratio is inverted, they are amplifying noise.

r/programming and r/machinelearning: Useful for discovering tools and papers. The voting system surfaces relevant content, but be aware of recency bias — the newest hot take displaces the thoughtful long-form post.

Newsletters: Curated newsletters are the highest signal-to-noise ratio source. Someone else has already filtered the firehose for you. A few durable ones: TLDR, The Batch (Andrew Ng), Import AI (Jack Clark), Pointer (for engineering leadership). Subscribe to three, not thirty.

The Filter

Practical filtering rules:

1. Set a time box: 30 minutes per day, maximum. If something is truly important, it will appear in multiple sources over multiple days. You will not miss it.
2. Favor depth over breadth: One article read carefully beats ten articles skimmed. If a post makes you think "I should try this," stop reading and go try it.
3. Save, don't consume: When you find something that looks valuable but you don't have time, save it to a read-later tool (Pocket, Raindrop, a simple text file). Review your saved items weekly. You'll find that 70% of what seemed urgent a week ago no longer matters.
4. Follow the trail, not the feed: When you find a genuinely excellent article, read everything else that person has written. Follow their references. One great author leads to ten more. This is higher-quality discovery than any algorithmic feed.

Part 6: Building a Learning System

Consuming information is not learning. Learning requires processing — turning raw input into structured understanding that you can retrieve and apply later. This is where most people fail. They read voraciously and retain almost nothing.

Note-Taking as Thinking

Obsidian (a note-taking application that stores notes as plain text Markdown files on your computer) is the tool this book recommends, but the tool matters less than the practice. The practice has three components:

1. Capture: When you encounter an idea worth keeping, write it in your own words. Not a copy-paste. Not a highlight. A restatement that proves you processed it. If you cannot restate it, you do not yet understand it.

2. Connect: Link new notes to existing notes. "This concept from the database chapter relates to this principle from the security chapter." The connections — not the individual notes — are where insight lives.

3. Retrieve: Notes you never revisit are notes you never wrote. Schedule a weekly review. Resurface old notes. Ask: "Has my understanding changed? Can I now connect this to something I've learned since?"

Spaced Repetition

Spaced repetition is a learning technique based on the finding that memory decays exponentially — you forget most of what you learn within 48 hours — but reviewing material at increasing intervals dramatically improves long-term retention. Andy Matuschak, a researcher and designer who worked on the Khan Academy learning platform and iOS at Apple, has written extensively about this: "People who read a lot but don't take notes or practice retrieval are essentially volunteering for amnesia."

The practical implementation: when you learn a concept, create a flashcard. Review it the next day. Then three days later. Then a week later. Then a month. Each successful review pushes the next review further out. Each failure resets the interval. Tools like Anki automate this scheduling.

You don't need flashcards for everything. Reserve spaced repetition for foundational knowledge — the kind of facts and concepts that unlock understanding of everything built on top of them. The SQL JOIN syntax. The HTTP status codes. The difference between authentication and authorization. The Big O notation for common data structures. These are the building blocks that make every future learning session faster.

Building for Understanding

Simon Willison takes a different approach. He builds small tools, deploys them publicly, and blogs about the process. Each blog post forces him to articulate his understanding. Writing is thinking — the sentence that doesn't flow reveals the concept that isn't clear. He has published thousands of blog posts, and his archive is one of the best technical resources on the internet — not because he set out to create a resource, but because he set out to understand things and writing was his medium for understanding.

Chip Huyen wrote Designing Machine Learning Systems because no book existed that bridged the gap between ML research and ML engineering in production. The book is extraordinary because it was born from the frustration of not finding what she needed — she wrote the thing she wished she had when she was learning.

The pattern across all three: production is the proof of understanding. Karpathy produces code. Willison produces blog posts. Huyen produces a textbook. The format varies. The principle is constant.

Part 7: The "Learn by Building" Philosophy

This is the core thesis of this book, but it bears explicit articulation in this chapter because everything else — reading repos, reading papers, reading documentation — is in service of this single idea.

You do not understand a database until you have corrupted one and recovered it. You do not understand authentication until you have been locked out of your own system. You do not understand deployment until you have pushed a bug to production and rolled it back. You do not understand AI until you have watched a model confidently generate nonsense and had to figure out why.

Paul Graham, co-founder of Y Combinator and author of some of the most influential essays in startup culture, writes in "How to Do Great Work": "The way to figure out what to work on is to work. If you're not sure what to work on, make something." This is not motivational advice. It is epistemological — a claim about how knowledge is created. Working on something generates the questions that reading alone never surfaces.

The Build Cycle

+---------------------------------------------------+
|              THE BUILD CYCLE                       |
+---------------------------------------------------+
|                                                    |
|  1. ENCOUNTER: Read, watch, discuss                |
|     "This concept seems important"                 |
|          |                                         |
|  2. BUILD: Implement the smallest version          |
|     "Let me make this work"                        |
|          |                                         |
|  3. BREAK: Push it until it fails                  |
|     "What are the edge cases? What if I..."        |
|          |                                         |
|  4. FIX: Debug, research, ask for help             |
|     "Oh, THAT'S why it works that way"             |
|          |                                         |
|  5. ARTICULATE: Write it down, explain to someone  |
|     "Here's what I learned and here's proof"       |
|          |                                         |
|  [Return to Step 1 with deeper questions]          |
|                                                    |
+---------------------------------------------------+

Step 3 is where most people stop. Building the working version feels like completion. It is not. The breaking reveals the understanding gaps. A database that works for 10 records might fail at 10,000. An authentication system that works in development might leak tokens in production. A prompt that works for English might hallucinate in Hindi.

Step 5 is where most people never start. Articulating what you learned — in a blog post, a note, a conversation with a colleague — forces a level of clarity that silent understanding never achieves. If you cannot explain it, some part of your understanding is an illusion.

What to Build

If you have read this far in this book, you have enough knowledge to build:

• A full-stack application with authentication, a database, and a deployed frontend
• An AI-powered feature (chatbot, summarizer, classifier) with prompt engineering and guardrails
• A data pipeline that collects, cleans, and visualizes information
• An API that other developers can integrate with

Pick one that solves a problem you personally have. The motivation difference between building a toy project and building something you will use is the difference between a homework assignment and a mission. Build the thing you wish existed. That is how every project in this book's bibliography started.

/Learning
  /Concepts      <- Technical ideas, definitions, mental models
  /Projects      <- Notes on what you build and what you learn
  /Papers        <- Summaries of research papers
  /People        <- Notes on thinkers whose work you follow
  /Questions     <- Things you don't yet understand

Chapter endnotes

[1] Andrej Karpathy's "micrograd" is available at https://github.com/karpathy/micrograd. His accompanying YouTube tutorial, "The spelled-out intro to neural networks and backpropagation," has been viewed over 2 million times as of March 2026. Karpathy's broader educational work, including "nanoGPT" and his "Neural Networks: Zero to Hero" series, exemplifies the learn-by-building approach at the highest level of technical sophistication.

[2] Simon Willison's blog at https://simonwillison.net/ contains thousands of posts spanning from Django's early development to modern AI tooling. His "TIL" (Today I Learned) repository on GitHub is a particularly good model for structured learning documentation.

[3] Chip Huyen's Designing Machine Learning Systems (O'Reilly, 2022) bridges the gap between ML research and production engineering. Her blog at https://huyenchip.com/ documents her learning process and has become a key resource for ML engineers.

[4] Paul Graham's essays are collected at https://paulgraham.com/. "How to Do Great Work" (July 2023) synthesizes his thinking on productivity, curiosity, and the relationship between working and discovering what to work on.

[5] Andy Matuschak's work on spaced repetition and learning is documented at https://andymatuschak.org/. His collaboration with Michael Nielsen produced "Quantum Computing for the Very Curious" (2019), which embedded spaced repetition directly into a technical essay — an experiment in new learning media.

[6] "Attention Is All You Need" by Vaswani et al. (2017) introduced the Transformer architecture that underlies every major language model in production today. Published as a Google Brain and Google Research paper, it has over 100,000 citations and is one of the most influential computer science papers of the 21st century.

[7] The MMLU (Massive Multitask Language Understanding) benchmark was introduced by Hendrycks et al. in 2020. While widely used for model comparison, its limitations as a proxy for real-world capability have been documented by researchers including François Chollet, who argues that benchmarks measure "skill" rather than "intelligence" or general capability.