Following the work

In class, an AI agent builds the first version of your portfolio, and you are the client. Then the changes come, week after week: a new project, a shorter "About" text, a bug fixed in the contact form. Following the work means three things. At any moment, you can see what changed. You can try a change before visitors see it. And you can undo it.

It starts with a history. Developers record their work with a version control tool, almost always Git. Each time a change works, they save it as a commit. A commit records what changed, who made the change and when, with a short message that says why. Together, the commits form the project's history, back to the first day. GitHub is a website that keeps this history online, where the whole team can read it. The lesson Working with an agent shows how to ask the agent for a commit after each step.

A history is not a backup. A backup is a copy of the whole site on one day. If something breaks on the 20th, the backup from the 1st brings back the site of the 1st, and you lose three weeks of work. A history shows the one change that caused the problem, so you can undo only that change.

The example below shows the same five commits of a portfolio, twice. On the left, every message says "update", so the history tells you nothing. In six months, nobody will remember why a change was made, not even the person who made it. That's exactly when you'll need to know. On the right, each message says what changed and why. Ask for one change per commit, with a message like these.

The live site, also called production, is the version of the site that visitors see. Nobody should change it directly. A change made on the live site reaches visitors with all its mistakes, perhaps while a recruiter is reading your portfolio.

So a change goes through several copies of the site, called environments. The first one is the builder's computer. There, the dev server shows the site at a localhost address that only the builder can open. Next comes a test copy that works like the live site, where the team tries each change. Teams call it staging. The live site comes last.

In the project, each change is prepared on a branch. A branch is a separate line of work, where a change is made and saved without touching the main branch, the version that the live site is built from. Your agent can work for a whole day on a branch called "drone-project", and your live portfolio doesn't change. When the change is ready, it's proposed for review in a pull request, the subject of the next part.

Many hosts, such as Netlify, Vercel or Firebase Hosting, make a preview link for each pull request. It's a private address where you can try that one change, on your phone too. Once someone approves the change, the branch is merged into the main branch, and the change is deployed to the live site. The previous version is kept, so you can return to it.

Ask for small changes, one at a time. Nobody can try two months of work in one afternoon. And if something breaks, nobody knows which of a hundred changes caused it.

A pull request is a change proposed for review before it joins the live site. Some tools call it a merge request. Its page, on GitHub for example, gives a description of what changed and why, the list of the files that changed, and often a preview link. When the developer asks "Can you approve it?", saying yes means accepting every change in it. Approving is not a formality.

As the client, or as the product owner, the person who decides what the product must do, you don't read the code. Another developer checks the code: this is code review. Your job is to check the result. First, does what changed match what you asked for? A good pull request says which request it answers, so you can compare the two. Then open the preview link and use the change as a visitor would, on a computer and on a phone. Follow the whole path, not only the page that changed. For a new price, go to the basket and the payment page too. For your portfolio, open the new project from the home page, and play its video on your phone.

If something is wrong, write it on the pull request itself, not in a separate email. Say what you did, on which device, what you saw and what you expected, as in a bug report. For example: "On my phone, the video doesn't start. On my laptop, it plays." Approve only once the problem is fixed and you've tried the preview again.

The example below shows two pull requests. Nobody can review the one on the left: 96 files, a month of work, no description and no preview. Ask for small pull requests instead, each with a description and a preview link. The one on the right says what changed, why, and how to check it.

One day, an update will break something on the live site. Teams call this an incident. Then you must decide: undo the update, or fix it?

When each update goes live as a saved version, and the previous version is kept, going back takes minutes. This is called a rollback. Hosts such as Netlify, Vercel or Firebase Hosting keep every version that went live, and they can put an earlier one back online with one button. Then the developer fixes the problem calmly, tries the fix on the test copy, and deploys it again. A fix made in a hurry on the live site, while visitors see the problem, often brings a second bug.

But a rollback undoes the whole update, including the parts that work. So compare the harm with what you would lose. Take your student association's site, which sells the tickets for the gala. If nobody has been able to pay since this morning's update, roll back now, because every hour costs ticket sales. If the same update opened the ticket sales but has a typo in a heading, don't roll back. Fix the typo with a small change, through the usual path: a branch, a pull request and a preview.

A rollback needs a way back. If the developer copied the new files over the old ones and kept no version, there's nothing to return to. The only option left is a hotfix on the live site, as fast as possible. Then insist that every update keeps the previous version.

After a rollback or a fix, run a smoke test: try the paths that matter yourself, such as browsing, the basket and payment, on a phone. If payments failed, check whether anyone paid without getting a ticket. Then ask why the problem wasn't caught before it went live, and what will catch it next time, such as a test purchase on staging. And put updates live when someone can watch what happens next, not on a Friday evening.

Over a whole season, a site gets dozens of requests and bugs. In a long email thread, they get lost. Is the video bug fixed? Who was supposed to send the photos? Nobody knows.

So teams use an issue tracker: a shared list with one item for each request or bug. GitHub Issues, Jira and Trello are common ones. Each item, called an issue or a ticket, has a title, an owner (most tools call this person the assignee) and a status, such as "to do", "in progress" or "done". When you ask for a change during the work, your change request becomes an issue. A bug becomes an issue too, written as a bug report. For your portfolio, the issue "The contact form sends nothing on Safari" can go to the agent, and the issue "Send the drone video" goes to you.

Then everything is linked. Each pull request says which issue it answers, and each commit message says what changed and why. Months later, anyone can follow a change from the request to the code, and back again.

Last, check whose name is on all of this. The history on GitHub, the hosting and the domain name should belong to you, or to the client, not only to the freelancer who built the site. When the freelancer leaves, the client keeps the history and the accounts. The lesson What keeps running lists what to collect at handover.

Ask these questions at the first meeting with a freelancer, an agency or an agent. Then ask them again before every update, all season.

At the first meeting, ask how changes are recorded and how they go live. You want each change saved as a commit with a clear message, prepared on a branch, shown to you on a preview link, and put live in a way that keeps the previous version. If the answer is "I change the live site directly", or "I'll put everything online in one go at the end", ask for small changes, prepared on a copy. Ask also where the history and the accounts are kept, and in whose name.

Before each update goes live, ask what changed since last time. Some teams keep a changelog that answers this question for you. Ask how the update would be undone if it goes wrong, and how long that would take: this is the rollback plan. Ask who checked it. A second person should check every change, even one that is "only prices", because small changes are the ones that nobody checks twice. Teams call this rule the four-eyes principle. And agree in advance on which problems mean "roll back first", such as failed payments. Then nobody has to debate it while customers wait.

Ask your agent the same questions. Did it work on a branch? Which issue does this pull request answer? Where is the preview link? Then try the change yourself, as the lesson Working with an agent explains.