The main risk is spending many iterations on code that looks finished but no longer solves the original product problem.
Research system
UPS: keep product requirements stable across long AI-assisted development
In long AI-assisted development, it is easy to end up with technically neat work that has drifted away from the original product need. UPS keeps requirements separate from the working conversation, gives Codex only the needed context, and validates the result through the repository, tests and reproducible startup.
Case at a glanceDefine the system purpose, the boundary between requirements and implementation, and the independent acceptance criteria.
A verified version passed 162 tests, Git checks and a clean archive run. The next step is to test the approach across several real projects.
01Requirements→02Task→03Implementation→04Verification
Done is not a model saying “finished”; it is a verifiable repository state that still matches the original requirements.
Technically clean code does not guarantee the right product
In long AI-assisted development, local tasks and tests can pass while implementation gradually drifts from the original goal. UPS separates requirements from the working conversation and accepts the result through a verifiable repository state. It is a research case about controlling product drift, not another orchestration framework.
Key finding03
Who owns product intent and who owns implementation
UPS keeps the product goal and constraints; Codex owns the implementation inside those boundaries.
UPS: what and why
Product need, requirements, boundaries, key engineering decisions and acceptance criteria.
Codex: how to implement it
Decomposition, change order, code and local repair.
How long development can drift from product intent
AI can solve the current task well, while the product is made of many local decisions. If the current context starts replacing the original requirements, the result can be technically correct but solve the wrong problem.
UPS keeps fixed product requirements and acceptance criteria separate from the current implementation step.
How the workflow works
First fix what the product should achieve, then give Codex a bounded task and check the result separately.
Need & boundaries
Capture the product problem, scope and acceptance criteria.
Options & engineering decisions
Evaluate implementation options and preserve the important decisions outside the current chat.
Requirements & relevant expertise
Pass only the requirements and knowledge needed for this task.
Bounded task for Codex
Give enough context to implement the change without letting the local task rewrite product intent.
Result & independent verification
Compare the Git changes with requirements, tests and a reproducible project state.
What already works reproducibly
The checks look at the actual project state, not only the model's completion report.
Repository state
Clean Git state and fsck tie the result to a specific repository state.
Automated checks
One verified version passed 162 tests.
Reproducibility
The project is tested both in the working repository and from a fresh archive.
Why the system stays compact
Extra task/session databases, background watchers and orchestration layers are not added unless the product actually needs them.
Context & measurement
- Context
- Personal research project
- Scale / period
- Validated foundation · 162 tests
Next step
Run the approach across several real projects and compare handoff quality, rework and result stability.
AI engineering
Facing a similar challenge?
Tell me where SEO is blocked by product, engineering or data.