George Hotz–Inspired Coding Guidelines

Skills + guidelines that push an AI coding agent toward radical simplicity — distilled from George Hotz's (geohot) publicly-stated philosophy on complexity, refactoring, and understandable code, then translated into rules a coding agent can actually follow.

For Codex (AGENTS.md), Claude Code (plugin / CLAUDE.md), and Cursor (.cursor/rules).

English | 简体中文

Unofficial. Not affiliated with, authored by, or endorsed by George Hotz, tinygrad, or comma.ai. This is a student's humble distillation of his public statements (talks, interviews, tinygrad) — deepest respect to geohot; the work and the ideas are his, any misreading here is mine alone. Quotes are sourced in Attribution.

Coding agents have a strong, repeatable bias toward complexity:

• they add a layer, an abstraction, a config flag, an adapter — when the answer was to delete something;
• they grow functions wide (options bags, 5+ parameters) instead of fixing the design;
• they assume behavior and generate a confident blob instead of looking at what the code actually does;
• they treat the existing structure as sacred and pile on top of it.

Left alone, the diff only ever grows. Hotz's whole career is the opposite reflex.

Four principles, each a direct translation of something Hotz actually says, into a rule an agent can act on.

"I'm trying to build something that manages complexity. You can always make your software do more. The magic is when you can make your software do more without adding complexity — because complex things eventually collapse under their own weight." — George Hotz

"Complex things eventually collapse under their own weight."

The goal is more capability at equal or lower complexity. Adding a feature by adding a layer is a loss, not a win.

• Do: solve the actual request with the least machinery that works.
• Don't: add speculative abstractions, configurability, plugin points, or "future-proofing" nobody asked for.
• Smell: if your plan introduces a new manager/handler/factory/adapter to do one thing, stop and ask what you can remove instead.

"You have never refactored enough. Your code can get smaller, your code can get simpler, your ideas can be more elegant."

tinygrad aims to express machine learning with roughly 25 low-level ops, compared with roughly 250 in XLA / PrimTorch, in a codebase Hotz keeps deliberately tiny. Line count is a number you drive down.

• Do: delete-first — before touching a subsystem, ask "can this not exist?" Collapse duplicated logic to one source of truth. The best PR is often a negative diff.
• Don't: treat lines of code as output. LOC is debt.
• Fence: prove something is actually dead before deleting it (check the callers), and never delete a real invariant (money, auth, data-integrity) to "simplify" — that's a bug, not a cleanup.

Parameter sprawl is a design signal, not a styling nit. As a Hotz-style rule of thumb: if a function is growing toward five arguments, treat the boundary as suspect. A wide interface is the symptom; the disease is the wrong boundary.

• Do: when an interface grows wide, redesign the boundary — split the responsibility, or pass one well-shaped value.
• Don't: paper over it with an options/**kwargs bag so the count "looks" smaller.

tinygrad as "the RISC of the machine learning stack — extreme simplicity that allows anyone to understand it."

Hotz builds things small enough that one person can hold the whole stack in their head. For an agent, that means: don't reason about what code "should" do — go look at what it does.

• Do: build the smallest runnable unit, print/inspect its real inputs and outputs, and check them against expectation before stacking more on top. Read the definition and the callsites before concluding.
• Don't: assume an API's behavior, cargo-cult a pattern you don't understand, or declare something "works" / "is safe" without seeing it.
• Agent rule: AI-generated code must be read and validated line by line; speed is not correctness.

Copy AGENTS.md into your repo root (or merge it with an existing one). Codex loads it as repository instructions.

curl -fsSL https://raw.githubusercontent.com/frankekn/george-hotz-skills/main/AGENTS.md >> AGENTS.md

Copy CLAUDE.md into your repo root (or append it to an existing one). Claude Code loads it automatically.

curl -fsSL https://raw.githubusercontent.com/frankekn/george-hotz-skills/main/CLAUDE.md >> CLAUDE.md

Drop the skill into your personal skills directory so it loads only when a task is about refactoring, simplification, or fighting complexity:

mkdir -p ~/.claude/skills/geohot-guidelines
curl -fsSL https://raw.githubusercontent.com/frankekn/george-hotz-skills/main/skills/geohot-guidelines/SKILL.md \
  -o ~/.claude/skills/geohot-guidelines/SKILL.md

Copy .cursor/rules/geohot-guidelines.mdc into your project's .cursor/rules/.

The Karpathy guidance is "think before you code." Hotz's is sharper and more physical: the enemy is complexity, and the move is almost always to remove, not add. An agent that internalizes "you have never refactored enough" produces smaller diffs, tighter interfaces, and code a human can actually keep.

• Diffs trend smaller; you see negative-line changes you didn't have to ask for.
• The agent proposes deleting/collapsing before adding.
• Functions stay narrow; when one goes wide, the agent flags the boundary instead of adding a parameter.
• The agent shows you a printed/observed value to justify a claim, instead of asserting "this should work."

Radical simplicity is a bias, not a religion. Some domains genuinely need the layer (security boundaries, real extensibility points, hard invariants). These rules tell the agent to default to removal and justify additions — not to delete load-bearing structure. Keep the fences in principle 2.

A community distillation of George Hotz's public statements. Sources:

• Commoditizing the Petaflop — George Hotz, Latent Space
• Lessons from George Hotz — Antoine Buteau
• George Hotz — Lex Fridman Podcast #387 (transcript)
• The Eternal Sloptember — George Hotz
• geohot on GitHub · tinygrad

Quotes are attributed to public talks/interviews; paraphrases are marked as such. Inspired by the format of andrej-karpathy-skills.

MIT — see LICENSE.