The AI ate my main branch: why feature branches matter more than ever

TL;DR: AI coding assistants can generate substantial changes rapidly. That speed is a superpower - until you're working directly on main and need to sync with remote changes. One messy merge later, you're questioning which parts of your codebase are even correct anymore. Feature branches aren't just good practice with AI - they're essential. This isn't theoretical advice. I learned it the hard way.

---

There's a particular feeling when you realise you've made a fundamental mistake. It sits somewhere between your stomach and your chest, and it usually arrives about three seconds after you've pressed Enter on a command you can't take back.

I experienced that feeling recently. Not because of anything exotic - just the oldest mistake in the book, dressed up in new clothes.

The setup: everything was going brilliantly

The project was progressing beautifully. Working with Claude as my AI coding assistant, we were building out a substantial feature - the kind that touches multiple files, requires careful coordination between components, and normally takes several days of focused work.

The AI was performing exceptionally well. Changes were coherent. Tests were passing. The feature was taking shape faster than I'd expected. Hours of work, dozens of files modified, everything building on itself in that satisfying way that happens when a session is really flowing.

And I was doing all of this directly on the main branch.

You already know where this is going.

The moment everything went wrong

Eventually, I needed to push my changes. As one does. But the remote had moved on - other changes had been merged while I was heads-down in my AI-assisted development session.

No problem, I thought. I'll just pull and merge.

What followed was... educational.

The merge introduced conflicts. Some were obvious. Others were subtle. And because I'd been working with an AI that had generated changes across many files - changes that I understood in the flow of creating them but couldn't necessarily reconstruct from memory - I suddenly wasn't sure what was "mine", what was from the remote, and what the AI had done that I hadn't fully internalised.

The codebase was in a state that was difficult to reason about. Not broken, exactly. But uncertain. And uncertainty in a codebase is its own kind of broken.

The lesson isn't new - but the context is

Here's the thing: this mistake isn't novel. "Don't work directly on main" is version control 101. It's advice so basic it feels almost embarrassing to write about.

But here's why it hit differently with AI assistance:

The volume of changes is higher. When you're pair-programming with an AI, you can generate more code in an hour than you might normally write in a day. That's the point. But it also means your working tree diverges from main faster and further than it would with manual development.

The changes span more files. AI assistants are good at making coordinated changes across a codebase. That's genuinely useful - but it also means a merge conflict isn't isolated to one file. It's potentially scattered across a dozen.

Your memory of the changes is different. When you write code by hand, every line passes through your conscious attention. When you're working with AI, you're reviewing and directing, but you might not have the same granular recall. During a merge conflict, that matters.

The temptation to "just keep going" is stronger. When the session is flowing well, when the AI is producing good work, the last thing you want to do is interrupt the momentum to create a branch. The cost feels high. The risk feels low. Until it isn't.

What I should have done

The fix is obvious in hindsight. It's always obvious in hindsight.

Create a feature branch before starting. Even if the work seems small. Even if you "just want to try something quickly." Especially when working with an AI that can generate substantial changes rapidly.

Merge main into the feature branch regularly. Don't let the branches diverge too far. Pull changes from main into your branch frequently - daily at minimum if main is active. Resolve any conflicts in the feature branch, where the stakes are lower.

Commit in smaller increments. AI sessions can generate massive changesets. Break them down. Commit logical chunks as you go. This makes the history comprehensible, makes rollbacks practical, and gives you clear checkpoints if something goes wrong.

Keep main deployable. The whole point of main is that it should always be stable. Working directly on main, even locally, puts that at risk.

These aren't new principles. They're just more important when your development velocity has increased.

Recovery strategies (for when you've already made the mistake)

If you find yourself in the situation I did, all is not necessarily lost.

Git reflog is your friend. Before you had any merge conflicts, your branch was in a good state. Git knows where that was. git reflog will show you the history of where HEAD has pointed, including states before your problematic merge.

Stash before merging. If you haven't done the merge yet but suspect it might be messy, git stash your local changes first. This preserves your work in a safe place while you investigate what a merge might look like.

Know when to cut your losses. Sometimes the right answer isn't to debug the merge. Sometimes it's to note what you accomplished, reset to a clean state, create a proper feature branch, and re-implement. With an AI assistant, re-implementation is often faster than you'd think - especially since you now understand the problem better.

Your AI can help with recovery. If you're using a tool like Claude Code that maintains conversation history, the AI has context about what was done. It can help you understand which changes were intentional, identify what might have been broken by the merge, and assist with re-implementation if needed.

AI-specific considerations

There are a few additional factors unique to working with AI assistants.

Context compaction happens. AI tools manage their context windows, and older conversation history may be summarised or compressed. If you're relying on the AI remembering the rationale for changes made hours ago, you might be disappointed. Save important decisions in comments, commit messages, or documentation files.

Session boundaries matter. If you're working across multiple sessions, the AI won't necessarily remember the full context of previous work. Starting fresh on a feature branch, with a clean description of the goal, is often cleaner than trying to resume mid-stream.

The AI's "memory" is your conversation history. Some tools save transcripts or maintain logs. These can be invaluable for recovery - you can read through what was discussed and decided, even if the AI's active context has moved on.

The meta-lesson

Working with AI coding assistants doesn't change the fundamentals of good software practice. If anything, it amplifies them.

Version control discipline isn't less important when you're developing faster - it's more important. Code review isn't less necessary when an AI wrote the code - it's more necessary. Testing isn't optional just because the AI said the code is correct.

The AI is a force multiplier. That's powerful when things are going well. It also means mistakes get multiplied. The guardrails that seemed like overhead for normal development speed become essential at AI-assisted development speed.

What I do differently now

After my educational experience, I've adopted a few practices:

Feature branch first, always. Before I start any AI-assisted session that might generate changes, I create a branch. No exceptions. The cost is seconds. The protection is substantial.

Checkpoint commits. When the AI completes a logical piece of work, I commit it. Even if it's not "finished." These checkpoints are invaluable for understanding what happened and rolling back if needed.

Frequent syncs with main. Every few hours during active development, I merge main into my feature branch. Small, frequent merges are dramatically easier than one large merge at the end.

Document decisions inline. If the AI and I make a non-obvious decision, I add a comment. The AI's context will eventually roll over. Comments are permanent.

Explicit session boundaries. When I take a break or end a session, I commit everything, push to the remote, and write a brief note about the current state. Starting fresh is much easier when you have a clear checkpoint.

The upside

Here's the good news: none of this reduces the productivity gains from AI-assisted development. It just protects them.

A feature branch takes seconds to create. Small commits are actually faster than large ones (less to keep in your head). Frequent merges prevent catastrophic merge conflicts.

These practices feel like overhead until the day they save you hours of debugging a messy merge. Then they feel like the minimum viable sanity.

---

Want to accelerate without the risk?

AI-assisted development is genuinely transformative when it's done well. Getting the workflow right - including version control discipline, testing practices, and review processes - is the difference between faster delivery and faster chaos.

If you're exploring how AI tools can enhance your development team's productivity, or if you're already using them and want to establish better practices, let's talk. Building sustainable AI-augmented workflows is something I help teams with regularly.

Book a call to discuss how AI can amplify your team's capabilities - safely.