Velocity, Quality, Security: Pick Three

Parallel coding agents quickly move the bottleneck from writing code to anything that requires two humans to talk. Reviews, handoffs, and judgment calls turn a parallel system back into a queue.

The answer is not to review less. It is to encode more engineering judgment into guardrails enforced by deterministic systems and independent LLMs. These can run at agent speed and, done well, raise the quality bar.

Six months ago, `/push` was a 123-line Claude Code skill that ran four commands: build, lint, test, push. Today it is 1,409 lines and roughly 19,000 words across 89 commits.

It grew one escaped bug at a time. Somewhere along the way, `/push` stopped being about Git. It became a system for proving the difference between "the code works" and "this is safe to merge."

Every change now passes through five non-negotiable layers. The coding agent can fix a failed gate. It cannot waive one.

!The five layers, as they appear when a branch clears them

1. Two reviewers, with different jobs

We started with one AI reviewer. It was useful. It also agreed with itself a lot.

Now Claude Code reviews the implementation for correctness, data loss, security, and weak tests. Codex challenges the approach, assumptions, and failure modes. Could the implementation work correctly and still be the wrong design?

The second reviewer is often wrong about our codebase. That is fine. Its job is not to approve the change. Its job is to disagree.

Every finding must be fixed, noted, or rejected with evidence. Two rubber stamps are not better than one. Two reviewers looking for different mistakes are.

2. Run the full CI, then fill the gaps

Every required build, lint, type, unit, and end-to-end check has to pass.

But existing CI is only the starting point. `/push` also asks whether the change arrived with the tests it should have. When coverage is missing, the agent adds it before moving on.

We learned why from an audit middleware change that arrived with 20 passing tests. Ten minutes against a real development server found three defects.

The tests were faithfully checking the author's assumptions. The assumptions were wrong.

3. Exercise the real application

After CI passes, `/push` runs the code.

For a UI change, it uses the browser. For an API, it calls the API. It verifies the happy path, then tries the cases most likely to expose a bad assumption: what should do nothing, what should be rejected, what happens when a dependency fails, and what happens the second time?

It then verifies the result independently. Do not trust the handler saying it wrote the row. Check the table.

AI makes the distinction more important because agents are very good at writing tests that validate their own mental model. Running the application forces that model to make contact with reality.

4. Attack security instead of reviewing it

Security used to be one item in a general review prompt. We got plenty of correctness findings and almost nothing about authorization.

Now it is a dedicated, blocking pass, and the instruction is not "review this for security." It is "attack this change."

Try to cross authorization boundaries. Manipulate identity and inputs. Look for a way around the intended guard. Do not report "no security impact" without explaining what you tried.

We also check the final diff again. Fixing tests and review findings changes the code, which means the version being pushed may no longer be the version that was reviewed.

5. Automate the last 5%

The final layer is less exciting, but it is what keeps parallel agents from becoming parallel interruptions.

`/push` rebases correctly, follows repository conventions, keeps the branch clean, prepares the PR, confirms what ran, reports anything skipped, and stops when it gets stuck instead of grinding forever.

Conflicts and dangerous Git operations go to a person immediately. Everything else should finish without creating another meeting, message, or review task.

The harness becomes institutional memory

Traditionally, much of a team's engineering judgment lives in experienced people's heads. That works when code production is slow. It works less well when ten agents can produce ten changes at once.

Now, when a bug gets through, we try to make the harness learn it too.

The bug happens once. We understand why. We encode the lesson into `/push`. Every future agent inherits it.

The file's 19,000 words are the fossil record of mistakes we do not want to make twice.

That is what these systems eventually become. They are not merely CI, and they are not really prompts. They are executable institutional memory.

AI makes code generation scale. The harness is how engineering judgment scales with it.

What it bought us

Two months ago, our whole engineering team was merging about 50 pull requests a week. Last week, four of us merged 179. Two engineers have spent much of this month between 60 and 80 merged pull requests per week individually.

PR count is imperfect, and we are a small startup. But the change within our own team is hard to miss.

The agents are not merely writing code faster. They are getting from working code to a mergeable branch without creating a proportional amount of human review work.

Humans still step in when the system is stuck or real judgment is required. They are no longer a mandatory checkpoint after every task.

That is the difference between making coding faster and making an engineering team faster.

Take ours

We stripped out the Tailor-specific pieces and are open-sourcing `/push` at tailor-hq/push-skill.

It is MIT licensed, has no dependencies, and runs on stock Node. A setup script reads your repository and generates a starter configuration for your commands, tests, review guidelines, and conventions.

AI made code cheap.

The fastest teams will be the ones that can raise confidence at the same speed.