You will be able to build with an assistant in small, tested and committed steps.
With her spec done, Priya asked the assistant to build the whole app at once. It produced nine files and about 400 lines of code. She ran it. The page loaded, she pasted feedback, pressed submit and got an error she did not understand. She asked for a fix. It changed four files. A different error appeared. After an hour she had no idea which parts worked, which change had broken what, or how to get back to anything that ran.
The cure is not a better assistant. It is a smaller step.
Break your spec into features you can each finish and test in one sitting. Then ask for one at a time, and run the app after each one.
Priya's spec broke down into five steps. First, a page with the text box and button that does nothing yet. Second, a server route that receives the text and sends back the item count, with no model call. Third, the model call for a single item, with the result shown as plain text. Fourth, schema validation and the results table. Fifth, the error handling from her spec.
Each step is small enough that when something breaks, you know it was the last change. Each one ends with something you can see working. That second point matters more than it sounds. Seeing the server return "3 items received" tells you the whole connection between browser and server works before you add a model call on top.
After every change, run the app and try the thing you just built. Also try one thing you built earlier, because changes break neighbouring features more often than you would expect.
Use git, the version control tool almost every software project uses, from the very first step. Git records snapshots of your project called commits. Each commit has a message describing what changed, and you can return to any earlier commit at any time.
The rhythm is simple. 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 the next step goes badly wrong, you can throw away the broken changes and return to the last commit, which you know works. Without commits, getting back means undoing changes by hand and hoping you remember them all.
Most coding assistants can run git for you, and many will offer to commit after each change. Let them, but read the message and make sure it describes what actually changed. If you are new to git, ask the assistant to explain each command before it runs it. You only need a handful to start: initialise the repository, check the status, commit, view the history, and go back to an earlier commit.
Before your first commit, check that your env file is listed in the git ignore file, as lesson 1.2 described.
The assistant writes the code. You still have to read it, because you are the one 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. You do not need to understand every detail of the syntax. You need to understand what each part does. When a line makes no sense to you, ask: "Explain what this line does and why it is needed." Assistants are good at explaining code, and the answer often reveals that the line is not needed at all.
If an explanation does not make sense, or the assistant cannot say why something is there, treat that as a warning. Code nobody understands is code nobody can fix.
Some changes deserve a closer look whenever they appear.
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 and now depend on. Deleted code. Assistants sometimes remove 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. The spec says the key lives in an environment variable. Hold the assistant to it. Changes outside the step. If you asked for the results table and the server route changed too, ask why.
Priya now works through her five steps with a commit after each. When step four broke the table, she reverted to step three's commit in seconds and tried again with a smaller request.
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 the first feature of your app in at least three committed steps, with a one-line commit message for each.
Junxiong-WFG Organisation is an authorised representative of AIA Financial Advisers Private Limited (Reg. No. 201715016G).