Andrej Karpathy:
a field guide for JayAI

1. The intellectual map

Karpathy connects three kinds of work that are often separated: explaining how neural networks work, building compact implementations, and exploring what people can do with learned systems. His personal site is the starting directory; his teaching, code and public essays provide the more useful detail.

These levels reinforce each other, but none substitutes for the others. Knowing backpropagation does not prove an agent has permission to act. A polished demo does not establish reliability. A passing benchmark does not settle whether the task is worth doing.

2. Neural networks and LLMs: build an accurate mental model

From a scalar gradient to a language model

Source view. Neural Networks: Zero to Hero works upward from backpropagation and micrograd through character modeling, multilayer networks, training diagnostics and GPT. Its notebooks and exercises let a reader reproduce the mechanisms instead of treating a model call as magic. MicroGPT compresses GPT training and inference into a dependency-free educational program of about 200 lines.

Our assessment. This is unusually valuable teaching because you can inspect the entire causal chain. But short code removes production concerns as well as distractions. Use it to explain gradients, attention and sampling; do not make its simplicity a reason to omit access control, recovery, data governance or serving tests.

What a language model is doing

Source view. Deep Dive into LLMs like ChatGPT follows the path from internet data and token prediction to post-training and practical model behavior. MinBPE makes tokenization tangible: the representation of text is part of the system, not a transparent wrapper. How I use LLMs supplies a practical companion focused on interacting with these tools.

Our assessment. Treat a fluent answer as a candidate result. For this network, exact call signs, source dates and quoted passages may matter more than prose quality. Preserve original inputs and references; make the model show the evidence a person needs to check its interpretation.

The project ladder

Nanochat is the current small-model lifecycle project to explore training and deployment together. NanoGPT is historical teaching material; its README now directs readers to nanochat. The GPT-2 reproduction lesson is useful for understanding how details affect a training run. llm.c and llama2.c expose training and inference below high-level frameworks.

For JayAI: study these projects in isolated learning exercises. Training a foundation model is not a prerequisite for better retrieval or transcription. Python and C are appropriate for this educational/model ecosystem; they do not create a reason to rewrite working Ruby application code.

A durable method. A Recipe for Training Neural Networks emphasizes inspecting actual data, starting with simple baselines, overfitting a small case to verify the pipeline, and adding complexity carefully. Our extension is to apply the same skepticism to an agent workflow: inspect real inputs, establish a baseline, and isolate one change at a time.

3. Software 2.0 and 3.0: additional tools, not a mandatory rewrite

Source view. In Software 2.0, learned weights act as software: developers shape data, objectives and training rather than specifying every operation. Software Is Changing (Again) adds the Software 3.0 framing: natural language becomes an important way of programming LLMs. The talk explores partial autonomy and interfaces that make model work easier for people to inspect.

Our assessment. These are complementary modes. A language instruction is not an authorization boundary. Keep Ruby in charge of contracts, allowed actions, validation and durable state. Let a model propose a transcript interpretation or draft explanation; require explicit evidence and deterministic checks before consequential effects. A useful interface should show source, proposed change, uncertainty and a clear review action.

4. Agentic engineering: preserve understanding as delegation grows

Source view. Sequoia Ascent 2026 discusses agentic engineering, the importance of context, agent-friendly interfaces and oversight as more implementation moves to agents. Karpathy labels this page an AI-generated summary and cleaned transcript that he reviewed; it is not a verbatim transcript.

Vibe coding MenuGen illustrates both rapid prototyping and the integration problems that appear around a real product, including flawed email-based payment/account matching. His October 2025 Dwarkesh interview discusses reliability and continual learning over a long horizon. Its decade-scale intuition should not be read as a delivery schedule.

Our assessment. Expert taste is a hidden input to impressive agent demos: someone notices the wrong abstraction, suspicious output or missing test. Delegation works better when the work package is small, the context is curated, the allowed tools are narrow, and the completion condition was written before implementation. Identity mapping, authorization, retries and recovery need explicit tests even if the happy path takes minutes to generate.

For JayAI: retain the existing minimal-diff and independent-review rules. Give an agent a task-specific evidence bundle rather than the entire network’s history. Separate instructions from retrieved material. Use a reviewed patch as the output of a coding task; do not make self-modifying production services the default. More agents add coordination cost and failure paths, so compare against one agent or an ordinary script first.

5. Verifiability: the evaluator is part of the product

Source view. Verifiability argues for the importance of outcomes that can be checked when automating work. 2025 LLM Year in Review connects verifiable rewards, uneven capabilities, benchmark limitations, application orchestration and new interfaces.

Our assessment. A checkable score is useful only if it captures the real goal. An answer can contain the expected words while citing the wrong source; a transcript can look plausible while inventing a call sign; a passing task can still perform a forbidden action. Repeatedly choosing the best candidate against one evaluator can optimize its blind spots.

Ruby’s existing rules already require tests first, an independent judge, unchanged evaluation criteria, held-out task/side-effect/cost/latency tests, and deploy/rollback checks. Testing goes further into grader errors, stale state, prompt injection, cancellation and partial failure. The improvement opportunity is to connect those declared standards to runnable artifacts and dated results, not to pretend the standards are missing.

• Define success independently: expected passages or hand-checked reference transcripts, allowed actions and explicit forbidden effects.
• Separate development and evaluation: tune on development cases; keep a genuinely held-out set out of the optimization loop.
• Measure the full task: correctness, unsupported claims, omissions, side effects, latency, cost and variance across repeated runs.
• Audit the grader: include examples that must fail, inspect disagreements, and report errors and skips separately from passes.

Our proposed evaluation receipt records task ID, code/model/prompt/corpus versions, result, evidence, tool actions, timing, cost and uncertainty. Join these receipts to existing observability where available. Telemetry explains resource use and failures; it does not prove semantic correctness.

6. LLM Wiki: a maintained knowledge artifact

Source view. The April 2026 LLM Wiki idea keeps raw sources separate from an interlinked Markdown wiki maintained by an agent under a schema. It treats knowledge synthesis as an ongoing compilation and maintenance activity. This is an idea document, not a finished production product.

Our assessment. The attraction is cumulative, inspectable knowledge in portable files. The danger is cumulative error: one unsupported synthesis becomes the next page’s apparent authority. A graph of links does not make the claims true. Keep originals immutable; require claim-level source links, observation dates, uncertainty, supersession history and a contradiction queue. A removed source should trigger review rather than silently disappear from the evidence chain.

For JayAI: a small wiki over public engineering notes complements the second-brain research and graph engineering. It need not replace them or start with a graph database. Begin with plain files and source passage retrieval. Compare answers before and after compilation, including questions whose answer is “not established.” Keep private operational material out of this public pilot.

Useful first entities are projects, decisions, requirements and evidence. Give each project a dated state: research, proposed, implemented, or independently verified. Keep observed behavior distinct from intent. A wiki answer should say when a proposal has no implementation evidence, even if the proposal is detailed and persuasive.

7. Autoresearch: borrow the loop, constrain the experiment

Source view. Autoresearch and its program instructions demonstrate a bounded optimization loop: change a narrow training script, run a five-minute experiment, measure the result, and keep or discard the change. The published setup was tested on an H100; that is not evidence it runs suitably, unmodified, on this network’s equipment.

Our assessment. The transferable idea is a disciplined experiment harness, not unrestricted autonomy or a particular GPU workload. A better validation score can reflect evaluator overfitting, noise or a machine-specific tradeoff. Preserve fixed evaluation code, keep an untouched final set, repeat runs and test transfer. Do not adopt suggestions to disable permission boundaries.

For JayAI: only after a baseline exists, try a bounded parser, prompt or retrieval experiment in an isolated copy. Limit editable files, candidate count, total time and cost. The experiment may write candidate artifacts and receipts; it may not publish pages, change permissions, contact people or modify production. A person reviews a reproducible result before promotion. Stop when the improvement is too small to justify operational complexity.

8. Vision, reinforcement learning, education and wider interests

Perception and learning through feedback

Source view. Karpathy’s 2016 vision teaching, linked from his site, and the CS231n notes introduce visual recognition and neural-network practice. The course has many contributors and subsequent instructors; the entire current curriculum is not his work. His Pong policy-gradient essay makes reinforcement learning concrete through actions, rewards and gradient updates.

Our assessment. Vision and RL reinforce the importance of data, feedback and distribution shift. Tesla AI Day 2021 is another primary watch path for his work on perception, data and deployment; find it through his talks directory. Do not turn that history into a claim that he designed all Tesla autonomy or robotics; he describes his Optimus involvement as brief. For JayAI, use these ideas to understand sensor and model errors, not to imply audio observations or model labels establish ground truth.

Teaching that produces retained understanding

Source view. Eureka Labs presents the combination of expert curriculum and an AI teaching assistant. Its public page presents a July 2024 launch vision; that alone does not establish a completed school or course. A Survival Guide to a PhD discusses research judgment, independence and choosing productive problems.

Our assessment. A tutor should build the learner’s ability to solve unfamiliar problems without it. Pair explanations with predictions, exercises and delayed checks. For a JayAI study group, reproduce a small model, explain a failure and debug a new case. Measure retained understanding rather than the number of generated lessons.

A broader public notebook

His append-and-review note explores simple capture and periodic review. Digital hygiene collects personal privacy and security preferences; these are not universal endorsements for every threat model. The Bitcoin mechanics essay is a technical learning exercise, not an investment recommendation. His reading list, older AI fiction and personal experiments show wider curiosity. Personal health or biohacking opinions should remain separate from evidence-based health advice.

9. What the JayAI network should keep, improve, add and skip

Evidence boundary: this review read public research and engineering pages plus local publishing instructions, static site content and the radio project README. It did not audit private data, production model quality, identity enforcement or dashboards. Public descriptions are evidence of what is documented, not proof every control operates.

The network today: distinguish documents from working evidence

• JayCorp hosts research on harnesses, graphs, local knowledge and radio. The older SDR article documents manual tools tested on October 9; the station architecture explicitly labels itself a proposal.
• Michigan now presents a radio control panel. The local radio README describes a stream, transcripts and recovery behavior, showing that later implementation work exists beyond the older proposal. We have not verified reception accuracy, service uptime or every proposed station feature. These documents should be reconciled with dated implementation evidence.
• Ruby publishes engineering policy. Its identity broker, outside-service choices and hardware upgrades include proposals, not blanket deployment claims. Observability is documented as running; this guide did not test its dashboards.
• aol.pm describes defensive security research, with notes coming soon. bada.im describes adversarial ML and repeatable failure measurements. These are useful interests and principles, not verified operational controls.

Keep

Keep the architecture that fits. Ruby services, explicit interfaces, portable files, cross-linked research and authorized-use boundaries are a strong base. The existing engineering rules already align with careful agentic work. Continue surgical changes and evidence proportional to risk.

Improve

Policy priority: Jay’s instructions and the applicable Ruby project guidance govern implementation. Karpathy’s opinions and our critiques are external analysis, not permission to override those rules. Any exception or policy revision below requires explicit project-owner approval before adoption.

Make claims traceable. Link a project’s status to a dated test command and receipt. Distinguish a planned feature from code that exists, and code that exists from behavior tested in production. Separate radio observations, transcripts and model inferences in the interface; a generated label should never masquerade as a measured fact.

Keep Ruby for demonstrated fit. Why Ruby makes strong claims about model readability and reliability without comparative task benchmarks. Treat those advantages as hypotheses until measured. The existing system’s simplicity and maintainability are already good reasons to retain Ruby; model training can still use its established Python ecosystem.

Apply policy according to risk. Minimalism can conflict with blanket multitenancy or “two providers, always” requirements in the service guidance. Our proposal, subject to explicit project-owner approval, is an applicability rule: a teaching script need not acquire a tenant hierarchy, broker and duplicate provider. A tenant-facing business system does need rigorous isolation. Do not quietly waive requirements; document the scope and review the exception.

Prove portability. Adapters reduce coupling but cannot erase differences in streaming, tool schemas, retries, identity mapping or side effects. Placeholder adapters do not establish failover. Use contract tests and an observed failover drill before claiming interchangeability. Secret-storage alternatives similarly describe choices, not proof each provider is operating.

Add

One benchmark and one experiment ledger. Start with public-site retrieval because the corpus is available and the work needs no new private recordings. If an existing lawful audio dataset and baseline are ready, SDR transcription is an equally useful alternative. Record model, prompt, code and corpus revisions; scores; repeated-run variation; and acceptance or rejection rationale. Reuse existing telemetry rather than building another dashboard.

Skip for now

Skip a Ruby-to-Python rewrite, foundation-model training as a dependency, a network-wide graph migration, additional multi-agent layers without measured benefit, disabled permissions and autonomous production self-modification. These increase scope without establishing that the current task gets better.

10. A prioritized implementation roadmap

Everything below is a proposal requiring a separately authorized implementation task. The numbers are suggested pilot acceptance criteria, not reported measurements. Agree on them before tuning; tighten them when consequences demand it.

P0 · Turn the existing standards into a reproducible baseline

Deliverable: a compact Ruby/Minitest evaluator for questions over a frozen copy of the public network corpus. Have a person author 30 cases: answerable questions, conflicting or stale documents, unanswerable questions, and instruction-like text embedded in sources. Reserve 10 unseen cases for the P2 final evaluation. Report counts and uncertainty: ten cases provide pilot evidence, not a strong reliability estimate. Give each answerable case an expected source passage; define allowed actions and forbidden effects independently of the generated answers.

Success: a repeatable command emits pass/fail/skip/error receipts with versions, citations, actions, latency and cost. Deliberately wrong citations and forbidden write attempts fail. All cases are accounted for; no silent skips. Run the baseline three times and report variation, unsupported claims, citation correctness and answer completeness. A person checks grader disagreements. This establishes measurement; it does not claim a quality win yet.

Alternative SDR pilot: use only lawfully obtained, authorized fixed clips with hand-checked references; split by recording session so adjacent audio does not leak between sets. Measure call-sign/entity accuracy, omissions, hallucinations on silence, transcription error, latency and cost. Preserve audio evidence and human review. Do not publish private recordings or inferred identities as part of the benchmark.

P1 · Make project status and portability auditable

Deliverable: dated research/proposed/implemented/verified labels for the public project catalog, plus one contract test for any provider boundary the pilot actually uses.

Success: every “verified” label links to evidence and its scope; failed, skipped and untested work remains visible. A failover drill demonstrates expected behavior for timeouts, partial output and retries without duplicate effects. The evaluator’s receipt ID joins to existing telemetry when available. No new dashboard is required.

P2 · Trial a small LLM Wiki

Deliverable: compile at most 20 public documents into linked Markdown with preserved originals, claim citations, dates, project states and a contradiction review queue. Compare against the P0 retrieval baseline on the same frozen development cases, then evaluate once on the held-out cases.

Success: all checked factual claims resolve to source passages; seeded contradictions and superseded pages are flagged; no private content appears. The pilot should improve answer completeness without increasing unsupported claims. Set a latency and cost budget from the baseline before running it. Reject the pilot if maintenance overhead outweighs the measured benefit.

P3 · Try one budgeted optimization loop

Deliverable: an isolated prompt, parser or retrieval experiment with a fixed evaluator, a maximum of 10 candidates and a preapproved time/cost ceiling. Keep candidate artifacts and reasons for every keep/discard decision. Before P3 begins, have an independent reviewer author a separate sealed final holdout; the P2 holdout is now exposed and cannot serve that role. The agent cannot edit the evaluator or see this new holdout. Do not tune further after examining its final results.

Success: a reproducible improvement on the predeclared primary metric, no regression on forbidden effects or unsupported claims, and results within resource budgets over three repeated runs. Report the untouched holdout result even when it loses. Human review is required before promotion; rollback restores the prior artifact and passes the same smoke checks. No experiment receives production publishing rights.

11. Choose a reading or watch path

• Understand LLMs without training one: Deep Dive → How I use LLMs → Verifiability. Finish by writing three ways a plausible answer could fail your actual task.
• Build the mechanisms: Zero to Hero → minbpe → MicroGPT → nanochat. Explain one training failure before scaling the exercise.
• Lead an engineering team: Software 2.0 → Software Is Changing (Again) → MenuGen → Sequoia Ascent. Draw the boundary between model suggestions and authorized effects.
• Improve JayAI now: the existing testing standards → P0 baseline → LLM Wiki → autoresearch. Do the baseline before either experiment.

12. Primary-source catalog and limitations

Links throughout the guide point to original teaching, repositories, talks and author-published writing. This compact catalog makes the map easier to revisit. Repository status and public pages can change after the research date; save a revision when using one for an implementation decision.

1. Directories: personal site and talks; older essays; current public writing.
2. Foundations: Zero to Hero syllabus; course repository; MicroGPT; training recipe.
3. LLM lectures: Deep Dive into LLMs like ChatGPT; How I use LLMs; GPT-2 reproduction.
4. Code: minbpe; nanochat; nanoGPT, historical; llm.c; llama2.c.
5. Software and agents: Software 2.0; Software Is Changing (Again); MenuGen; Sequoia Ascent 2026; Dwarkesh interview.
6. Evaluation and iteration: Verifiability; 2025 review; autoresearch; LLM Wiki.
7. Vision, RL and learning: CS231n; Pong policy gradients; Eureka Labs; PhD survival guide.
8. Wider interests: append-and-review; digital hygiene; Bitcoin mechanics; books.

The network recommendations are our synthesis. We have not established that every public proposal is implemented, nor proved that an unlisted capability is absent. No new model-quality, failover, cost or latency result is claimed. Future work should replace hypotheses with dated, reproducible evidence.