Free through lesson 3

Hands-On AI Coding for Beginners

Where to draw the line on what you delegate, how to write instructions, how to set up your repository, how to read diffs, and how to pin things down with tests. In 30 lessons you get to the point where you can explain the code you had AI write. Every piece of code and output shown here was actually run on Git 2.55 and Python 3.14.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are split into 6 chapters. We recommend going in order from chapter 1, but feel free to dip into whatever catches your interest. Note: The Python examples run right in your browser. Try the git and shell examples in a repository on your own machine. Agent responses change every time, so they are not included.

Chapter 1 — What to Delegate and What Not To (lessons 1–5)

First, we settle what AI can and can't do, and who is responsible for the code you adopt. By the end, you'll be able to tell for yourself which jobs are safe to hand off.

What to Decide Before Letting AI Write Code

The tools and mindset this course assumes. The starting point: whether to adopt generated code is your call, and it's not about memorizing any one tool's UI.

Free

What Language Models Are Good and Bad At

They're fast at well-defined conversions and boilerplate, but silently fill in gaps in the spec. Using a median function, we run code to see where they shine and where they're risky.

Free

Once You Adopt It, It's Your Code

Whoever commits generated code is responsible for it. Starting from the fact that git blame shows your name, we set criteria for adopting code.

Free

Ways of Using AI That Get in the Way of Learning

The habit of looking at the answer first erodes your ability to read and fix code. Concrete ways to keep the order: predict first, then run.

How to Tell Which Jobs to Delegate

Delegate jobs whose correctness can be checked mechanically. Don't delegate jobs with no way to check. We draw this line with a table and real examples.

Chapter 2 — Writing Instructions (lessons 6–11)

Learn to write instructions that get back what you had in mind: passing context, sizing each request, and using input/output tables. The chapter ends with an exercise that rewrites a vague one-liner into an instruction that can't be misread.

Passing Context (What You Show Decides the Result)

The same instruction returns different code depending on which files you show. We use differences in rounding to see what happens when you don't show the repository's conventions.

Instruction Size (One Change at a Time)

Asking for everything at once makes the diff big, and a diff you can't read is a diff you can't decide on. Compare how the diff changes when you ask in separate pieces.

Conveying the Spec with an Input/Output Table

A spec written in prose leaves room for interpretation. Write a table of expected values first and hand it over, and you get both the gaps in the spec and a way to judge the result.

Four Types of Failing Instructions

Vague, huge, double, and dumped. When what comes back misses the mark, it fits one of these four. A rounding example shows what vagueness really is.

How to Ask for a Redo (Send It Back with a Counterexample)

Just replying "that's wrong" won't fix it. How to send it back with one failing input, and how to decide when to stop retrying.

[Practice] Rewrite an Instruction Three Times

An exercise in rewriting a vague one-liner into an instruction with an input/output table. Using a business-day counting function, you plug the holes in the spec yourself.

Chapter 3 — Setting Up the Repository (lessons 12–17)

With a rules file, a directory map, a check command, and an ignore list, you build a place for the warnings you'd otherwise repeat every time. The chapter ends with actually putting all four into one repository.

Adding a Rules File

Instead of writing the same warnings every time, put your repository's rules in a file. Where to put it, how to write it, and why you still need to check that it was followed.

Adding a Directory Map

Put what lives where into a single file. It cuts down time spent exploring and prevents changes that land in the wrong place.

Turning Your Checks into One Command

Bundle tests, syntax checks, and formatting into one script, and humans and agents go through the same checks. Decide even how failures are reported.

Deciding What Not to Share

Whatever you hand over leaves your machine. Use an ignore list and a check command to keep secrets and production data out.

Keeping History Small

If you split commits by purpose, you can undo just part of a change. The more code gets generated, the more the granularity of your history pays off.

[Practice] Put the Setup into a Repository

An exercise in actually putting all four pieces into one repository: a rules file, a map, a check command, and an ignore list. You go as far as verifying the setup yourself.

Chapter 4 — Reading Diffs (lessons 18–23)

Decide on an order for reading, and learn to spot code that runs but is wrong, safeguards that were removed, and dependencies that were added. The chapter ends with an exercise in finding a planted bug from a diff.

The Order for Reading a Diff

Look at overall size, then added files, then removed lines, then remaining lines. With a fixed reading order, the size of a diff no longer overwhelms you.

Code That Runs but Is Wrong

No errors, existing tests pass, and yet it doesn't match the spec. Using a pagination implementation, we confirm the only way to find it is to run it and compare.

Looking for Missing Boundaries and Edge Cases

Zero items, one item, empty strings, negative numbers, upper limits. These are the first things generated code misses. Decide on an order for hunting them down.

Looking at Removed Lines

Removed lines are more dangerous than added ones. Extract just the - lines of a diff to check that validation, exceptions, and logging weren't quietly dropped.

Looking at Added Dependencies

Adding a library in one line brings maintenance, licensing, and supply-chain issues along with it. Check first whether the standard library can do the job.

[Practice] Find the Planted Bug in a Diff

Of three diffs, only one changes behavior. An exercise in reading to form a hunch, then comparing results to confirm it.

Chapter 5 — Pinning It Down with Tests (lessons 24–27)

Write tests first to lock in the spec, and stop regressions with tests that reproduce bugs. The chapter ends by running the full loop: from a table to tests, an instruction, and a diff review.

Writing Tests First

Writing tests first locks in the spec and makes judging generated code automatic. Using phone number formatting, we walk through turning a table into tests.

Stopping Regressions with Tests That Reproduce Bugs

Before fixing, write one failing test. Using a slug generation bug, you actually build a safeguard so the same bug never comes back.

Look at Boundaries, Not Coverage

Running every line doesn't mean the spec is met. With a full-width digits example, we confirm that a high coverage number guarantees nothing.

[Practice] Write Tests First, Then Have AI Implement

A capstone exercise using a bill-splitting calculation: table, then tests, instruction, implementation, and diff review, all the way through.

Chapter 6 — Using It as a Team (lessons 28–30)

Turn review rules, the line on confidential information, and licensing and attribution into systems rather than matters of personal conscience. We wrap up the 30 lessons by returning to "being able to explain it."

Setting Your Team's Review Rules

Make how you handle generated code a rule, not a matter of personal conscience. Decide the review order, accountability, and where to draw the line, then write it down.

Protecting Confidential Information as a Team

Leave it to individual judgment and something will leak. List what may be shared, and prepare fake data so you don't need to share the real thing.

Licenses, Attribution, and the Responsibility That Remains

You can't trace where generated code came from. Decide how to handle what you can't trace, and finally return to "being able to explain it" in this wrap-up.

Once you finish all 30 lessons, move on to the Git & GitHub for Beginners course to solidify how you handle diffs and history, the Software Testing Techniques for Beginners course to go deeper on writing tests, or the Intro to Design & Refactoring course to turn generated code into something readable and easy to change. A membership unlocks every course.