I built a free course that teaches Claude Code. Inside Claude Code.
You open a folder, type "let's start", and an AI tutor called June walks you through everything. You're building from minute one.
Here's what you learn:
𝗠𝗼𝗱𝘂𝗹𝗲 𝟬
Set up Claude Code. Build a CLAUDE[dot]md that gives it permanent memory of who you are and how you work.
𝗠𝗼𝗱𝘂𝗹𝗲 𝟭
Build two AI agents that work together. One researches. One writes. They hand off automatically.
𝗠𝗼𝗱𝘂𝗹𝗲 𝟮
Build a slash command that encodes your own workflow. One word triggers the whole thing.
𝗠𝗼𝗱𝘂𝗹𝗲 𝟯
Connect Claude to Google Calendar via MCP. Claude reads and creates real events.
𝗠𝗼𝗱𝘂𝗹𝗲 𝟰
Build an orchestrator. One agent that routes work to specialist agents — the architecture inside every serious AI product.
𝗠𝗼𝗱𝘂𝗹𝗲 𝟱
Run experiments on your own agents. Understand the latency, cost, and quality tradeoffs before you build anything real.
Total time: ~6 hours. (Most people finish it in 3)
Free. No waitlist. No "comment below for access."
There's also a Slack community where people share what they've built.
Signup below
Don't pay $100/month for the Claude Max plan. Use these 7 hacks to protect your tokens (and your money):
1. When you keep 𝗺𝗮𝗻𝘆 𝘁𝗼𝗽𝗶𝗰𝘀 𝗶𝗻 𝗼𝗻𝗲 𝗰𝗵𝗮𝘁, Claude rereads all of them every time you send a message, even the ones you are done with.
𝗙𝗶𝘅: Start a new chat for each topic. When one gets long, ask for a short summary, copy it, and paste it into a fresh chat.
𝟮. 𝗪𝗵𝗲𝗻 𝘆𝗼𝘂 𝘂𝗽𝗹𝗼𝗮𝗱 𝗮 𝗣𝗗𝗙, Claude pays for it twice. Once to read the words, and again because it turns every page into an image and reads that too.
Fix: Copy the text out, paste it into a plain document, and upload that. Same words, a fraction of the cost.
3. Claude has three models.: A fast cheap one, a balanced one, and a heavy expensive one. Most people leave it on the heavy one for everything, even fixing typos.
Fix: Use the cheap one for small tasks and the heavy one for hard problems.
4. When Claude gets something wrong, you probably say "no, I meant this." That reply stacks on top of everything above it, and Claude rereads the whole pile to answer.
Fix: scroll up, edit your original message, and run it again.
5. If you upload the 𝘀𝗮𝗺𝗲 𝗳𝗶𝗹𝗲 𝘁𝗼 𝗳𝗶𝘃𝗲 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝗰𝗵𝗮𝘁𝘀, you pay to read it five times.
Fix: Put it in a Project once instead. Every chat inside that Project can use the file without uploading it again.
6. You explain everything about you and your work repeatedly.
Fix: Open Settings, then Capabilities, and tell Claude who you are, what you work on, and how you like answers. It carries that into every new chat, so you stop burning the first few messages re-explaining yourself.
7. Asking Claude to make a doc, sheet, or slide costs more than a normal answer. You build one, scrap it, and build again. And pay the cost for every iteration.
Fix: Get the plan right in a plain chat first, then build it once.
I changed those seven things and never hit the limit again. Same usage.
Saving tokens is the easy part. The real shift is when you 𝘀𝘁𝗮𝗿𝘁 𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝘄𝗶𝘁𝗵 𝗖𝗹𝗮𝘂𝗱𝗲.
I made a free course that does exactly that. You learn Claude Code inside Claude Code. 6 Modules:
1. How to write effective prompts
2. How to build a skill
3. How to build an Agent
4. How to connect apps via MCP
5. How to build a second brain
6. How to optimize cost, latency, quality
It takes 5 hours to build all of this. Completely FREE. (link in comments)
1. Automating my internal processes. I've been creating content for a very long time. And now I've automated 50% of it.
2. Built a news app that solves my biggest pains a) everything is click baity b) it's written for sensationalism and not explaining what really happened.
3. Interview + resume + job tool that adapts to what's happening in the real world and reduces users effort on low value tasks. (In progress)
4. Reduce doom scrolling (pre launch)
5. Simplest habit building tool (idea stage)
Last year I opened a folder on my laptop I had created in 2014. It's called "𝗠𝗶𝗹𝗹𝗶𝗼𝗻 $ 𝗶𝗱𝗲𝗮𝘀." It had more than twenty product ideas in it that I added over the last ~10 years. I read through them one by one, and most of them are still good ideas. But I had not built even a single one of them.
I have always loved building things that could make someone's life a little easier, even if it helped only one person. But wanting to build was never my problem. Actually building was.
Almost every idea in that folder needed a skill I did not have, like coding, mechanical engineering, or hardware. So I tried to learn those skills the usual way. I signed up for courses. I watched hundreds of hours of tutorials. I looked for co-founders who had the skills I was missing. Nothing worked. After a while I stopped trying, and I told myself this is just how it is. Some people have the ideas, and other people build them, and I was someone who only had ideas.
Then about six months ago, almost on a whim, I took one idea off that list and decided to build it myself. And I did. The whole thing, fully working, on my own, without ever learning the skills I had failed to learn for years. I still remember the moment it worked for the first time. I just sat there looking at the screen.
I realised that if I could build this one, I could build any of the others too.
So I kept building. Since that first one I have built more than five real products that people use. I have started and dropped at least ten more. I am working on three others right now. I am building ideas from that list faster than I can add new ones.
It has not been easy. There has been a lot of trial and error, some real wins and some real failures. The things that used to stop me have not all gone away. There are just far fewer of them now than there were five years ago. So I keep going, because I believe one thing.
Right now, anyone who wants to build something can actually build it.
𝗔𝗻𝗱 𝗜 𝗮𝗺 𝗻𝗼𝘁 𝗴𝗼𝗶𝗻𝗴 𝘁𝗼 𝘀𝘁𝗼𝗽.
That folder used to be a list of things I wished I could build. Now it is just a list of things I am building.
And that is why I am writing this.
What changed everything for me was 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 𝘁𝗼 𝗯𝘂𝗶𝗹𝗱 𝘄𝗶𝘁𝗵 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲. It did not take years. It took weeks. So I put everything I learned into a FREE course that teaches claude code inside claude code:
1. writing prompts that Claude actually follows.
2. building a skill that really matters
3. building an agent that takes actions
4. building a second brain that keeps you on track
If you have a folder of ideas you have never built, this is where you start building them. (Link in comments)
Niche tools for small businesses in india.
The original idea was limited to simple invoice generator + basic automation (like email responders, invoice follow ups, etc)
Over the years, the idea matured into driving efficiencies for SMBs via automation.
Why: majority of SMBs in India still struggle with being tech first. There are very few companies / people focusing on this segment. And it's a tough space to crack given limited budgets and the mental model of the founders around: "I'll find another more manual alternative which is cheaper than implementing systems"
I still want to give it a shot because building it is much much easier today. But I still don't have 1) distribution 2) ops model figured out.
𝗔𝗜 𝗣𝗿𝗼𝗱𝘂𝗰𝘁 𝗠𝗮𝗻𝗮𝗴𝗲𝗺𝗲𝗻𝘁 𝗶𝘀 𝗼𝘃𝗲𝗿𝗵𝘆𝗽𝗲𝗱. That is what I told myself when I first started working on AI products. Turns out, I had no idea what an AI PM really did.
After spending years watching world-class AI PMs, building AI products at scale, making 100s of bad decisions, I have a much better definition of the role.
But, sadly, even today, most PMs trying to work on AI are in the same boat: confused and clueless about "what does an AI PM actually do."
Here's the simplest mental model to think of an AI PM's role:
An AI PM is responsible for finding answers to these 7 questions.
1. What problem should we solve to maximize impact?
2. Does this need AI?
3. Do we have the right data?
4. How do we turn data into something useful?
5. How will users experience it?
6. How do we know it works before launch?
7. How do we keep making it better?
Let's understand in detail:
𝗪𝗵𝗮𝘁 𝗽𝗿𝗼𝗯𝗹𝗲𝗺 𝘀𝗵𝗼𝘂𝗹𝗱 𝘄𝗲 𝘀𝗼𝗹𝘃𝗲 The problem must be specific, validated with real users, and solution-agnostic. If you get this wrong, the model does not matter.
𝗗𝗼𝗲𝘀 𝘁𝗵𝗶𝘀 𝗿𝗲𝗮𝗹𝗹𝘆 𝗻𝗲𝗲𝗱 𝗔𝗜 This is the most important question an AI PM asks. And the answer is usually no. Saying no to AI when the situation does not call for it is not a failure. It is the job.
𝗗𝗼 𝘄𝗲 𝗵𝗮𝘃𝗲 𝘁𝗵𝗲 𝗿𝗶𝗴𝗵𝘁 𝗱𝗮𝘁𝗮 "We have data" is not a strategy. An explicit data plan that includes what data we need, what we have, and what is missing is the right strategy. AI is only as good as the data behind it.
𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝘁𝘂𝗿𝗻 𝘁𝗵𝗲 𝗱𝗮𝘁𝗮 𝗶𝗻𝘁𝗼 𝘀𝗼𝗺𝗲𝘁𝗵𝗶𝗻𝗴 𝘂𝘀𝗲𝗳𝘂𝗹 Simple prompt, ML model, RAG, or agents. Each has a different use case, cost profile, and failure modes. The PM who skips this hands those decisions to engineering.
𝗛𝗼𝘄 𝘄𝗶𝗹𝗹 𝘂𝘀𝗲𝗿𝘀 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝗶𝘁 Users need trust, control, and recovery. Design for when the AI fails, not only for when it works.
𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗸𝗻𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝗹𝗮𝘂𝗻𝗰𝗵 There is no binary pass/fail. Build an eval framework. Define good, bad, and edge cases. Ship only when the product clears your threshold.
𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗺𝗮𝗸𝗲 𝗶𝘁 𝗯𝗲𝘁𝘁𝗲𝗿 𝗮𝗳𝘁𝗲𝗿 𝗹𝗮𝘂𝗻𝗰𝗵 AI products degrade in production if you stop watching them. Sample live conversations. Add new failure modes to your test set. Never stop monitoring.
--
Want to ship your first AI product? I just launched a free Claude Code course taught inside Claude Code. (Link below)
Karpathy's claude [dot] md has 143k stars on GitHub.
Most people building with Claude Code haven't still read it.
Here are Karpathy's 4 rules that will change how you code
→ Think before you code
State your assumptions. if unsure, ask. If multiple interpretations exist, present all of them. Don't pick one silently and run with it.
→ Simplicity over everything
Write the minimum code that solves the problem. No abstractions nobody asked for. No "flexibility" that turns 50 lines into 200. If a senior engineer would call it overcomplicated, simplify.
→ Surgical changes only
Don't touch code unrelated to the request. Don't "improve" adjacent comments. Don't refactor things that aren't broken. Every changed line traces back to what was asked. nothing else.
→ Goal-driven execution
Turn vague instructions into verifiable success criteria before writing a single line. "Fix the bug" becomes "write a test that reproduces it, then make it pass." Don't tell the model what to do. Tell it what done looks like.
You won't lose your job to AI. You'll lose it to the PM who has shipped multiple AI product with consistently high quality, while you were still watching videos about prompt engineering.
Most PMs are stuck in the world of "traditional" product management. They are comfortable as long as the product works in a fixed pattern: "If X, then Y."
But here's the truth, AI PMs have moved on. They understand how AI works. They've built AI products. They know how to work with AI's unpredictability.
The good news is ....
that you can also become an AI PM, without an actual AI PM job. All you need is a structured approach and a good starting point.
Here is how I would learn how to build AI Products all over again
→ Find the right problem
→ Ensure that AI is the right solution
→ Have a data strategy
→ Scope the thinnest MVP slice to validate user-AI fit
→ Define quality
→ Build, evaluate, ship, iterate
I'm not making this up. I've built 5 AI products using this approach. I have helped 80 PMs in the AI PM Acclerator to build usable, fully functional AI products in just 8 weeks.
If we can do it, you can too.
Don't take my word. Try it yourself for FREE.
Here is my new free course on Claude Code (taught inside Claude Code) that will teach you
1. How Claude Code works
2. How to set up your first agent
3. How to create your first Claude skill
4. How to build an orchestrator that delegates tasks.
(Link in comments)
This free course teaches you Claude Code inside Claude Code.
Claude Code is an AI coding agent that builds products end to end. You describe what you want in plain English. It writes the code, tests it, and fixes its own mistakes.
Apps. Automations. Internal tools. Workflows.
Whatever you need.
The course takes you from zero to a working product in 5 hours. No engineering knowledge required. No programming experience.
If you've had an idea stuck in your head for months, after this course, you will know how to build it.
Completely free. Taught inside Claude Code.
Sign up below👇
Every Product Manager thinks they can "figure out AI" when they need to. They're wrong.
I've been too many product reviews where PMs confidently presented AI features they didn't understand.
The results were painful to watch.
Here's what traditional PM experience actually teaches you about AI PM (spoiler: not much):
𝗥𝗲𝗾𝘂𝗶𝗿𝗲𝗺𝗲𝗻𝘁𝘀 𝗪𝗿𝗶𝘁𝗶𝗻𝗴
↳ Traditional: "Sort search results by price"
↳ AI PM: "Rank results based on user preferences and intent using behavioral signals"
The shift? From precise instructions to desired outcomes.
𝗧𝗲𝘀𝘁𝗶𝗻𝗴 𝗦𝘁𝗿𝗮𝘁𝗲𝗴𝘆
↳ Traditional: A/B test → observe → ship winner
↳ AI: Offline evaluation → shadow testing → human review → gradual rollout
You're not just testing features—you're validating model behavior and output accuracy.
𝗦𝘂𝗰𝗰𝗲𝘀𝘀 𝗠𝗲𝗮𝘀𝘂𝗿𝗲𝗺𝗲𝗻𝘁
↳ Traditional: Engagement, conversion, NPS
↳ AI: All of the above PLUS precision, recall, model accuracy
You need to speak both languages: business metrics and model performance.
𝗣𝗼𝘀𝘁-𝗟𝗮𝘂𝗻𝗰𝗵 𝗥𝗲𝗮𝗹𝗶𝘁𝘆
↳ Traditional: Monitor adoption, optimize features
↳ AI: Monitor model drift, manage retraining pipelines, collect feedback data
An AI product literally evolves after launch.
𝗧𝗲𝗮𝗺 𝗖𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗶𝗼𝗻
↳ Traditional: Engineers, designers, analysts
↳ AI: Add ML engineers, data scientists, data engineers, compliance teams
The skill that matters most? Translation between business needs and technical constraints.
The opportunity is massive. But you need to start learning the new language of data, models, and probabilities—paired with the product mindset you already have.
I spent 3 hours using an LLM to convince myself of something. Then 10 minutes later it convinced me of the exact opposite. Both times I felt completely certain.
Here's what happened: I was drafting a take on a strategy decision. Fed it to the model, asked it to sharpen the argument. It did. Beautifully. I was sold.
Then, just to stress-test it, I asked the same model to argue the other side.
It demolished everything it had just helped me build. New framing, new evidence, new logic. All just as clean. All just as convincing.
The model wasn't wrong either time. It was just... compliant. Extremely, fluently, persuasively compliant.
This is the part nobody warns you about. LLMs are not thinking partners. They're world-class debaters who will take whatever side you hand them and make it sound airtight.
Useful tool. Dangerous mirror.