Karpathy-Skill + Claude Code покращує поведінку AI-кодера: дисципліна замість хаосу

[music] >> Hi. Welcome to another video. So, today I want to talk about a GitHub repo that looks extremely simple on the surface. But I think it is actually one of the more useful things you can add to your AI coding workflow right now. It is called Andrej Karpathy skills. Now, despite the name, this is not really about some giant bundle of flashy skills or crazy automation. The main idea is actually much simpler than that. It is basically a lightweight instruction layer derived from Andrej Karpathy's observations about how coding agents usually fail. And if you have used AI coding tools for any real work, you already know exactly what he means. 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. And sometimes they will happily create 500 lines of architecture when 50 lines would have solved the problem. So, let's get right into it. What this repo tries to do is fix that behavior at the instruction level. According to the readme, the whole thing is centered around four principles. The first one is think before coding. This basically means the agent should not silently guess what you meant. If something is ambiguous, it should surface the ambiguity, ask the right clarifying question, or at least show the trade-offs instead of just charging ahead. The second one is simplicity first. This is one of my favorite parts because a lot of AI coding tools still have this weird urge to overbuild everything. This repo pushes the agent to write the minimum code needed to solve the problem. No speculative abstractions, no giant framework for a one function task, no trying to be clever for no reason. The third principle is surgical changes, and this one is super important. The agent should only touch what is necessary for the task. It should not randomly clean up unrelated code, rewrite comments, refactor adjacent functions, or improve stuff that was not part of the request. And then the fourth principle is goal-driven execution. This is basically about turning vague requests into verifiable outcomes. So, instead of just saying fix the bug and hoping for the best, the agent should think in terms of success criteria. Reproduce the bug, make the fix, verify that it works, and then stop. So, this is kind of great because what you're really installing here is not a feature. You're installing discipline. That is why I think this repo matters. It is not trying to make the model sound smarter. It is trying to make the workflow more reliable. And to be honest, that is what most people actually need. Now, let me explain what this thing actually is in practice. The repo is basically centered around a single Claude.md file, plus a plugin install path for Claude code. So, this is not some giant complicated setup. It is intentionally lightweight. You can use it in two main ways. The first way is the Claude code plugin path, which is the recommended option in the repo. The readme says you first add the marketplace with plugin marketplace add forest chang andrej karpathy skills, and then install it with plugin install andrej karpathy skills at karpathy skills. That makes it available as a Claude code plugin. So, the guidelines can be used across your projects. The second way is the simpler per project route. If you want it only inside one repo, you can just download the Claude.md file directly into your project. For new project, the readme shows this. And if you already have a Claude.md, you can append it instead of replacing your existing project instructions. So, the setup itself is actually very easy. But now the more important question is, how do you use it? And this is the part that I think people misunderstand. You do not really use this like some separate feature where you type a fancy {slash} command every time. You install it once, and then it changes how your agent behaves during normal work. So, for example, let us say I ask my coding agent to add a billing dashboard. Without these kinds of guidelines, a lot of agents will just start coding immediately. They create tables, API routes, webhooks, UI components, validation, maybe even some settings pages, all in one go. And then you have to inspect a giant diff and figure out what on earth it just did. With these Karpathy-inspired guidelines in place, the ideal behavior is very different. The agent should first clarify the scope. Are we talking one-time payments or subscriptions? What provider are we using? Do we need a full dashboard or just a read-only billing summary? What is the minimal version needed right now? Then it should keep the solution simple. Then it should make only the necessary edits. Then it should verify the result with a concrete check, a test, or some kind of success criteria. That is the real usage pattern. You are basically giving the agent a better default operating system for engineering work. Now, there's also a nice practical way to know if it is actually working. If you install this and your agent starts asking better clarification questions before writing code, that is a good sign. If your diffs get smaller and more focused, that is a good sign. If it stops randomly refactoring neighboring files that had nothing to do with the task, that is a very good sign. And if it starts thinking in terms of verification instead of just I implemented it, trust me, that is also exactly what you want. So, this is not really about adding power in the usual sense. It is about removing failure modes. And that is why I like it. Now, briefly, I want to mention how I think about this with Verdant because I do use Verdant, and that is why I would configure it there, too. I would not frame it as installing it exactly the same way inside Verdant. I would frame it more as porting the philosophy. Since Verdant already lets you define project context, rules, and agent behavior, I would just take these same four principles and place them into my Verdant instruction setup, so the agents follow the same discipline there, as well. So, the point is not really Verdant itself. The point is that these guidelines are portable. If your tool gives you a place for rules, agent memory, or system level instructions, you can usually carry the same ideas over. And that is one of the biggest strengths of this repo. It is not tied to some magical proprietary feature. It is a reusable way of making AI coding agents behave more like careful engineers. Now, one more thing I want to say here is that this repo is valuable even if you never install it exactly as is because the four principles are just solid advice for prompting coding agents in general. Think before coding. Keep it simple. Change only what is necessary. And define success clearly. If you start prompting your agents with that mindset, you will already get better results. But if you actually install the repo and bake those principles into the tool itself, then you do not have to remember to restate them every single time. The discipline is already there by default, which is pretty good, for sure. So, my overall take is this. Andrej Karpathy skills is not a hype repo. It is not trying to wow you with some giant dashboard or some fancy benchmark claim. It is solving a very real problem, which is that coding agents are often capable but badly behaved. This gives them a better behavioral framework. It helps reduce wrong assumptions. It helps reduce over-engineering. It helps reduce messy diffs. And it pushes the agent toward verifiable goal-driven execution. That is useful in Claude code. That is useful in any tool where you can inject rules. And in my case, because I use Verdant, too, I would absolutely carry the same principles over there as part of my configuration. So, yes, I think this is worth trying. Overall, it's pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the super thanks option or becoming a member [music] by clicking the join button. Also, give this video a thumbs up and subscribe to my channel. I'll see you in the next one. Until then, bye. >> [music]