AI Engineering From Scratch

Use this guide to learn AI engineering

Most “learn AI” repos are fancy link lists, but I found this one is different.

ai-engineering-from-scratch by Rohit Ghumare has 230+ hands-on lessons across 20 phases, from linear algebra to autonomous agent swarms, written in Python, TypeScript, Rust, and Julia. But the scope isn’t what caught my attention. It’s the philosophy underneath the structure.

Every lesson follows six steps:

• a one-line motto

• the problem it solves

• the concept explained visually

• building it from scratch

• using it with real frameworks

and then the part most learning resources quietly skip: shipping something. Each lesson ends with a real artifact. By the time you finish a phase, you don’t just understand the concept. You have something in your outputs/ folder.

Most learning resources end at understand it. This one ends at ship it. That difference compounds fast.

What it covers:

The 20 phases span the full AI engineering stack:

• math foundations

• classical ML

• deep learning

• NLP

• computer vision

• speech and audio

• Ransformers

• generative AI

• reinforcement learning

• LLMs from scratch

• LLM engineering

• multimodal AIools and protocols

• agent engineering

• autonomous systems

• multi-agent swarms

• production infrastructure

and closes with ethics and alignment, not as an afterthought but as a deliberate final stop.

The sequencing matters. You build a neural network before touching PyTorch. You implement self-attention before fine-tuning anything. You write the agent loop before orchestrating a swarm. The whole repo makes a bet: that you can’t really engineer what you don’t understand. I think that bet is right.

One honest note

Some lessons are still stubs. The structure is complete but the content is uneven, a few phases are fully built out, others are being filled in. Worth knowing before you dive in.

Even so, the core idea, treating every lesson as a small software project with a real output, is something I haven’t seen applied consistently anywhere else. It changes the motivation loop. You’re not just studying, but you’re building a reusable library as you go.

I’m working on a full guide for navigating this repo, because dropping someone into 230 lessons across 20 phases without a map is just unkind. That post will cover where to start based on your background, which phases matter most if agents are your focus, and what you can safely skip.

For now, the repo is here. Start by reading how the lessons are structured. That alone is worth the visit.

---

Most “Claude Code” workshops teach features.

This one teaches systems.

There’s no shortage of Claude Code tutorials right now.

You can learn commands, shortcuts, and prompting techniques almost anywhere.

What’s much harder to find is guidance on how to make Claude Code reliable inside a real engineering workflow.

How do you structure context? Build reusable skills? Enforce guardrails? Create workflows your team can actually adopt?

In this live workshop, Sam Keen (AI researcher and educator, former engineer at AWS, Lululemon, and Nike, and bestselling author of Clean Architecture with Python) will show how experienced engineers are moving beyond prompts and building systems around Claude Code.

You’ll learn how to:

• Structure context for consistency across sessions

• Build reusable workflows and skills

• Use hooks effectively

• Apply guardrails without bloating context

• Create workflows that scale across projects and teams

If you’re already using AI coding tools and want to move beyond ad-hoc prompting, this workshop is for you.

Limited seats available at 50% off using code CLAUDE50

---

Why AI Makes Git More Critical, Not Less

I spend a lot of time these days watching AI generate code. It is highly efficient, and slightly unsettling. Today, writing the actual syntax of software is a solved problem. If you need a script, a component, or a database query, you ask, and it instantly appears.

But this shift exposes a deeper truth about software engineering. Writing code was never the hardest part of the job; organizing, structuring, and collaborating on it is.

This is why Git has only grown more critical, not less. Even when an LLM writes ninety percent of your pull request, it still cannot manage the social and technical architecture of how that code merges with everyone else’s. Git is the history of our decisions, our dead ends, and our breakthroughs. Yet, for something so fundamental to modern development, our collective understanding of it is surprisingly shaky.

Most of us learn Git through survival-mode memorization. We keep a mental cheat sheet of five or six commands close by. We commit, we push, and we pray we never have to touch a detached HEAD. The moment a merge conflict happens, or we need to clean up a messy commit history before a pull request, the illusion of mastery shatters. We treat Git like a text-based magic spell because we cannot see what it is actually doing. We lack a clear mental model of the graph.

This is why I always recommend Learn Git Branching to anyone looking to bridge the gap between survival-mode memorization and actual comprehension.

The site is essentially an interactive visual sandbox. Instead of staring at abstract terminal output, you are given a live, real-time tree diagram. Every command you run instantly updates a visual graph. When you branch, you see a new node bud. When you merge, you see the lines weave together.

By turning command-line syntax into a spatial puzzle, the tool demystifies Git's trickiest concepts. The anxiety of typing a destructive command in your local terminal completely evaporates when you can safely break things in a visual playground.

Go give it a try, even if it is just the first few introductory levels. I would love to know what is the one Git command that still makes you hold your breath before hitting enter?

---

Watching the subscriber count grow is great, but numbers don’t tell me who you are. I want to know who is actually on the other side of this screen.

I made a quick, two-minute survey to help me write things that are actually useful to you. No marketing tricks, just a simple feedback loop.

If you have a moment to fill it out, it would mean a lot. Or, just hit reply and tell me: what is one technical challenge you are trying to solve this week? I read every response.

---