Your AI agent keeps mentioning Git. Do you need to care?

Mik Bry · 2026-08-25 · ~8 min read · KB · Launch Readiness

Your AI coding tool mentions "commits," "branches," or "pushing to GitHub" the way a contractor mentions rebar — like you're supposed to already know why it matters. You don't write code, so it's tempting to wave it off as plumbing you'll never need to look at.

I don't think you can afford to wave this one off, and it's the first thing I check when I look at an AI-built app for someone: does this project even have a real history. Not because you need to learn to "do" Git. Because without it, getting cleanly back to a previous working version becomes much harder.

01 — What is it?

Here's the simplest frame I've found: it's Google Docs' version history, for your entire app.

You already know that feeling — you open a Google Doc, click "version history" in the corner, and scroll back through every draft since the file was created. Google Docs saves versions automatically. Git gives software projects the same kind of history, but that history is created when changes are committed.

That happens locally: every time your AI agent (or a human developer) commits a meaningful chunk of work, Git records a snapshot — what changed, when, and a short note about why. Over weeks of building, that turns into a full timeline of your app, not just its current state.

GitHub is a different thing, and this is the part worth getting exactly right: Git remembers the history. GitHub stores and shares that Git history online. If Git is Word's track-changes, running on whatever machine your agent works on, GitHub is Google Drive — the place that same tracked document lives so it can be reached from anywhere, shared with someone else, and survives even if the original machine doesn't. GitHub itself isn't the version history. It's where the version history goes to be safe and shareable.

Neither of these requires you to open a terminal. Everything in this article works through GitHub Desktop or your AI tool's own built-in GitHub integration — a few clicks, no commands to memorize.

02 — Why should you care if you don't code?

An autonomous coding agent may make changes you didn't explicitly ask for, or changes whose consequences you only notice later. That's not a flaw in any particular tool — it's what "autonomous" means. A version history is the safety net underneath that: the thing that turns "the agent broke something and I don't know what" into "here's exactly what changed, and here's the version from before it happened."

This is one of the first things I look for in a Trust Report, because so many other questions become easier once there is a reliable history. Everything else — whether tests exist, whether anything checks a change before it ships, whether secrets are exposed — is easier to reason about once you know there's a record to check against. Without version history, a scan (or a person) can't even establish what changed between "it worked yesterday" and "it doesn't today." With it, that question has an actual answer.

There's a second reason, more about ownership than safety: at some point you'll likely hand this project to a developer, bring on a co-founder, or show it to an investor. If the only copy of your app's history lives inside your AI tool's own account, you don't fully control it — you're a guest in someone else's system. Keeping the GitHub repository under an account or organisation you control, before any of that happens, is my recommendation, not an industry rule everyone follows. But it's the difference between handing someone a project and handing someone a project whose source and history you actually control.

03 — What does good look like?

You don't need to read code to check most of this. Look for:

• A repository exists at all. Somewhere, this project is tracked by Git — not just sitting as a folder of files with no history behind it.
• Commits are meaningful, not one giant dump. A useful history has regular, meaningful commits over time, rather than one giant dump that hides months of work.
• Changes in progress are isolated somehow — often with branches — instead of every experiment going straight to the live version.
• A remote points at GitHub — the local history isn't just sitting on one machine; it's backed up and reachable online.
• You or your company control the GitHub account or organisation the repository lives under — not an account that belongs to your AI tool, an old contractor, or nobody in particular.

If you don't have a GitHub account or a repository yet, both take a few minutes and no command line: getting started with your GitHub account covers signing up, and the quickstart for repositories walks through creating one. From there, GitHub Desktop — or your AI tool's own "connect to GitHub" button — handles the rest.

Reference: freeCodeCamp's description of Git as "the Google Doc of coding" is where I first saw this analogy land cleanly for a non-technical reader, and it's the one I've kept coming back to since.

04 — What can you safely ask your AI agent?

You don't need to inspect any of this yourself. You can ask your AI coding tool to check it for you — and the exact wording matters, because a search that finds nothing is not the same claim as a project that has nothing. If your agent can't find a repository, the honest answer is "I couldn't find one," not "there is none." Paste this in as-is:

Read the answer, don't act on it yet. If your agent finds a real repository, recent commits, and a remote pointing to GitHub, you've found the main signals described in section 3. If it comes back saying it found nothing, that's your actual starting point — worth understanding before you build another week on top of it.

This is one article in the Launch Readiness KB series, which walks through what a Trust Report scan actually looks for before you launch, hire, or raise on an AI-built app — one concept per article, always ending in something safe to ask your agent, never something that changes your code.