Andre Karpathy posted a long thread on X about how his coding workflow
completely flipped.
He went from 80% manual coding to 80% agent coding in just a few weeks, and he was pretty honest about it. He said he is now mostly programming in English, telling the model what to write in plain words.
But the interesting part was not the productivity gains. It was the failures.
He laid out clearly how coding agents keep messing up in ways that are not obvious.
They are not writing broken syntax anymore.
The mistakes are deeper. They make assumptions about what you meant and keep going without checking.
They pick one interpretation out of three possible ones and commit to it silently.
They do not ask you to clarify.
They just act confident and move forward.
And then you end up reviewing a giant pull request that solves a problem you never actually had.
So that thread got a lot of attention, and a developer named Forrest Chang took the core ideas from that post and turned them into a single file, a file called claud dot m d. It is a set of behavioral guidelines for claud code. The repo is called Andre Karpathy Skills, and it is on GitHub right now. It has more than 26 thousands, and honestly, it is one of the most practical things I have seen in this space recently.
Not because it does anything fancy,
but because it targets the exact problems that waste the most time when you are working with AI coding agents every day.
Okay. So before I show you how to install it and use it, I want to explain why this matters.
Because if you have not run into these problems yet, you probably will soon.
And if you already have, then you know exactly what I am about to describe. The first problem is silent assumptions.
You ask your agent to add user authentication.
There are 10 different ways to interpret that. Session based? Token based? OAuth?
The agent does not know. But instead of asking you which direction to go, it just picks one and starts building. And it picks the most complex version.
So twenty minutes later, you have a 400 line auth system with OAuth, refresh tokens,
and role based access control.
All you needed was basic email and password for a prototype. The model guessed instead of asking. The second problem is overengineering.
You ask for a simple function that formats a date string. You get back a configurable date formatting utility class with six methods, a builder pattern, and error handling for edge cases that will never happen. The model writes 200 lines when 30 would do. It is trained on massive code bases where abstraction is valued,
so it defaults to that style even when the task is small. The third problem is scope creep in edits. You ask the agent to fix a bug in one function, it fixes the bug. But it also reformats the file, renames variables,
cleans up comments that were not part of the task, and refactors an adjacent function that was fine.
Now your diff is 40 lines instead of four, and you have to review every change to make sure nothing broke. The fourth problem is the lack of verification.
You tell the agent to add form validation.
It adds the validation code and says done, but did it actually test it? Did it check if it handles empty strings, special characters,
values that are too long? Usually no. It just writes the code and moves on. There is no verification step. There is no success criteria.
It does what you asked in the most literal way and calls it finished.
So those are the four core problems, and the Carpathi Skills repo addresses each one with a matching principle.
The first principle is called think before coding.
It basically tells the agent to stop and surface any ambiguity before writing a single line. If there are multiple ways to interpret a request, list them. If something is unclear, ask. Do not guess. The second principle is simplicity first. Write the minimum code needed to solve the problem.
No speculative features.
No abstractions for things that are only used once. Alright. So now let me show you how to actually set this up.
I am going to go through the installation, and then we are going to build a small project with it so you can see the difference. So I am on my screen right now. There are two ways to install this. The first way is the recommended one, and that is the Claude Code plugin route. You open Claude Code and run slash plugin marketplace add Carpathi skills that adds the marketplace.
Then you run slash plugin install skills. And that is it. Now the guidelines are installed as a plugin, which means they apply across all your projects automatically.
You do not have to copy any file into each project folder. It just works everywhere.
The second way is the per project route.
This is for when you only want the guidelines inside one specific project.
You open your terminal, go to your project folder, and run this cURL command that downloads the file straight into your project root. Now if you already have a claud. Md file and you do not want to lose your existing rules, you can append instead of overwrite.
The repo shows the command for that. You run echo to add a blank line and then curl the file content and pipe it into your existing claud. Md.
Your project rules stay on top and the Carpathi guidelines get added at the bottom.
Either way takes about ten seconds. Okay. So now that it is installed,
let me actually build something with it so you can see how the agent behaves differently. I am going to ask Claude Code to build a simple ecommerce dashboard.
Nothing crazy. Just a front end page that shows total revenue, number of orders, top selling products, and maybe a recent orders table. The kind of thing you would want to glance at to see how your store is doing. So I type my prompt, build an ecommerce dashboard page that shows total revenue, order count, top products, and a recent orders table, use React and Tailwind, keep it simple, and now watch what happens. With the Carpathathy guidelines active, the first thing the agent does is ask me questions.
It wants to know if the data should come from a real API or if hard coded sample data is fine for now.
It asks if I want the dashboard to be responsive or desktop only. It asks if I need any filtering or date range selector or if this is just a static snapshot view. This is exactly the behavior we want. It is not guessing. It is asking. I tell it sample data is fine, desktop only for now, and no filters needed. Just the basic overview. And then it builds exactly that, nothing more. The output is clean. One file, maybe 120
lines of code. Four stat cards at the top, a simple table for recent orders, and a short list of top products.
No router setup, no state management library,
no API service layer, no authentication wrapper, no dark mode toggle. Just the dashboard I asked for. And if you have ever asked an agent to build a dashboard without these guidelines, you know what usually happens.
You get six to eight files, maybe 500 lines, with a full component tree, context providers,
a mock API with fetch hooks, loading skeletons, pagination, and a sidebar navigation for pages that do not even exist yet. For a prototype,
for something you just needed to check a layout idea,
that is the difference these guidelines make. And here is the other thing I noticed. The diff is exactly what I expected.
Every line that changed traces back to what I asked for. There are no surprise edits, no renamed variables in other files, no reformatted comments, no drive by refactors.
Just the code I asked for, and nothing else. That is the surgical changes principle doing its work. You spend way less time reviewing because there is less noise in the output. And now there is a trade off the repo is honest about. These guidelines bias toward caution over speed. For simple stuff like fixing a typo, you do not need the full rigor. The guidelines are meant for nontrivial work.
The kind where wrong assumptions cost you hours and over engineering means throwing away the output.
And I think that is what makes this repo different from a lot of other stuff in the AI coding space right now. It is not trying to impress you, it is solving a very specific,
very real problem.
Coding agents are capable, but they behave badly.
They make silent mistakes that look correct on the surface.
They build too much when you need too little. They touch things they should not touch, and they do not verify their own work.
This file corrects those patterns in about 50 lines of markdown. If you are using Claude code regularly,
this is worth trying. It takes ten seconds to install, and the worst case is you delete the file. But once you see the difference in your diffs and code reviews, you will want to keep it. Alright, so that's it from the video, and I hope you enjoyed it. If you did, please like this video and subscribe to the channel, and I'll see you in the next video.