Build with an assistant in small steps, testing and committing each one.
Priya has finished the spec for her app, which analyses feedback that people paste in. She asks her coding assistant to build the whole thing at once, and it produces 9 files and about 400 lines of code (example figures).
She runs it. The page loads, she pastes some feedback, presses submit and gets an error she does not understand. She asks for a fix, the assistant changes 4 files, and a different error appears. After an hour she cannot tell which parts work, which change broke what, or how to get back to a version that ran.
When an assistant builds a whole app in one go, you get a lot of code at once. If it fails, you cannot tell which part broke, and fixes can spread across many files and add new errors. A better assistant will not solve this. A smaller step will.
Break your spec into features that you can finish and test in one sitting. Ask the assistant for one feature at a time and run the app after each one. Keep each step small, so that when something breaks you know the last change caused it. Each step should end with something visible that works.
Priya split her spec into 5 steps. Step 1 is a page with the text box and button, and the button does nothing yet. Step 2 is a server route that receives the text and returns the item count, with no model call. Step 3 adds the model call for a single item and shows the result as plain text. Step 4 adds schema validation and the results table. Step 5 adds the error handling from her spec.
When the server in step 2 replies "3 items received", Priya knows the connection between the browser and the server works before she adds the model call on top of it.
After every change, run the app and try the feature you just built. Then retest one feature you built earlier, because changes break neighbouring features more often than people expect.
Use git from the very first step. It is the version control tool almost every software project uses, and it saves snapshots of your project. Each snapshot is a commit, with a message describing what changed. You can go back to any earlier commit at any time.
When a step works, commit it with a one-line message saying what now works, such as "Server route counts pasted feedback items", then start the next step. If a step goes badly wrong, throw away the broken changes, return to the last commit, which you know works, and try again with a smaller request. Without commits, getting back means undoing changes by hand and hoping you remember all of them.
Priya worked through her 5 steps and committed after each one. When step 4 broke the table, she reverted to step 3's commit in seconds and tried again with a smaller request.
You need only a few git commands to start: initialise the repository, check the status, commit, view the history, and go back to an earlier commit. Most coding assistants can run git for you, and many offer to commit after each change. Let them, but read each commit message and check that it matches what actually changed. If you are new to git, ask the assistant to explain each command before it runs it.
Before your first commit, check that your env file is listed in the git ignore file. Lesson 1.2 explains how to do this. The git ignore file only stops git from picking up files it is not already tracking. If your env file was committed before you listed it, git keeps tracking it until you remove it from the index with git rm --cached, so read the gitignore page in the official git documentation to see how this works.
The assistant writes the code, but you still have to read it, because you are responsible for what it does. After each step, look at what changed. Most assistants show a diff, a view of every line added and removed in a change.
You don't need to understand every detail of the syntax, but you do need to understand what each part does. If a line makes no sense, ask the assistant what it does and why it is needed. Assistants are good at explaining code, and the explanation often shows that the line isn't needed at all. If the explanation doesn't make sense, or the assistant cannot say why something is there, treat that as a warning, because nobody can fix code that nobody understands.
Four kinds of change need a closer look every time:
New libraries. If the assistant adds a package you did not ask for, ask what it does and whether the job could be done without it. Every library is code you did not write but now depend on. Deleted code. Assistants sometimes delete code to make an error go away, including code that was doing something important. Any deletion you did not expect needs an explanation. Keys and secrets written into files. Check every change for anything that looks like an API key, a password or a connection string. Your spec says the key lives in an environment variable, so hold the assistant to that. Changes outside the step. If you asked for the results table and the server route changed too, ask why.
For each feature, then, the order is: ask for that feature only, read the diff and check for these four signs, run the app and try the new feature plus one earlier one, commit with a message that matches the change, and move on.
The activity below asks you to build the first feature of your own app the same way: small steps, a run after each, and a commit with a clear message for each one.
Build your app's first feature in at least three committed steps. Give each commit a one-line message.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).