The most dangerous thing about AI-generated output isn’t that it’s wrong. It’s that it’s confidently, plausibly wrong — and it looks exactly like correct output.
A code agent that misunderstands an acceptance criterion doesn’t produce a syntax error. It produces working code that does the wrong thing. A requirements agent that skips edge cases doesn’t throw an exception. It produces AC that looks complete but has gaps.
You can catch these with human review. But human review is the thing teams under pressure skip first.
Author agents are our answer: automated reviewers that gate each phase structurally, before output moves forward.
What author agents do
After each phase in our pipeline — requirements, code, tests — a dedicated author agent reviews the output and rates it on a 1–5 scale.
The rating drives a decision:
| Rating | Meaning | Action |
|---|---|---|
| 5 | Excellent | Advances immediately |
| 4 | Meets bar | Advances immediately |
| 3 | Minor gaps (missing edge cases, no negative tests) | Refines — up to 2 retries |
| 2 | Significant gaps | Refines — up to 2 retries |
| 1 | Fundamental issue (no AC, ambiguous scope, wrong domain) | Escalates to human |
The key: a rating of 1 is not a retry. It’s a stop. Some problems can’t be fixed by trying harder — they require human clarification.
The three author agents
@author-requirements reviews AC quality before implementation begins. It checks that acceptance criteria are specific, testable, and complete. Vague language gets flagged. Missing negative test cases get surfaced. Auth and security requirements get their own checklist.
@author-code reviews implementation quality after the code agent finishes. It applies a structured lens — security, SOLID principles, pattern consistency, error handling — without attachment to the output. It didn’t write the code, so it doesn’t have a stake in it.
@author-tests reviews test coverage after the test agent finishes. It checks that the tests actually exercise the acceptance criteria. A test suite that passes but doesn’t verify the right things is a false confidence machine.
The clarity gate
Before any of this starts, there’s a pre-flight check. If the story has vague AC, undefined scope, or missing requirements, @story surfaces a warning and offers a handoff to @requirements for refinement.
You can proceed with documented assumptions — but you’re making that choice explicitly, with the gaps recorded. No accidental optimism.
Why this matters for quality engineers
The traditional quality engineering model is a phase at the end: dev finishes, QE picks up, finds problems, dev fixes them, cycle repeats. The feedback loop is slow and the fix cost is high.
Author agents move quality gates left — into every phase, not just testing. Requirements issues are caught before a line of code is written. Implementation issues are caught before tests are written. Test gaps are caught before the PR is opened.
This isn’t AI replacing QE. It’s AI enforcing the discipline that humans apply inconsistently under pressure. The quality engineer’s job shifts to designing the quality gates — what does a rating-1 scenario look like? what AC patterns indicate incomplete requirements? — rather than executing reviews manually on every PR.
The structural answer to “we ship under pressure and skip review” isn’t more process. It’s gates that can’t be skipped.
In the ADLC — The Missing Lifecycle for AI-Assisted Engineering, author agents are the Review phase made structural. The rating and routing they produce are the feedback signal that drives the Refine phase — what gets updated in the instruction files, what gets tightened in the rubric, what gets caught earlier next cycle.