Karpathy Skills Repo: Discipline Over Features for AI Code

The interesting thing about Andrej Karpathy's new GitHub repository isn't what it adds to AI coding agents. It's what it takes away.

The repo—called "Karpathy Skills"—consists primarily of a single markdown file containing four engineering principles. No fancy automation. No benchmark-topping features. Just a behavioral framework designed to fix how AI coding agents actually fail in practice. According to a recent breakdown by AICodeKing, what appears to be a minimalist approach might actually be addressing the most persistent problem in AI-assisted development: agents that are technically capable but operationally undisciplined.

The Failure Pattern

Anyone who has used AI coding tools for production work recognizes the pattern immediately. The agent makes assumptions without asking clarifying questions. It generates 500 lines of architecture when 50 would solve the problem. It confidently refactors files that weren't part of the request. It creates messy diffs that touch unrelated code. As the video notes: "These agents often make assumptions too quickly. They over-engineer simple tasks. They edit files they were never asked to touch. They sound confident even when they are confused."

This isn't a capability problem—most modern coding agents can technically accomplish complex tasks. It's a behavioral problem. The agents lack the engineering judgment that human developers apply instinctively: when to ask for clarification, when to keep solutions minimal, when to stop.

Four Principles as Infrastructure

Karpathy's approach centers on four principles that function less like features and more like operating constraints:

Think Before Coding means the agent shouldn't silently guess at ambiguous requirements. If something isn't clear, surface the ambiguity. Ask the right clarifying question. Show the trade-offs. Don't just charge ahead hoping you interpreted correctly.

Simplicity First directly counters the over-engineering tendency. Write the minimum code needed to solve the problem. No speculative abstractions. No building frameworks for single-function tasks. No attempting cleverness for its own sake.

Surgical Changes addresses scope creep at the code level. Only touch what's necessary for the task. Don't randomly clean up unrelated code, rewrite comments, refactor adjacent functions, or improve things that weren't part of the request.

Goal-Driven Execution transforms vague requests into verifiable outcomes. Instead of "fix the bug" and hoping for the best, think in terms of success criteria: reproduce the bug, make the fix, verify it works, then stop.

As the video emphasizes: "What you're really installing here is not a feature. You're installing discipline."

Implementation as Philosophy

The technical implementation is deliberately lightweight. The repository provides two installation paths for Claude Code: a plugin marketplace installation that makes the guidelines available across all projects, or a simple per-project approach where you drop the CLAUDE.md file directly into your repository.

But the more significant aspect is how these principles actually function in practice. They don't operate as commands you invoke. You install them once, and they change the agent's default behavior.

Consider the billing dashboard example from the video. Without behavioral guidelines, an agent receiving the request "add a billing dashboard" might immediately generate database tables, API routes, webhooks, UI components, validation logic, and settings pages in one massive commit. The developer then faces a sprawling diff with no clear understanding of what decisions were made or why.

With the Karpathy principles active, the agent should first clarify scope: one-time payments or subscriptions? Which payment provider? Full dashboard or read-only summary? What's the minimal viable version? Only after establishing clear parameters does it proceed—and when it does, the changes should be focused, the code minimal, and the outcome verifiable.

The success indicators are practical: agents that ask better questions before coding, smaller and more focused diffs, elimination of random refactoring in unrelated files, and verification-based thinking instead of "trust me, I implemented it."

Portability as Design

What makes this approach particularly interesting from a policy perspective is its portability. The repository isn't tied to proprietary features or specific tools. The video demonstrates this with Verdant, another AI coding platform: "If your tool gives you a place for rules, agent memory, or system level instructions, you can usually carry the same ideas over."

This matters because it suggests a potential path for establishing behavioral standards across AI coding tools. Right now, each platform develops its own approaches to managing agent behavior. A shared framework based on engineering principles rather than technical features could provide consistency across tools.

The principles also function independently of installation. As the video notes, even without formally installing the repository, developers can adopt these principles in how they prompt AI agents. The difference is whether the discipline is manually applied each time or baked into the system by default.

The Regulation Question

From a regulatory standpoint, this raises interesting questions about how we should think about AI tool governance. Most policy discussions focus on model capabilities—what the AI can do. This repository implicitly argues that behavior—how the AI approaches tasks—might be equally important.

Current regulatory frameworks struggle to address this distinction. They tend to focus on preventing specific harmful capabilities rather than shaping beneficial behaviors. But in software development contexts, the harm often comes not from what the agent can't do, but from what it does without sufficient constraint: making assumptions, over-engineering, creating technical debt.

There's also a question of responsibility. If behavioral frameworks like this prove effective at reducing errors and improving reliability, should they become standard practice? Should platforms have obligations to implement similar constraints? Or is this purely a matter of developer choice and workflow preference?

The fact that these principles can be implemented as a single markdown file—no model retraining, no architectural changes—suggests that behavioral governance might be more achievable than capability governance. You're not trying to prevent the model from doing something it technically can do. You're giving it a better default framework for deciding when and how to act.

What Remains Unresolved

Several tensions remain. First, there's the question of when discipline becomes constraint. Simplicity is generally good, but complex problems sometimes require complex solutions. Surgical changes are ideal, but comprehensive refactoring is occasionally necessary. Goal-driven execution works well for defined tasks, but exploratory work requires different approaches.

Second, the effectiveness of instruction-layer interventions depends heavily on the underlying model's ability to follow complex behavioral guidelines consistently. A framework is only as good as the agent's capacity to internalize and apply it.

Third, there's a usability trade-off. Agents that ask more clarifying questions are more reliable, but also slower and more demanding of user attention. The optimal balance likely varies by context and user preference.

The repository presents a testable hypothesis: that AI coding agent problems are primarily behavioral rather than technical, and that lightweight instruction layers can address these problems more effectively than capability additions. Whether that hypothesis holds across different tools, models, and use cases remains an open empirical question.

What's clear is that the focus on discipline over features represents a different approach to AI tool development—one that might matter more for practical reliability than the next capability breakthrough.

— Samira Okonkwo-Barnes