A Ticket-to-Merge Clock Stops Before the Fix Reaches Users

# A Ticket-to-Merge Clock Stops Before the Fix Reaches Users Ticket-to-merge time measures how fast a fix reaches a merged pull request, not how fast users get it, so I ask where an agent speed claim's clock starts and stops. Brad Vincent, who makes the FooGallery plugins, reports in an X thread (2026-10-14) that a user's lazy-loading and paging bug was reproduced, fixed and opened as a pull request with tests by Hermes agents. The PR was merged 28 minutes after it went up, "just over 2 hours" after the report (¶5-¶6). The fix shipped in v3.3.7 a week later (¶7). Count what sits inside the two hours. A cron job polls the WordPress.org support feeds every 4 hours (¶12). A human merges, "usually me" (¶71), so 28 minutes of the total is a person reading and merging. Outside the clock: the release, which came a week later, and the customer reply. Merge, release and reply all stay with a human, "at least for now" (¶75, ¶86), and nothing posts to the support thread automatically "(YET!)" (¶26). The thread gives no per-stage times, so agent time, poll wait and human time can't be separated from the headline figure. The thread's own artifacts also show a gap it doesn't explain: the support-thread link names version 3.3.3, and the fix shipped in 3.3.7. The workflow deserves credit for specifics. The agent builds a throwaway local site with Cove and reproduces the failure in Chrome and Firefox, finding items stuck loading and a JavaScript EvalError while every thumbnail request returned fine (¶48-¶52). The thread states its limits: the test site "can still differ from the customer's real site" (¶46), and a Playground non-repro doesn't dismiss a bug (¶57-¶58). Two public artifacts, the PR and the support thread (¶73-¶74), let a reader check the timestamps. Where this breaks. This is a vendor describing its own products and its own public skills repo (¶80), ending with a request to share (¶89). It reports one ticket: no count of tickets handled, no failures, no median time. The share of the fix the agents wrote versus the author's edits before merge isn't stated, the model names (¶77-¶78) carry no links, and I haven't read the PR timestamps, so the 28 minutes and the two hours stay the author's account.  ## Why This Matters When a vendor or DevRel post claims agent speed, I'd ask for three things before repeating the number: the event that starts the clock, the event that stops it, and which stages in between were human. For our own docs work, an agent claim gets measured from ticket to published page, since a merged PR the reader can't see hasn't helped anyone. ## Links - [[3. Resources/Permanent Notes/Faster Implementation Raises the Value of Review and Release Controls]] — evidence-for: the thread keeps merge, release and customer reply with a human, and the merge step sits inside its own speed claim. - [[3. Resources/Permanent Notes/Trust Not Ticket Volume Is the Right AI-Support Metric]] — extends: time-to-merge is another throughput number; trust that the agent represents the vendor accurately is the test for the customer reply it drafts. - [[3. Resources/Permanent Notes/Verification Must Test the Claimed State Not Only the Latest Change]] — evidence-for: the thread's rule to check the rendered page and browser errors, because a 200 on every thumbnail hid a broken gallery. - [[3. Resources/Permanent Notes/Automation Is Only Safe Unattended Once Done Is Machine-Testable]] — constrains: the three human gates stay human because "done" at merge, release and reply isn't machine-testable. - [[3. Resources/MOCs/AI & the Future of Knowledge Work MOC]] — applies-in: a concrete agent workflow with its human gates named. - [[3. Resources/MOCs/Evidence & Claims Literacy MOC]] — applies-in: a vendor self-report with one case and no stage timings. ## Source - [[3. Resources/Readwise/Tweets/My Agents Took a WordPress Support Ticket to a Merged Fix in Just Over 2 Hours|My Agents Took a WordPress Support Ticket to a Merged Fix in Just Over 2 Hours]]