Someone recently asked me why an AI-assisted refactor that produced working code in two days still sat untouched in review for seven more. The answer is straightforward: the generation step solved the smallest slice of the problem. The remaining work—confirming the change against real usage, routing the right approvals, and updating the surrounding systems—still moves at human speed.
This is the foundational misread that causes product teams to celebrate velocity they cannot actually ship. When the diff appears quickly, teams assume the bottleneck has moved upstream into creation. In practice the constraint simply relocates to verification and coordination.
Teresa Torres’s continuous discovery framework makes the distinction clear. Discovery is not a phase that ends when code is written; it is the ongoing work of checking whether the proposed change still matches user needs, risk tolerance, and operational reality. AI accelerates the proposal. It does nothing to shorten the loop that tests whether the proposal holds up.
Why the generated diff is only the first 20 percent of the work
The two-day refactor touched a payment reconciliation module used by volunteer coordinators who run monthly reporting for small churches. The model produced clean, idiomatic updates to the query logic and added the missing null checks. On the surface the task looked finished.
What the model could not do was run the change against the last six months of actual reconciliation exports those coordinators keep in shared drives. Those exports contain the edge cases—duplicate donor IDs, currency conversions entered as text—that never made it into the test suite. Someone still had to pull the files, replay them, and confirm nothing broke before the change could move forward.
Continuous discovery treats this verification as first-class product work, not cleanup. The team that shipped the change eventually spent three additional days constructing a one-off script to replay the real exports. That script became the permanent regression check the original refactor had omitted.
The coordination tax that appears once code moves faster than review
Once the diff existed, four people needed to sign off: the staff engineer who owned the billing service, the ministry operations lead who understood how coordinators actually used the reports, the volunteer who maintained the print templates, and the part-time contractor who handled month-end data hygiene. None of them worked on the same calendar.
The engineer reviewed the same afternoon. The operations lead asked for a walkthrough two days later because she was traveling to a regional training. The volunteer needed the change described in a short Loom because he only checked email on Tuesdays. The contractor flagged a downstream field mapping that would affect his monthly cleanup script. Each handoff added latency that no amount of generation speed could compress.
Torres would call this the discovery loop becoming visible. The faster the code arrives, the more obvious it becomes that the organization has no standing rhythm for these conversations. Teams that treat verification as an afterthought simply accumulate calendar debt.
How ministry product teams already handle this without formal methods
Ministry teams have long worked with volunteers whose availability is measured in hours per week rather than hours per day. They already route changes through a short, explicit checklist: does the update still produce the printed report the volunteer needs, does it preserve the export the bookkeeper downloads, and does the person who will run the next cycle know the change happened.
These checklists are continuous discovery in practice. They force the proposer to name the exact artifacts and people required before any code is considered ready. When an AI refactor lands, the same checklist simply gets applied to the new diff instead of being skipped because the code “looks done.”
The teams that absorbed the two-day refactor most cleanly already kept a one-page living document titled “What must still work after any change to reporting.” Updating that document became the first verification step rather than the last. The remaining sign-offs then moved in days instead of weeks because the criteria were already written down.
Your Turn: Apply This Today
- Pick one small refactor you have been considering for an internal tool and run it through an AI coding assistant this week; commit only the generation step and nothing else.
- Immediately after the diff appears, list every person and artifact that must be checked before the change can ship; write the list in the pull request description before requesting any review.
- Schedule the first verification conversation within 24 hours of opening the pull request, even if the reviewer has not yet looked at the code; treat the meeting as discovery, not approval theater.
- Document the exact steps you took to replay real data or usage against the change; turn those steps into a reusable check that lives alongside the test suite.
- Track the elapsed time between generation and final sign-off for this single change; note which steps consumed the majority of calendar days rather than active work hours.
- Share the timing breakdown with one other product person on your team so the next refactor starts with the verification path already mapped.
See also The Context Window That Only Closed When a Real Coordinator Sat Down and The Permission Gate That Kept the Agent From Running the Schedule.
I consult with ministry product leaders and faith-tech PMs on AI refactor verification, continuous discovery loops, and coordination patterns that keep small teams shipping. Let’s talk.