AI coding agents are getting good at producing code that compiles, passes tests and looks convincing in a pull request.
That is useful. It is not enough.
A product team does not ship “a green test suite”. It ships a specific outcome for a customer who pays. That outcome started as a PRD, became user stories, acceptance criteria, security constraints and product decisions. The hard part is making sure those things still mean the same thing after an agent has touched the code fifty times.
An agent starts with a clear request.
Then it encounters an awkward dependency, a failing test or a missing detail. To keep moving, it changes an implementation choice. Later it adapts a test. Later still it narrows the behaviour until the test passes.
Nothing necessarily looks alarming in a diff. Every local step can seem reasonable. But the product may no longer do what was requested.
That is specification drift.
The agent did not need to be malicious or “hallucinate” for this to happen. It only needed permission to optimise for the evidence nearest to it: the files, tests and commands currently in context.
For a throwaway prototype, that may be acceptable. For a customer-facing product, it is expensive. Tests tell us something important: a defined check passed.
They do not automatically tell us that the original user story was delivered, that security constraints remain intact or that an agent did not quietly reinterpret the requirement to make the check easier.
I find it useful to separate two questions:
The first question is about tool calls, diffs, builds and tests.
The second is about traceability. Which PRD requirement does this change serve? Which acceptance criteria were verified? What constraints must remain true? What changed when reality forced a trade-off?
Without that link, human reviewers spend their time reconstructing intent from code after the fact. That is where a large part of the cost goes.
People often describe AI coding as a generation problem.
In practice, the slow part is validation.
An agent can produce a huge amount of code quickly. Someone still has to decide whether the code matches the product, whether a test is testing the right thing, whether an exception was justified and whether the implementation introduced a security or usability regression.
If those decisions only exist in a chat window or in somebody’s head, they disappear as soon as the next context window begins. Then the team repeats the same work: reading, guessing, asking, checking and repairing.
A reliable AI software workflow should preserve more than code.
For every meaningful change, the team should be able to follow a short chain: That does not mean turning development into bureaucracy. It means keeping the product contract visible while agents operate.
The goal is not to stop agents from making decisions. It is to make those decisions inspectable, reversible and accountable to the original intent.
This is the problem behind ** PAELLADOC**.
The aim is to turn specifications, PRDs and user stories into a controlled product-building workflow where agents can work quickly without quietly rewriting the brief. Code, decisions, security constraints and verification should remain connected all the way to a deliverable a real client can use.
The useful standard is not “the agent finished”.
It is “the product we promised is demonstrably the product we built”.
Feedback is very welcome, especially from teams using coding agents on real client work.