A single text file has gathered close to 200,000 stars on GitHub.

It contains no program. It is roughly seventy lines of prose setting out four behavioral rules for an AI. That this much attention landed on a note about conduct, rather than on a feature or a product, is itself a marker of the moment we are in.

The CLAUDE.md Phenomenon: Executive Summary

It Began as a Complaint About a Capable Subordinate

The story starts on January 26, 2026, with a post on X by the AI researcher Andrej Karpathy.

He described his own coding shifting from roughly 80 percent manual and 20 percent agent in November 2025 to 80 percent agent and 20 percent cleanup by December. He went so far as to say he is, in effect, now programming in English.

Yet in the same post he named the failures plainly. The model makes wrong assumptions on your behalf and runs with them without checking. It bloats a hundred lines into a thousand. It alters or deletes nearby code it does not fully understand.

Capable, but prone to overreach the moment it is left alone. The lament will be familiar to any manager who has handed real work to a brilliant new hire.

The Person Who Wrote the Rules Was Not Karpathy

This distinction matters, and it is easy to blur.

Karpathy did not turn his complaint into rules. The next day, January 27, the developer Forrest Chang distilled the observations into a note for the coding assistant to read, and published it on GitHub as a single file named CLAUDE.md — the instruction file such tools load at the start of every session.

The four rules are written in strikingly austere language.

  • Think Before Coding — "Don't assume. Don't hide confusion. Surface tradeoffs."
  • Simplicity First — "Minimum code that solves the problem. Nothing speculative."
  • Surgical Changes — "Touch only what you must. Clean up only your own mess."
  • Goal-Driven Execution — "Define success criteria. Loop until verified."

Note that every rule is built from "don't" and "only." Not one of them adds a capability. The file is subtraction — a frame drawn around a gifted subordinate to keep it from wandering.

The original repository alone holds about 176,000 stars as of June 2026, and reporting in May placed the combined total across mirrors above 220,000. Star counts vary by source and date, so the safe habit is to read them with the date and the repository attached.

How to Read "41 Percent Down to 11"

As the file spread, one number took on a life of its own.

The claim was that these four rules cut the AI's error rate from 41 percent to 11. It is crisp and eminently shareable. It is also not Karpathy's figure, nor an official measurement from the tool's maker.

It traces to one individual's private test, said to span thirty codebases, fifty tasks, and six weeks. The methodology is unpublished and the result unverified. Spin-offs have since appeared — "four more rules, down to 5 percent," "twelve rules, down to 3" — each more flattering and none substantiated.

Here sits a literacy every executive should carry. When a number promises AI productivity, ask first where it came from and how it was measured. Then test it on your own tasks before deciding. Crispness is not proof of truth.

What "The Four Rules Aren't Enough" Teaches

A second debate is also live on the ground: that four rules fall short for an era of many agents working at once.

One developer community listed four gaps. No cap on workload, so a debugging loop can run wild for ninety minutes. No checkpoints along the way. No protocol to read before writing. And no mechanism to prevent the quiet failure of reporting an unfinished task as done.

That last point lands squarely on a managerial nerve.

A subordinate who fails loudly is still manageable. The truly expensive one reports "done" while the work is not. AI agents fail in exactly this quiet way. So the heart of operating them shifts from coaxing out capability toward designing the supervision that makes failure visible.

Treat adoption as "hand it off and forget it," and you stumble here. The question is not delegation. It is oversight.

Not an Instruction Sheet, but a Blueprint for Supervision

Seen this way, the 200,000 stars mean something different.

People were not endorsing a clever shortcut. They were endorsing a universal craft of supervision — how to put a frame around a capable thing that overreaches. That is why it spread across languages and tools.

Karpathy called the shift a move from the imperative to the declarative. Don't dictate each step; give success criteria and watch it run. From managing the procedure to defining the goal and the boundary. This is hardly unique to AI. The better your people, the more they move on shared purpose rather than dictated steps.

So the file is at once a manual for disciplining AI and a mirror of how we lead people. Can you articulate the success criteria? Can you mark the boundary of what may be touched? Do you have a way to surface the quiet failures? An instruction that does not work on AI usually has not been working on people either.

Bringing It Back to the Business

Three decision points for your own organization.

First, hold your instruction assets as organizational assets. Without changing the model, a single sheet of guidance changes the output. The center of gravity in your investment moves from "which model" to "what guidance, version-controlled by whom." From private knack to shared standard.

Second, do not chase the numbers. The more dramatic the improvement rate, the harder you check its origin and method, and the more you test on your own work before adopting. That small discipline spares you the swing between hype and disillusion.

Third, design supervision rather than delegation. The scope you entrust to AI, the checkpoints, the mechanism that makes failure visible — decide these three first. They align, uncannily, with what management of people was supposed to do all along.

Seventy lines of text teach more than how to steer an AI. They also reveal how poorly we have been disciplining ourselves.

References