AI coding agents are very good at sounding finished.
A coding session often ends with a message such as:
"Implemented the requested feature. Added tests. Everything is working correctly."
That sounds reassuring.
It may even be true.
But the statement still came from the same system that performed the work.
That should be treated as a delivery report.
It should not automatically be treated as independent verification.
SOFTWARE TEAMS ALREADY UNDERSTAND THIS
Normal software development has always separated implementation from approval.
Developers write code.
Tests check known behavior.
Pull requests expose changes.
Reviewers inspect the implementation.
QA checks important workflows.
CI verifies builds.
Staging catches environment problems.
Deployment checks help confirm whether the release actually worked.
AI-generated code should not remove these distinctions.
If anything, it makes them more important.
THERE ARE MORE STATES THAN "DONE"
Imagine an AI agent finishes a coding task and creates a branch.
What does "done" actually mean?
It could mean the agent attempted the requested work.
It could mean files were changed.
It could mean some tests passed.
It could mean the agent believes the task was completed.
It could mean a human reviewed the result.
It could mean the branch was accepted.
It could mean the code was merged.
It could mean the change was deployed.
It could mean the feature was verified in production.
Those are different events.
Putting all of them under a single status called "Done" hides useful information.
DELIVERY IS A CLAIM
A better delivery message is:
"This is what changed. This is what was tested. This is the evidence. These are the remaining uncertainties."
That is a useful output.
It is also appropriately limited.
The agent may have misunderstood the original requirement.
The tests may not cover the important edge case.
The implementation may work technically while creating a poor user experience.
The development environment may differ from production.
The agent may simply be wrong.
A delivery report should help somebody else review the work.
It should not replace review.
ACCEPTANCE IS A DIFFERENT DECISION
The person or system delivering the work answers one question:
"What did we produce?"
The reviewer answers another:
"Is this acceptable?"
Those are not the same question.
Separating them reduces the risk of turning a confident completion message into automatic approval.
This is especially useful as teams start delegating more work to AI agents.
A task can be executed successfully and still fail review.
That is normal.
It means the workflow is doing its job.
DEFINE ACCEPTANCE BEFORE THE WORK STARTS
Review becomes much easier when the task contains clear acceptance criteria.
Suppose the task involves authentication.
Weak acceptance criteria would be:
"Make sure login still works."
Stronger criteria might specify that existing authentication tests must pass, unauthorized users must still be blocked, expired sessions must return the expected error, no credentials may appear in logs, and the staging flow must be tested manually.
Now the final review has something concrete to compare against.
The reviewer is not trying to guess whether the task feels complete.
They can inspect the evidence against a known standard.
THIS IS WHERE WORKFLOW TOOLS MATTER
Wagglet separates task delivery from task acceptance.
That distinction is important because the person or agent reporting the work does not automatically decide whether the work is good enough.
A task can be prepared, claimed, executed, delivered, reviewed, accepted, or sent back.
Those states preserve information.
They also make it easier to understand what actually happened.
"Delivered" means somebody produced a result.
"Accepted" means somebody with the appropriate responsibility reviewed that result and decided it met the requirement.
That is a much more useful distinction than a generic "Done."
HUMAN REVIEW SHOULD NOT BE CEREMONIAL
There is another common failure mode.
A company adds a human approval button and assumes that automatically creates safe AI oversight.
It does not.
A human clicking "Approve" without enough evidence is not meaningful review.
Good review requires context.
The reviewer needs to understand what the task was supposed to accomplish.
They need evidence showing what happened.
They need enough knowledge or authority to judge whether the result is acceptable.
Without those things, human review becomes a formality.
EVIDENCE SHOULD MATCH THE TASK
Different tasks need different evidence.
A UI task might need screenshots.
A performance task might need before-and-after measurements.
A bug fix might need a reproduction case and test results.
A database migration might need schema output, migration logs, and rollback confirmation.
A documentation task might need the changed files and link checks.
A security-sensitive task might require a qualified reviewer and additional automated checks.
There is no universal delivery package.
The evidence should match the risk and the nature of the task.
SOME REVIEW BELONGS TO MACHINES
Human review does not mean humans should manually check everything.
Machines are better at many deterministic checks.
Tests can verify expected behavior.
Linters can catch structural problems.
Type systems can catch invalid assumptions.
CI can verify builds.
Security scanners can identify known patterns.
Automated checks should handle the parts that are repeatable and objective.
Humans should focus on the parts that require judgment.
Does the workflow make sense?
Does the visual result match the intended design?
Did the implementation preserve the product behavior?
Is this an acceptable tradeoff?
Does the change introduce a risk that the automated tests do not understand?
That is where human review is most valuable.
RISK SHOULD DETERMINE PROCESS
None of this means every AI-generated change needs a complicated approval chain.
A typo in internal documentation does not need the same workflow as a payment authorization change.
Review should match risk.
Low-risk tasks can move quickly.
High-risk tasks should produce stronger evidence and involve more qualified reviewers.
The important part is that the workflow uses truthful states.
Attempted is not delivered.
Delivered is not accepted.
Accepted is not merged.
Merged is not deployed.
Deployed is not automatically successful.
As AI agents perform more implementation work, those distinctions will matter more, not less.
The best AI workflows will not be the ones with the most approval buttons.
They will be the ones where every status has a precise meaning, every important decision has an owner, and an agent cannot declare its own work correct simply because it finished generating code.
Top comments (0)