Karpathy Principles

The models make wrong assumptions on your behalf and

just run along with them without checking. They don't

manage their confusion, don't seek clarifications,

don't surface inconsistencies, don't present

tradeoffs, don't push back when they should.

>

(Andrej Karpathy, on agentic coding failure modes)

What This Is

A four-principle contract for reducing the most common LLM coding pitfalls. Compact entry-point. Each principle has a deeper-dive skill in night-market; this skill is the index, not the encyclopedia.

Derivation: distilled by Forrest Chang (forrestchang/andrej-karpathy-skills, MIT) from Karpathy's observations. Full attribution in references/source-attribution.md.

When to Use

• Before starting any coding task larger than a typo
• During code review, to name the failure mode you see
• After writing a diff, to self-audit before claiming

done

• When training a junior engineer to read agent diffs

When NOT to Use

These principles bias toward caution over speed. For cases listed in modules/tradeoff-acknowledgment.md, use judgment: trivial fixes, exploratory spikes, documentation-only edits, and time-boxed prototypes.

The Four Principles

1. Think Before Coding

State assumptions. Surface confusion. Match tone to evidence.

• If multiple interpretations of the request exist,

list them. Do not silently pick.

• If a simpler approach exists, name it. Push back

when the simpler path is correct.

• If something is unclear, stop and ask. Hidden

assumptions are the cheapest bug to prevent and the most expensive to find later.

• Make claims no stronger than the evidence supports.

Calibrated tone beats confident hand-waving.

Deep dives: Skill(imbue:rigorous-reasoning) for the sycophancy guard, Skill(superpowers:brainstorming) for option generation, /spec-kit:speckit-clarify command for ambiguity drilldown.

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

They really like to overcomplicate code and APIs,

bloat abstractions.

>

(Andrej Karpathy, on the same agentic-coding thread)

• No features beyond what was asked
• No abstractions for single-use code
• No flexibility or configurability that wasn't

requested

• No error handling for impossible scenarios
• If you wrote 200 lines and it could be 50, rewrite

it

Self-check: would a senior engineer say this is overcomplicated? See modules/senior-engineer-test.md.

Deep dives: Skill(imbue:scope-guard) for the worthiness formula and branch budgets, Skill(leyline:additive-bias-defense) for burden of proof on every addition, Skill(conserve:code-quality-principles) for the KISS / YAGNI / SOLID foundation.

Record the Tradeoff (decision journal)

When this step settles a decision with real alternatives, record it to docs/tradeoffs.md while the reasoning is live (draft and confirm):

• If leyline is installed, invoke Skill(leyline:decision-journal) and append

a tradeoff entry (the decision, the options weighed, and what was sacrificed; set phase to plan). Show the draft; append on confirmation.

• Fallback (leyline absent): append to docs/tradeoffs.md using the in-file

ENTRY TEMPLATE; assign the next TR-NNN id.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

• Do not improve adjacent code, comments, or

formatting

• Do not refactor things that aren't broken
• Match existing style even when you would do it

differently

• If you notice unrelated dead code, mention it; do

not delete it

• When your changes orphan imports or variables,

remove the orphans you created. Pre-existing dead code stays unless asked.

The trace-back test: every changed line should trace directly to the user's request.

Deep dives: Skill(imbue:justify) for additive-bias audits on diffs, Skill(leyline:additive-bias-defense) for the burden-of-proof contract, the bounded-discovery.md rule for read-budget caps.

4. Goal-Driven Execution

Define verifiable success criteria. Loop until verified.

Transform vague tasks into checkable goals:

• "Add validation" becomes "tests for invalid inputs

pass"

• "Fix the bug" becomes "test reproducing the bug,

then make it pass"

• "Refactor X" becomes "tests pass before and after"
• "Make it faster" becomes "benchmark Y under N ms"

For multi-step tasks, state a brief plan with verification per step. Strong success criteria let you loop independently. Weak criteria require constant clarification.

See modules/verifiable-goals.md for the full reformulation template.

Deep dives: Skill(imbue:proof-of-work) for the Iron Law (no implementation without a failing test first), Skill(superpowers:test-driven-development) for the RED-GREEN-REFACTOR loop.

The Karpathy Self-Check

Before you ship, four questions:

Four "yes" answers means ship. Anything else means iterate.

Modules

• modules/anti-patterns.md - eight named drift rails

with before/after diffs

• modules/senior-engineer-test.md - the

three-question self-check battery

• modules/verifiable-goals.md - vague-to-verifiable

reformulation template with worked examples

• modules/tradeoff-acknowledgment.md - when the four

principles do not apply

References

• references/source-attribution.md - Karpathy

primary citation, Forrest Chang derivation, license, adjacent prior art

Related Skills

• Skill(imbue:scope-guard) - worthiness formula and

branch budgets

• Skill(imbue:proof-of-work) - Iron Law TDD gate
• Skill(imbue:rigorous-reasoning) - sycophancy and

hidden-assumption guard

• Skill(imbue:justify) - additive-bias diff audit
• Skill(leyline:additive-bias-defense) - burden of

proof on every addition

• Skill(conserve:code-quality-principles) - KISS,

YAGNI, SOLID

• Skill(superpowers:test-driven-development) -

RED-GREEN-REFACTOR

• Skill(superpowers:brainstorming) - generate

options before committing

• See docs/quality-gates.md#skill-level-quality-gate-composition

for the full gate-skill federation graph (this skill is the synthesis hub)

Required TodoWrite Items

When invoked as a pre-flight gate, create:

• karpathy:assumptions-listed - principle 1 satisfied
• karpathy:simplicity-checked - principle 2 satisfied
• karpathy:trace-back-verified - principle 3 satisfied
• karpathy:success-criteria-defined - principle 4

satisfied

Exit Criteria

• Each of the four principles has been answered with a

concrete artifact (assumption list, scope rationale, diff trace, verification plan).

• The senior-engineer test was applied at least once.
• Verifiable success criteria are written down before

the implementation begins.

• The chosen approach and its simplicity tradeoff are

recorded to docs/tradeoffs.md (or the in-file template) when real alternatives were weighed.

Anti-Patterns: Eight Named Drift Rails

Each drift rail names a specific way LLM-driven coding goes wrong, with a trigger pattern, a short bad example, a short good example, and a one-sentence test you can apply to your own diff. Naming the rail helps recall.

Adapted from observations distilled by Forrest Chang from Karpathy's notes; see references/source-attribution.md for the citation chain. Examples are rewritten in our own prose to illustrate the failure shape, not lifted verbatim.

AP-1: Hidden Assumptions

Maps to: Principle 1 (Think Before Coding)

Trigger: User asks for a feature with multiple unstated dimensions (scope, format, volume, privacy). The agent picks one silently and ships.

Bad shape

def export_users(format='json'):
    users = User.query.all()
    if format == 'json':
        with open('users.json', 'w') as f:
            json.dump([u.to_dict() for u in users], f)

Assumed: all users (privacy?), file path, fields, volume.

Good shape

Before implementing, I want to confirm:

>

- Scope: all users, or filtered?

- Format: download, background job, or API endpoint?

- Fields: which? Some are sensitive.

- Volume: thousands or millions?

>

Default proposal: a paginated JSON endpoint. Adjust?

Test: count silent assumptions in the diff. Three or more is a rail violation.

AP-2: Multiple Interpretations Picked Silently

Maps to: Principle 1 (Think Before Coding)

Trigger: A request like "make the search faster" has at least three valid readings (response time, throughput, perceived speed). The agent picks one and implements 200 lines without flagging the choice.

Bad shape

@lru_cache(maxsize=1000)
async def search(query: str) -> List[Result]:
    # 200 lines of caching, async, indexes, all picked
    # without confirming what "faster" means
    ...

Good shape

"Faster" could mean response time, throughput, or

perceived speed. Each is a different fix:

>

1. Response time: indexes plus query caching (~2h)

2. Throughput: async path plus pooling (~4h)

3. Perceived: progressive load and partial results

(~3h)

>

Current: ~500ms typical. Which axis matters?

Test: when the verb in the request is ambiguous (faster, better, cleaner, simpler), did the agent name the alternatives or pick one?

AP-3: Strategy Pattern for One Function

Maps to: Principle 2 (Simplicity First)

Trigger: User asks for a single function. The agent ships an abstract base class, two implementing classes, a config dataclass, and a coordinator class for ten lines of arithmetic.

Bad shape

class DiscountStrategy(ABC):
    @abstractmethod
    def calculate(self, amount: float) -> float: ...

class PercentageDiscount(DiscountStrategy):
    def __init__(self, p): self.p = p
    def calculate(self, a): return a * (self.p / 100)

# Plus FixedDiscount, DiscountConfig, DiscountCalculator
# for what should be one function

Good shape

def calculate_discount(amount: float, percent: float) -> float:
    return amount * (percent / 100)

Test: count types and classes added per actual use case. If types-added exceeds use-cases-served, the pattern is premature.

AP-4: Speculative Features

Maps to: Principle 2 (Simplicity First)

Trigger: "Save user preferences to database" becomes a class with optional caching, validation, notification hooks, and merge semantics. None were asked for.

Bad shape

class PreferenceManager:
    def __init__(self, db, cache=None, validator=None):
        ...
    def save(self, user_id, prefs,
             merge=True, validate=True, notify=False):
        # 60 lines of optional behavior

Good shape

def save_preferences(db, user_id: int, preferences: dict):
    db.execute(
        "UPDATE users SET preferences = ? WHERE id = ?",
        (json.dumps(preferences), user_id),
    )

Test: list every parameter that was not in the request. If you cannot point at a sentence in the request that demanded it, delete the parameter.

AP-5: Drive-by Refactoring

Maps to: Principle 3 (Surgical Changes)

Trigger: User reports a single bug. The agent fixes the bug, then "improves" three other functions, adds docstrings, and tightens validation logic that nobody asked about.

Bad shape: a 90-line diff to fix a 4-line bug, with related but unrequested cleanups across two more files.

Good shape: a 4-line diff that fixes only the reported bug. If you noticed unrelated issues, list them in the response and ask before touching them.

Test: read the diff line by line. For each changed line, ask "which sentence in the user's request demanded this?" Lines without an answer are candidates for removal from the diff.

AP-6: Style Drift During Edit

Maps to: Principle 3 (Surgical Changes)

Trigger: User asks for one logging line in an upload function. The agent ships type hints, docstrings, single-quote-to-double-quote conversion, and a flattened control flow.

Bad shape

- def upload_file(file_path, destination):
+ def upload_file(file_path: str, destination: str) -> bool:
+     """Upload file to destination."""
      try:
-         with open(file_path, 'rb') as f:
+         with open(file_path, "rb") as f:
              ...

Good shape

+ logger = logging.getLogger(__name__)
+
  def upload_file(file_path, destination):
+     logger.info(f'Starting upload: {file_path}')
      try:
          with open(file_path, 'rb') as f:
              ...

Test: the diff should not change quote style, type hint presence, docstring presence, or whitespace patterns unless the request named them.

AP-7: Vague Success Criteria

Maps to: Principle 4 (Goal-Driven Execution)

Trigger: "Fix the authentication system." The agent responds "I will review the code, identify issues, make improvements, and test." That is a plan shape, not a verification plan.

Bad shape: a four-step list of verbs (review, identify, improve, test) with no checkable signal per step.

Good shape

"Fix authentication" is too broad to verify. Best

guess at the actual problem: sessions stay alive

after password change. Plan:

>

1. Write failing test: change password, prior

session is rejected.

2. Implement: invalidate sessions on change.

3. Edge cases: concurrent change, multi-session.

4. Regression: full auth suite green.

>

Is the password-change-stale-session bug the right

target?

Test: each step in the plan should have a one- sentence "verify by ..." attached. If a step lacks one, the step is ill-specified.

AP-8: Multi-Step Plan Without Verification Gates

Maps to: Principle 4 (Goal-Driven Execution)

Trigger: "Add rate limiting." The agent ships 300 lines with Redis backend, configuration system, and monitoring in one commit, with no per-step verification.

Bad shape: one large commit covering basic limits, middleware extraction, Redis integration, and configuration. Nothing is independently shippable or revertible.

Good shape

Plan, each step independently verifiable:

>

1. In-memory limit on one endpoint. Verify: 11

requests, the 11th gets 429.

2. Extract to middleware, apply broadly. Verify:

/users and /posts both rate-limit; existing tests

pass.

3. Redis backend. Verify: limits persist across

restarts; two instances share counters.

4. Per-endpoint config. Verify: /search 10/min,

/users 100/min, parsed config tested.

>

Start with step 1?

Test: each step in the plan should be revertible on its own. If reverting step 3 breaks step 4, the steps are not independent and the plan needs a redraw.

How to Use This Module

When reviewing your own diff or someone else's, name the rail you see. "This is AP-5: drive-by refactoring" travels faster than "this could be simpler somehow." Naming the rail is the first half of fixing the rail.

Cross-references for the rails:

• AP-3, AP-4 connect to Skill(imbue:scope-guard) and

Skill(leyline:additive-bias-defense)

• AP-5, AP-6 connect to Skill(imbue:justify) and

the bounded-discovery.md rule

• AP-7, AP-8 connect to Skill(imbue:proof-of-work)

and Skill(superpowers:test-driven-development)

The Senior Engineer Test

A three-question battery to apply to your own code before claiming it is done. The questions stand in for the senior engineer who is not in the room.

Adapted from a self-check Karpathy calls out for agentic coding: ask whether a senior engineer would say this is overcomplicated. We expand the question into three concrete sub-questions that map to common LLM coding failures.

The Question

Would a senior engineer who is busy and a little

grumpy say this code is overcomplicated?

If yes, the diff is not ready.

The Three Sub-Questions

Q1: Could this be 50% shorter without losing meaning?

Most LLM-written code can be cut by a third to a half. If the diff is 200 lines, ask: which 100 lines exist because the agent felt clever, not because the problem demanded them?

Common 50% wins:

• Replace abstract base class plus two subclasses

with one function plus a parameter.

• Replace try-except wrapping every call with a

single boundary handler.

• Replace explicit getter and setter with direct

attribute access.

• Replace nested conditionals with a flat early-return

pattern.

Q2: Are abstractions earning their weight?

An abstraction earns its weight when it is used three or more times, or when it isolates a real boundary (network, disk, locale). A class with one consumer is ceremony. A factory with one product is ceremony.

Test: for every type, class, or helper added, count the call sites. One call site means the abstraction costs more than it saves.

Q3: Could a junior dev follow this in six months?

Six months means: docs may have rotted, original context is gone, the original author is on another team. The code has to carry its own meaning.

Failure signals:

• Names that mean something only if you remember the

ticket

• Comments that describe what the code does (the code

shows that) instead of why

• Indirection that requires three jumps to find the

actual logic

• Implicit invariants that nothing checks and nothing

documents

The Decision Tree

For each of Q1, Q2, Q3:
  - Yes -> next question
  - No  -> stop and address before shipping

If three Yes -> ship
If any No   -> rework that dimension first

A No answer is not a failure of the agent; it is the agent doing its job. Catching the violation before the senior engineer catches it is the entire point.

Worked Example

Diff under review: a class hierarchy for a single discount calculation.

• Q1 (50% shorter)? Yes obviously: one function

replaces five classes.

• Q2 (abstractions earning weight)? No: zero

additional call sites for the strategy pattern.

• Q3 (junior in six months)? No: two indirection hops

to find the multiplication.

Two No answers means rework. Replace the hierarchy with the function. Now Q1, Q2, Q3 are all yes.

When the Test Does Not Apply

The senior-engineer test assumes the code will be read again. For a one-shot data migration that runs once and is deleted, the test is too strict. See tradeoff-acknowledgment.md for the boundary cases.

Cross-References

• Skill(imbue:scope-guard) formalizes Q2 (does the

abstraction earn its weight) into the Worthiness formula.

• Skill(conserve:code-quality-principles) is the

KISS / YAGNI / SOLID foundation that Q1 leans on.

• Skill(leyline:additive-bias-defense) is the

burden-of-proof contract that backs Q2.

Tradeoff Acknowledgment: When Not to Apply These

The four principles bias toward caution. That bias costs speed. For a substantial portion of coding work the cost is worth paying. For a non-trivial minority, the cost is wrong. This module names the boundary honestly.

The upstream framing puts it as: "These guidelines bias toward caution over speed. For trivial tasks, use judgment." That sentence does the same work as this module, just compressed.

When the Principles Do Not Apply

Trivial One-Line Fixes

Asking three clarifying questions before fixing a typo in a comment is a parody of caution. For diffs under five lines with obvious intent, ship and move on. Principle 1 (Think Before Coding) is for ambiguous requests, not unambiguous ones.

Exploratory Spikes and Throwaway Scripts

A 50-line script that runs once, produces a CSV, and gets deleted does not need the senior-engineer test. It does not need TDD. It does not need careful abstraction analysis. The artifact's lifetime caps the time worth investing in its quality.

Test: if the script will run again next week, treat it like real code. If you will throw it away in an hour, do not over-invest.

Documentation-Only Changes

Style drift in docs is often the point. Rewriting a paragraph for clarity touches every line by design. Principle 3 (Surgical Changes) was written for code diffs, where adjacent edits hide intent. Prose is different.

Time-Boxed Prototypes

A "by Friday or we move on" prototype is a different artifact from a feature. Verifiable success criteria for a prototype look like "the demo runs end to end," not "the test suite is green." Calibrate ambition to the deadline.

Production Fires

When the database is on fire, "let's write a failing test first" is the wrong move. Stop the fire, then write the test that prevents the next fire. The Iron Law assumes a normal-operations context.

Contrarian Voices Worth Engaging

Three voices push back on rigorous-by-default LLM coding rules. Their critiques sharpen the boundary.

Simon Willison ("Not all AI-assisted programming is vibe coding," March 2025) defends throwaway prototyping as legitimate. His golden rule: do not commit code you cannot explain. That rule is compatible with everything in this skill, but it makes the throwaway-prototype boundary explicit.

Mastering Product HQ ("What Karpathy's CLAUDE.md misses") argues code simplicity does not equal scope simplicity. A 50-line solution to the wrong problem is still waste. The principles help with how to build; they do not help with what to build. For "what," see Skill(imbue:scope-guard) and Skill(imbue:feature-review).

NMN.gl ("Vibe Coding Considered Harmful," March 2025) warns that vibed black boxes compound. This is adjacent support for the principles, not pushback, but it names the real cost of skipping them at scale: each black box you accept becomes a future debugging expense.

The Honest Bottom Line

These principles solve a specific class of problem: LLM agents shipping wrong-shape code on tasks they could have shipped right with five minutes of upfront thought. That class is large. It is not universal.

If you find yourself about to invoke these principles on a task that fits in a sticky note, stop. The principles are the heavier path. Use the heavier path when the cost of getting it wrong is larger than the cost of slowing down. Otherwise, ship and move on.

Cross-References

• Skill(imbue:scope-guard) for "should we build

this at all" (the scope question this module punts on).

• Skill(imbue:feature-review) for prioritization

using RICE / WSJF / Kano scoring.

• Skill(conserve:decisive-action) for guidance on

when to skip clarification and proceed.

Verifiable Goals: A Reformulation Template

Vague tasks generate vague work. The fix is a mechanical reformulation: rewrite the request as a goal that has an unambiguous "done" signal. Then loop until the signal fires.

This module makes the reformulation explicit, with a template and worked examples.

The Template

Original request: <user's words>

Reformulated goal:
  Success signal: <something a script or test can check>
  Test that proves the signal fires: <how>
  Out-of-scope cleanups noticed: <list, do not fix>

The success signal must be checkable without human judgment. "It feels faster" is not a signal. "p95 under 200ms on the seed dataset" is.

Worked Examples

Example 1: "Add validation"

Original: Add validation to the user signup endpoint.

Reformulated:
  Success signal: requests with invalid email,
    missing username, or password under 8 chars
    return HTTP 400 with a JSON error.
  Test: three pytest cases, one per failure mode,
    asserting status 400 and a specific error key.
  Out of scope: rate limiting, password complexity
    rules, captcha. Mention but do not implement.

Example 2: "Fix the bug"

Original: Fix the bug where empty emails crash the
  validator.

Reformulated:
  Success signal: validate_user with email '' or
    None raises ValueError, not AttributeError or
    TypeError.
  Test: test_validate_user_empty_email and
    test_validate_user_none_email, both asserting
    ValueError before the fix lands.
  Out of scope: improving username validation, adding
    docstrings, refactoring quote style.

This pattern is the heart of Skill(imbue:proof-of-work) and the Iron Law: write the failing test first.

Example 3: "Refactor X"

Original: Refactor the upload service.

Reformulated:
  Success signal: the existing test suite for
    upload (12 tests) is green before the refactor,
    green after, with no test changes.
  Test: pytest tests/upload/ both before and after
    the diff, with diff capture.
  Out of scope: anything that requires changing a
    test. If a test must change, the request is
    behavior change, not refactor, and needs a new
    spec.

Example 4: "Make it faster"

Original: Make the search faster.

Reformulated:
  Success signal: median latency on the seed query
    set drops from current N ms to under M ms (M
    chosen with the user).
  Test: a benchmark script that runs 100 queries
    against the seed dataset and reports median.
    Captured before and after the change.
  Out of scope: throughput optimization, perceived
    speed, frontend caching. These are different
    "faster" axes. Confirm which one before starting.

This example also illustrates AP-2 (Multiple Interpretations): when "faster" is ambiguous, name the axis before reformulating.

Example 5: "Improve UX"

Original: Improve the checkout UX.

Reformulated:
  Success signal: a test user completes the checkout
    flow in 4 clicks or fewer (current: 7), with no
    blocking validation surprises.
  Test: a Playwright or manual click-through script
    that records click count and timestamp per step.
  Out of scope: visual redesign, copy revisions,
    accessibility audit. Mention but do not bundle.

Example 6: "Add rate limiting"

Original: Add rate limiting to the API.

Reformulated:
  Success signal (step 1): the 11th request to
    /signup in 60 seconds returns 429.
  Test: a curl loop in CI plus a pytest that
    simulates 11 sequential calls.
  Out of scope (this step): Redis backend,
    per-endpoint configuration, monitoring. Each
    is a separate reformulation.

This example illustrates AP-8 (Multi-Step Plan Without Verification Gates): each step gets its own reformulation, its own success signal, its own test.

Why This Works

When the success signal is a script or test, three things become true:

1. The agent can loop independently. No need to ask "is it good now?" The test answers. 2. The user can review by running the test, not by reading 300 lines of diff. 3. The work is self-documenting. The next person can see what "done" meant for this task.

Cross-References

• Skill(imbue:proof-of-work) is the contract that

enforces this template under the Iron Law.

• Skill(superpowers:test-driven-development) is the

RED-GREEN-REFACTOR loop this template feeds.

• /spec-kit:speckit-clarify command helps when the

reformulation surfaces an ambiguity that needs the user's input first.

Source Attribution

This skill is a derivation, not original work. Honest attribution belongs at the front, not the back.

Primary Source: Andrej Karpathy

The underlying observations about LLM coding pitfalls trace to Andrej Karpathy on X (formerly Twitter). The most-cited verbatim quote, anchoring principles 1 and 2, is the one Karpathy posted on agentic coding failure modes:

The models make wrong assumptions on your behalf

and just run along with them without checking. They

don't manage their confusion, don't seek

clarifications, don't surface inconsistencies, don't

present tradeoffs, don't push back when they

should.

Source: <https://x.com/karpathy/status/2015883857489522876>

Principles 3 (surgical changes) and 4 (goal-driven execution) are inferred from adjacent Karpathy posts and talks rather than a single tweet. Useful adjacent sources:

• Karpathy on AI-assisted coding rhythm (April 2025):

<https://x.com/karpathy/status/1915581920022585597>

• Karpathy "Software 3.0" / YC AI Startup School

(June 2025): <https://www.ycombinator.com/library/MW-andrej-karpathy-software-is-changing-again>

• Karpathy 2025 LLM Year in Review (Dec 2025), framing

Reinforcement Learning from Verifiable Rewards as the paradigm shift: <https://karpathy.bearblog.dev/year-in-review-2025/>

Distillation Source: Forrest Chang

The four-principle wording (Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution) is Forrest Chang's synthesis, not Karpathy's. The skill name "karpathy-guidelines" upstream describes derivation, not authorship.

Upstream repository:

• <https://github.com/forrestchang/andrej-karpathy-skills>
• License: MIT
• Files distilled from: CLAUDE.md, EXAMPLES.md,

skills/karpathy-guidelines/SKILL.md

This night-market skill rewrites prose in the project's own voice and conventions. No upstream prose is copied verbatim. Principles, naming, and attribution structure constitute facts and methodology, not protected expression.

Attribution Caveat

When citing this skill, prefer "derived from Karpathy's observations" over "Karpathy's principles." Karpathy named the failure modes; the four-principle architecture is a community distillation. Conflating the two is sloppy citation.

Adjacent Prior Art Surveyed

A tome:code-search pass surveyed nine adjacent repositories. Patterns absorbed or deferred are documented in the project specification. The repos:

Two patterns were absorbed into this skill: the drift-rail framing for anti-patterns and the calibration sub-rule under Think Before Coding. Two were deferred to follow-up issues: the agent-writable Project Learnings store and the PromptSentinel verb-detection hook.

Contrarian Voices Cited

The tradeoff acknowledgment module cites three voices that push back on rigorous-by-default LLM coding rules:

1. Simon Willison, "Not all AI-assisted programming is vibe coding" (March 2025): <https://simonwillison.net/2025/Mar/19/vibe-coding/> 2. Mastering Product HQ, "What Karpathy's CLAUDE.md misses": <https://www.masteringproducthq.com/p/what-karpathys-claudemd-misses-and> 3. NMN.gl, "Vibe Coding Considered Harmful" (March 2025): <https://nmn.gl/blog/dangers-vibe-coding>

These are referenced for intellectual honesty rather than to undermine the principles.

License

Upstream repository: MIT (Forrest Chang). This derivation: same plugin license as the night-market repository (MIT).