GitHub for Beginners: How to Use It With AI Coding Agents

GitHub feels complicated until you realize your AI coding agent can handle most of it for you. Here’s our complete beginner’s guide to repos, commits, branches, forks, pull requests, deployment, security, Copilot, Claude Code, Codex, and more, with timestamps from our live walkthrough with GitHub’s Cassidy Williams.

Written By
Grant Harvey
Grant Harvey
Sep 11, 2026
24 minute read

Have you always wanted to make something digital, but didn't know how?

A website. An app. A little tool that solves some annoying problem in your life. You’ve seen people build ridiculous stuff with AI in an afternoon and thought, okay... that's cool and all, but how do I actually do that?

If you already have a ChatGPT, Claude, or Gemini account, you’re surprisingly close.

You can describe what you want in plain English and have an AI coding agent help build it. You do not need to learn how to write all the code yourself first.

That said, you do need to learn how to wrangle the code.

Where does it live? How do you save it? How do you change something without destroying what already works? How do you put it on the internet? And when your AI agent confidently tells you it “pushed a branch and opened a PR,” how do you know whether to smile or panic?

That’s where GitHub comes in.

Don't worry, we'll explain it below.

Now, GitHub has a funny problem in the AI coding era.

Claude Code, Codex, GitHub Copilot, and other coding agents can build surprisingly complex software before you know what half the buttons in GitHub mean.

Then your agent says:

“I created a branch, committed the changes, pushed them to origin, and opened a pull request.”

Cool.

What the hell did it just do?

That was the problem we wanted to solve when we invited Cassidy Williams, GitHub’s Senior Director of Developer Advocacy, onto our GitHub for Total Beginners livestream.

And there is one thing we want to make extremely clear before we explain any of this:

You can use the GitHub Copilot app, Claude Code, Codex, or another capable coding agent to do almost everything in this guide for you.

You can literally say:

  • “Create a GitHub repo for this project.”
  • “Commit what we have right now.”
  • “Push this to GitHub.”
  • “Make a branch for this new feature.”
  • “Clone that repository.”
  • “Review this pull request.”
  • “Resolve the merge conflict.”
  • “Deploy this website.”
  • “Check this repo for security issues before I run it.”
Advertisement

Or just copy and paste this entire blog into your agent and tell it to walk you through it step by step!

See, your agent knows Git (the versioning control system that powers GitHub).

Your job is to understand enough GitHub to know what the agent is doing, what you are approving, and how to recover when something goes sideways.

Think of this article as learning the dashboard before you let someone else drive.

Contents

  • First up, the TL;DR
  • Before You Start: Pick How You’ll Work With GitHub
  • Step 1: Understand What GitHub Actually Is
  • Step 2: Create Your First Repository
  • Step 3: Learn the Git Vocabulary Your Agent Will Use
  • Step 4: Understand Branches, Forks, Clones, and Worktrees
  • Step 5: Use Other People’s Code
  • Step 6: Put a Website Online With GitHub
  • Step 7: Automate Things With GitHub Actions
  • Step 8: Use GitHub Copilot as an AI Coding Workspace
  • Step 9: Connect Claude Code, Codex, and Other Agents
  • Step 10: Keep Your Code and Secrets Safe
  • What GitHub Becomes in the Agent Era
  • Your Action Plan
  • Bonus Q&A From the Livestream
  • All Resources and Links

First up, the TL;DR

Here are the key moments from the livestream if you want to jump around:

Advertisement

🧰 Tools we’ll use along the way

You do not need all of these. We’ll show you what each one does and where it fits.

  • GitHub — where your code lives, changes get tracked, and projects get shared.
  • GitHub Copilot app — GitHub’s agentic coding app. This is where Cassidy does a lot of the live building.
  • GitHub Desktop — the beginner-friendly visual way to commit, push, pull, and manage repos without living in a terminal.
  • Claude Code — Anthropic’s coding agent, which can handle most of the Git/GitHub work for you.
  • Codex — OpenAI’s coding agent and another way to build, edit, test, commit, and ship projects.
  • GitHub Pages — the easiest way we’ll show to turn a GitHub repo into an actual website on the internet.
  • GitHub Actions — GitHub’s built-in automation system for testing, deploying, scheduling jobs, and more.
  • GitHub MCP — lets AI agents connect directly to your GitHub repos, issues, pull requests, Actions, and other GitHub context.
  • Project HydraFusion — GitHub’s experiment in letting multiple AI models work together on coding tasks.
  • Microsoft Foundry — Microsoft’s broader platform for building and running AI agents and models.
  • Netlify — another way to automatically deploy a website whenever you push new code to GitHub.

And yes: the AI agent can help you set up most of the AI-agent stuff. Welcome to 2026.

Now let’s actually understand what all of those words mean.

Before You Start: Pick How You’ll Work With GitHub

There are several ways into GitHub.

For an AI-first beginner, we’d start with one of these:

Option 1: GitHub Copilot app

Cassidy spent the back half of the stream inside the GitHub Copilot app.

This is probably the cleanest option if you want AI coding and GitHub to feel like one product.

GitHub describes its current app as a desktop environment built specifically around agent-driven development. Sessions can work with branches, files, issues, pull requests, diffs, browser previews, and merges from the same workspace.

Cassidy shows this flow at 1:23:36. She searches for the “neuron-is-fun” repository, opens it, and Copilot clones it automatically.

Then she starts asking for changes.

Advertisement

Option 2: Claude Code

You can do the same basic workflow from Claude Code.

We have a separate full guide to Claude Code, but the GitHub part is straightforward.

Point Claude Code at a local repository and tell it what you want:

Check the current git status, create a branch for this feature, implement it, test it, commit the changes, and open a pull request.

That sentence covers an alarming percentage of what we are about to teach you.

Option 3: Codex

Same idea.

Give Codex access to the repo, describe the outcome you want, and let it use Git underneath the project.

GitHub becomes especially useful once agents start operating in parallel. We’ve previously covered how Spotify uses Claude across more than 20 million lines of code, where the surrounding engineering system becomes just as important as the model doing the coding.

Option 4: GitHub Desktop

Want a visual interface without putting an AI agent in charge?

Download GitHub Desktop.

Cassidy recommends it at 23:41 as an approachable way to see files, changes, commits, and pushes without memorizing terminal commands.

⚡ Action step: Create a GitHub account, then pick one working environment. You do not need all four.

Step 1: Understand What GitHub Actually Is

Cassidy gives two good explanations.

The first is incredibly literal:

GitHub is somewhere your code can live on the internet.

She compares it to a Google Doc at 6:27. Your document lives on somebody else’s computer and has a URL you can share.

GitHub does that for code.

Her second analogy is even better:

“Wikipedia for code.”

People can publish projects. Other people can inspect them. Open-source projects can accept contributions from strangers all over the world.

Your project lives inside something called a repository, usually shortened to repo.

Advertisement

And a repository is basically...

A glorified folder.

That folder might contain:

  • Code
  • Images
  • Documentation
  • Configuration files
  • Audio
  • Small video assets
  • Instructions for AI agents
  • Project notes
  • Website files
  • Tests

A viewer asked whether GitHub repositories could hold audio. Cassidy’s answer at 19:57 was yes, although enormous media files often belong on services designed for media storage.

This is also why repositories are becoming so useful for AI agents. The agent sees the project’s files together instead of working from random snippets pasted into a chat.

Step 2: Create Your First Repository

At 14:12, Cassidy walks through the process.

Create an account at GitHub.com, then click the plus button and choose New repository.

You give the repository a name.

You choose public or private.

Then GitHub creates the project.

For your first one, Cassidy recommends creating the special profile repository that matches your username. Her username is cassidoo, so hers is effectively:

cassidoo/cassidoo

A README inside that special repo appears on your GitHub profile.

What is a README?

A README is usually the first document somebody sees inside a repository.

It explains things like:

  • What the project does
  • How to install it
  • How to run it
  • How to contribute
  • What dependencies it needs
  • What the files are for

READMEs are commonly written in Markdown, which Cassidy explains at 27:50.

If you use ChatGPT or Claude, you already see Markdown constantly. Headings, bullets, bold text, links, and code blocks often use Markdown syntax.

And AI agents love Markdown files.

Public or private?

At 17:54, Cassidy gives the simple answer:

Public means other people can see the repository.

Private limits who can see it.

Cassidy publishes much of her work openly.

Grant’s beginner strategy is slightly more cowardly and extremely practical: keep things private until they stop looking embarrassing, then decide whether to make them public.

Advertisement

Both work.

⚡ Action step: Make one private repository for something tiny. Your agent can create the files inside it for you.

Step 3: Learn the Git Vocabulary Your Agent Will Use

Here is where GitHub starts sounding much scarier than it is.

You really need a small collection of words.

Git

Git is the version-control system.

GitHub is the online platform built around it.

Cassidy explains the distinction at 9:59.

Before version control, developers could literally send files back and forth and hope they knew which one was current.

Git records how those files change over time.

Commit

A commit is a checkpoint.

Cassidy compares it to saving before fighting a boss in a video game.

Your agent changes six files.

Everything works.

You say:

Commit this version.

Now you have a recoverable checkpoint.

Git even assigns every commit a unique identifier, which Cassidy shows at 55:07.

Push

A commit records the checkpoint.

A push sends those commits to the GitHub copy of the repository.

Cassidy does this at 29:26, refreshes the browser, and the file she created locally suddenly appears online.

So:

Commit = save point.

Push = send your saved changes to GitHub.

Issue

An issue describes work that needs attention.

At 39:18, Cassidy creates one requesting better formatting for the demo README.

Issues can represent:

  • Bugs
  • Feature requests
  • Tasks
  • Documentation work
  • Enhancements

They can also be assigned, labeled, filtered, and handed directly to coding agents.

Pull request

A pull request, usually called a PR, says:

Here are some changes. Do you want to pull them into the project?

Cassidy walks through this at 45:53.

PRs give you a place to inspect the changes before they become part of your main code.

This is extremely valuable with agents.

Ask:

Review this PR. Explain what changed in plain English. Flag anything risky. Run the tests. Tell me whether you recommend merging it.

Now the vocabulary becomes useful.

You understand what you are asking the agent to inspect.

Merge

Merging combines the changes.

Cassidy’s traffic analogy at 50:44 works well. Cars enter the lane. Code changes enter your main codebase.

Deploy

Deployment means making the software actually exist somewhere people can use it.

Cassidy defines it at 1:11:43.

A common agent instruction might now make complete sense:

Commit these changes, push them to GitHub, merge the PR, then deploy the latest version.

Six mysterious developer words just became normal English.

Step 4: Understand Branches, Forks, Clones, and Worktrees

This was the part several people in the chat wanted explained.

Understand the nouns once and let your agent handle the commands forever.

Branch

Imagine your main project is a tree trunk.

A branch lets you work on a change without immediately modifying that trunk.

Cassidy uses that exact metaphor at 1:04:07.

Say you want to redesign your homepage.

Ask your agent:

Create a branch called homepage-redesign and do the work there. Leave main untouched.

The feature can evolve separately.

Once you like it, merge the branch back into main.

Fork

A fork creates your own separate repository based on somebody else’s repository.

Cassidy demonstrates it at 59:27.

Forking is common in open source because you usually cannot directly edit somebody else’s project.

So you:

  • Fork their repository.
  • Modify your copy.
  • Submit a pull request proposing your changes.

Cassidy demonstrates this with Online Go at 1:01:08.

Clone

A clone puts the repository onto your computer.

Cassidy’s shortest explanation at 1:03:06:

Cloning is downloading.

Fork = make your GitHub copy.

Clone = make your local computer copy.

Worktree

Worktrees become especially important with AI agents.

A worktree gives a task another working copy of the repository.

Cassidy explains why at 1:05:06.

Imagine one agent is rebuilding your settings page while another needs to fix an urgent login bug.

Separate worktrees let them operate in parallel without constantly switching the state of one folder.

Grant points out the AI-specific problem at 1:06:17: agents love creating worktrees.

Each local worktree can consume disk space.

Run enough parallel agents on a big codebase and your computer can fill up surprisingly fast.

Cassidy says she has Copilot clear old worktrees automatically.

And when changes collide?

That is a merge conflict.

Cassidy explains one at 53:58, then hilariously hits a real one during the demo at 1:50:03.

Her preferred beginner solution?

Ask your AI agent.

So do we.

⚡ Action step: Ask your agent to explain the current branch, recent commits, and worktrees in one of your repositories in plain English. You’ll learn faster using your own project.

Step 5: Use Other People’s Code

One of GitHub’s superpowers is open source.

Cassidy explains it at 8:06: enormous amounts of the infrastructure underneath modern software are openly available for anyone to inspect and contribute to.

Want to try someone’s project?

You might:

  • Download the ZIP.
  • Clone it.
  • Fork it.
  • Open it with GitHub Desktop.
  • Open it with Copilot.
  • Give the URL to Claude Code or Codex.

The README normally tells you how to run it.

Or use our favorite approach.

At 44:05, Grant suggests simply giving the repository link to your agent:

I want to try this project. Review the repository first. Explain what it does and anything I should know about running it. Then clone it and help me set it up.

One important warning

A public GitHub repository is accessible code. It is not automatically trustworthy code.

This came up repeatedly in the live chat.

Cassidy summarized the tradeoff perfectly at 49:01:

The cool part of open source is that anybody can contribute.

The scary part is that anybody can contribute.

GitHub has security tools such as Dependabot, which can identify known vulnerable dependencies and malicious packages.

Your agent can also inspect a repository before you clone or run it.

Ask:

Review this repository before we execute anything. Check its dependencies, install scripts, GitHub Actions, permissions, known vulnerabilities, suspicious packages, and anything that could execute code on my machine.

That review reduces risk.

Keep your own judgment in the loop too. GitHub’s security guidance warns that untrusted code can create risks through workflows and Actions, especially when privileged automation processes untrusted pull-request content.

⚡ Action step: Find one open-source project you are curious about. Give the link to your agent and ask it to explain the repo before touching it.

Step 6: Put a Website Online With GitHub

GitHub can host simple websites through GitHub Pages.

Cassidy creates an index.html file during the stream.

Then at 1:10:32, she opens the repository settings, chooses a branch, enables Pages, and deploys it.

A few moments later, the website exists.

You can still play with the bizarre cat game the agent built during the livestream.

GitHub can also feed code into another hosting platform.

Cassidy uses Netlify.

Grant mentions Cloudflare and Railway.

Corey mentions Vercel.

Grant’s actual workflow at 1:16:42 looks something like:

  • Code with Claude Code or Codex.
  • Commit the change.
  • Push it to GitHub.
  • The hosting service notices.
  • The website automatically redeploys.

Once configured, updating a website can be as simple as:

Fix the homepage, test it, commit it, and push it.

Your hosting platform handles the rest.

Step 7: Automate Things With GitHub Actions

GitHub Actions are automations that run when something happens in your repository, or on a schedule.

Cassidy explains them at 1:19:23.

A common engineering example is testing.

Someone opens a pull request.

An Action automatically runs your test suite.

If the tests pass, great.

If something breaks, the Action flags it before the code is merged.

Actions can also:

  • Deploy websites.
  • Check formatting.
  • Run security checks.
  • Mark old issues as stale.
  • Run scripts on a schedule.
  • Trigger other services.
  • Apply rules around who can deploy.

Cassidy even jokes that an Action could enforce something as absurdly specific as letting only people whose names begin with G deploy on Wednesdays.

And yes, your agent can create Actions too.

Ask:

Create a GitHub Action that runs our tests whenever someone opens a pull request. Explain the configuration before you commit it.

GitHub Actions are powerful, which also means you should review workflows that execute outside code or accept untrusted input.

Automation increases leverage in both directions.

Step 8: Use GitHub Copilot as an AI Coding Workspace

This is where the livestream jumps from “GitHub basics” into what GitHub increasingly looks like in 2026.

At 1:23:36, Cassidy opens the GitHub Copilot app.

She finds the repository.

Copilot clones it.

Then the agent can work inside it.

You can:

  • Ask questions about the repository.
  • Plan changes.
  • Edit files.
  • Create branches.
  • Create worktrees.
  • Run parallel sessions.
  • Review diffs.
  • Open pull requests.
  • Review pull requests.
  • Preview the app.
  • Merge code.
  • Automate workflows.

You can choose your model

Cassidy shows the model picker at 1:30:26.

She increasingly prefers Auto, where Copilot chooses based on the task.

Her reasoning is pretty relatable: she increasingly cares less about which model name appears in the dropdown as long as it does the job well.

Rubber Duck: make another model check the plan

At 1:26:59, Cassidy demonstrates the Rubber Duck workflow.

One model family creates a plan.

A different model family reviews it.

Then the original process can reconcile the feedback before implementing.

That idea scales into something GitHub is experimenting with much more aggressively.

HydraFusion: GitHub chooses the workflow too

Cassidy points us to Project HydraFusion at 1:31:51.

HydraFusion can dynamically choose between different multi-model strategies.

One model might handle the task directly.

A cheaper model might attempt it first, with a stronger model brought in if needed.

One model can draft while another independently critiques.

GitHub’s September 2026 offline evaluations reported HydraFusion within 1.5 points of the Opus 5 baseline or better across the three benchmarks it published, while reducing estimated workflow cost by 36% to 67%.

That is worth paying attention to.

The model picker itself may slowly matter less.

The coding environment can increasingly decide which model, or combination of models, should tackle each part of the job.

Pick and Polish

Cassidy also demonstrates Pick and Polish at 1:37:01.

The generated website is visible in Copilot’s integrated browser.

She clicks a specific element.

Copilot identifies the relevant code.

She says what she wants changed.

The agent edits it.

That workflow feels much closer to directing software than traditionally programming it.

Step 9: Connect Claude Code, Codex, and Other Agents

Maybe you prefer Claude Code.

Maybe you prefer Codex.

Great.

GitHub still works.

At 1:33:22, Cassidy explains GitHub’s MCP server.

MCP stands for Model Context Protocol.

The simple explanation is enough:

MCP lets an AI agent connect to another tool and use what that tool exposes.

Connect GitHub and an agent can potentially access context around:

  • Repositories
  • Issues
  • Pull requests
  • Repository search
  • Recent activity
  • GitHub Actions
  • Other GitHub operations allowed by its permissions

This lets you ask questions at the workflow level:

Which pull requests still need my review?

Find the issue about the login bug and fix it on a branch.

Which Actions failed today? Explain why.

Review the repository and tell me which areas have not been touched in months.

Create a PR for this change and summarize the risk.

You can also work locally without MCP if your coding agent already has access to the cloned repository and Git.

The GitHub integration handles the cloud side.

The local Git commands handle the code side.

For a deeper look at how agents divide and verify coding work, our guide to Claude Code’s agent loops gets into that pattern.

Step 10: Keep Your Code and Secrets Safe

This section matters more once AI makes shipping fast.

First rule: commit often

One viewer asked what happens if an agent accidentally deletes code.

Cassidy’s answer at 34:55:

Git history.

You can inspect earlier commits and restore an earlier state.

That is why developers have repeated “commit early and commit often” for years.

It becomes even more useful when an agent can modify dozens of files in one session.

Ask your agent to commit at logical checkpoints.

Bad:

Build the entire app.

Better:

Implement authentication first. Test it. Commit that checkpoint. Then move to the dashboard.

Now one broken dashboard change does not force you to unwind the authentication work too.

Review unfamiliar pull requests

Grant asks Cassidy whether beginners should simply reject pull requests from strangers because they may not understand the code.

Her answer at 47:43 is more useful.

Read the change.

If you understand it, decide.

If you do not understand it, ask your AI tools.

Keep digging until you understand what you are merging.

AI gives beginners a new layer of code review. It does not turn an unexplained change into a safe one.

Use Dependabot

At 45:44, Cassidy shows GitHub’s dependency security tools.

Dependabot can warn you when software packages your project relies on contain known vulnerabilities.

GitHub also supports malware alerts for known malicious dependencies.

Useful.

Still a backstop rather than a magic shield.

Protect API keys and passwords

Grant saves one of the most important beginner questions for 1:51:55.

What happens when your application needs something secret, like an API key?

You do not want the key sitting in a public file for the internet to copy.

Cassidy walks through several defenses.

GitHub secret scanning can detect supported credentials committed into repositories.

Push protection can block supported secrets before they reach a repository.

You can store sensitive values using GitHub secrets or environment variables and reference those values from your workflows.

Learn .gitignore

At 1:53:46, Cassidy shows another file you will see constantly:

.gitignore

It tells Git which files or folders to leave out of commits.

Cassidy shows examples such as build folders and node_modules.

You might also ignore local environment files that contain secrets.

And yes, you can ask your agent:

Review this repository’s .gitignore and make sure we are excluding credentials, environment files, generated files, dependencies, and other files that should stay local.

Then read its explanation before approving the change.

What GitHub Becomes in the Agent Era

The original reason developers learned GitHub was collaboration.

One person changed code.

Another person reviewed it.

Git kept a record.

That system maps almost suspiciously well onto AI coding.

At 11:48, Cassidy takes Grant’s “I collaborate with my agents through GitHub” idea to its logical extreme.

Imagine a software factory with 100 agents.

One agent changes authentication.

Another rewrites the settings page.

Three agents tackle bugs.

Another reviews their changes.

Something goes wrong.

GitHub tells you which agent changed what, when it changed it, what the previous version looked like, and what eventually got merged.

That may be GitHub’s most important role for AI-first builders.

The code is becoming easier to produce.

Managing changes, permissions, provenance, review, recovery, and deployment becomes more important as production gets cheaper.

You do not need to memorize every Git command.

You need to understand the state of your project.

What branch am I on?

What changed?

Was it committed?

Did we push it?

What PR am I reviewing?

What gets merged?

What gets deployed?

Can I roll it back?

Who or what has permission to do this?

Those questions survive no matter which coding agent happens to be winning the benchmarks this month.

Your Action Plan

You can learn the useful 80% of GitHub by actually using it once.

1. Create an account

Go to GitHub.com.

2. Create one private repository

Call it whatever you want.

3. Connect your coding agent

Use GitHub Copilot, Claude Code, Codex, or another agent that can work with Git repositories.

4. Ask it to build something tiny

A personal homepage is plenty.

5. Ask it to explain the repo

Try:

Explain every important file and folder in this repository to me like I am new to GitHub.

6. Make a commit

Make sure the app works, then commit this as our first working version with a clear commit message.

7. Push it to GitHub

Push the current commit to my GitHub repository.

Go look at the website.

There it is.

8. Create a branch

Create a new branch and add dark mode. Do not change main yet.

Now you understand branches by using one.

9. Review and merge it

Show me the diff in plain English. Run the tests. If everything looks good, open a pull request.

Review it.

Then:

Merge the pull request.

10. Deploy it

Use GitHub Pages or connect another host.

11. Try someone else’s repo

For homework, Cassidy gave everyone her own open-source website.

Go to Cassidy’s blog repository.

Then give that URL to your agent:

Read the setup instructions in this repository. Help me create my own version. Explain every step before you do it.

That one exercise makes half of this article real.

Bonus Q&A From the Livestream

Is a repository basically a project?

For beginner purposes, yes.

A repo is the Git-controlled folder containing the files and history for a project.

Larger projects can span multiple repositories, but you can ignore that until you actually have the problem.

Is a private GitHub repo safe?

Private controls access to the repository.

You should still manage permissions, credentials, dependencies, Actions, and account security carefully.

“Private” is an access setting, not a reason to stop thinking about security.

Can I store images, audio, and videos in GitHub?

Yes.

Cassidy answers this at 19:57.

Huge media files may be better stored elsewhere.

Do I need backups if I use GitHub?

Git gives you version history when you commit your changes.

Cassidy shows at 34:55 how you can move back through commits after a bad agent change.

Treat that history as a powerful recovery mechanism.

Critical production systems can still warrant additional backup strategies.

How do I find somebody’s repository?

Search.

Cassidy demonstrates GitHub search at 33:09.

You can search repositories, users, code, and issues.

Or ask your agent:

Find Cassidy Williams’ open-source blog repository on GitHub.

What is GitHub versus Hugging Face?

We answered this one in the chat with an intentionally oversimplified analogy:

GitHub is like Wikipedia or Google Drive for code.

Hugging Face is like Wikipedia or Google Drive for AI models.

There is overlap, but that mental model will get a beginner surprisingly far.

Does GitHub scan everything for viruses?

GitHub provides several security systems, including Dependabot alerts, malware alerts for known malicious dependencies, code scanning, and secret scanning.

That still leaves room for unsafe code.

Review unfamiliar repositories before running them.

Giving the URL to an agent and asking for a security review is a good first step.

Should I use a branch or a fork?

Use a branch when you are working inside a repository you already control.

A fork is useful when you want your own repository-level copy, especially when contributing to somebody else’s open-source project.

Cassidy walks through both starting at 59:27.

Can I move a GitHub-hosted website somewhere else later?

Yes.

Your code can stay in GitHub while Netlify, Cloudflare, Vercel, Railway, GoDaddy, or another platform hosts the actual application.

Cassidy covers that at 1:15:20.

Does Copilot use my Copilot allowance or my Claude/OpenAI allowance?

It depends on how you configure the model.

Cassidy answers this at 1:43:07.

If Copilot provides the model, usage comes through Copilot.

If you configure an outside provider with your own key, usage comes through that provider.

Can I start a project directly in Copilot without a repo?

Yes.

Cassidy shows at 1:43:54 that a session can start as a chat or brainstorming project and become a repo later.

Can GitHub control my heat pump?

Somebody actually asked this.

The useful answer is: if the device exposes software controls or an API your code can access, you can potentially build software that controls it.

Cassidy’s own programmable-light setup at 1:46:28 is the less HVAC-intensive example.

She gave Copilot the problem.

It found the device interfaces.

It helped create the mappings.

Then she hooked the result to a programmable keypad.

AI coding gets much more fun once your projects escape the browser.

Everything we shared or referenced during the stream:

Watch and learn

GitHub basics

AI and agents

Cassidy Williams

From the rest of the stream

One More Thing

The easiest way to use this guide might be the same way we told people to use Cassidy’s repo.

Give the article to your coding agent.

Then say:

I’m new to GitHub. Read this guide and help me set up GitHub for my current project. Explain each Git concept the first time we use it. Handle the commands for me, but ask before anything destructive, public, security-sensitive, or irreversible. Commit frequently so we can recover from mistakes.

GitHub becomes much less intimidating once the commands stop being the assignment.

The vocabulary is what you need. The agent can type.

The unresolved part gets more interesting from here.

As coding agents create more branches, worktrees, pull requests, tests, reviews, and deployments themselves, how much of GitHub eventually becomes infrastructure humans supervise rather than an interface humans operate?

You probably still want to understand the commits.

Grant Harvey

Grant Harvey is the Lead Writer of The Neuron, where he continues to lead the publication's daily coverage of AI news, tools, and trends.

The Neuron Logo

Don't fall behind on AI. Get the AI trends & tools you need to know. Join 700,000+ professionals from top companies like Microsoft, Apple, Salesforce and more.

Property of TechnologyAdvice. © 2026 TechnologyAdvice. All Rights Reserved

Advertiser Disclosure: Some of the products that appear on this site are from companies from which TechnologyAdvice receives compensation. This compensation may impact how and where products appear on this site including, for example, the order in which they appear. TechnologyAdvice does not include all companies or all types of products available in the marketplace.

Stay in the loop

Get notified when we publish new articles.