Managing code repositories when AI writes the code

AI will open a pull request before lunch. That is not the hard part.

The hard part is still the same as it was when the junior on the team typed too fast: knowing what changed, why it changed, and whether you can reverse it at 2am without guessing.

At PelicanSoft we use AI to move work. We do not hand it the keys to main and hope. If your shop is letting models write real code into real repos, here is how we think about the repository — not the model.

1. Treat every AI change like an untrusted contributor

Same rules as a contractor you have never met.

• One branch, one job. Do not let a session sprawl across “while we’re in here.”
• Small pull requests. Reviewable in one sitting. If the diff needs a map, it is too big.
• Human owns the merge. The model drafts. A person with context hits the button.

If you cannot explain the change in two sentences, you are not ready to merge it.

2. Make the history tell the truth

Commit messages that say fix stuff or wip ai are a tax on everyone who follows you — including you next quarter.

Ask for:

• A subject that names the behavior change, not the tool (Add invite expiry to farm roles, not cursor changes).
• A body that says what and why. Link the ticket or the decision.
• No secret dumps in the commit. Models will happily paste .env fragments into a file. Pre-commit hooks and secret scanning are not optional anymore.

The repository is the audit trail. Write it like someone will read it under pressure.

3. Protect main like production

AI does not respect your feelings about “just this once.”

• Branch protection on main / master. Required reviews. Required checks.
• No force-push to shared branches.
• CI that actually runs: build, lint, unit tests that cover the code you claim to ship.
• Preview deploys for web work when you can afford them. A green check that never boots the app is theater.

If AI can merge straight to main, you do not have a process. You have a slot machine.

4. Scope the agent’s working tree

A model with the whole monorepo open will “helpfully” edit three packages you did not ask about.

• Give it a narrow prompt and a narrow path.
• Prefer one PR per concern: schema, API, UI — not all three in one fog.
• Diff before you accept. Read the file list first, then the meat of the change.
• Delete generated noise. Lockfile thrash, reformatting the universe, and drive-by renames belong on the floor.

Your job is to keep the blast radius small.

5. Tests and types are the cheap safety net

AI is confident. Confidence is not coverage.

• Prefer typed languages and strict mode where you already have them.
• Require tests for the behavior the PR claims to add.
• Do not accept “I couldn’t run the tests” as a merge reason. If the agent cannot run them, you run them.
• Snapshot and golden files need human eyes. Models love updating snapshots until the suite is green and the product is wrong.

Green CI with empty assertions is how you get a quiet production incident.

6. Secrets, data, and prompts do not live in git

Same rule we use for databases: production truth does not go into a chat, and it does not go into the tree.

• .env stays local or in a secrets manager.
• Scrub fixtures. No real customer rows in seed files “for realism.”
• Review agent transcripts and PR descriptions for leaked tokens before you paste them into Slack.

If the model saw the secret, rotate it.

7. Keep a human map of the system

AI will not remember why you chose SQLite on device, or why that migration is one-way.

Maintain a short living doc in the repo:

• How to run it.
• How to ship it.
• What must never change without a product call.
• Where the landmines are (upgrade paths, dual-write, feature flags).

When the agent is gone, the map has to still make sense.

8. Decide what “done” means before you start the session

Write the acceptance criteria first. Then let the model work toward them.

Done might be: tests pass, migration is reversible, mobile build installs over existing data, no new dependency without a reason. Done is never: “the agent said it finished.”

Bottom line

AI is a force multiplier for people who already know how to run a repository. It is a mess amplifier for shops that skip reviews, skip CI, and merge on vibes.

We will keep using the tools. We will also keep the boring parts — branches, reviews, tests, secrets, and a main branch that means something.

If your team is shipping faster than your repo discipline can absorb, that gap is the fire. Tell us where it hurts: pelican-soft.com/contact

— Jere DeLaune
PelicanSoft, LLC
Built in Texas