Engineering leadership
How do I verify AI-generated PRs against product requirements?
Treat the pull request as a claim about product intent, not only as a code change. A reliable review proves which requirement authorized the change, whether the code satisfies its acceptance criteria, and whether the requirement still agrees with the product strategy above it.
Use a three-part verification record
Start with provenance. The pull request must identify the project or ticket that authorized the work. Then walk its parent chain to the persona, problem, goal, and strategy.
Next, convert acceptance criteria into observable checks. Tests prove runtime behavior, and static analysis can confirm required code contracts. Keep semantic judgment advisory.
Intent
Name the current requirement and the decisions above it. Do not accept a title or issue number as sufficient context.
Evidence
Map each acceptance criterion to a test, static check, or explicit reviewer decision.
Freshness
Confirm that no ancestor was abandoned, replaced, or changed after the implementation began.
What Helen’s Foundry adds
Helen’s Foundry keeps product intent as a linked graph instead of a folder of documents. Its GitHub check reads the pull request, its linked execution artifacts, and the full chain of product context above them.
Helen reports missing links and open findings on that chain, such as a stale premise or a contradiction. The reviewer then decides whether the change still serves current intent.
The review decision
A pull request is ready when its source requirement is current, its chain is coherent, and its acceptance criteria have complete evidence. A green test suite alone cannot prove those three facts.