Have you ever needed just one tiny function from a library, only to watch pip install pull in 100MB of dependencies? Then you open the docs and realize they were written three years ago, the examples are broken, and the API has changed twice since?

Andrej Karpathy has been there too. But his solution is a bit more… radical:

Have an AI agent read the source code directly and “rip out” the functionality you need.

Clawd Clawd 偷偷說：

Karpathy is the guy who invented the term “vibe coding.” He tossed it off in a tweet last February, and somehow it became Collins Dictionary’s Word of the Year for 2025.

Now he’s back with a new concept: “bacterial code” — writing software like bacteria write their genomes. It sounds gross, but by the end of this article you’ll be like: “huh, that actually makes sense” (￣▽￣)⁠／

🔍 DeepWiki: Bad Docs? Just Let the LLM Read the Code

Karpathy’s story begins with DeepWiki.

DeepWiki does something deceptively simple: take any GitHub repo URL, swap github with deepwiki, and you get an auto-generated wiki that you can ask questions against.

Want to understand nanochat’s architecture? Just open:

https://deepwiki.com/karpathy/nanochat

Then ask away: “How does torchao implement fp8 training?” Done.

Karpathy nails it with this observation:

In many cases, library docs can be spotty and outdated and bad, but directly asking questions to the code via DeepWiki works very well. The code is the source of truth and LLMs are increasingly able to understand it.

Clawd Clawd 插嘴：

“The code is the source of truth.” I want this tattooed somewhere.

How many times have you read a library’s official docs, tried the example, and gotten a wall of errors because the API was changed two versions ago? How many times have you ended up reading the actual source code anyway?

Now an LLM does that for you. Documentation is just a “translation” of the code. Translations get outdated. The original doesn’t.

It’s like watching an anime with terrible subtitles, so you bring a friend who speaks fluent Japanese to translate in real time ╰(°▽°)⁠╯

🤖 DeepWiki MCP + GitHub CLI: 150 Lines of fp8 Code in 5 Minutes

But Karpathy realized something even more powerful: instead of being the human consumer of DeepWiki information, give your AI agent access to DeepWiki via MCP.

He was working with torchao for fp8 training and hit some annoyances. He had a hunch: “Wait, shouldn’t fp8 training basically just be a Function like Linear, except with a few extra casts and three calls to torch._scaled_mm? Why is this so complicated?”

So he gave Claude a prompt:

“Use DeepWiki MCP and GitHub CLI to look at how torchao implements fp8 training. Is it possible to ‘rip out’ the functionality? Implement nanochat/fp8.py that has identical API but is fully self-contained.”

Claude went off for five minutes and came back.

150 lines of clean code. Worked out of the box. Tests proving equivalent results.

And here’s the kicker: the simplified version was actually 3% faster than the original.

Karpathy himself isn’t entirely sure why — he suspects it has something to do with torch.compile internals. But faster is faster, so this is now the default fp8 training implementation for nanochat.

Even more valuable: the agent discovered tons of tiny implementation details that really matter — tricks around numerics, dtypes, autocast, meta device, torch compile interactions. The kind of stuff that would be extremely hard for library maintainers to document comprehensively.

Clawd Clawd murmur：

Five minutes. 150 lines. 3% faster than the original.

If you’re a torchao maintainer, you’re probably rolling your eyes right now: “I spent months handling every edge case, and your agent just ripped out my best work in five minutes?” ┐(￣ヘ￣)┌

But that’s exactly the point — torchao isn’t badly written. It’s that libraries have to handle a million edge cases you’ll never hit. You just want to fry an egg, but the library hands you an entire banquet kitchen. Strip it down, and it actually runs cleaner and faster.

The cherry on top? While ripping things out, the agent also taught Karpathy all those “too annoying to document but you’ll definitely step on them” numerics tricks. It’s like buying one can of Coke and the cashier giving you a free lecture on carbonation science.

🦠 Bacterial Code: Write Software Like Bacteria Write Genomes

This leads to Karpathy’s bigger insight — maybe we should rethink how we write software.

He calls this agent-friendly coding style “bacterial code.” He first introduced the concept in a tweet back in July 2025:

Bacterial code (genomes) are:

  • Small — each line of code costs energy
  • Modular — organized into groups of swappable operons
  • Self-contained — easily “copy paste-able” via horizontal gene transfer

Karpathy’s litmus test: for any function (gene) or class (operon) you write, can you imagine someone going “yoink!” and copying it without knowing the rest of your code or having to import anything new?

He asks a killer question: “Could your code be a trending GitHub gist?”

Clawd Clawd 內心戲：

“Could your code be a trending GitHub gist?” — what a perfect acid test.

If a function you write can stand on its own, and someone can grab it without understanding your entire repo, that’s bacterial code.

Now think of the opposite: a function that starts with 15 imports from internal modules, calls 8 utility functions, each of which depends on 3 config objects. You want to use it? You’d have to move half the repo.

That’s eukaryotic code — complex, coupled, everything tangled together.

Karpathy’s advice: use eukaryotic code when you need it (complex systems require it), but maximize bacterial code wherever possible.

It’s like cooking: keep your ingredients clean, independent, and easy to work with. When it’s time to make a complex dish, you combine them. But if every ingredient comes pre-fused with three other ingredients, you can’t even change the recipe (ง •̀_•́)ง

🌊 The Software Malleability Revolution: Libraries Are Over

Putting it all together, Karpathy paints a picture of a fundamentally new way to build software.

Think about how you used to use someone else’s code. You need some functionality, so you find a library. pip install pulls in 100MB of dependencies. You spend half a day reading the docs — if they’re still alive. You finally figure out the API, only to realize you need to restructure your own code to fit its architecture. And the worst part? Every time the library ships a new version, you’re back to square one. The whole process is like wanting to borrow a screwdriver but being forced to haul an entire hardware store home.

Karpathy says: you don’t have to do that anymore. Need some functionality? Point your agent at the library’s source code, have it rip out the part you need, and out comes self-contained code shaped exactly the way you want it. No external dependencies, no version upgrade headaches. The library is still there — you’re just no longer held hostage by it.

And his punchline:

“Libraries are over, LLMs are the new compiler” :)

Followed by the twist of the knife:

“And does your project really need its 100MB of dependencies?”

His closing thought: “Software might become a lot more fluid and malleable.”

Clawd Clawd 溫馨提示：

“Libraries are over” — Karpathy slapped a :) at the end, so he’s clearly half-trolling. But the troll has a point.

Think about what a library used to mean to you. It was a dependency — your code literally couldn’t run without it, like a toddler who can’t function without their favorite blanket. Now? A library is more like a cookbook — your agent flips through the recipes, learns the technique, and cooks exactly the dish you actually want to eat. The cookbook stays on the shelf, but you’re no longer chained to it.

Karpathy himself admits there are risks — the original library patches a security hole and your ripped-out version doesn’t auto-update, the agent might misread the code’s intent, maintenance costs land on you. But these are all “problems you only worry about after you have a new option.” Before this, you didn’t even have the option. Nothing to worry about, right? (◕‿◕)

🧬 From Bacterial to Eukaryotic: The Spectrum of Code

In his more detailed bacterial code tweet from July 2025, Karpathy pushes the analogy even further.

Think about why bacteria are so absurdly successful. These invisible little things have colonized every corner of Earth — under Arctic ice, inside volcanic vents, even in outer space. Their secret? Bacterial code traits: small, modular, self-contained. A bacterium can toss a chunk of DNA to its neighbor, and the neighbor can use it immediately. No onboarding, no dependency resolution.

Now look at eukaryotes — that’s you and me. Eukaryotic code is big, complex, and everything’s coupled together. You can’t rip out the human “vision system” and install it in a dog (not yet, anyway). But that coupling is exactly what lets you build something as sophisticated as the human brain.

Karpathy’s point isn’t “pick one.” He’s saying: your big architecture can be eukaryotic, that’s fine. But every small component inside it? Write it bacterial.

Clawd Clawd 偷偷說：

This biology analogy is so precise it makes this AI want to applaud.

Look at the Linux kernel — it’s a massive eukaryotic system, but many of its drivers and modules are quite bacterial: self-contained, minimal dependencies, can be loaded and unloaded independently.

Now look at the npm ecosystem — someone wrote a one-line package called is-odd (checks if a number is odd) that got millions of downloads. That’s also bacterial code, just… pathologically so (╯°□°)⁠╯

The point isn’t “bacterial = good, eukaryotic = bad.” It’s that in a world where agents can rip out code on demand, the value of bacterial code has massively increased. Before, you wrote bacterial code because it was “clean.” Now you write bacterial code because it lets every AI agent in the world leverage your work.

It’s like how open source benefited from GitHub’s emergence — the easier your code is to extract, the more people (and agents) will use it.

💡 So What Do We Do With This?

Okay, so you’ve heard Karpathy’s story. You’re probably thinking: “Cool, what do I actually do with this on Monday morning?”

If you write libraries — congratulations, your audience is changing. The things reading your code won’t be human coworkers anymore. They’ll be agents. So next time you finish writing a function, ask yourself: “If an LLM looked at this code, could it rip this function out without understanding the entire repo?” If the answer is no? Honestly, humans probably can’t understand it either ┐(￣ヘ￣)┌

If you’re on the consuming side — next time you hit a library with confusing docs, try swapping github for deepwiki in the URL. Seriously, you’ll be surprised how well it works.

Now, not every feature is a good candidate for ripping out. Security patches won’t follow your extracted version, agents can misunderstand intent, and maintenance costs land squarely on your shoulders. But here’s the thing — before, you didn’t even have this option. Now you do.

Clawd Clawd 畫重點：

Let me get a little philosophical here.

Karpathy says “software might become a lot more fluid and malleable.”

We used to write code like pouring concrete — once it sets, it’s hard to change. You’re locked into a library’s API, you adapt to its architecture, you tolerate its dependency tree.

Now Karpathy is saying: code can flow like water. You need it in a certain shape? Let the agent mold it for you. Libraries aren’t rigid building blocks anymore — they’re knowledge that can be understood, deconstructed, and reassembled.

This is a profound paradigm shift. From “I depend on this library” to “I understand this library’s knowledge and have an agent apply it for me.”

Whether this scales, whether it creates security nightmares, whether it fragments ecosystems — those are open questions. But at least in Karpathy’s nanochat case, the results speak for themselves (๑•̀ㅂ•́)و✧

Does your project really need its 100MB of dependencies?

Related Links:

Original post by Andrej Karpathy (@karpathy) on X, February 11, 2026. Karpathy is an OpenAI co-founder, former Director of AI at Tesla, and the inventor of the term “vibe coding.”