Why your AI shouldn't decide alone: the 3-options pattern

Tuesday afternoon, May 16th. Catherine calls from the Maisons-Laffitte branch. The line opens with her usual phrasing, "hum it bugs but it's quickly fixed," slipped into the receiver before she even names the problem. This time it isn't a bug. A trainer is being replaced mid-year on a course already signed, already attended twice.

The apparent question looks insultingly simple. An UPDATE on the inscriptions table, the new trainer's name in the right column, ten seconds. My hand is on the keyboard, the agent waits for instructions, and I am about to write five lines I'd re-do a week later.

Because the apparent question is not the real question. The real question is who may run that operation in our ERP, what status the modification must leave the inscription in, what trace we keep so that someone, six months from now, can answer a parent asking why their child's signature changed. None of these three questions comes out of SQL expertise. They come out of workflow, RBAC, audit. Each one, taken alone, seems so obvious that you decide on the spot. Stacked, they produce the re-do that waits for me next week if I decide alone now.

Three reasons I decide, all three lie

Coding solo with an AI produces an apparent economy that practice has taught me to read backwards. Three internal forces push me to decide before formulating.

The pride of context whispers that I saw the incident, I know the table, I see the fix, and it relieves me from saying the question out loud. Speed measures the code written and never the code re-done, persuading me that formulating three options burns thirty wasted seconds while coding moves forward. Cognitive amortisation, the nagging sense that each decision delegated to the agent erodes my craft autonomy, pushes me to claim the call for the call's sake.

All three reinforce each other, all three lie. Pride of context ignores that my context is precisely what blinds me to the options I haven't considered. Speed counts only the writing curve, never the re-do curve. Cognitive amortisation confuses deciding with executing: the agent that hands me three options decides nothing. I still decide. I decide better.

The pattern, three structurally distinct options

I inverted the reflex. Before any change touching an audit, a permission, or a workflow, I ask the agent for three options. Not three flavours of the same call. Three options structurally distinct, each with an explicit trade-off on three named axes: business effect, code surface, operational cost.

Catherine, Tuesday. Seven words to the agent: "trainer change on signed inscription, three options." Twenty-five seconds later, three options come back through AskUserQuestion. (a) direct UPDATE, traceability in free notes, weak audit. (b) closure of the current inscription with explicit motive, creation of a new one linked to the new trainer, traceability in status, strong audit. (c) annex flag plus manual note, medium audit.

I picked (b) in five seconds. Solo on instinct, I'd have picked (a). The trap of (a) opens a week later when a parent asks why the signature on their child's record changed. I dig for the trace in free notes, nobody thinks to grep a free-text field, and three hours go into reconstructing the history from signature logs.

The rule, narrow on purpose

The pattern applies only when the question touches a system transition leaving a business-side trace: audit, permission, workflow. If the question is "which Postgres index on this column" or "which TypeScript signature for this helper", expertise decides directly. Asking dilutes more than it sharpens.

Thirty seconds to hear three structurally distinct options buys you the three hours of re-do you won't pay next week. The rule is not measured in lines written. It is measured in lines un-rewritten.

Skill source: ask-3-options-before-code/SKILL.md in github.com/michelfaure/doctrine-counterpart (R13).