iToverDose/Software· 27 MAY 2026 · 12:05

Why AI should not make audit or permission decisions alone

Delegating critical decisions to AI may seem efficient, but bypassing structured review can lead to costly rework. Learn how to use AI as a sounding board—not a decision-maker—for audit-sensitive changes.

DEV Community4 min read0 Comments

When your AI assistant writes code faster than you can blink, it’s tempting to trust its output and move on. But what happens when that code meets a regulatory audit, a parent’s query, or a process workflow months later? The answer isn’t just a bug fix—it’s a week of digging through unstructured logs and patching gaps in traceability.

The hidden cost of instant decisions

Last Tuesday, around 3 p.m., Catherine phoned from the Maisons-Laffitte branch. Her usual greeting—"Hmm, it’s glitchy but quickly fixed"—was already in the air before she even identified the problem. This time, it wasn’t a glitch. We needed to replace a trainer mid-course, on an already signed enrollment with two signatures logged.

On the surface, the fix was trivial: a single UPDATE statement on the enrollment table, swapping the trainer’s name in the right field. My fingers hovered over the keyboard, the agent waited for my instruction, and I was about to type five lines I’d regret rewriting a week later.

The surface question wasn’t the real question. The real question was who is authorized to run that query, what status the enrollment must carry after the change, and what audit trail would let a parent check why their child’s signature had changed six months from now. None of these are SQL questions. They’re workflow, RBAC, and audit questions. Each, taken alone, seems obvious enough to decide on the spot. Together, they become the rework I’d face next week if I rushed the decision alone.

Three internal forces that push you toward bad decisions

Writing code solo with AI creates a false economy. Three inner voices whisper justifications that sound convincing but crumble under scrutiny.

  • Context pride convinces you that you saw the incident, you know the table, you see the fix, so you can skip asking aloud. It ignores that your context is precisely what blinds you to options you haven’t imagined.
  • Speed illusion measures progress by lines of code written, not by work still to be done. It tells you that framing three options takes thirty seconds you don’t have, while coding moves things forward. Yet speed only counts one curve—the writing curve—never the re-do curve.
  • Cognitive amortization frames delegated decisions as losses to your autonomy. You equate deciding with executing, assuming the agent proposing three options is making the call. In reality, you still decide. You just decide better when you hear three distinct paths first.

Each voice reinforces the others, and each lies. The only path forward is to invert the reflex: instead of coding the first idea, surface three structurally different options before touching the keyboard.

The three-option pattern: a safeguard for audit-sensitive changes

I changed my habit. Before any change touching audits, permissions, or workflows, I now ask the agent for three structurally distinct options. Not three variations of the same patch, but three fundamentally different approaches, each with explicit trade-offs across three axes: business effect, code surface touched, and operational cost.

Catherine’s call became a test case. I typed seven words to the agent: "Changement formateur sur inscription signée, trois options." Twenty-five seconds later, the response arrived via AskUserQuestion:

  • (a) Direct update: One-line UPDATE, notes in a free text field, weak audit trail. Risk surfaces a week later when a parent asks why the signature changed and no one remembers to check free-text notes.
  • (b) Close and reopen: Terminate the current enrollment with an explicit reason, create a new linked enrollment under the new trainer, store audit trail in status fields, strong compliance. Takes two extra lines of code but prevents weeks of digging.
  • (c) Flag and note: Add a side flag, manual note, medium audit trail. Cheap to implement but brittle under scrutiny.

I chose (b) in five seconds. Alone, I’d have picked (a). The trap in (a) opens only after the fact, when logs don’t match parent expectations and three hours vanish reconstructing history from signature logs.

This pattern applies only when the change leaves a business-side trace: audits, permissions, or workflow transitions. For low-stakes questions—"Which Postgres index on this column?" or "What TypeScript signature for this helper?"—expertise alone suffices. Asking dilutes clarity more than it adds insight.

The rule: narrow for a reason

Thirty seconds to hear three distinct options is thirty seconds you won’t spend reworking them next week. The rule isn’t measured in lines of code. It’s measured in lines not rewritten, in tickets avoided, and in audit trails that actually serve their purpose.

Future-proofing software isn’t about faster typing—it’s about clearer thinking before you type. Next time your AI assistant flashes a suggestion, pause. Ask for three options. Then decide.

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

AI summary

Yapay zekâ destekli kodlama sürecinde hız adına verilen acele kararlar, gelecekte saatlerce sürecek yeniden yapılanmalara yol açıyor. Kritik değişikliklerde 3 seçenek kuralını uygulamak, sistem güvenilirliğini artırıyor.

Comments

00
LEAVE A COMMENT
ID #G2U1IV

0 / 1200 CHARACTERS

Human check

6 + 8 = ?

Will appear after editor review

Moderation · Spam protection active

No approved comments yet. Be first.