Does Defining “Done” Upfront Mean Fewer Revisions?

The AI-built packing-list app could add items, mark them as packed, and delete them. It opened with six example items and kept the list after a refresh. The evaluation criteria called for an empty starting list that reset on refresh—but neither expectation was in the initial request.

A small test using made-up data on September 27, 2026 compared one short-request run (A) with one brief-first run (B). It examined when expectations were shared, not productivity or time savings. Both runs used Korean requests and test inputs. This English edition reports the same experiment, not a separate English-language test.

What the sources say: what counts as done?

The Scrum Alliance glossary describes acceptance criteria as testable conditions for meeting user expectations. This article uses these as checks for one feature, stating an observable result: “Submitting only spaces shows an error message and leaves the list unchanged.”

The formal Definition of Done in the 2020 Scrum Guide establishes a shared understanding of work that meets the product’s quality measures. In this article, the title’s “done” refers to a checklist for one feature, not that formal concept. Neither source establishes that these practices make AI-assisted work faster.

Recorded observations: the same feature, different information

Each run started from an identical HTML skeleton and empty CSS and JavaScript files and produced a local browser app. Both runs were asked for a personal travel packing list with add, mark-as-packed, and delete actions and a comfortable layout. Appearance was not scored. B also received purpose, user, actions, screen states, exceptions, exclusions, eight checks, and instructions to report observations for each check. Both conditions allowed clarification questions, and A ran first. A separate AI operator agent (Claude Opus 5.5) evaluated the results and sent the change request, knowing the intended outcomes. A represents late disclosure of known expectations, not a typical beginner.

The record lists Codex CLI 0.153.4, the requested model gpt-6-astra, and medium reasoning effort. The actual responding model identifier was not retained, so whether both runs used the same model cannot be established. Development took place on macOS 27.0; the operator agent checked the pages separately in Chrome 153.0.8010.53 (headless, with a 1280×900 viewport). Both implementation agents failed to launch their own browser checks. B also retried with --no-sandbox, which disables the browser’s sandbox protection; that attempt failed too. B reported every screen check as 확인하지 못함 (“could not verify”). A reported passes in a simulated environment rather than a real browser. The table below comes from the operator’s browser checks, not the implementation agents’ reports. Requesting observations did not itself secure browser evidence.

The original test strings are preserved here: 물병 means “water bottle,” 양말 means “socks,” and 책 means “book.” The English glosses explain the inputs; they were not substituted during testing.

A contained code to trigger the browser’s own warning bubble, so it did have an error-handling mechanism. The automated check searched page text and could not detect this kind of warning. The saved screenshot could not establish whether a readable message appeared at that instant.

Both first deliveries matched the checks for trimming the extra spaces before and after 양말 , marking 물병 as packed and then unmarking it, and deleting one of two 양말 entries while leaving one. These details were never requested in A, so their match cannot be credited to the brief. The <b>책</b> check was also never requested in A. Submitting it displayed those characters literally without creating an HTML bold element. That last check is limited to this input, not a comprehensive security assessment.

A then received one message describing the expected and observed results for four items: the empty start, total count after adding, blank-input error display, and reset on refresh. The first two shared one cause: the six example items. Its next delivery started empty, displayed an error message on the page, and removed automatic saving. These changes followed the disclosure of previously unstated expectations. They do not show that adding items was broken or that saving a list was inherently wrong. Empty start and no saving were policy choices for this app; neither policy was tested for usefulness to travelers. In the retained checks after the checker adjustment, A’s second delivery and B’s first met all eight criteria. However, the retained checking code differs from the version locked in before the comparison. The operator reported keeping the criteria, order, and pass rules unchanged, but the before-and-after code evidence is incomplete.

The time record leaves out original authoring effort

Both requests were written beforehand. Their original authoring time is absent below, and the elapsed gap is neither the duration of the one correction exchange nor a saving.

A revision exchange here means one change-request message followed by the agent’s response, not each individual issue in that message.

Preparation consisted only of copying an existing request and registered as approximately zero minutes at the log’s one-second resolution. The time originally spent writing the requests and prepared answers to possible questions, setting up the shared environment, and checking the verification tools is unknown. Active operator effort was not measured separately either. These figures cannot be treated as total production time or used to calculate a savings percentage. Subscription resources were consumed, but actual additional charges were not independently verified.

Limits of the record

The verification record also has gaps. A’s first automated check misidentified page elements and was invalid. Its output was overwritten by a corrected check, leaving no copy of the invalid result. The operator also built a reference app beforehand to test the checking script, which departed from the plan. Isolation was incomplete: B saw A’s folder name and enumerated unrelated instruction-file paths. There is no recorded read of the other app’s source contents. Both runs ended after final verification before their 60-minute per-run limits, but full compliance with the procedure cannot be claimed. The separately retained experiment record preserves the detailed evidence and limitations.

My view: what I would put in the next request

A matched the four expectations after one message disclosed them; B received no change request. That cannot answer the title with a general “yes.” I suggest recording expectations alongside observations as a way to explain a change. The runs differed in several ways at once: information quantity, request length, disclosure timing, and the detail of checking instructions. The evaluator knew the intended outcomes and checked A first. Whether both used the same model is unconfirmed, and the time contribution of A’s extra filters, progress display, and illustration is unknown. With one run per condition, the results cannot establish the brief’s effect or a general reduction in revisions. Eight criteria are not eight independent experiments.

The following is a brief you can copy and fill in for one feature. Its effectiveness has not been tested, and the effort required for a beginner to write it was not tested. The examples reflect choices made for this practice app. This is an English adaptation of the Korean edition’s template, not an additional experimental prompt.

Feature/purpose: What should this feature help someone do?
User/device: Who will use it, and where?
Actions: What will they click or enter?
Screen states: What appears at first, after success, and after invalid input?
Exceptions: For example, what happens with blank input, duplicate names, and refresh?
Out of scope: For example, login, saving, and synchronization.
Acceptance criteria — input/action → expected result:
  Accepted input: Submit 물병 to an empty list → one item, not yet marked as packed;
    input field clears. (물병 means “water bottle.”)
  Rejected input: Submit three spaces → readable error; list unchanged.
Completion report: Give run instructions and actual observations for each check.
  Identify anything not verified; do not claim a pass from code inspection alone.

If the AI could not verify a check, open the page and try the input yourself. A change request can record input or action → expected → observed. A written condition can still be read differently, and the criteria themselves may miss important behavior. This experiment did not assess Korean character composition (IME), longer text, mobile use, keyboard behavior, accessibility, or maintenance, and passing its practice checks does not establish readiness for real use. When new requirements emerge, the criteria can change too.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.