4 min read
A fictional eight-person product team accepted a neat agent patch that missed one tenancy rule. The correction took 20 minutes. Recovering the requirement, reproducing the leak, checking adjacent queries, rerunning tests, briefing the reviewer, and updating the runbook consumed the rest of the day. The patch was cheap to produce and costly to trust. This is an explicitly fictional composite, used to expose a repeatable engineering decision without inventing a customer result.
Almost right AI code creates a lifecycle cost that starts after generation. Price discovery, reproduction, context recovery, correction, retesting, rereview, and documentation as one verification workload. The model is not a universal benchmark. It is a practical way to stop treating a quick patch as a completed feature.
Generation time is the smallest visible number
The easiest number to capture is how long the agent ran. It is also the least useful on its own. A seven-minute edit can create hours of downstream work when the change is plausible enough to pass a shallow scan. The cost sits across several roles, so no single time sheet shows it.
Stack Overflow Developer Survey 2025 helps bound this point. The results are self-reported perceptions, not causal production telemetry.
| Lens | What to inspect |
|---|---|
| 1 | Agent run: 7 minutes |
| 2 | Correction: 20 minutes |
| 3 | Context and reproduction: 95 minutes |
| 4 | Retest, rereview, docs: 150 minutes |
The numbers and labels above are a diagnostic, not benchmark data. Replace them with repository evidence before using the model in a staffing or investment decision.
Seven cost buckets expose the real workload
Build the estimate around seven buckets: discover the mismatch, reproduce it, recover the intended rule, correct the implementation, retest the behavior, rereview the change, and sync affected documentation. Record elapsed time and scarce-role time separately. Thirty minutes from a security reviewer is not interchangeable with thirty minutes of unattended model execution.
The sequence matters because later evidence depends on earlier intent. Skipping one step transfers uncertainty to a reviewer who has less time and often less context.
Fluent output can hide missing behavior
Clear prose and tidy code increase cognitive fluency. That can make a change feel easier to accept before the evidence is checked. The 2025 survey language around almost-right answers matters because the defect is often close enough to require careful comparison with intent, not obvious enough to reject at first glance.
Lee and See on trust in automation adds a second boundary. The paper supplies general human-factors guidance, not coding-specific prevalence.
:::mistake **Mistake:** Counting only agent runtime as delivery cost. **Fix:** Count every human and machine step needed to reach an accountable decision. :::The correction is deliberately procedural. A workflow can be inspected, rehearsed, and improved. A warning without an owner or artifact rarely survives the next busy sprint.
Use a verification budget before work starts
Set a verification budget during planning. A copy change may need one focused check. A billing rule may need a product owner, a domain reviewer, a migration test, and rollback evidence. If the budget is larger than the expected feature value, reduce scope or change the approach before code appears.
paqad-ai v1.67.0 was the current public release when this article was verified on July 21, 2026. Its public repository describes local workflows, risk routing, specialist roles, deterministic checks, documentation sync, and audit records. Those are product mechanisms, not independent proof that a team will achieve a specific outcome.
Use the broader AI workflow audit guide to map the operating system, compare the evidence bar with production-ready AI code, and use the consultant selection guide when outside ownership is being considered.
The decision rule for this article is: If verification work exceeds the expected value of the change, reduce scope or change the delivery approach before coding.
Frequently Asked Questions
Is almost-right code always AI slop?
No. A reasonable draft can still miss one business rule. AI slop describes low-quality mass output, not every change that needs verification. Judge the output, the evidence, and the workflow instead of insulting the person or tool.
How should teams measure the cost?
Track elapsed time and role time across the seven buckets for a small sample of changes. Keep the numbers local. The purpose is to compare feature classes and find repeatable bottlenecks, not publish a universal percentage.
Can better prompts remove the cost?
Better context can reduce avoidable mistakes, but it cannot remove review responsibility. Product intent, security judgment, and release authority remain team decisions even when the first patch improves.
What next?
If this failure pattern exists in your repository, install paqad-ai and test the decision tool above on one real feature. Keep the evidence local, inspect provider permissions, and retain human authority for the final risk decision.
