Lesson 10: How should AI write my code?

The everyday picture

Building a house. The AI is an extremely fast, tireless builder who never complains, but sometimes confidently builds a wall in the wrong place. You are the owner holding the blueprint. The builder lays the bricks; you decide where the walls go, inspect the work, and nothing gets knocked down without your say.

What it really is

A safe way of working with AI, in eight habits:

Write the requirements first. What it does, for whom, and what "done" looks like, in plain words.
Decide the architecture yourself. Use Lessons 1–9. Let AI advise, but you choose.
Make small changes, one at a time. "Add a login page" is better than "build the whole app".
Use Git for everything. Every change is saved and can be undone. This is your safety net.
Ask for tests. Small programs that check the code works, and run them after every change.
Review, and ask "why?" Ask the AI to explain each change in plain words. If the explanation doesn't make sense, the code probably doesn't either.
Guard the dangerous areas. Logins, payments, personal data and secret keys need extra review. Never paste passwords or secret keys into an AI chat.
Write down the rules. Keep a project rules file the AI reads every time: your stack, your conventions, what it must never do. This is governance: the rules stay the same even when the conversation changes.

And one golden rule: nothing that can't be undone happens without your approval. That includes deleting data, changing the live site, or sending messages to customers.

What it means for your idea

This is where everything in Tutor Workstation comes together. You don't need to type the code. You do need to understand it well enough to direct it, check it and own the decisions. That understanding is exactly what the learning journey gives you.

Pick this when...

Always. AI types; you decide.

Quick check

The AI says "I've rebuilt the whole app to fix the bug". What should worry you, and what should you ask for? A huge change for a small problem is hard to check and may break other things. Ask it to undo the change (Git makes that possible) and fix only the bug, in a small change with a test that shows it's fixed.

Goes deeper in Modules 81–90, and is practised in every level.