AI wrote the code. Here's how to keep the repo healthy.

AI can build a working app in a weekend. That part got easy.

But when someone opens your repo, they're not only looking at the app. They're looking at how you work. And a lot of repos shared on LinkedIn look like this:

• one branch, main, with everything pushed straight to it
• 200 commits called "update", "fix" or "changes"
• one commit that touches 40 files
• no README, or the default one
• a .env file in the history

The app works. The repo says nobody is maintaining it.

None of this is hard to fix. Here's what to set up, in order.

1. Protect main

main should always be the version that works. Nothing goes into it directly.

On GitHub: Settings → Rules → Rulesets → New branch ruleset.

• Enforcement status: Active
• Target branches: main (and develop if you use one)
• Tick Restrict deletions and Block force pushes
• Tick Require a pull request before merging, with required approvals set to 0
• Tick Require status checks to pass, and pick your CI check

Branch protection is free on public repos. Private repos need a paid plan.

2. One short branch per change

Every change gets its own branch, with its type in the name:

feat/supplier-search      new feature
fix/login-redirect        bug fix
chore/upgrade-next        setup, dependencies
docs/readme-setup         documentation
test/checkout-failures    tests
refactor/order-service    restructure, same behaviour

Anyone can tell what a branch does before opening it.

Keep branches short. Merge within a day or two. A branch that stays open for a week while main moves on will end in merge conflicts that take longer than the work itself.

3. Open a pull request for every change, even when you work alone

This sounds like extra work. It's the most useful habit on this list, especially when AI writes the code.

When you ask an AI tool for a feature, it can change ten files at once. Some of those changes you asked for. Some you didn't. In your editor, it's easy to accept all of it and move on.

The pull request shows you the full diff in one place. Read it like a reviewer would:

• Did it change files that have nothing to do with the task?
• Did it remove a check, a test or an error handler?
• Did it add a package you don't need?
• Would you be able to explain every line if someone asked?

If you can't explain a change, don't merge it. That is the difference between using AI and being used by it.

4. Run CI on every pull request

CI is a script that checks your code automatically before it can merge. Nothing fancy is needed. A file like this in .github/workflows/ci.yml is enough:

name: CI
 
on:
  pull_request:
    branches: [main, develop]
 
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npx tsc --noEmit
      - run: npm run build

Lint, type check, build. If any of them fails, the pull request goes red and can't merge (once you've turned on the status check rule from step 1).

AI-written code often looks right and still fails the type check. CI catches that before it reaches main, not after.

5. Write commits a stranger can follow

Compare these two histories:

update
fix
changes
fix again
final

feat(auth): add password reset email
fix(cart): keep items when the session expires
chore: upgrade next to 16.3
docs: add setup steps to README

The second one uses a format called Conventional Commits (opens in new tab): type(area): what changed. Six months later, you can find when something broke by reading the log.

Two rules make the biggest difference:

• One change per commit. If the message needs "and", it's probably two commits.
• Don't commit AI output in one go. Split it by what it does, so each commit can be read on its own.

6. Keep secrets out of the repo

This one costs real money when it goes wrong.

• Put .env and .env.local in .gitignore before your first commit.
• Commit a .env.example with the variable names and fake values, so others know what to set.
• AI tools sometimes paste keys straight into code. Search before every pull request:

git diff main --stat
git grep -nE "sk_live|sk-|AKIA|service_role|password\s*=" -- . ':!*.example'

7. Write a README a stranger can follow

A recruiter or reviewer gives your repo about a minute. The README decides what they see in that minute. It needs four things:

1. What it is, in one or two sentences
2. A link to the live app, and a demo login if it needs one
3. How to run it locally: install, environment variables, start command
4. What's not done yet, honestly

The last one matters more than it looks. "Payments not built yet" reads much better than a reviewer finding it out on their own.

8. Write down why

Code shows what you did. It doesn't show why.

When you make a choice that's hard to undo, like the database, the auth method or the folder structure, write a short file in docs/decisions/: what was decided, why, what else you looked at, and what it costs. More on that in Architecture decision records: write down why.

This matters even more with AI. Six months later, "the AI suggested it" is not an answer anyone can work with.

The checklist

Before you share a repo, go through this:

• main is protected, and nothing is pushed to it directly
• every change came in through a pull request
• CI runs on every pull request, and it's green
• commit messages say what changed
• no .env or keys in the code or history
• .env.example exists
• README has what it is, a live link, how to run it, and what's missing
• big decisions are written down

AI makes building fast. These habits are what make the result something people can trust, and something you can still work on in six months.