Code is not complete merely because an agent says it is.

Context

Code generation answers how quickly an implementation fragment can appear. It does not answer whether the code meets a requirement, who checked it, or how a failure returned for correction.

Problem

One agent role easily mixes implementation with self-assessment. Decision history disappears into conversation, while “the tests passed” can remain a narrative without an external artifact.

My role

• workflow and specification-contract design;
• separation of implementation and review;
• quality gates and completion criteria;
• publication of the experiment as open source.

Architecture and method

The specification defines the result and test. An implementation role creates the change, a second role reviews compliance, and CI runs an independent gate. A correction returns to a concrete requirement instead of starting another unstructured conversation.

specification → implementation → independent review → CI → human decision

Every transition in the repository can be checked against a specific requirement, code change, test, CI log, and final verdict. The diagram describes the actual experimental workflow, not agent autonomy.

How quality was evaluated

The repository, change history, tests, and CI result are public artifacts. A reader can inspect not only the final code but how a requirement became a change and how that change was verified.

Outcome

The result is a clonable example of agent work with explicit role boundaries. Its value comes from visible process and artifacts, not from a claim of universal superiority.

What did not work

Adding more agents without an explicit contract did not improve control. It increased message volume and made it harder to identify the person or role accountable for acceptance.

Limitations

This is one experiment and pattern, not a quality guarantee for every repository. Time, cost, and impact depend on task type and test maturity.