AI-Written Python: Decide Which Side Owns the Threshold

Imagine you run a studio that offers collection slots for finished orders. A request submitted exactly 48 hours before collection belongs in the standard preparation band, according to the rule you agreed with the team. An AI assistant writes the script that assigns bands from the number of hours remaining. The examples in the chat look right. Then a customer submits a request at precisely 48 hours and the script sends it to the review queue. A one-character difference in a comparison can turn a clear operating rule into extra work.

This kind of error is hard to spot in a long list of ordinary cases. A value well inside a band will often land in the same place whichever side owns the boundary. The only way to tell which rule the code implements is to look directly at the cut-off and check what happens on both sides. Python’s bisect functions make a useful example because they differ precisely in how they treat equality.

Write the rule without mentioning Python

Suppose the studio has three internal bands. Requests with fewer than 24 hours go to urgent review. Requests from 24 hours up to, but excluding, 48 hours go to priority preparation. Requests with 48 hours or more go to standard preparation. These are fictional operating rules, but the wording matters. The word “from” tells you where 24 belongs; “or more” does the same for 48. A label such as “24–48 hours” leaves both decisions open.

Write down one example from the point of view of the person who will do the work. If a request has exactly 48 hours left, should anyone open it to decide what to do? If the answer is no, put that case in the brief and give it an expected result. The assistant can then propose code against something more specific than an attractive set of labels.

Read the insertion point as a band number

The Python 3.14 documentation for bisect describes two ways to locate an insertion point in sorted data. bisect_left places an exact match before existing equal values. bisect_right places it after them. Neither call inserts anything. Both give you a position that you can use to look up the corresponding band.

For the studio, use the sorted thresholds [24, 48] and the labels ["urgent review", "priority preparation", "standard preparation"] in that order. The position returned by bisect_right([24, 48], 48) is 2, which selects the third label because Python starts counting positions from zero. bisect_left([24, 48], 48) returns 1 and selects the second label. With 47 hours both functions give you position 1. The dispute only becomes visible when the number meets the boundary.

The right-hand function fits this studio because each listed threshold begins a new band. If the written rule instead says “up to and including 48 hours”, the lower band owns 48 and the left-hand approach may fit. With only two thresholds, plain comparisons might be easier for the next person to read. The point of understanding bisection is to recognise the choice when generated code makes it for you.

If different bands use different rules for equality, a single bisection call may hide the distinction. Imagine the urgent band includes exactly 24 hours, and the standard band begins at exactly 48. Each rule is clear on its own, but the thresholds do not both behave as starting points or both behave as end points. Explicit comparisons make that policy easier to read and review.

Test the numbers your workflow really uses

Give the assistant a tiny decision table before asking it to update the script. For whole hours, test 23, 24, 25, 47, 48 and 49, and say what each result should be. If the script works with elapsed minutes, the most useful neighbouring examples are 47 hours 59 minutes and 48 hours 1 minute. Compare in a consistent unit. If a display rounds 47 hours 59 minutes to 48 hours, decide whether the label describes the display or the actual time remaining.

• Check what happens without a usable measurement. A missing collection time or a collection that has already started may need a separate outcome before any band lookup.
• Check the thresholds and labels together. A lookup over two thresholds has three possible positions. Reordering the thresholds without checking which band each position names can make a technically correct lookup produce the wrong action.
• Make the exact cut-off cases part of any future change. If a colleague moves the boundary, update the tests and the plain-language rule together.

For a very small workflow, it can help to run a handful of fictional examples all the way through the output. A function may return the intended band while a later step sends that band to the wrong place. Inspect the final label or queue assignment, especially if the AI also drafted the code that sends the result onwards. Our guide to deciding which columns leave an AI-written CSV export makes a related point: an internal result and the record another person sees are separate things to check.

Keep the operating decision visible

Ask the assistant to explain the equality rule beside the code in ordinary language. Someone who manages collections should be able to tell whether the explanation matches the workflow without having to follow the search algorithm. If the code and the explanation disagree, use the expected outcomes from the brief as the reference and correct the implementation. You can often review a whole set of bands by asking one question at each boundary: what happens to the person whose record lands exactly here?

Source

• Python 3.14 documentation: bisect, array bisection algorithm.