Requirements as code represents important product and engineering constraints in versioned, machine-validatable repository artifacts. For coding agents, this provides a stable source to retrieve before implementation and a basis for generating or running evidence after the change.
Why prose requirements disappear from agent work
A requirement in a ticket or planning document may guide the first implementation and vanish from later maintenance. Months afterwards, an agent sees the code but not the promise that shaped it. The requirement has become latent knowledge.
Moving the accepted constraint into a repository artifact does not eliminate product tools. It creates a durable engineering projection of the requirement at the boundary where code changes happen.
Code-like does not mean executable prose
The goal is not to force every sentence into a programming language. Keep the human-readable requirement, add validated identity and lifecycle, then declare evidence only where a test or policy can prove something meaningful.
A restoration promise, for example, can remain readable while relating to tests for recoverability and checks that prevent direct destructive paths.
Give agents the requirement before the solution
When a task touches an affected domain, the agent should retrieve the governing requirement and related decisions before planning. This changes the question from 'What implementation looks reasonable?' to 'What implementation satisfies the accepted constraint and its consequences?'
Maintain honest coverage
Not every requirement can be proved automatically. Track which records have objective evidence and which remain review obligations. Unclassified or judgement-based requirements should not disappear from reports, and the presence of some checks must not imply full coverage.