Built by QCerris

Why We Built CodeMerlin

We didn't set out to build a product. We set out to fix our own delivery — and the fix turned out to be the product.

QCerris is an engineering company. When AI made our coding faster but our delivery no better, we built the layer we couldn't buy. This is that story.

31 Oct 2026QCerris Team

Where it started

We had the same problem our clients have

QCerris runs engineering teams for enterprise clients. We adopted AI coding tools early and the effect was immediate: more code, written faster, by every engineer.

Delivery didn't speed up to match. Vague tickets turned into confidently wrong implementations. Pull requests piled up faster than anyone could honestly review them. And every team used AI its own way, so quality depended on who picked up the ticket.

We looked for a tool that managed the whole loop — from the ticket to the merged pull request — and found tools that each covered one step. So we built the missing layer ourselves, for our own teams, on our own projects.

The two-minute version: what CodeMerlin does and why it exists.

What we built

A loop, not another step

CodeMerlin runs the work from intent to delivery: Specification → Technical plan → Tasks → Tests → Implementation, with a person approving at the points that matter.

It starts inside the tools we already used. Tickets sync both ways with Jira and Linear — nothing is re-entered, nothing drifts out of date. From the ticket, CodeMerlin writes a testable spec with acceptance criteria and puts the open questions at the top, so a person settles the ambiguity before an agent writes a line of code.

The expensive mistakes were never in the code. They were in what the code was asked to do.

CodeMerlin ticket sync with Jira and Linear — Your Jira or Linear tickets, synced both ways. CodeMerlin starts from the ticket you already have.

CodeMerlin spec with acceptance criteria — A testable spec with acceptance criteria — written and approved before any code.

Different by design

Review the intent, not just the diff

Plenty of tools will review a pull request. They read the diff: style, bugs, patterns. CodeMerlin reviews the pull request against the approved spec — did this change deliver what was asked? That difference sounds small and changes everything downstream.

It also acts on the answer. The merge gate holds a pull request until it demonstrably delivers the spec, which means "done" stops being an opinion. And because every ticket, spec, plan and PR hangs on one thread, leadership gets a single view of where work stands across teams — without asking anyone to fill in a status report.

There's nothing new to learn. Engineers keep their IDE and their agents, product keeps Jira or Linear, reviewers keep GitHub or GitLab. CodeMerlin is the layer between them, in your cloud or on-prem, with your choice of model.

CodeMerlin merge gate — The merge gate: a pull request merges when it delivers the spec, not just when the diff looks clean.

CodeMerlin cross-team board — One view across teams: where every piece of work stands, from intent to merged.

Why we trust it

We ran it on ourselves first

CodeMerlin governed QCerris delivery before it had a name or a website. Our own teams were the first users and the harshest reviewers, and the features that exist are the ones that survived real projects: the spec gate exists because vague tickets burned us, the merge gate exists because fast code without proof burned our clients.

We built it because we needed it. We kept it because it works.

Built by QCerris. Run on QCerris. Ready for you.

See CodeMerlin in action →