Andrew Ng × Anthropic: A Hands-On Claude Code Tutorial and Core Methodology

Andrew Ng and Anthropic's Claude Code course: architecture, methodology, and three hands-on cases.
Andrew Ng and Anthropic present a hands-on Claude Code course covering its surprisingly simple architecture, localized security benefits, and the core methodology of providing clear context. Three practical cases—a RAG chatbot, Jupyter data analysis, and Figma-to-frontend—unlock real AI programming productivity.
From Code Completion to Agents: The Evolution of AI Programming
Over the past two years, AI-assisted programming has undergone rapid evolution. As Andrew Ng points out in this short course produced in collaboration with Anthropic, the evolutionary path roughly goes: from people occasionally posing programming questions to large language models (LLMs), to GitHub Copilot–style autocompletion, and now to the highly autonomous Claude Code.
It's worth understanding that a large language model (LLM) is a neural network model based on the Transformer architecture, trained on massive amounts of text data. The Transformer architecture has become the unified foundation of modern LLMs since Google's 2017 paper "Attention Is All You Need." Its core innovation lies in the "self-attention mechanism"—it enables the model to attend to context at any position in a sequence while processing a piece of code, without being constrained by the vanishing gradient problem of earlier RNN architectures, where "the greater the distance, the smaller the influence."
The self-attention mechanism works as follows: when computing the representation of each token, the model dynamically assigns different weights to all other tokens in the sequence, with the magnitude of the weight reflecting the degree of semantic relevance between that token and the current computation position. This characteristic is especially critical for programming scenarios: understanding the behavior of a function often requires tracing back to variables or interface conventions defined hundreds of lines away, and the Transformer's global attention view is precisely able to cover such long-range dependencies. From the perspective of computational complexity, the cost of the self-attention mechanism grows quadratically with sequence length (O(n²))—which is the fundamental reason why early models had limited context windows. In recent years, breakthroughs in engineering optimizations such as FlashAttention and Sliding Window Attention have made it possible to expand the context window from the early 4K tokens to today's 100K+ tokens while maintaining computational efficiency, thereby fundamentally changing the boundaries of AI's ability to handle large codebases.
In the programming domain, the evolution of LLM capabilities has passed through several key milestones: the early GPT-3 could only answer simple code questions; the 2021 release of GitHub Copilot embedded LLMs into the IDE, enabling line-level and function-level autocompletion; and after 2023, with the substantial improvement in model reasoning capabilities and context windows, AI began to be able to handle complex cross-file, cross-module tasks. Each step means that the "agency" of programming assistants has been continuously strengthening—the essence of this "agency" is a paradigm shift in which the model moves from "passively responding to a single prompt" to "proactively planning and executing multi-step tool calls," which is also the core feature that distinguishes modern AI agents from early chatbots.
The release of Claude Code represents a significant leap in the agency of programming assistants. What surprises many developers is that you can assign Claude a task, and it can work independently for minutes or even longer. And now, some developers no longer just drive a single Claude instance—they orchestrate multiple instances simultaneously, letting them process different parts of the codebase in parallel.
Orchestrating multiple Claude instances to process a codebase in parallel is essentially a multi-agent system design. The core challenge of this model lies in: how to avoid concurrent write conflicts by multiple agents on the same file, how to pass intermediate results between agents, and how to resolve code logic conflicts during the final merge. From a distributed systems perspective, this is essentially a race condition management problem—when multiple agents write to the same resource simultaneously, the lack of locking mechanisms or isolation design leads to unpredictable results.
In practice, developers typically isolate the scope of an agent's work through module boundary partitioning (ensuring each agent's write operations are idempotent), track each agent's changes with Git branch management, and finally perform a final consistency check through the pull request merge process. Notably, this pattern has a classic theoretical foundation in software engineering—Conway's Law states that system architecture tends to mirror the organization's communication structure; conversely, when you assign a codebase to different agents by module boundaries, you are also implicitly making architectural decisions about the system. This parallelization strategy can, in theory, compress the completion time of complex tasks by several times, but it also places higher demands on task decomposition capabilities and engineering standards, making it an important direction for advanced Claude Code usage. Multi-agent coordination is backed by a mature theoretical framework in academia, including task allocation based on the Contract Net Protocol and shared state management based on the Blackboard System—and Claude Code's practice is bringing these theories into daily development workflows in a more engineering-oriented manner.

This course is taught by Anthropic's Eddie Shobik (Ellie). Andrew Ng describes Claude Code as his current personal favorite programming assistant, one that "greatly boosts my productivity and that of many developers." The goal of the course is to systematically explain the most important ideas behind using Claude Code—this may well be the most authoritative set of teaching materials on the tool.
The Underlying Architecture of Claude Code: Surprisingly Simple
One highlight of the course is that it reveals the underlying architecture of Claude Code, and this architecture may surprise many people—it is remarkably simple.
No Code Indexing—Understanding Through "Reading"
Claude Code relies on only a handful of tools to get its work done: searching for patterns in code files, listing directories, viewing files, and executing regular expression matches. It does not rely on semantically embedding code, nor does it convert the codebase into some searchable structure.
To understand this design choice, you first need to understand what it gives up. Traditional code intelligence tools (such as early semantic code search) typically rely on "semantic embedding" technology: converting code snippets into high-dimensional vectors (usually arrays of 768-dimensional or 1536-dimensional floating-point numbers), storing them in a vector database (such as Pinecone, Chroma, or pgvector), and finding semantically related code through approximate nearest neighbor (ANN) search.
The essence of semantic embedding technology is mapping text to a point in a high-dimensional vector space, where semantically similar content has a smaller Euclidean or cosine distance in that space—this characteristic makes "retrieval by semantics rather than keywords" possible. Vector databases are specially optimized for large-scale nearest neighbor search, typically using algorithms such as HNSW (Hierarchical Navigable Small World graphs) or IVF (Inverted File Index), which can complete similarity retrieval over millions of vectors in milliseconds—a performance boundary unattainable by traditional relational databases.
However, this approach has several inherent limitations: the embedding process usually requires uploading code to an external API (creating data sovereignty risks), the vector representation struggles to capture the dynamic semantics of code at execution time (such as runtime types and side effects), and index maintenance costs are high when code changes frequently (each commit requires triggering an incremental update). Moreover, an embedding model's understanding of code semantics is essentially a "compressed approximation"—compressing thousands of tokens of semantics into a fixed-dimensional vector inevitably involves information loss, especially for debugging and refactoring tasks that depend on precise semantic reasoning, where this loss may lead to retrieval results that "seem relevant but are actually misleading." Claude Code abandons this route and instead adopts an "agentic reading" strategy—reading files on demand during task execution, similar to how a human developer reads code. This design trades higher real-time computational cost for architectural simplicity and data localization—a conscious engineering trade-off.
In other words, it does not build a "code index" in the traditional sense. Instead, Claude Code reads your code in an agentic manner, recording its understanding in files like CLAUDE.md, autonomously figuring out what the code does, and thereby driving subsequent decisions and code evolution.
CLAUDE.md is the core mechanism Claude Code uses to persist project context. Since the LLM itself is stateless (each conversation is independent, and no internal state is retained after inference completes), cross-session "memory" must be implemented through external files—which is essentially the same as how human engineers rely on README files, architecture design documents, and code comments to convey knowledge, except that the reader changes from human to AI.
CLAUDE.md is usually stored in the project root directory and records information such as project architecture descriptions, coding standards, common commands, and the responsibilities of key modules; in large monorepos, local CLAUDE.md files can also be placed in subdirectories, forming a hierarchical context management system—Claude Code collects all relevant CLAUDE.md files up the directory tree while executing tasks, building a complete project context view. This design is in line with the "Docs as Code" concept in software engineering—documentation and code are version-controlled in sync and treated equally—and also makes team collaboration possible: anyone can influence the AI assistant's behavior baseline by maintaining CLAUDE.md, without needing to modify the model itself.
From an information architecture perspective, CLAUDE.md is essentially doing "team-based, version-controlled prompt engineering," solidifying context that was originally scattered across individual conversations into reviewable, iterable engineering assets. Worth further reflection is that the quality of CLAUDE.md's content directly determines how accurately Claude Code understands the project—a well-maintained CLAUDE.md is essentially the product of a team converting tacit engineering knowledge into explicit documentation, and this process itself can, in turn, promote in-depth review and organization of the team's understanding of its own codebase architecture.

Security Advantages of a Localized Design
Not needing to index the codebase directly brings an important benefit: the codebase can be kept entirely local. In the course, Ellie specifically mentions the security significance of this design—for enterprises and teams that value code privacy and compliance, core code assets do not need to be uploaded or embedded into external systems, reducing the risk of data leakage at the source.
This characteristic is especially important for heavily regulated industries such as finance, healthcare, and defense, which often have clear data residency and data sovereignty requirements prohibiting source code from leaving specific geographic or network boundaries. It's worth noting that some regulatory frameworks (such as the EU's GDPR and China's Data Security Law) also have clear constraints on "personal data that may be contained in code"—for example, hardcoded user IDs, personal information in debug logs, etc.—which makes the compliance significance of localized code handling far exceed what developers typically recognize. From the defense-in-depth perspective of enterprise information security, Claude Code's localized design eliminates a potential "supply chain attack surface": code does not need to be relayed through third-party servers, so there is no risk path for man-in-the-middle interception or internal data leakage at a service provider. The localized design enables Claude Code to be deployed compliantly in these scenarios without requiring enterprises to invest additional costs in security audits.
Core Methodology: Provide Claude Code with Clear Context
If there is only one most critical piece of advice from this course, it is: provide Claude Code with clear context to help it efficiently accomplish the tasks you want.
Specifically, this involves three levels:
- Point to relevant files: Explicitly tell Claude Code which files to focus on, rather than letting it blindly explore the entire codebase.
- Describe requirements clearly: Explain the functions, features, and behaviors you want clearly to reduce ambiguity.
- Extend capabilities correctly: Appropriately extend the capability boundaries of Claude Code through MCP (Model Context Protocol) servers and other tools in the ecosystem.
MCP (Model Context Protocol) is an open protocol proposed by Anthropic in 2024, aimed at standardizing the way AI models interact with external tools and data sources. Before MCP appeared, each AI programming tool needed to develop separate adaptation layers for different external systems (databases, APIs, design tools, etc.), leading to a fragmented ecosystem—highly similar to the dilemma in the early computer peripheral ecosystem where "each device needed a dedicated driver."
The core idea of MCP is similar to the USB standardized interface: the protocol defines a three-layer unified specification of "Tool Description" (containing the tool's name, functional description, and parameter schema), "parameter passing" (structured input in JSON format), and "result return" (standardized response format). As long as a tool implements the MCP server specification, any MCP-compatible AI client (such as Claude Code) can discover and call that tool through a standard handshake process, without additional adaptation development. This "discover and use" design greatly lowers the barrier to tool integration.
MCP also has a built-in permission sandbox mechanism—a server can declare the minimum permission scope it requires, and the client displays the permission request to the user before calling, similar to the app permission management model of mobile operating systems, guaranteeing the auditability of tool calls at the protocol level. From the perspective of software architecture evolution, MCP essentially reproduces the core value proposition of "microservices architecture" at the AI tool level: by decoupling service providers from consumers through standardized interfaces, each MCP server can iterate and deploy independently without affecting the stability of the overall ecosystem. Currently, the MCP ecosystem already covers dozens of categories of server implementations, including database queries, browser control, code execution sandboxes, and design tools, and is becoming an important infrastructure for interconnectivity in the AI tool ecosystem.

Andrew Ng emphasizes that many people, even if they are already Claude Code users, still have enormous room for improvement if they have never worked alongside someone familiar with best practices. These best practices are not yet widely known, and they are precisely the key to driving astonishing productivity.
Three Hands-On Cases: A Complete Walkthrough from RAG to Figma
The course uses three progressively challenging hands-on cases to help learners truly put the above methodology into practice.
Case One: Building a RAG Chatbot
The first case is a RAG (Retrieval-Augmented Generation) chatbot. RAG (Retrieval-Augmented Generation) is one of the most mainstream architectural patterns in current enterprise AI applications. Its core idea is: when a user asks a question, first retrieve the document fragments most relevant to the question from an external knowledge base, then feed these fragments as context together into the LLM to generate an answer. This solves two inherent limitations of LLMs—the problem of outdated knowledge caused by the training data cutoff date, and the problem of model hallucination (by injecting "citable factual basis" into the prompt, making the model's answers verifiable).
A complete RAG system typically includes six stages: document parsing (converting formats such as PDF and Word into plain text, involving technical challenges such as OCR and table extraction), chunking (cutting long documents into fragments suitable for retrieval, usually 500–1000 tokens; the quality of the chunking strategy directly affects retrieval recall, with fixed-size chunking, sentence-boundary chunking, and semantic chunking each having their applicable scenarios), embedding vectorization (converting text into vector representations; when choosing an embedding model, you need to balance vector dimension, inference speed, and semantic expressiveness), vector storage (persisting to a vector database, requiring consideration of index update frequency and storage cost), retrieval ranking (finding the most relevant fragments based on the query vector; in engineering practice, vector similarity search is usually combined with BM25 keyword matching, i.e., "hybrid retrieval," to balance semantic similarity and lexical precision), and generation (injecting the retrieval results into the prompt, with the LLM generating the final answer; the prompt design in this step directly determines citation quality and answer style).
Worth particular attention is the evaluation dimension of RAG systems: beyond the user-experience-level question of "whether the answer is accurate," engineers also need to separately evaluate the performance of the retrieval stage (Recall, Precision) and the generation stage (Faithfulness, Relevance)—specialized evaluation frameworks such as RAGAS were created precisely for this. This covers almost all key processes of modern AI application development, which is why the course chose it as the first hands-on case.
Learners will fully implement each function from front end to back end, including:
- Refactoring code
- Writing tests
- Handling pull requests and fixing issues using GitHub integration
In this process, you will deeply use the core features of Claude Code: planning, thinking modes, creating parallel sessions, and managing Claude's memory.
Case Two: Jupyter Notebook and E-Commerce Data Analysis
The second case turns to the data domain, using a Jupyter Notebook to explore e-commerce data. The focus is on using Claude Code to refactor the Notebook, remove redundant code, and further build a fully functional dashboard and web application.
As a standard tool in the data science field, Jupyter Notebook's "step-by-step cell execution" working mode aligns highly with the iterative nature of AI-assisted programming—each cell is a natural unit of code review and modification, enabling Claude Code to precisely locate the fragments that need optimization without having to process the entire script at once. It's worth mentioning that the Notebook's cell structure naturally forms checkpoints of execution state: the output of each cell is an observable intermediate result, which provides Claude Code with an "instant feedback loop"—it can execute a cell, observe the output, judge whether it meets expectations, and then decide on the next action. This "execute-observe-decide" loop is precisely a typical manifestation of agentic behavior patterns.
From the perspective of data engineering, e-commerce data analysis scenarios usually involve complex operations such as multi-table joins, time-series aggregation, and funnel analysis, and these are precisely the places most prone to "redundant intermediate-state code" in Notebooks—refactoring such code requires a global understanding of the data flow rather than line-by-line modification, which is exactly a typical scenario where Claude Code's large context window advantage can be fully leveraged. This stage demonstrates the practical value of Claude Code in data analysis and visualization scenarios.
Case Three: Converting a Figma Design into a Front-End Application
The final case is the most comprehensive: based on visual mockups in Figma, combined with the Figma MCP server and other MCP servers, importing, iterating on, and testing the design, and building a complete front-end application in an agentic manner.
The Figma MCP server works by serializing Figma's design data (including the component tree, style properties, spacing constraints, color variables, etc.) into a structured JSON description, exposed as context that Claude Code can understand. Behind this is an important information transformation chain: Figma exposes the complete design file structure through its REST API, the MCP server translates this raw design data into AI-friendly text descriptions, and Claude Code then maps the text descriptions into specific CSS properties, React component structures, or Tailwind class names.
This makes the "design mockup directly generates code" workflow possible—AI is no longer just a crude approximation of "looking at an image and writing code" (an approach that relies on a vision model's understanding of screenshots and struggles to accurately reproduce pixel-level constraints), but can precisely read every pixel constraint and interaction state in the design intent (including the independent design data for UI states such as Hover, Focus, and Disabled). From the perspective of the product development process, the deep value of this workflow lies in breaking the semantic gap that has long existed between "design and development": the component boundaries, auto-layout rules, and design tokens defined by designers in Figma can be directly converted into component boundaries, CSS variables, and style systems in front-end engineering through MCP—design decisions are transmitted to the code layer in a nearly lossless manner, greatly compressing the rework costs and communication losses caused by manually "translating" design mockups. This greatly compresses the translation cost from design to development and fully demonstrates how the MCP ecosystem connects Claude Code with external design tools to form an end-to-end development workflow.

Conclusion: A Claude Code Methodology Worth Mastering for Every Developer
Whether or not you are already using Claude Code, this systematic methodology is worth studying in depth. Andrew Ng believes that for developers who have not yet gotten started, these ideas will significantly accelerate the way you build systems; and for experienced users, Ellie's comprehensive and systematic explanation will also bring quite a few new ideas that can be put into practice immediately.
From a simple architecture with just a few basic tools to the advanced approach of orchestrating multiple instances in parallel, Claude Code's depth far exceeds its surface impression. The real leap in productivity often lies hidden within these best practices that are not yet widely mastered.
Key Takeaways
Related articles

The Truth Behind Codex 'Build a Website in 5 Minutes': AI Isn't Creating Sites—It's Helping You Copy Them
Exposing the truth behind viral Codex 5-minute website videos: creators aren't building original sites with AI—they're copying shared prompts or scraping others' work. Learn AI coding tools' real limits.

Getting Started with AI Agent Development: A Complete Guide from Concept to Practice
A comprehensive guide to AI Agent architecture and development, covering automated marketing, intelligent customer service, and investment analysis scenarios with single and multi-agent collaboration.

The Truth Behind Codex 'Build a Website in 5 Minutes': AI Isn't Creating Sites — It's Helping You Copy Them
Exposing the truth behind viral Codex 5-minute website videos: creators aren't building original sites with AI — they're copying shared prompts or scraping others' work.