Is a multi-stage agent pipeline for reverse-engineering user stories from a codebase over-engineered?

Codex Codex CLI
, , ,
1

I am looking for honest architectural and product advice on a Python CLI project
that uses Codex CLI to reverse-engineer business user stories from an existing
application repository.

The intended output is deliberately simple:

Epic
→ User Story
→ Acceptance Criteria

The system currently works as follows:

  1. Deterministic framework-aware repository discovery.
  2. Bounded extraction of routes, views, forms, fields, validations, controllers,
    state changes and related evidence.
  3. Multiple Codex tasks reconstruct actors, capabilities, business rules,
    permissions and user flows.
  4. A Codex planning task organizes the reconstructed capabilities into epics and
    stories.
  5. Each story is authored in a separate bounded Codex call.
  6. A final Codex editor standardizes the epic.
  7. Deterministic validators check structure, evidence coverage, unsupported claims,
    technical-language leakage and checkpoint integrity.

For a bounded Care Request Management canary, the pipeline required:

  • 28 Phase 3 reconstruction calls;
  • 1 Phase 4 planning call;
  • 12 separate story-authoring calls;
  • repeated final editor attempts;
  • several hours of execution;
  • substantial token usage and manual intervention.

The final result contained:

  • 1 epic;
  • 12 partial user stories;
  • 86 explicit [NEEDS REVIEW: …] acceptance criteria;
  • full provenance and evidence traceability.

An implementation defect initially produced a 227 MB Phase 4 input because of a
duplicated denormalized relationship graph. After fixing that, the bounded planning
package was approximately 790 KB.

Although the final output is traceable and conservative, I am concerned that the
pipeline is more expensive and complicated than the original task. A developer or
business analyst might obtain a comparable draft faster by manually selecting the
relevant repository evidence and making one or a few focused model calls.

I am now considering three options:

A. Continue developing the autonomous multi-stage pipeline.
B. Retain deterministic repository evidence extraction, but replace most AI stages
with one focused drafting call followed by human review.
C. Stop the project because code alone does not contain enough business intent to
justify the cost and complexity.

Questions for developers who have built similar systems:

  1. Does this architecture appear fundamentally over-engineered for the use case?
  2. Which stages would you remove or combine?
  3. Would you keep deterministic evidence extraction but use a much simpler
    human-guided generation workflow?
  4. What metrics would you use to determine whether this is economically worthwhile?
  5. How would you benchmark it against a developer or analyst using Codex directly?
  6. Are 86 review gaps a useful indication of responsible uncertainty, or evidence
    that repository-only requirements reconstruction is not useful enough?

I am not looking for help with one specific prompt. I am looking for candid advice
about the product premise, architecture, cost, latency and appropriate level of
human involvement.

I cannot share the private repository, but I can provide anonymized architecture,
timings, task counts, validation design and sample output structure.