You know that feeling when you try to actually learn AI engineering, and you end up with seventeen browser tabs, three Reddit threads, a Medium article from 2024, and someone’s half-finished GitHub repo? Two hours later, your brain looks like a junk drawer.

It’s like going to a night market where every stall only sells one dish. Braised pork over here, stinky tofu way over there, drinks across the street. You walk the entire thing just to piece together one meal — and by the time you’re done, you’re full. Not from eating. From walking.

Alexey Grigorev apparently felt the same way. So he did something simple but genuinely useful: he took the 200+ resources he’d collected while writing the AI Engineering Field Guide and released them as a standalone open-source list called Awesome AI Engineering.

Clawd Clawd OS：

Another awesome-xxx list, I know. You’re already reaching for the eye-roll button. But hold on — this one’s different from those “500 links nobody ever opens again” collections. Back in CP-137, we covered Karpathy talking about the shift in AI development workflows — that was about “how to do the work.” Grigorev’s list is about “what to read before you start.” The two pair perfectly ╰(°▽°)⁠╯

Most awesome lists just dump links into categories and call it a day. Grigorev’s list is different because it doesn’t collect “articles that sound impressive.” It collects “things written by people who got burned in production and lived to tell about it.”

Think about it. Anthropic’s prompt engineering docs? Those exist because customers kept asking the same questions until someone finally wrote them down. Netflix’s ML platform articles? Those are lessons from burning millions in GPU costs on their recommendation system. Uber’s feature store design? That’s an architecture that actually ran across thousands of microservices. These aren’t “10 Tips for Better AI” listicles. They’re battle reports with real scars.

And the scope is intentionally wide: how interviews are run, how to draw system designs, what production pitfalls look like, which books and podcasts are worth your time, even hiring trends.

Clawd Clawd 真心話：

You know what the real pain is? It’s not that you can’t find resources. It’s that you read ten articles about RAG, and not a single one tells you how to talk about RAG in an interview. We discussed this in CP-154 about Data Engineers transitioning to AI Engineering — the biggest barrier isn’t the tech, it’s not knowing where to start. Grigorev is trying to connect those dots (๑•̀ㅂ•́)و✧

Three Things That Were Always on the Same Road

The interesting part of this list isn’t the volume. It’s that Grigorev forces three things people usually look at separately back onto the same map:

How companies build AI systems → How they hire for it → What skills keep showing up

Think about it. When you read a system design doc, it doesn’t usually tell you “here’s how the interviewer expects you to explain this.” When you browse interview experiences, nobody connects the dots to “this question maps to a real production architecture at Company X.” But when you put them side by side, things that were fuzzy suddenly click.

It’s like finally dumping all your scattered puzzle pieces into one box — oh, they were the same picture all along.

Clawd Clawd 內心戲：

Honestly, the biggest problem in AI engineering right now isn’t a lack of resources. It’s too many resources with zero context. Your bookmarks probably have three hundred links in them. Can you explain how they relate to each other? Didn’t think so. Simon Willison made a similar observation in CP-169 about agentic engineering — the field moves so fast that even veterans get lost in the knowledge fragmentation ┐(￣ヘ￣)┌

From Research Side-Effect to Main Character

Here’s a neat detail: this list started as Grigorev’s personal research notes while writing the AI Engineering Field Guide. He didn’t sit down and say “I’m going to build an awesome list.” The list grew out of answering a real question.

That matters. Lists born from real work tend to be better than lists born from curation for curation’s sake. Every resource got included because it was needed in a specific context — not because someone was padding a category.

It’s like the difference between the stuff you actually use when you move apartments versus the stuff you thought you’d need. The gap can be enormous.

Clawd Clawd 插嘴：

My experience with organizing resources: start by collecting things to solve a problem, then realize the collection itself is valuable. That’s completely different from “create a Notion folder first and then wonder what to put in it.” One is actually useful. The other is cosplaying productivity (¬‿¬)

So How Should You Use This?

Grigorev’s own advice is pretty blunt: star it, save it, come back later.

But I think there’s a better way — don’t try to read it all at once. Preparing for interviews? Hit the interview section. Designing a new AI feature? Check system design and production case studies. The value of this list isn’t in how much you’ve read. It’s in knowing it’s there when you need it.

Remember the night market from the opening? What Grigorev did is basically draw you a map of the whole market — “savory food this way, desserts that way, drinks down this alley.” You still have to walk and eat yourself, but at least you’re not wandering blind anymore.

Clawd Clawd 想補充：

Alright, one last sharp thought. In a world where everyone screams “AI will replace engineers,” Grigorev went and did the most engineer thing possible — not writing code, not tuning models, but organizing knowledge into a path people can actually follow. Ironic, isn’t it? The least AI-like work might be exactly what’s missing most right now (╯°□°)⁠╯