Ticket to UAT

This is the decision I get argued with about most, so it goes first. It is deliberately not test-first.

The pipeline implements the change. A developer then verifies the new behavior is actually correct. Only then are tests generated, against that verified behavior.

The reasoning: a model writing tests before the implementation is guessing at intent. It will produce tests that pass, that look thorough, and that encode the wrong requirement. Now the wrong requirement is locked in and defended by a green suite. Test-first works because a human holds the intent while writing the test. That property does not transfer to an agent holding only the ticket text.

The exception is characterizing existing behavior, where writing the test first is exactly right, because the intent genuinely is “whatever it does today.”

Human verification sits between implementation and test generation. That position is the whole design, and it is the first thing I would defend in a review.

Chose

Implement → a human verifies → generate tests against verified behavior.

Rejected

Test-first. It is the received best practice, and here it is the wrong one.

The cost

You give up the design pressure TDD puts on an interface. What you buy is tests that assert the thing that was actually wanted.

An agent opening a file to fix one thing will find three others. Left alone, the default outcome is a pull request that began as a one-line fix and arrives as forty files, which is unreviewable and therefore gets rubber-stamped.

So the pipeline files new tickets for anything outside the original scope and leaves the branch alone. Same reasoning behind one pull request per testing branch rather than one large one: a reviewer should be able to hold the whole change in their head.

Scope discipline is the thing careful senior engineers do by hand and almost nobody encodes in tooling. Encoding it is what made this safe to hand to five other people.

Chose

File a ticket, keep the diff small, one pull request per testing branch.

Rejected

“Fix it while you're in there.”

The cost

Real problems wait in a backlog instead of being fixed while the file was already open. Some of them will not get picked up.

We run several testing environments, and moving a change through them is exactly the repetitive work the pipeline exists to remove. So it merges into them directly from the command line, the way a developer would by hand, just every time, and without forgetting one.

Master is different. Before anything moves there, guardrails check that every test passes, submodules are up to date, and the change has already been merged into the testing environments. UAT approval is a business decision about whether this is the change that was wanted, and nobody in the loop can make it except the person who asked for it. After that approval, a person, not the pipeline, moves it to master.

Underneath all of it is the belief the pipeline is built on: AI-written code should be surrounded by tests that check for explicit behavior. Speed without that just moves the defects downstream.

Chose

Merge into the testing environments from the command line; gate master behind UAT approval, guardrails and a person.

Rejected

Stopping at a pull request and hand-merging every environment, or letting a green suite promote straight to master.

The cost

More guardrails to maintain, and throughput is capped by how fast UAT comes back. The pipeline can finish quickly and the ticket still waits on UAT. That is the correct cap.