Courseware / Software Engineering / course-016
Guiding LLMs to Write Better Code: Leveraging CLAUDE.md and Karpathy's Coding Rules
Tweet@akshay_pachaarView Source →

🎙 Podcast Version

2-host dialogue — ALEX & SAM discuss this course.

Guiding LLMs to Write Better Code: Leveraging CLAUDE.md and Karpathy's Coding Rules

Overview

This course explores how a single markdown file named CLAUDE.md can dramatically improve the quality of code generated by large language models (LLMs). By examining the viral success of a CLAUDE.md file that garnered 192 k GitHub stars, we uncover the underlying principles derived from Andrej Karpathy’s observations about LLM coding tendencies. Learners will understand why LLMs tend to over‑engineer, ignore existing project patterns, and introduce unnecessary dependencies, and how a concise guideline file can mitigate these pitfalls. The course equips software engineers, AI‑assisted developers, and technical leads with concrete techniques to steer LLMs toward producing maintainable, idiomatic code that aligns with established codebases.

Background & Context

The rise of AI‑pair programming tools such as GitHub Copilot, Amazon CodeWhisperer, and various open‑source LLM‑based code assistants has transformed everyday software development. While these models excel at generating syntactically correct snippets, they frequently produce code that diverges from a team’s conventions, introduces heavyweight libraries, or solves problems in unnecessarily complex ways. Andrej Karpathy, a prominent AI researcher formerly at Tesla and OpenAI, identified three recurrent failure modes in LLM‑generated code: over‑engineering (building more abstraction than needed), ignoring existing patterns (reinventing wheels that already exist in the codebase), and adding dependencies you never asked for (pulling in external packages without explicit request). These observations sparked community interest in creating lightweight, project‑specific instruction files that LLMs can reference before generating code. The CLAUDE.md convention emerged as a simple yet powerful solution: a markdown file placed at the root of a repository that outlines coding standards, preferred patterns, dependency policies, and anti‑patterns. Its effectiveness was highlighted when a single CLAUDE.md file amassed over 192 k stars on GitHub, signaling broad endorsement from the developer community as a practical guardrail for AI‑assisted coding.

Core Concepts

CLAUDE.md File

A CLAUDE.md file is a plain‑text markdown document that lives in the top‑level directory of a software project. Its purpose is to communicate project‑specific guidelines directly to LLMs that are prompted to generate or modify code. Unlike traditional documentation aimed at human readers, CLAUDE.md is written in a concise, imperative style that LLMs can easily parse when included in the prompt context. Typical sections include:

  • Language and version constraints (e.g., “Use Python 3.11+; avoid Python 2 syntax.”)
  • Preferred libraries and frameworks (e.g., “Prefer the built‑in pathlib module over os.path for filesystem operations.”)
  • Dependency policy (e.g., “Do not add new third‑party packages without explicit approval; if a package is needed, justify its inclusion in a comment.”)
  • Code style rules (e.g., “Follow PEP 8; limit line length to 88 characters; use 4‑space indentation.”)
  • Anti‑patterns to avoid (e.g., “Do not create a new class for a single‑use function; prefer a plain function.”)
  • Testing expectations (e.g., “Every public function must be accompanied by a unit test in the corresponding test_*.py file.”)

When an LLM receives a prompt that includes the contents of CLAUDE.md (either verbatim or summarized), it treats those instructions as higher‑priority constraints, reducing the likelihood of generating code that violates them.

Karpathy’s Coding Rules (LLM Failure Modes)

Andrej Karpathy’s observation distills three systematic mistakes LLMs make when left unguided:

  1. Over‑engineering – The model tends to introduce unnecessary abstractions, such as creating interfaces, abstract base classes, or factory patterns when a simple concrete function would suffice. This stems from the model’s exposure to vast amounts of enterprise‑grade code where patterns are over‑represented.
  2. Ignoring existing patterns – Rather than reusing utilities, helpers, or established modules already present in the repository, the LLM often rewrites equivalent functionality from scratch. This leads to duplication and inconsistency.
  3. Adding unrequested dependencies – The model frequently suggests importing popular libraries (e.g., lodash, numpy, pandas) even when the task can be accomplished with the language’s standard library. This inflates the project’s dependency tree and can introduce licensing or security concerns.

These rules are not inherent flaws of the models but rather artifacts of their training data distribution. By explicitly encoding counter‑measures in a CLAUDE.md file, developers can bias the model’s output toward safer, more idiomatic code.

GitHub Stars as a Signal of Community Validation

The statistic that a single CLAUDE.md file reached 192 k GitHub stars serves as empirical evidence that the developer community finds value in lightweight, explicit LLM guidance. Stars on GitHub indicate that users have bookmarked the repository because they consider it useful, inspiring, or worth referencing. In this case, the repository likely contains a exemplary CLAUDE.md template that many projects have adopted or forked. The high star count underscores:

  • The scalability of a simple markdown file across diverse languages and domains.
  • The willingness of developers to adopt a low‑overhead practice that yields measurable improvements in AI‑generated code quality.
  • The emergence of a de‑facto standard for LLM‑oriented project documentation, akin to .editorconfig or .gitignore.

How It Works / Step‑by‑Step

Integrating a CLAUDE.md file into your workflow involves several concrete steps. Below is a detailed guide that assumes you are using a Git‑hosted repository and an LLM‑powered coding assistant (e.g., GitHub Copilot, Cursor, or a custom LLM endpoint).

  1. Create the CLAUDE.md file

At the repository root, add a file named CLAUDE.md. Use a clear heading structure and bullet points for readability. Example starter content:

```markdown

# CLAUDE.md – Coding Guidelines for LLM Assistance

## Language

- Use Python 3.11+; avoid deprecated syntax.

## Style

- Follow PEP 8; line length ≀ 88 characters; 4‑space indentation.

## Dependencies

- Do not add new third‑party packages without explicit approval.

- If a package is required, justify its use in a comment above the import.

## Preferred Patterns

- Use pathlib.Path for filesystem operations.

- Prefer functions over single‑method classes.

- Reuse existing utilities in utils/ before writing new code.

## Anti‑Patterns

- Do not create abstract base classes for a single implementation.

- Avoid deep nesting (>3 levels) without refactoring.

## Testing

- Every public function must have a corresponding unit test in tests/.

- Tests should achieve ≄80% line coverage.

```

  1. Ensure the file is committed and pushed

Run git add CLAUDE.md && git commit -m "Add LLM guidance file" && git push. The file must be on the default branch so that any LLM that indexes the repository can access it.

  1. Configure your LLM assistant to include CLAUDE.md in the prompt

- If using GitHub Copilot, enable the “Reference files” feature (available in Copilot Enterprise) and add CLAUDE.md to the list of context files.

- For Cursor or similar IDEs, open the settings and specify CLAUDE.md as an always‑included file.

- When prompting a custom LLM via API, prepend the file’s contents to the user query:

```python

prompt = open("CLAUDE.md").read() + "\n\nUser request: " + user_query

response = llm.generate(prompt)

```

  1. Validate the generated code

After receiving a suggestion, run your usual checks:

- Linting (flake8, pylint) to verify style compliance.

- Dependency scanners (pip-audit, safety) to ensure no unauthorized packages were introduced.

- Code review to confirm reuse of existing patterns.

  1. Iterate and refine

If the LLM repeatedly violates a rule, update CLAUDE.md with a more explicit directive or add an example. Over time, the file evolves into a living contract between human developers and the AI assistant.

Real-World Examples & Use Cases

Example 1: Refactoring a Legacy Python Script

A team inherits a legacy script that uses os.path.join extensively. They add a CLAUDE.md entry: “Prefer pathlib.Path over os.path for all path manipulations.” When a developer asks Copilot to “write a function that reads a configuration file from the user’s home directory,” the model returns:

from pathlib import Path

def load_config() -> dict:
    config_path = Path.home() / ".myapp" / "config.yaml"
    # ... rest of implementation

Without the guideline, Copilot might have suggested os.path.expanduser("~/.myapp/config.yaml"), which, while functional, deviates from the team’s preferred pattern.

Example 2: Preventing Unnecessary Dependency Injection

A Node.js project’s CLAUDE.md states: “Do not add new npm packages; use built‑in modules whenever possible.” A developer prompts the LLM to “create a utility that debounces a function.” The model, seeing the guideline, outputs a pure JavaScript implementation using setTimeout and clearTimeout rather than pulling in lodash.debounce. This keeps the dependency list lean and avoids potential version conflicts.

Example 3: Enforcing Testing Discipline

A Java repository’s CLAUDE.md includes: “Every public method must be accompanied by a JUnit test class named <MethodName>Test.” When the LLM generates a new service method, it also produces a skeleton test:

public class OrderServiceTest {
    @Test
    void testPlaceOrder() {
        // Arrange
        // Act
        // Assert
    }
}

This reduces the chance of forgetting to write tests, a common oversight when relying solely on AI suggestions.

Key Insights & Takeaways

  • A CLAUDE.md file provides a lightweight, version‑controlled mechanism to inject project‑specific constraints directly into LLM prompts, significantly reducing off‑spec code generation.
  • Karpathy’s three failure modes—over‑engineering, ignoring existing patterns, and adding unrequested dependencies—are predictable and can be mitigated by explicit anti‑pattern statements in CLAUDE.md.
  • The 192 k GitHub stars on a standalone CLAUDE.md file demonstrate broad community endorsement, indicating that developers view this practice as a valuable complement to traditional linting and CI checks.
  • Including CLAUDE.md in the context window of an LLM shifts the model’s behavior from generic code synthesis to context‑aware, policy‑driven generation, improving alignment with team standards.
  • Regularly revisiting and refining CLAUDE.md based on observed LLM mistakes turns the file into a living document that continuously improves AI‑assisted development outcomes.
  • The practice scales across languages and ecosystems; the same structural approach works for Python, JavaScript/TypeScript, Java, Go, Rust, and more.
  • Combining CLAUDE.md with automated checks (linting, dependency scanning, test coverage) creates a defense‑in‑depth strategy where AI suggestions are first filtered by policy, then validated by tooling.
  • Explicit dependency policies in CLAUDE.md help maintain a minimal, auditable supply chain, reducing security and licensing risks introduced by AI‑generated imports.
  • By encoding preferred patterns (e.g., “use pathlib”), teams can ensure that AI contributions reinforce, rather than fragment, existing codebases.
  • The effort required to maintain a CLAUDE.md file is minimal compared to the potential savings in code review time, refactoring effort, and technical debt avoidance.

Common Pitfalls / What to Watch Out For

  • Over‑loading the file with excessive detail – If CLAUDE.md becomes too long or overly prescriptive, LLMs may truncate or ignore parts of it. Keep guidelines concise, focusing on high‑impact rules.
  • Failing to update the file as the project evolves – Outdated guidelines can cause the LLM to suggest code that conflicts with newer standards. Schedule regular reviews (e.g., per sprint) to keep CLAUDE.md aligned with the actual codebase.
  • Assuming the LLM will always read the file – Not all LLM integrations automatically include external files. Verify that your tooling is configured to inject CLAUDE.md content; otherwise, the guidelines will have no effect.
  • Confusing CLAUDE.md with general documentation – CLAUDE.md is meant for directive content that influences generation models can be parsed as constraints, not explanatory prose. Avoid long narratives that dilute the actionable instructions.
  • Neglecting to enforce the rules via CI – Relying solely on the LLM to obey CLAUDE.md is risky; complement it with linters, dependency checkers, and test coverage gates to catch violations that slip through.
  • Using ambiguous language – Phrases like “prefer” or “consider” may be interpreted loosely by the model. Use stronger directives such as “must,” “shall not,” or “always” for critical rules.
  • Overlooking language‑specific nuances – A rule that makes sense for Python (e.g., “avoid globals()”) may be irrelevant or misleading for another language. Tailor each section to the primary language(s) of the repository.
  • Ignoring the model’s token limits – Extremely large CLAUDE.md files can consume a significant portion of the prompt’s token budget, leaving less room for the actual user request. Aim for brevity; if necessary, provide a summarized version for the prompt and keep the full file for reference.
  • Believing the file eliminates the need for human review – AI assistance augments, but does not replace, engineer judgment. Always review generated code for correctness, security, and suitability.
  • Neglecting to communicate the purpose to the team – If developers are unaware of CLAUDE.md’s role, they may overlook it or treat it as irrelevant documentation. Include a brief mention in the project’s onboarding README.

Review Questions

  1. Explain how the three failure modes identified by Andrej Karpathy (over‑engineering, ignoring existing patterns, adding unrequested dependencies) manifest in LLM‑generated code, and describe specific CLAUDE.md directives that counteract each mode.
  2. Outline the step‑by‑step process for integrating a CLAUDE.md file into a GitHub Copilot workflow, including how to verify that the file is being used as context during code suggestion generation.
  3. Given a JavaScript repository that currently lacks any LLM guidance, draft a concise CLAUDE.md snippet (no more than eight lines) that addresses the project’s complaints about frequent unnecessary imports of lodash and inconsistent use of const vs let. Explain why each line you include is likely to reduce those specific issues.

Further Learning

  • Study the official documentation for GitHub Copilot’s “Reference files” feature to learn how to prioritize context files in different IDEs.
  • Explore existing open‑source CLAUDE.md templates (search GitHub for CLAUDE.md stars) to compare styles and extract best‑practice patterns for various languages.
  • Investigate prompt‑engineering techniques such as few‑shot examples and chain‑of‑thought prompting that can be combined with CLAUDE.md for even greater control over LLM output.
  • Examine how tools like pre-commit, husky, and CI pipelines can be configured to lint CLAUDE.md itself, ensuring the guideline file remains syntactically correct and follows a chosen markdown lint standard (e.g., markdownlint).
  • Read research papers on “LLM grounding” and “retrieval‑augmented generation” to understand the theoretical basis for why providing external documents like CLAUDE.md improves model fidelity.
  • Experiment with creating language‑specific CLAUDE.md variants (e.g., CLAUDE-python.md, CLAUDE-js.md) and using conditional inclusion based on file type to tailor guidance more precisely.
  • Look into automated dependency‑approval bots (e.g., Dependabot, Renovate) and consider how their policies can be mirrored or reinforced through CLAUDE.md directives.
  • Participate in community discussions on platforms like Reddit’s r/MachineLearning or Stack Overflow about practical experiences with LLM‑guided development to gather real‑world anecdotes and evolving advice.
← Previous