I have been learning to work with AI coding tools by asking Claude to build me the curriculum. The first thing it put in front of me was not code. It was version control, and by the time I understood why, I had a better answer to the question I thought I was asking.
I am not far enough in to tell you whether any of it has worked. Nobody outside this loop has assessed my judgement yet, so what follows is a report on a design rather than a result. It is already teaching me two things at once: what a curriculum for safe AI coding actually contains, and how to build and refine one of these things in the first place.
Where this started
I have been following AI coding the way most product people have. Interested, slightly wary, unsure where to begin. I looked at paid training and found it expensive, and none of it was aimed at someone who wants to direct a coding tool rather than become a developer. Then the obvious occurred to me. I already had a subscription to the thing I was trying to learn.
So I asked it. Not “teach me to code”, but something narrower: what would I need to know to use an AI coding tool without wrecking something, and how would you teach me that in short sessions? What came back was not a reading list. It was a skill, which in Claude’s terms is a written specification for how my sessions run, what they cover and how they adapt. It starts when I type “Next Dev”.
The first thing: the syllabus is a safety syllabus
The curriculum is built around four capabilities. Only one of them involves writing anything.
A safety net. I can always get back to a working state. Commit before letting the tool loose. Read the diff before accepting. Revert without panic. Use a branch for anything risky.
Read and judge. Given code I did not write, I can say what it does, which file to look in, and whether a proposed change is reasonable.
Locate a failure. Something breaks. I can reproduce it, read the error, and say which layer it is in: my code, the config, the data, the environment, or the tool itself.
Verify. I can prove it works by running it, testing it and looking at the output, rather than trusting that it works because the AI said so.
The first carries most of the value, and it is the least technical thing on the list. Version control is the difference between “the AI destroyed my project” and “it made a change I did not like, so I undid it”. Same event. Very different afternoon.
I can hear the objection, because I would make it myself. Three of those four are ordinary developer practice, taught for twenty years. Calling it a curriculum for AI coding is a new label on an old box.
Fair on the content. Not fair on the order. Conventional training teaches you to write code first and reaches version control around week three, because it assumes you are the author. If you are the reviewer of code you cannot fully read, that order inverts. You will be accepting changes you do not understand from day one, so the safety net has to come first.
The whole track is designed around one bad outcome: accepting a large AI-written change I cannot read, cannot test and cannot undo. Most of the AI coding horror stories I have read are that same failure wearing different clothes.
The second thing: how to refine a skill
I did not go looking for this half, and it may end up being the more transferable one.
A specification is worth very little until it meets reality. Mine has been rewritten three times, and every rewrite came from evidence rather than preference.
The first version scheduled sessions twice a day and sent notifications to prompt me. It took three nudges to land one session, and I was ignoring the nudges and then opening a session myself when I had capacity. So sessions became pull rather than push. Nothing starts one except me typing two words.
The second version was puzzle-first, with a prediction before almost every command. Sound in principle. In practice it made sessions feel like a test. The default now is a guided build: the finish line, the numbered steps, and help doing them. Prediction survives as one moment per session, placed where being wrong teaches me something.
The stack changed too, from Python and a notes tool to TypeScript and a browser game. Types make a class of AI mistake visible in the editor before anything runs. A game shows you its bugs on screen. The thing moves wrong, the score is wrong, the colour is wrong.
Smaller rules get written in as they are earned. A session was lost to a confident instruction that did not match my machine, so verifying the environment first became a rule. Another taught me never to chain a command that can fail with the command that checks its result, because you cannot then tell which half failed.
The specification improves every time something goes wrong, provided somebody writes down what went wrong rather than what should have happened. That is a discipline, not a feature of the tool, and it is the bit most people will skip.
Where this is meant to get me
The spine project is a Wordle clone, chosen for one reason. The scoring rule has an edge case involving repeated letters. It is easy to get wrong, and in my experience it is the kind of thing an AI tool does get wrong. The code still looks finished. It still runs.
That is the artefact I am working towards being able to catch. The target is not writing a scoring function. It is looking at one that runs cleanly and working out that it is wrong.
I recognise that muscle. It is the one I use interrogating an architecture decision I did not make, or sitting on a bridge call in the small hours while people who know more than me work out which layer has failed. I do not write production code and I am not planning to. What I have needed throughout my career is the judgement to ask the right question of people whose work I cannot fully verify. An AI coding tool is that situation with the meetings removed.
The objection I cannot fully answer
The AI set the syllabus, runs the sessions and assesses how I did. It can teach me its own blind spots and I would not know.
Two things reduce that. Much of the curriculum is arbitrated by something other than the AI: a test passes or it does not, a game works on screen or it does not, a deployed page is live or broken in public. And the rewrites came from what I actually did in sessions, including the parts I got wrong, rather than from what I said about myself afterwards.
Nothing reduces the rest of it. That gap closes when I ship the game and somebody who knows more than me looks at it. I will write that post too, whichever way it goes.
What I would take from this so far
If you are a product person circling AI coding and wondering whether you need to learn to code first, I do not think that is the question. The question is whether you could get back to a known-good state if the tool did something you did not want.
If the answer is no, start there. It is one habit and two commands: save a version you are happy with before you let the tool change anything, and know the command that throws away everything since. It takes an evening, and every other risk in AI coding gets more manageable once you have it.