A pipeline instead of one clever chat: blockers surface before production, not during an incident

A language model is confidently wrong. A single model that writes the code and then checks its own work is one voice with no opponent: it defends its own decision instead of hunting for the hole in it. So we built a process where every decision always faces an independent adversary.

Pipeline

Five stages

Stage 01

Plan

The task becomes a rigid document rather than prose: the goal, the exact list of files, numbered steps each with an owner and a verification command, binary acceptance criteria, risks and edge cases, and an explicit list of what is out of scope. Acceptance criteria are written so they can be answered yes or no, never “seems to work”.

Stage 02

Independent plan review

The plan is critiqued by an independent reviewer — with full read access to the code, but no right to rewrite the plan; on critical paths that role goes to a model from a second vendor. The reviewer returns a green / yellow / red verdict and a list of findings. Red means the plan must not be executed. We accept or reject every finding in writing: the architect has the final word, but silently ignoring a finding is not an option.

Stage 03

Execution

The work is split between agents with different profiles: reasoning-heavy ones take architecture and hard debugging, fast ones take mechanics and tests. Independent chunks run in parallel. Every worker gets a four-part contract: the goal, the required report format, which files and tools are in play, and the boundaries — what must not be touched. A bug counts as fixed only when the reproducing scenario has been run and passes, and nothing that passed before has broken.

Stage 04

Double blind review and synthesis

Finished code goes to two reviewers working in parallel and independently, blind to each other; on critical paths one of those voices is a model from a second vendor. Both receive only the diff and the acceptance checklist — never the author's reasoning, because “here's why I did it this way” anchors the reviewer and turns review into rubber-stamping. Findings use a strict format: severity, file and line, scenario, fix. The two reviews are never shown to each other before synthesis.

Stage 05

Handover and operations

Launch is not the finish line. Handover comes first: credentials, database dumps, documentation, deployment instructions — the exact materials and rights are fixed in the contract. Then operations under an SLA: monitoring, a contractual incident response time, updates, restore testing of backups and an agreed volume of changes per month. The subscription costs RUB 40,983.61 / month (RUB 50,000 incl. VAT at 22%); and if you take the system over and run it yourself, we hand it over in a state fit for that, not in a state of “it works as long as nobody touches it”. The subscription scope and price are in the price list.

The fail-closed rule

An empty or truncated reviewer response means “no verdict”, not “all clear”. Every blocking finding is closed either by a fix or by a written justification for declining it. A single vote for a blocker forces a discussion even if the other reviewer disagrees. And if a reviewer keeps returning “looks great” with no findings at all, we treat the review as decorative and reinforce it rather than celebrating.

The difference

How this differs from “we wrote it with ChatGPT”

A model from one vendor has systemic blind spots — and they are identical whether it acts as author or as reviewer. A model from a different family does not share them — which is why, on critical paths, we make the second voice a model from a second vendor. Cross-vendor review is exactly what caught blockers that would otherwise have shipped: a migration that only worked on a newer database version, and a non-idempotent migration that granted privilege escalation on a repeat run. In the in-house messenger case, cross-vendor review found 32 defects, 12 of them critical — after the first release had already shipped.

Show a reviewer the author's rationale and they will almost always confirm it. We hand over only the code and the criteria — and get findings instead of agreement.

“Works correctly” is not a criterion. A criterion is “command X returns Y”, “test Z is green”, “the reconciliation across 15 reports closes at 0.00 ₽”. You cannot talk your way past that. That last criterion comes from the marketplace settlement reconciliation case, where the gap closed at zero.

Backup before the operation, a transaction with a row-count gate, read-back verification, a snapshot-based rollback plan, migrations rehearsed on a restored copy first. A worker's mistake must never become a loss of your data.

What this buys you

You aren't paying for lines of code; you're paying for a system that won't fail on live data. The pipeline costs us extra time on every task — and saves you outages, rollbacks and conversations with lawyers. That is precisely why we take on production work rather than prototypes only.

See what the pipeline produced on live projects — case studies →

Discuss your project