You now know the parts of the AI workspace: files give the project durable context, the editor and terminal let you work with it, an agent can build inside it, Git records the change, GitHub carries approved work outward, and the cloud makes a product available to other people.

Those are not separate subjects. They are one working loop.

The loop is how an idea becomes a real product without turning into a pile of chats, mystery changes, and risky deployments.

The whole flow

Imagine you want to add a company-comparison feature to Sonariq. You do not start by telling an agent “make comparisons.” You turn the idea into a small system of work.

Idea and researchMarkdown brief: goal, rules, successGit branch: isolated changeAI agent: read, plan, buildLocal tests and browser reviewGit commit: approved checkpointGitHub: backup, review, previewDeploy to cloudLive productHandoff: what changed and what is next

Every stage answers a different question:

Step 1: write the work down before you build it

Start with a Markdown brief. It can be a SPEC.md, a task inside TASKS.md, or a section of CONTEXT.md. It does not have to be long. It needs to make the change testable.

# Company comparison page

Goal: Let a reader compare two companies on the same research metrics.

Must include:
- valuation, growth, leverage, and key risks
- a source link beside every displayed figure
- a clear mobile layout

Must not change:
- existing company report pages
- database schema without approval

Done when:
- comparison works with two real companies
- page is checked on desktop and mobile
- tests pass

This is more than a prompt. It is the durable product decision. The agent reads it, you review it, and the next session can find it after the first chat is gone.

Step 2: make a branch before the change becomes complicated

The main branch—often called main—should represent the working version of the project. Create a branch for one focused piece of work, such as:

feature/company-comparison

That branch does not create an entirely separate project. It gives this one change its own safe line of history.

The value is psychological as much as technical. You can let an AI explore a real feature without the feeling that every edit immediately touches the version you depend on. If the work is bad, unfinished, or simply not the direction you want, you do not have to pretend it belongs in main.

Step 3: direct the agent inside the right workspace

Open the project root in VS Code. Start Codex or Claude Code from that root. Then give the agent a bounded instruction:

Notice what this request does. It gives the agent a starting context, confirms the safe branch, draws a scope boundary, asks for a plan, requires verification, and requests a handoff. That is how you direct a system rather than merely ask for an output.

Step 4: prove the change locally

The agent writes code and runs checks. But the local browser is where you see whether the idea became the thing you wanted.

Open the local version. Test the actual user behavior. Look at the comparison on a narrow screen. Try messy inputs. Read the source links. Ask the agent to explain anything that feels surprising.

This is not optional “polish.” Automated tests catch some failures. Your eyes catch whether the feature is useful, clear, on-brand, and ready for a real person.

When the result is acceptable, make a Git commit. A good commit message names the result, not the struggle:

feat: add company comparison view

Now you have an exact checkpoint for the work you reviewed.

Step 5: use GitHub as the review and delivery bridge

Push the branch to GitHub. This gives the change a remote backup and a shareable review surface. GitHub shows the changed files together, making it easier to notice an unexpected deletion or an AI edit outside the agreed scope.

Many teams open a pull request at this point. A pull request compares the branch against main. Even when you work alone, it is useful: it creates a deliberate pause between “the agent made this” and “this is now part of the product.”

Some hosting services automatically build a preview from the branch. A preview is not yet the public production version. It is a safe online version for checking a real deployment before you merge.

Step 6: merge and deploy deliberately

After review, merge the approved branch into main. The deployment service can then publish the main version to the live product.

This is the boundary where local work becomes public work. Check which environment is receiving the deployment. Check whether it uses live credentials, a production database, payments, email, or real users. The agent can execute the steps, but you should know what is about to become public and what it could cost.

If something breaks, Git gives you a known history of changes. You can inspect the deploy, fix forward, or restore a previous approved version. This is why the sequence matters: the safety does not come from any one tool; it comes from using the tools in the right order.

Step 7: leave a handoff, then begin the next loop

The last step is simple and often skipped. Write the handoff.

# Handoff — Company comparison

Changed:
- Added the comparison page and source-link display.

Tested:
- Local build and automated checks passed.
- Compared MGM and Caesars on desktop and mobile.

Decisions:
- No database schema change; metrics come from existing research records.

Next:
- Decide whether readers can save comparison sets.

Now the project remembers the feature, not just the current chat session. The next agent can start with facts instead of reconstruction.

What this does not mean

You do not need to create a branch for a spelling correction. You do not need a cloud deployment for a private experiment. You do not need to understand every Git command before your first project.

The point is to recognize the larger pattern as soon as the work matters:

Context → safe change → local proof → checkpoint → review → live release → handoff

Class 6 will teach you how to operate more of this flow from the CLI. Project Control will teach the deeper Git, branch, review, and recovery practices. But you now have the map.

Practical exercise: draw your own product path

Pick one small improvement you want to make to a real project. Write a six-line plan:

1. The Markdown file where the goal will live. 2. The branch name you would use. 3. The first files the agent should read. 4. The local check that proves it works. 5. The GitHub review or preview you would inspect. 6. The handoff note the next session needs.

Do not build it yet. First prove that you know how the work will move through the system.

Check your understanding

1. Why is a Markdown brief useful before an AI begins coding? 2. What does a branch protect? 3. Why is local browser review still necessary after automated tests pass? 4. What is the difference between a Git commit and pushing to GitHub? 5. Why should a deployment be a deliberate decision rather than an automatic afterthought?