How to make your non-tech vibe coders team scale, Engineering 3.0
The pipeline
This is the structure that survives contact with a real team — a product owner and QA who do not read code, an agent that writes all of it, and an engineering team positioned as gates rather than authors.
Walk it once, because every box is placed where it is for a reason.
The ticket is the contract. The product owner writes it in plain language: what should be different, for whom, and — the part most tickets skip — how you would tell it worked. Those acceptance criteria get frozen with the ticket, because two gates downstream will test against them, and criteria invented after the fact always pass. The product owner never touches code, and never needs to.
The agent is the only author. One branch per ticket, and every line in the system comes through it. A finding at any later stage — QA’s, the engineer’s, the tech lead’s — returns to the agent as a prompt, never as a hand-edit. That rule looks pedantic and is load-bearing twice over: the moment a human patches by hand, the provenance chain breaks and the review chain reviews the wrong thing.
Nothing reaches a human red. Between the agent and the first person sits the only gate with no human in it: the suite, the type checker, the linter, a security scan, a dependency audit. It runs on the branch, and a failure goes straight back to the agent as a prompt without costing anyone a review. This box is doing more work here than in an ordinary pipeline, because the humans downstream are specifically bad at what it catches — a non-technical reviewer clicking through a preview cannot see an injection, a missing authorization check, an N+1 or a race, and a model will produce all four while the screen looks perfectly correct. Put the machine first and the human gates get to spend their attention on the things only they can judge.
Every task gets its own running environment. The branch auto-builds and deploys a full stack — its own containers, its own seeded data — and a wildcard proxy (Traefik, or anything that can route task-47.staging.example.dev to the right containers) puts it on a link. This is the move that makes a non-technical team possible at all. You cannot ask a non-coder to review a diff; you can ask them to click a link and try the thing. And because each task runs alone, tasks stop trampling each other on one shared staging — the classic failure of the shared-environment era.
That link is also what keeps the tech team undisturbed. The product owner who wrote the ticket can open the preview and check the core behaviour against what they meant — no engineer pulled out of what they were doing, no “can someone deploy this so I can look”, no meeting to demo it. Intent gets verified against a running system instead of a description of one, at the moment it is cheapest to correct, and the seats further down spend their attention only on what has already survived that check.
QA speaks prompts, not patches. QA drives the preview like a user, against the ticket’s criteria. What fails goes back to the agent as a prompt; what is ambiguous goes back to the product owner as a comment on the ticket about what it meant. Notice what just happened: the entire find-fix loop runs between two non-technical people and a model, on a disposable stack, without an engineer in it. When the task finally passes on its own environment, QA opens the pull request — the diff, the preview link, the trail of what was checked.
The engineer reviews fit. Three different things get proven in three different places, and it is worth being precise about which: behaviour on the preview, by someone driving it; correctness by the suite, which covers the error paths, the concurrency and the authorization checks nobody clicks through; fit here, by a person. Re-proving the first two in a diff view would be theatre. This seat asks the questions neither of the others can answer: does this fit the architecture, does it re-implement something the codebase already has, does it pull in a dependency for a solved problem, is the data model sane, will the next ticket be easier or harder because of it. Requested changes go — where everything goes — back to the agent as a prompt, and the review runs again. The harder tickets are also the engineer’s to carry: the same seat that judges engineering fit is the one that drives the awkward, cross-cutting work through the agent, the way the product side drives the simple tickets through it.
QA signs off again before the merge. The engineer’s requested changes were, like everything else, written by the agent — which means the running task has changed since QA last saw it. So QA re-drives the preview against the same criteria before the PR moves on. A task reaches the tech lead carrying both marks: it works as intended, and it fits the system it lands in.
The tech lead owns the architecture, and the last word. The senior engineering seat checks the final PR — now carrying QA’s second sign-off — and squashes it to staging: one commit per ticket, which is the unit of revert, of blame, and of audit. The author of record is the agent and the approver is a human — but be honest about how thin that is on its own. GitHub’s require approval of the most recent reviewable push keys on who pushed, and if the agent pushes under its own identity then the person who prompted the change never pushed and is still eligible to approve it. The forge cannot see who drove a ticket, only who touched the branch. So the separation that actually holds is procedural, not mechanical: this seat, held by someone who did not prompt the work. Turn the setting on — it costs nothing and closes the hand-edit case — but do not mistake it for the guarantee. The same seat owns the architecture the engineer reviews against, and approves the code that goes out at release — the buck stops one place, and it is this one.
Staging is the integrated QA pass. Everything that has been squashed since the last release, tested together, against each ticket’s frozen criteria. Per-task isolation was the right call one row up, and it deliberately hid one thing: how tasks interact. This pass is where that bill is paid — before release, by a person who read the tickets, not the code.
Not every ticket has a screen. A dependency bump, a migration, a background job, an API-only change, a performance fix — QA cannot drive any of them and the product owner cannot write “how you would tell” for them. They need their own lane: the engineer or tech lead writes the ticket, the acceptance criterion is a check rather than a click (a green suite, a query plan, a benchmark, a restored backup), and the preview is exercised by a script instead of a person. Same rails, different evidence. A pipeline that only knows how to ship visible things quietly stops maintaining itself, and somebody owns production besides the release button — name that seat too.
Release is a tag, and a human act. At release time — not merge time — staging is tagged, the tag goes to main, and main deploys. main receives nothing but release tags, production runs nothing but main, and rolling back the code is checking out the previous tag. Rolling back the data is not — a migration that has already run is not undone by moving a tag, so anything touching schema needs its own reverse path, written and tried before the release that carries it. No script in the pipeline publishes on its own; the last box is a person deciding the release exists. One cost worth naming rather than discovering: a main that only ever receives release tags inverts what the rest of the ecosystem assumes — Dependabot, default code scanning, new pull requests and forks all treat main as trunk, and every one of them needs pointing at the branch you actually develop on.
Nothing is obliged to reach release. The forward path is the happy one, not the only one. Any gate can send a ticket back a step rather than all the way to the start — the tech lead returns it to architectural review, QA returns it to the preview — and any gate can make the case for killing it outright, which the product owner decides. Cancelling is cheap here in a way it usually is not: the branch is deleted, its preview stack is torn down with it, and nothing was ever merged, so there is no revert to write and nothing stranded on staging. A ticket that turns out to be wrong costs the work already done and not a penny more — which is exactly the property that makes it safe to open one on a hunch.
The company around it
Count what the diagram claims. The agent authors one hundred percent of the code. Four human seats gate it, and two of them — the product owner and QA — never read a line. The engineering team moved from the write path to the gates, which is the whole trade: reading every diff is linear in volume, and volume is the thing that just became free. A gate samples at leverage; an author scales at one.
Drawn as a company instead of a process, the same actors settle into a shallow tree — a team per domain, two sides inside the team, two layers underneath — and the ownership map is the org chart:
The split between the two sides is subject matter, not seniority. The product side owns business logic and ships it: simple, well-understood tickets and the feature scaffolding that has to match how the business actually works are driven by the product owner and QA straight through the agent, and out through the same gates as everything else — vibe coding, with rails. The engineering team owns product architecture, takes the complicated work, and is accountable for the quality of the whole. What differs between the sides is not who types — nobody does — but which tickets each can carry from intent to release.
The hierarchy is shallow and does little work — the structure is carried by ownership, not reporting lines. The scaling asymmetry is the point, and it is an asymmetry rather than a freeze: the agent layer and its ticket branches grow with the backlog immediately and without hiring — though not for free: every open ticket is a running stack plus a meter on the model, the meter is variable rather than fixed, and two runs at the same task can differ several-fold. The cost did not vanish, it moved from payroll to a line item that scales with the backlog — while the people layer grows when a gate becomes the bottleneck. Both do grow — a second QA, another reviewer, a second product owner running a parallel stream all buy real throughput. They just buy it at the gates instead of at the keyboard, which is the whole change: headcount stops setting how much code can be written and starts setting how much can be judged.
Sideways is the other axis, and it is the familiar one. The unit in the diagram is one team owning one domain; the next domain gets another copy of it — its own product side, its own gates, its own agents and branches. Which is worth stating plainly, because it is the least novel thing here: the company shape barely moves. Organisations already split into domain-aligned teams with a product owner, QA and engineers inside them, and that is exactly what this is. What changes is the inside of the team — who authors, and what a seat is for — not the org chart around it. The founder chip sits where it does on purpose: a founder can take any seat on the left side and often should. The seats they cannot absorb are on the right — every gate in the pipeline must be someone other than the author, and an agent approving an agent’s work is one party twice.
The reject rate is the gauge. A gate that always approves is theatre, and you cannot tell from the process document — it reads identically either way. Near zero, the gate has gone soft. Near one, the tickets have outrun the shared frame: people are asking for things the system cannot yet safely mean, and the fix is design, not discipline. A healthy pipeline sends a meaningful fraction of tasks back; watch that number the way you would watch error rates.
Two more things carry the scaling. Push the product toward data, because data is what non-engineers can own outright: every part of the system you can move from code into declared, validated content — workflows, pricing rules, forms, configuration — is a part the product side can change end to end, with a validator refusing what a reviewer would have had to catch. The trap is that this quietly routes behaviour around every gate in the diagram, so the data layer has to earn the same machinery the code has: versioned, previewed on a stack before it goes live, and reversible. Skip that and you have not removed a bottleneck, you have grown an untyped language with no tests and no rollback. And write the boundaries down: each seat gets a one-page role — what it may do, what it must escalate — signed and dated, because “use your judgment” is not a boundary anyone can act on, and the escalation list matters more than the permission list.
One consequence of the no-hand-edits rule deserves saying out loud, because it is the least obvious thing on this page. The rule is what makes provenance clean, and it is also what drives the human-authored share of the codebase toward zero — and in the US, material generated by a model is not copyrightable, with prompting alone not counting as authorship. Trade secret, contract and access control still protect you; copyright largely does not, which matters more than it sounds if the codebase is the asset someone is buying. Worth a lawyer and a deliberate answer rather than a discovery during diligence.
What limits the team is none of the things that used to. The first seat to saturate is QA, and it is not close. QA is one seat but three passes — the preview, the re-check after review changes land, and the integrated pass on staging — so every extra ticket costs it three times what it costs the engineer. Watch that seat before any other. The ceilings are the gates’ throughput, collisions between tickets touching the same surface — which the preview isolation defers and the staging pass catches — and domain judgment, the one input no model manufactures. The ceiling that is absent is the one every previous era was built around: the number of people who can code.