Give the explanation a test it can fail.
The event list puts November 10 ahead of November 2. You paste a screenshot into an assistant, describe the order as wrong, and ask for a fix. It offers a convincing explanation about date parsing. A few seconds later, you have a patch touching the parser, the sorting function, and the component that renders the list.
You still do not know which change addresses the complaint.
A screenshot shows an outcome. It does not establish which value the program compared, whether the input was already misordered, or whether the display concealed a distinction in the underlying data. An assistant can turn that uncertainty into code remarkably quickly. The useful first request is smaller: produce the failure with an input you can inspect.
Consider a fictional event list with three records. One has the identifier “late,” the date 2026-11-10, and the display label “November 10.” The other two are “early-a” and “early-b,” both dated 2026-11-02 and both labeled “November 2.” The input arrives in that order: late, early-a, early-b. The desired output is early-a, early-b, late. For this example, events sharing a date should retain their incoming order.
Those details are the beginning of a bug packet. They make “wrong order” concrete and add a requirement that a hurried fix might miss. Sorting the two dates correctly is necessary. Preserving the order of the two same-day records is necessary too. Neither requirement needs a production database, an account, or a large fixture to become testable.
The original function in this example uses Python’s sorted function with each record’s label as its key. It compares the display strings. The local reproduction produced late, early-a, early-b, which fails the expected chronological order. That is an observed result from a synthetic test prepared for this article, not an account of a customer incident or a measurement of an assistant.
At this point, there are at least two plausible explanations for what a user sees. The view might simply preserve the incoming order, leaving the November 10 event first because it arrived first. Alternatively, it might actively sort the labels as text, which also places “November 10” before “November 2.” The first fixture produces the same visible result under both explanations. Reproducing the symptom has narrowed the problem, but it has not yet distinguished the causes.
The cheapest next test is to reverse the two different-date records. Supply early-a first and late second, then run the same function. A view that preserves input order would leave early-a first. A label sort would move late back to the front. The local test returned late, early-a. That result supports the label-sorting explanation for this function and rules out simple input preservation as its behavior.
This is a better use of an assistant than asking it to brainstorm every possible date bug. Give it the fixture, the expected order, the actual order, and the two hypotheses. Ask it to propose a test whose outcomes differ between those hypotheses before suggesting a change. The question is whether the next observation will eliminate an explanation. A longer list of explanations can leave you exactly where you started.
Here, the source code also shows the label key. Reading it provides direct evidence about the implementation; the reversed-input test demonstrates the consequence. In a real investigation, you may have access to both. You should use both. The test is especially useful when someone later changes the function or replaces it with a different implementation. It checks behavior without depending on the explanation remaining persuasive.
The correction follows the data contract. These fictional records contain a date-only field in year-month-day form, and that field is authoritative. The display label is for readers. The revised key parses the date field with Python’s date.fromisoformat method and sorts on the resulting date. Python’s date documentation describes that conversion. Nothing in this example requires changing how the labels are rendered.
The corrected function returned early-a, early-b, late. A separate equal-date test supplied early-b before early-a and received early-b before early-a. That second check matters because the intended tie behavior is preservation of input order, not alphabetical ordering by identifier. Python documents its sorts as stable: records with equal keys retain their relative order. The test makes our dependency on that behavior visible.
The small fixture now earns its place as a regression test. The original implementation fails the chronological expectation; the corrected implementation passes it. The reversed pair distinguishes the competing explanations. The equal-date pair checks the tie rule. A further check confirmed that this example leaves the input records unchanged. Each observation answers a specific question, rather than accumulating checks to make the patch look more thoroughly tested.
There is still an input boundary to decide. An impossible date, such as November 31, raises an error with this parser; the local test confirmed that behavior. It does not tell us whether the product should reject the record, flag it for correction, or place it somewhere else. Quietly adding a fallback would make that product decision inside a sorting patch. Keep it visible instead, and ask the responsible person to choose if malformed dates are part of the actual problem.
There is also a boundary around the reproduction itself. Date-only events are not timestamps. This fixture says nothing about converting time zones, crossing midnight, or reconciling server and browser clocks. If the original complaint involves any of those, this packet may be a clean demonstration of the wrong bug. A passing test can establish that the change satisfies the fixture while leaving the user’s problem untouched.
The developer therefore has one final job before accepting the fix: connect the reduced example back to the reported failure. Confirm that the real path compares the same field, receives the same kind of input, and promises the same tie behavior. If one of those assumptions fails, revise the reproduction. The assistant’s confidence does not close that gap.
Keep the finished packet with the patch: the three records, expected and actual identifiers, both hypotheses, the reversed-input result, the one-key correction, and the chronological and equal-date assertions. It is small enough for another engineer to run and specific enough to challenge. The next person does not have to reconstruct your reasoning from a screenshot and a confident paragraph.
The useful output of an AI-assisted debugging session is a failure another person can reproduce, followed by a change that makes that same test pass.
Use Python’s Sorting HOW TO to check the key and stability assumptions in your next sorting bug packet.
If this was useful, forward it to one engineer who needs less noise in their feed.