Your First Safe Vibe Coding Workflow

Vibe coding becomes useful when the AI assistant is part of a controlled development process.

Without that process, a typical session can become difficult to manage. You ask for a feature, the assistant changes several files, the application partly works, another prompt introduces more changes, and eventually it becomes unclear which version was stable.

A safer workflow starts before the first prompt.

You confirm the project location, check Git, define one small task, choose the appropriate AI tool, review every modified file, test the result, and commit only what you understand well enough to keep.

This final article in the setup series combines Visual Studio Code, WSL, Git, GitHub, GitHub Copilot, and Claude Code into one repeatable beginner workflow.

Version note: AI tool interfaces, extension names, permission controls, authentication methods, and supported features may change. Verify product-specific instructions against the current official documentation before publication.

What You Will Learn

By the end of this guide, you should be able to:

• open the correct WSL project in Visual Studio Code;
• confirm that the repository starts from a clean state;
• define a small and testable coding task;
• choose between GitHub Copilot and Claude Code;
• create a Git checkpoint before risky work;
• review AI-generated changes with Git;
• test the intended behavior;
• check for unrelated files and exposed secrets;
• commit only the verified result;
• push the commit to GitHub;
• record unresolved issues for the next task.

The goal is not to complete a large application in one session. It is to establish a process you can repeat safely.

The Complete Workflow at a Glance

The workflow in this article follows this sequence:

Open the correct project
→ Confirm the environment
→ Pull remote changes
→ Check Git status
→ Define one small task
→ Choose the AI tool
→ Ask for inspection or a plan
→ Approve a limited change
→ Review the Git diff
→ Test the result
→ Check for secrets and unrelated changes
→ Stage selected files
→ Review the staged diff
→ Commit
→ Push to GitHub
→ Record the next task

The most important idea is that the AI assistant works between Git checkpoints.

The AI proposes and modifies.

You decide what becomes part of the project history.

Step 1: Open the Correct Project

Start from the WSL terminal.

Move into the repository used throughout this series:

cd ~/projects/vibe-coding-practice

Confirm the path:

pwd

The output should resemble:

/home/your-username/projects/vibe-coding-practice

List the top-level files:

ls -la

You should recognize the repository contents.

Now open the project in Visual Studio Code:

code .

The period means the current directory.

When VS Code opens, confirm:

• the Explorer shows the expected repository;
• the WSL connection indicator is visible;
• the integrated terminal opens inside the project;
• the terminal path begins with /home/;
• the project is not an accidental copy stored elsewhere.

Run inside the VS Code terminal:

pwd
whoami
uname -a

These commands confirm the current folder, Linux user, and WSL environment.

This check may feel repetitive, but it prevents one of the most common AI-assisted development mistakes: editing the wrong copy of a project.

Step 2: Synchronize with GitHub

Before starting new work, check whether the remote repository contains newer commits.

First inspect the local state:

git status

When the working tree is clean, retrieve remote changes:

git pull

A successful result may report that the repository is already up to date or that new commits were downloaded.

Run:

git status

again.

You want a known starting point before asking an AI tool to modify files.

If the repository contains uncommitted changes, do not pull or begin a new AI task automatically. Review those changes first:

git diff

Decide whether they should be committed, discarded, or completed before continuing.

Step 3: Confirm the Starting Checkpoint

Review recent history:

git log --oneline -5

You should recognize the latest commit.

For example:

73af8c1 Document AI-assisted development workflow
5d220ab Add Copilot practice functions
2e902de Update README with repository status

The latest commit is your current recovery point when the working tree is clean.

You do not need to create an empty commit before every task. You only need to know which committed state represents the last verified version.

A useful starting condition is:

Current branch is known
Working tree is clean
Latest commit is understood
Remote changes are synchronized

Once these conditions are true, the AI-generated change will be easier to isolate.

Step 4: Define One Small Task

Do not begin with a request such as:

Make this project better.

That prompt has no clear completion condition.

Choose a task with:

• one visible outcome;
• a small number of affected files;
• a clear verification method;
• no unnecessary external dependency;
• limited security risk.

For this workflow, use a small JavaScript task.

Suppose the repository contains:

function normalizeTaskTitle(input) {
  return input.trim();
}

The task could be:

Update normalizeTaskTitle so that it returns an empty string when the input is not a string. Preserve the existing trimming behavior for valid strings. Do not add dependencies or modify unrelated files.

Now define how you will verify it:

Verification:
- "  Buy milk  " returns "Buy milk"
- "" returns ""
- null returns ""
- 42 returns ""

This task is specific, limited, and testable.

Step 5: Choose the Right AI Tool

GitHub Copilot and Claude Code can overlap, but they support different working styles.

Choose GitHub Copilot When

Use Copilot for:

• a small function;
• inline completion;
• explaining selected code;
• suggesting a few test cases;
• editing a focused section in the current file;
• answering a question while you remain inside VS Code.

The task in this example affects one small function, so GitHub Copilot may be sufficient.

Choose Claude Code When

Use Claude Code when the task requires:

• inspecting several connected files;
• understanding project structure;
• planning a multi-file change;
• running project commands;
• updating implementation and tests together;
• investigating an error across the repository.

Even with Claude Code, keep the first request narrow.

Do Not Choose Based Only on Model Preference

The best tool is not always the one with the largest feature set.

Choose the tool that creates the smallest reasonable review burden.

A one-function edit does not need a broad project agent. A coordinated multi-file refactor may not fit comfortably into a single inline suggestion.

Step 6: Ask for Inspection or a Plan First

Before allowing a coding agent to edit several files, ask it to inspect and explain.

For Claude Code:

Inspect the project without changing files. Find normalizeTaskTitle, identify where it is used, and tell me which files would need changes to add type-safe input handling.

For GitHub Copilot Chat:

Review normalizeTaskTitle and explain the smallest change needed to return an empty string for non-string input. Do not modify the code yet.

Compare the response with the actual project.

Check:

• did it find the correct function;
• did it identify real files;
• did it invent a dependency;
• did it propose a much larger change;
• did it misunderstand the desired behavior?

The inspection step gives you a chance to correct the direction before any code changes occur.

Step 7: Request the Smallest Useful Change

After reviewing the plan, request the implementation.

For example:

Modify only normalizeTaskTitle in copilot-practice.js. Return an empty string when input is not a string. Keep the existing trim behavior for strings. Do not edit other functions, add packages, or create new files.

A suitable implementation may look like:

function normalizeTaskTitle(input) {
  if (typeof input !== "string") {
    return "";
  }

  return input.trim();
}

Do not accept it only because it looks familiar.

Read it line by line.

Ask:

• Does the type check match the requirement?
• Is the original string behavior preserved?
• Does it return the expected value for empty input?
• Did the AI rename anything?
• Did it alter nearby functions?
• Did it add unnecessary comments or abstractions?

If the tool requests permission to edit or run commands, review each request before approving it.

Step 8: Inspect the Repository Immediately

After the AI finishes, do not continue with another prompt.

Run:

git status

The expected result should show only the intended file.

For example:

modified: copilot-practice.js

If you see:

modified: package.json
modified: README.md
untracked: debug-output.txt

the scope expanded beyond the request.

Investigate before proceeding.

Now inspect the exact change:

git diff copilot-practice.js

Review every added and removed line.

The AI summary is useful, but the Git diff is the repository evidence.

Step 9: Check for Unrelated Changes

Compare the file list with the original task.

The task allowed:

copilot-practice.js

Anything else requires an explanation.

Check for:

• dependency changes;
• lock-file updates;
• generated files;
• formatting across unrelated code;
• renamed functions;
• changed comments;
• deleted error handling;
• configuration edits;
• environment files;
• logs.

When an unrelated tracked file changed, review it:

git diff path/to/file

If the change is unwanted and uncommitted:

git restore path/to/file

This discards the file’s uncommitted changes.

Inspect the diff before restoring it because the discarded work may not be recoverable.

For an unwanted untracked file, inspect it before deleting it:

cat debug-output.txt

Then remove it only when you are certain it is unnecessary:

rm debug-output.txt

Git cannot restore an untracked file that was never committed.

Step 10: Test the Intended Behavior

The code should now be tested against the acceptance criteria.

Add temporary test calls only if they belong in the project, or use the existing test framework.

For a simple script, you may run:

console.log(normalizeTaskTitle("  Buy milk  "));
console.log(normalizeTaskTitle(""));
console.log(normalizeTaskTitle(null));
console.log(normalizeTaskTitle(42));

Then execute:

node copilot-practice.js

Expected behavior:

Buy milk

followed by empty results for invalid input.

Do not test only the new case.

Also confirm that existing valid input still behaves correctly.

Ask:

• Does the new requirement work?
• Did the original behavior remain intact?
• Are error messages present?
• Did existing tests still pass?
• Did the change affect any unrelated behavior?

When the project has an automated test suite, run the documented command:

npm test

When the project has formatting, linting, or type-checking commands, run the ones already defined by the project.

Do not invent or install new tooling only to complete a tiny change.

Step 11: Review Security and Privacy

Before staging, inspect the changed files for sensitive information.

Check for:

• API keys;
• tokens;
• passwords;
• .env files;
• private URLs;
• personal email addresses;
• production database strings;
• company names;
• customer data;
• local usernames or private paths.

Run:

git status

and review all untracked files.

Also inspect dependency changes if any occurred.

An AI coding tool may solve a simple problem by adding a package. That is not automatically acceptable.

Ask:

• Was the package necessary?
• Is it already approved?
• Did package files change?
• Did installation scripts run?
• Is the dependency actively maintained?
• Could the task be completed without it?

For this example, no dependency is required.

Any package change should be rejected.

Step 12: Stage Only the Verified Files

Once the change works and the scope is correct, stage the specific file:

git add copilot-practice.js

Do not use:

git add .

unless you have reviewed every file in the repository state.

Check:

git status

The file should appear under staged changes.

Now review the exact content prepared for the commit:

git diff --staged

This is the final pre-commit review.

The staged diff should contain only the type check and related intended edits.

If you staged the wrong file:

git restore --staged path/to/file

This removes it from staging while preserving the working-directory changes.

Step 13: Create a Meaningful Commit

Choose a commit message that describes the completed behavior.

For example:

git commit -m "Handle non-string task titles"

Avoid vague messages such as:

Update code
AI changes
Fix stuff
Latest version

A good commit message helps future readers understand what changed.

Check the result:

git status
git log --oneline -3

The working tree should be clean, and the new commit should appear at the top of the history.

The AI-generated change is now a verified project checkpoint.

Step 14: Push the Commit to GitHub

Send the commit to the remote repository:

git push

Open the repository on GitHub and verify:

• the new commit appears;
• the intended file changed;
• no unexpected files were uploaded;
• no sensitive information is visible;
• the commit message is clear.

This is your final external check.

A successful push means the remote repository now contains the verified history.

It does not prove that the application is production-ready. It only means this specific reviewed change was recorded and shared.

Step 15: Record Unresolved Issues

An AI task may succeed while revealing another problem.

For example:

• the function has no automated tests;
• task objects do not have IDs;
• error handling is inconsistent;
• documentation is outdated;
• a larger refactor may be useful later.

Do not expand the current task automatically.

Record the issue in a simple note, project issue, or task list.

For example:

Next task:
Add automated tests for normalizeTaskTitle.

Not part of the current commit:
- Introduce a test framework
- Refactor other task functions
- Change task object structure

This keeps the current commit focused.

It also reduces prompt drift, where one task gradually turns into several unrelated tasks.

The Safe Workflow Checklist

Use this checklist before and after every AI-assisted change.

Before the AI Task

• Open the intended project.
• Confirm the WSL environment.
• Run git pull.
• Run git status.
• Confirm a clean working tree.
• Review the latest commit.
• Define one small task.
• Write acceptance criteria.
• Define allowed and prohibited files.
• Choose Copilot or Claude Code deliberately.

During the AI Task

• Ask for inspection or a plan first.
• Limit the scope.
• Read permission requests.
• Reject unnecessary package installation.
• Avoid administrative commands.
• Stop when the tool begins changing unrelated files.
• Do not start a second task before reviewing the first.

After the AI Task

• Run git status.
• Inspect every changed file.
• Run git diff.
• Check untracked files.
• Test the intended behavior.
• Run existing tests.
• Check for secrets.
• Restore unwanted changes.
• Stage specific files.
• Run git diff --staged.
• Commit with a meaningful message.
• Push to GitHub.
• Record the next task separately.

When to Stop the AI Session

Continuing is not always the best choice.

Stop the session when:

• the tool repeatedly changes unrelated files;
• each fix introduces a new error;
• the task scope keeps expanding;
• you no longer understand the current diff;
• the tool requests unexpected administrative access;
• a package is being added without a clear reason;
• the project contains sensitive material you should not share;
• the latest known-good state is unclear.

When this happens:

git status
git diff

Review the current state.

Then decide whether to:

• keep part of the change;
• manually edit it;
• restore selected files;
• discard all uncommitted tracked changes;
• start a new session with a smaller task;
• return to a previous committed state.

Stopping is not failure.

It is part of responsible software development.

Copilot and Claude Code in One Workflow

You do not always need to choose only one AI tool for an entire project.

A practical division of work may look like this:

GitHub Copilot

Use it for:

• inline suggestions;
• short functions;
• comments and documentation;
• small test cases;
• explaining selected code;
• local code questions.

Claude Code

Use it for:

• repository inspection;
• multi-file planning;
• coordinated code and test changes;
• tracing behavior across files;
• running project checks;
• summarizing project-level changes.

Git

Use it for:

• establishing the starting checkpoint;
• identifying modified files;
• reviewing exact changes;
• separating staged and unstaged work;
• restoring unwanted edits;
• committing verified results;
• synchronizing with GitHub.

The AI tools help produce and explain changes.

Git controls what becomes history.

Common Workflow Failures

Starting with a Dirty Working Tree

Existing changes become mixed with the AI task.

Always run:

git status

before beginning.

Asking for Too Much at Once

A prompt that combines authentication, database design, UI changes, testing, and deployment creates a large review burden.

Break the work into separate features.

Trusting the AI Summary

The summary may omit files or describe intended behavior rather than actual changes.

Use:

git status
git diff

Staging Everything Automatically

git add . may include logs, secrets, generated files, or unrelated edits.

Stage named files.

Testing Only the New Example

A new feature may work while existing behavior breaks.

Run existing tests and check regression cases.

Committing Without Reviewing the Staged Diff

The working diff and staged diff can differ.

Always run:

git diff --staged

Continuing After Context Drift

When the AI no longer understands the current task, stop and reset the scope.

Do not keep adding corrective prompts indefinitely.

Treating a Successful Demo as Production Readiness

A local feature can work and still lack:

• security review;
• accessibility;
• performance testing;
• monitoring;
• deployment configuration;
• backup;
• error handling;
• maintenance documentation.

A completed beginner workflow is not the same as a production system.

A Practical Senior Review Mindset

You do not need senior-level knowledge to begin using senior-level review questions.

Before committing, ask:

Intent

• What problem did this change solve?
• Does the diff match the original request?

Scope

• Which files changed?
• Were any unrelated files modified?
• Is the solution larger than necessary?

Correctness

• Does the feature work?
• What happens with invalid input?
• Did existing behavior remain intact?

Maintainability

• Can I explain the code?
• Does it follow existing project patterns?
• Did the AI add unnecessary complexity?

Security

• Were credentials exposed?
• Was untrusted input validated?
• Were risky commands or dependencies introduced?

Verification

• Which tests were run?
• What evidence supports the result?
• Is the staged diff ready to become history?

This mindset is more valuable than searching for a perfect AI prompt.

A strong workflow assumes that every generated change deserves review.

From Setup to Real Projects

This series began with the tools required for vibe coding:

• Visual Studio Code;
• WSL;
• Git;
• GitHub;
• GitHub Copilot;
• Claude Code.

It then connected those tools into a controlled process.

You now have the foundation to begin a real project.

The next series will move from setup to product development:

Choose an idea
→ Define the user problem
→ Write a project brief
→ Break the work into features
→ Prompt the AI
→ Review generated code
→ Debug errors
→ Manage Git checkpoints
→ Use APIs safely
→ Test and deploy

The tools are now ready.

The next challenge is choosing what to build and keeping the project small enough to understand.

Conclusion

A safe vibe coding workflow is not built around one AI model.

It is built around a sequence of deliberate decisions.

Open the correct project. Confirm the environment. Start from a clean Git state. Define one small task. Choose the appropriate AI tool. Ask for inspection before broad edits. Review every changed file. Test the actual behavior. Check for secrets and unrelated changes. Stage only what you intend to keep. Review the staged diff. Commit and push the verified result.

The AI assistant can generate code quickly.

Your workflow determines whether that code becomes reliable project history.

This completes the Getting Started with Vibe Coding: A Practical Setup Guide for Beginners series. The next series will begin with the concept of vibe coding itself and guide readers from a small idea to a working application.

Frequently Asked Questions

Should I use GitHub Copilot and Claude Code in the same project?

Yes, when each tool has a clear role.

Copilot can help with focused editor tasks, while Claude Code can support broader repository-level work. Use Git to review and control changes from both tools.

Do I need to commit before every AI prompt?

Not necessarily.

You need a known, recoverable state. When the working tree is clean and the latest commit is verified, that commit already serves as the checkpoint.

What should I do when I do not understand the AI-generated diff?

Do not commit it.

Ask for an explanation, reduce the task, inspect one file at a time, or restore the change and try a smaller approach. A change you cannot review is not ready to become project history.