A 4-gate workflow: reduce uncertainty before coding with agents

The cost of discovering an assumption late

Agents can produce changes across several layers quickly. If a wrong assumption lives in the problem definition, implementing it first in the database, services and UI multiplies the cost of fixing it. The upfront work aims to make the decisions with the largest blast radius visible before a lot of code is generated.

The four gates proposed in the source material are a planning pattern, not a formal standard. They can be adapted to the size and risk of the task; a trivial change does not need the same ceremony as a change that affects data, permissions or deployments.

The four decision gates

Each checkpoint produces an answer that can be reviewed. If a key decision is still open, the next step must reduce that uncertainty rather than hide it under more implementation.

1. Product: who has the problem, what outcome they want and how success will be recognized.
2. Architecture: which systems, interfaces, data, permissions and boundaries are affected.
3. Program design: which modules, contracts, files and tests make up the change.
4. Vertical slices: the minimal path through UI, logic and data that tests the hypothesis.

Separate research from solution: a QRDSPI sequence

The NotebookLM document calls a sequence “QRSPI”, although it lists six phases. To avoid hiding that discrepancy, the six initials are written here as QRDSPI: Questions, Research, Design, Structure, Plan and Implement. It is an editorial label to explain the article’s flow, not a certified methodology or a universal framework.

First, neutral questions are asked about the code and the problem; then the repository is researched without presupposing the solution. With that evidence, behavior is designed, the structure is defined, tests and slices are planned and, finally, the work is implemented in reviewable parts.

1. Questions: turn the ticket into verifiable questions.
2. Research: look for answers and constraints in the existing system.
3. Design: agree on experience, behavior and acceptance criteria.
4. Structure: define boundaries, contracts and component responsibilities.
5. Plan: order tests and small vertical slices.
6. Implement: build one slice, validate it and move on to the next.

Keep the gates proportional to risk

Use lighter checkpoints for reversible changes and widen the review when a task touches sensitive data, payments, access, migrations or production. A useful plan records pending decisions and exit criteria; it does not try to guess every detail before learning something from the first slice.

Approval belongs to the people accountable for the product and the system. The agent can prepare alternatives, tests and documentation, but it does not turn its own proposals into approved decisions.