AI-Written Python: Why One Customer Can Become Two Groups

An independent shop asks an AI assistant to write a short Python script that totals orders by customer. The sample report looks tidy. Then a new export arrives in purchase order: customer A spent £12, customer B spent £8, and customer A came back to spend £5. The script prints two entries for A. When another line turns those results into a dictionary, the first entry for A disappears. The report now says A spent £5. There is no error message to tell the shop what happened.

This hypothetical failure starts with a reasonable looking choice: using a function called groupby to group records. The missing instruction is what kind of group you mean. Are you counting uninterrupted runs of records, or do you want a single total for each customer across the whole export? In a file already sorted by customer, those two jobs can look identical. In a file sorted by purchase time, they can produce very different reports.

Read the function’s rule before judging the output

The Python documentation for itertools.groupby explains that the function starts a new group when the key changes as it moves through its input. With a customer ID as the key, the sequence A, B, A gives three groups. The last A starts a new run even though the same ID appeared earlier. A group can be summed correctly and still be the wrong unit for the report.

In the shop example, summing each run produces A: £12, B: £8, A: £5. If you use those pairs to build a dictionary, the later value for A replaces the earlier one. That second step removes visible evidence that the first step produced two groups. A test that checks only whether every customer appears exactly once in the final dictionary would miss the problem. Check the amounts as well as the keys.

Choose a fix that fits the report

If the script needs complete groups of rows, sort the input by the same customer key you pass to groupby. In the example, A’s two orders then sit together and the group total is £17. Be explicit about what else the sort changes. If the page also shows orders in purchase order across all customers, keep the chronological view separate from the sorted input for the summary.

If you only need totals, a running total per key may be easier to read. Start an empty dictionary, add each amount to the value already recorded for that customer, and keep going until the export ends. It does not matter whether A’s second purchase follows the first or arrives after a hundred other orders. You still need to decide which field identifies a customer. Using a display name can merge two people who share it; using a stable ID gives you a clearer rule when the input supplies one.

Keep the original grouping if the task really is about runs. In a support timeline, for instance, you might want to see an issue pass from sales to support and back to sales. Collapsing both sales entries into one group would hide the handover you were trying to observe. The important choice is whether a return to the same key represents a continuation of one total or the beginning of a new episode.

There is also a timing question if the export arrives in chunks. Sorting each chunk and writing its subtotals straight to the final report still leaves open the possibility that a customer appears in several chunks. For a complete report, either combine the subtotals by customer before writing the final rows or arrange for the whole input to be ordered by customer. Add a test that puts A’s two purchases on opposite sides of a chunk boundary. That catches a mistake that a three row file processed in one batch cannot expose.

Test what the clean sample hides

Ask the assistant to show you a failing example before changing the code. Three rows are enough: A, B, A. Give the two A rows different amounts, and write down the correct result yourself. Then check another order of the same rows. A summary by customer should keep the same totals even if its display order changes. A report of consecutive runs should change when the same key moves away from its neighbour.

• Compare the sum of the report totals with the sum of the input amounts, after any intended exclusions. In the example, both should be £25 for a complete customer summary.
• Check at least one expected total by customer. A matching grand total can still hide amounts assigned to the wrong ID.
• Decide how to handle a missing customer ID before grouping. A shared blank label can make unrelated orders look as though they belong together.

Our article on empty and missing fields in CSV imports offers a related check: verify what the incoming data means before you act on it. In a grouped report there is another question to ask about the rows that do contain a valid key: what should happen when the same key returns later?

A useful brief for an AI coding assistant is to state that rule directly: ‘Produce one total per customer ID regardless of row order. Show a test where the first and last rows share a customer. Preserve the original order in the detailed export.’ That gives you a result you can check on a scrap of paper. It also makes the difference between a run and a customer explicit enough for the next person to maintain.

Source

• Python standard library documentation, itertools.groupby, consulted 6 November 2026.