How a small moment of frustration became a quiet rebellion against cognitive overload
There are days in engineering where the code isn’t the hard part but it’s everything around the code.
You open a merge request and suddenly you’re drowning in context switches. Dependency chains. Side effects. “Wait, how does this affect that?” Tabs multiplying like rabbits. Documentation you know exists… somewhere. Review queues stacking up. And the invisible tension of “don’t break anything,” pressing on your shoulders.
That’s the world I was living in when Mergebot was born. Not in some grand strategy meeting. Not in a whiteboard workshop with sticky notes and clever frameworks.
It was born in the quiet moments – the annoyed moments when I kept staring at MRs thinking:
Why does reviewing code feel harder than writing it?
And why does it require a human every single time, even when the change clearly doesn’t deserve one?
The Two Sparks
Looking back, the inspiration for Mergebot came from two places that collided gently, then loudly, then unignorably.
1. Cognitive Overload — The Silent Tax
Modern teams don’t struggle because they’re bad at coding.
They struggle because our brains are over-stimulated with unnecessary detail.
Every MR feels like unpacking someone else’s suitcase:
tiny changes mixed with big ones
hidden implications
dependencies nested like Russian dolls
“you need to check this file because that file depends on it”
and the mental gymnastics to understand what’s actually changing versus what’s noise
It was a daily tax. Small enough to ignore. Large enough to slow teams down.
I kept thinking:
This is not a human problem. This is a machine problem we’re forcing on humans.
2. High-Velocity Teams… Choked by Their Own Velocity
At the same time, I was part of a team/org that wanted to ship fast. And we could technically but bureaucracy doesn’t care about technical capability.
Every single change, even the harmless ones needed a reviewer.
Not because it made sense but because “that’s the process.”
It didn’t matter if the change was:
- fixing a typo
- removing dead code
- adjusting a config
- bumping a version
- updating a doc
- or touching something so isolated it couldn’t possibly harm anything
It still had to wait in a line for someone to click “Approve.” That’s when the question started burning in my head:
Can we take advantage of AI to break this dependency on human reviewers?
Can AI become the first line of defense for teams that want to move fast — but responsibly?
That was the moment Mergebot went from irritation → idea → obsession.
So What Is Mergebot Really?
Mergebot is a machine reviewer.
A reviewer that:
never gets tired
never gets overwhelmed
never forgets context
and never complains about “too many tabs open”
It takes in the whole picture — diff, dependencies, history, tests, affected areas — and returns a score from 0 to 10.
Not a judgement. Not a “merge this now” decision. Just a number that says:
“Here’s how risky this change really is.”
Then you — or your rules — decide what to do with it. Different teams, different thresholds:
- Some teams merge automatically when Impact Score < 3 symbolizing a low risk change
- Some stop merges below 2
- Some treat it like a second opinion
Mergebot doesn’t replace your reviewers. It refactors their workload.
Humans handle the changes that deserve humans. AI handles the noise.
A Note About MedTech
I work in a regulated industry. A world where compliance shapes everything — including how we review code.
But Mergebot wasn’t built for medtech.
It wasn’t built for finance.
Or automotive.
Or SaaS.
Or startups.
It was built for anyone with a pulse and a pull request.
We all live with cognitive overload.
We all deal with review queues.
We all experience the friction between wanting to ship fast and needing to be responsible.
Mergebot simply started in my world — but it was never meant to stay there.
The Heart of It
When I strip away everything — the architecture diagrams, the model fine-tuning, the experiments, the pipelines — what remains is simple:
I built Mergebot because I was tired. Not physically but Cognitively. And I knew we could do better.
If machines can fly planes, translate languages, and write poetry…
then surely, surely, they can tell us whether changing three lines inutils.pyis safe to merge.
This Is Just the Beginning
Mergebot is not trying to replace engineering principles or rewrite the rules of software development or promise some magical zero-review utopia.
It’s simply a tool born from a very human moment:
“I’ve seen this somewhere before — in a tab, a doc, a Jira ticket — why am I redoing this analysis again?”
Mergebot remembers so you don’t have to.
Everything else grows from that.
Learn more about Mergebot here and the Github project
