Foundational AI Course

WEEK 1 · THE FOUNDATION · 40 HOURS · REQUIRED

The first week of the Founder's Year. Everyone takes it. No exceptions.

---

Welcome, Founder

You're holding the most important week of your entire year at Kaern Schools. Not because it's the hardest — it isn't — but because everything else stands on top of it.

This week teaches you one meta-skill: how to operate AI as your execution engine. By Friday you will have used Claude to research, write, design, build, and ship a real artifact for your Kaern startup — the company you'll spend the year building. You'll do it without writing a single line of code yourself (unless you want to).

Who this is for

Absolute beginners. If you've never opened a terminal, never touched GitHub, never written a "prompt" more deliberate than a Google search — you are exactly who we built this for. No code required. No prior AI experience required. Just curiosity and a willingness to be a little uncomfortable for five days.

What you'll walk out with

By the end of Week 1 you will be able to:

1. Explain, in plain language, what a large language model actually is — and what it's great and terrible at.
2. Write clear, structured instructions that get you the result you wanted on the first or second try.
3. Work inside an AI project with files, tools, and a persistent "Brain" (your knowledge repo).
4. Break a big job into steps and direct several AI agents to do it — and verify the result.
5. Ship one real thing for your Kaern startup, end to end.

How the week runs

Five days. Eight hours each. Forty hours total. Each day has a theme, a few lessons, worked examples, hands-on exercises you do live with Claude, the mistakes everyone makes (so you can skip them), and a check-for-understanding before you move on. Mornings lean toward concepts and demos; afternoons are hands-on. We build daily and we ship Friday.

Your tutor

I'm Maya. I've led bootcamps for years, taken hundreds of people from "I'm not technical" to "I just shipped that." I'm warm but I'll push you. I'll give you analogies that stick, tell you why a thing matters, and ask you questions instead of just feeding you answers. When you're stuck, that's not failure — that's the part where the learning happens. Raise your hand (metaphorically — or literally in the cohort channel).

The one rule that governs this whole week

You don't just chat with AI. You learn to direct it.

A chatbot answers questions. A founder directs an execution engine. The difference between those two postures is the difference between a hobby and a company. Hold onto that. Everything this week is about moving you from the first to the second.

Let's begin.

---

Day 1 — Mindset & How AI Actually Works

Theme: AI is an execution engine you direct, not a magic oracle you consult.

Learning objectives

By the end of Day 1 you can:

1. Describe in plain language what a large language model (LLM) is and how it generates text.
2. Define context and the context window, and explain why they matter for every task.
3. List concrete things AI is great at and things it's bad at — and predict which a given task will be.
4. Adopt the operator's mindset: AI as an execution engine you direct and verify.

---

Lesson 1.1 — What is a large language model, really?

Teaching script (Maya):

"Okay, founders — let's kill the magic first, because magic is useless to an operator. Here's the honest version. A large language model like Claude is, at its core, a very, very good prediction machine. It was trained by reading an enormous amount of text, and what it learned to do is predict what word should come next, given everything before it. That's it. That's the engine.

Now — before you feel let down — think about what it takes to predict the next word well. To finish the sentence 'The capital of France is ___,' you need facts. To finish 'In conclusion, the three risks to this business plan are ___,' you need reasoning, structure, and judgment. So in learning to predict text, the model absorbed a staggering amount of how-the-world-works.

Here's my analogy. It's like the most well-read assistant you've ever met, who has read almost everything but remembers none of it perfectly, has no eyes or hands of its own, and will confidently keep talking even when it's unsure. Brilliant, fast, occasionally wrong with total confidence. Your job as a founder is not to be amazed by it — it's to direct it and check it.

So tell me: if it's a prediction machine, what do you think it's quietly bad at?"

Worked example:

Prompt: What is the capital of Australia? → Claude answers "Canberra." Correct, because that pattern is everywhere in its training.

Prompt: What did my co-founder email me yesterday? → Claude cannot know this. It has no access to your inbox, no memory of yesterday. If it answers confidently anyway, that's a hallucination — a confident guess dressed as a fact. The lesson: the model only knows what's in its training plus what you put in front of it.

Hands-on exercise:

Open Claude. Ask it three questions: (1) a general-knowledge fact, (2) something about you it could not possibly know, (3) a reasoning question like "If a train leaves at 2pm going 60km/h, when does it arrive 180km away?" Note which it nails, which it guesses, and which it reasons through. Write one sentence on each in your notes.

Common mistakes:

1. Treating the model as a database of true facts (it's a predictor, not a lookup table).
2. Assuming it knows your private context (it knows nothing you haven't given it).
3. Trusting confident tone as a signal of correctness (confidence ≠ accuracy).

Check for understanding:

1. In one sentence, what is an LLM fundamentally doing when it produces text?
2. Why can Claude correctly name a country's capital but invent a fake citation?
3. What does "hallucination" mean, and what causes it?

---

Lesson 1.2 — Context and the context window

Teaching script (Maya):

"Here's the single most useful concept this whole week: context. Context is everything the model can 'see' right now — your instructions, the files you've attached, the earlier messages in this conversation, the documents in your project. The model has no memory of yesterday and no access to your world except what's in its context window right now.

Picture the context window as the model's desk. A big desk, but finite. Whatever you put on the desk, it can use. Whatever's not on the desk might as well not exist. If you ask 'make this better' without putting this on the desk, you'll get generic mush — not because the model is dumb, but because you handed it an empty desk and asked it to organize.

This reframes your whole job. Most bad AI output isn't a model failure — it's a context failure. You knew something the model didn't, and you didn't put it on the desk. The founders who get spectacular results aren't writing magic words. They're curating the desk: the right instructions, the right examples, the right background, nothing irrelevant cluttering it up.

When a conversation gets very long, the desk fills up and older items get crowded. That's why we'll later use projects and files to keep the right things in front of the model.

So — when an answer disappoints you, what's the first question you should ask yourself?"

Worked example:

Weak: Write our pitch. → generic, could be any startup. Strong: Here's our one-pager [pasted]. We sell automated bicycle-washing systems to municipal bike-share operators in Germany. Write a 90-second investor pitch in a confident, plain-spoken voice. → specific, usable. Same model. The difference is what's on the desk.

Hands-on exercise:

Take a task you care about for your Kaern startup. First, ask Claude with zero context. Then ask again after pasting in 3-5 sentences of background plus one example of the style you want. Compare the two outputs side by side. Write down what changed.

Common mistakes:

1. Asking "improve this" without including this.
2. Assuming the model remembers a fact from a different chat (each conversation starts with a clean desk).
3. Dumping in huge irrelevant text, burying the signal under noise.

Check for understanding:

1. What is the "context window" in your own words?
2. Why does the same prompt produce better results when you add background?
3. If output is generic, what's the most likely cause?

---

Lesson 1.3 — Great-at / bad-at, and the operator's mindset

Teaching script (Maya):

"Let's get practical about where this engine shines and where it slips. AI is great at: drafting (emails, copy, code, plans), transforming (summarize, translate, reformat), brainstorming options, explaining concepts, and tireless repetition without complaint. It's unreliable at: precise arithmetic on big numbers, knowing recent or private facts, staying perfectly consistent across a long document, and admitting when it doesn't know.

Notice the pattern. It's strong on language and structure, weak on ground truth and exactness. So the operator's mindset is: use it for the language-and-structure muscle, and bring the ground truth yourself — or give it a tool to fetch the truth, which we'll do on Day 3.

This is why I keep saying execution engine, not oracle. An oracle you trust blindly. An engine you point at a job, let it run, and then check the output. A founder who ships great work with AI does three things on a loop: direct clearly, let it execute, verify the result. Direct, execute, verify. That loop is the whole job. It never goes away — not in Week 1, not when you're running a ten-agent fleet in Week 4.

The mindset shift I want from you today: stop asking 'what can the AI do for me?' and start asking 'what's the job, and how do I direct and verify it?' One is passive. One is how founders operate.

What's a task in your week that's all language-and-structure — perfect for AI — versus one that needs ground truth you'd have to supply?"

Worked example:

"Summarize these 12 customer emails into the top 3 complaints" — great fit (language + structure). "Tell me our exact revenue last quarter" — bad fit unless you hand it the actual numbers. Same engine, opposite reliability, because one needs ground truth you alone hold.

Hands-on exercise:

Make a two-column list: 5 tasks from your real life that are great-fit for AI, 5 that are bad-fit (or need you to supply ground truth). Then take one great-fit task and actually do it with Claude. Verify the result yourself before you accept it.

Common mistakes:

1. Using AI for exact math/figures without checking (it can be off — verify or give it the numbers).
2. Skipping the verify step because the answer "looked right."
3. Staying in passive "consumer" mode instead of directing the work.

Check for understanding:

1. Name two things AI is great at and two it's unreliable at, and the pattern behind both.
2. What are the three steps of the operator's loop?
3. Why do we call AI an "execution engine, not an oracle"?

---