Leveraging AI for Complex Decisions: Three Options, Explicit Trade-Offs

Michel Faure outlines a method for AI-assisted decision-making. By prompting for three distinct options with clear trade-off axes, founders can avoid costly re-work on changes affecting audit, permissions, or workflow.

Michel Faure, writing on dev.to, avoided three hours of re-work by asking an AI agent to generate three distinct options for a seemingly simple ERP update. His method addresses the hidden complexities of audit, permissions, and workflow that often lead to costly re-dos. This approach shifts decision-making from instinct to structured analysis, even for minor system changes, demonstrating a repeatable playbook for AI-assisted decision-making.

Unmasking Hidden Workflow Costs

Faure describes a common scenario: a quick UPDATE to replace a trainer in an ERP system. This "technically insulting of simplicity" fix, updating a single field, appeared to take ten seconds. However, the apparent simplicity masked deeper issues: who can perform the operation (RBAC), what status the modification leaves the enrollment in (workflow), and what trace remains for future audit (audit trail). Ignoring these, Faure notes, leads to re-work a week later.

He identifies three internal biases that push founders towards quick, solo decisions. "Pride of context" suggests immediate familiarity with the incident, table, and solution, bypassing deeper inquiry. "Speed" measures only code written, never code re-done, creating a false sense of progress. "Cognitive amortization" fosters a resistance to delegating decisions, mistaking execution for ultimate authority. These biases, Faure argues, collectively blind a founder to unconsidered options and conflate deciding with executing, ultimately leading to suboptimal outcomes.

AI-Generated Structurally Distinct Options

To counter these ingrained biases, Faure inverted his reflex. Before any modification touching audit, permission, or workflow, he now prompts an AI agent for three options. The critical distinction is that these must be structurally distinct, not merely cosmetic variations of the same approach. Each option must also explicitly detail its trade-offs across three named axes. This forces a broader consideration of impact beyond the immediate technical task.

Defining Three Trade-Off Axes

Faure specifies three axes for evaluating each AI-generated option: "effet métier" (business effect), "surface de code touchée" (code surface touched), and "coût opérationnel" (operational cost). These provide a comprehensive framework for comparing options beyond immediate technical implementation. By explicitly mapping each option to these axes, founders gain clarity on long-term implications, resource allocation, and potential downstream effects.

Case Study: Trainer Change Workflow

The specific example involved a customer service call about replacing a trainer on an already signed enrollment. Faure's prompt to the agent was concise: "changement formateur sur inscription signée, trois options" (trainer change on signed enrollment, three options). Within 25 seconds, the AI returned three options via AskUserQuestion: (a) Direct UPDATE, with traceability relegated to free-text notes, resulting in a weak audit trail. This was Faure's initial instinct, a quick code fix. (b) Close the current enrollment with an explicit reason, then create a new enrollment linked to the new trainer. Traceability is embedded in the status, ensuring a strong audit trail. (c) Implement an annex flag and a manual note, providing a medium level of audit.

Faure selected option (b) in five seconds. He notes that choosing option (a) would have led to three hours of re-work a week later. A parent inquiring about a signature change would have forced a manual reconstruction of history from logs, a process that option (b) proactively avoids by structuring the data for clear auditability. This demonstrates how a small upfront investment in structured decision-making prevents significant future operational costs.

WHAT WE'D CHANGE

The playbook offers a clear framework for complex decision-making, but its efficacy depends on several factors. The AI's ability to generate structurally distinct and valid options is paramount. This requires the AI to possess a deep understanding of the system's architecture, business rules, and potential impacts, which is not a given for all LLMs or contexts. Without this, the AI might hallucinate options or present variations that are not truly distinct, undermining the exercise. Founders must validate the AI's output against their domain knowledge.

Furthermore, the "narrow by choice" rule, applying the pattern only to system transitions involving audit, permission, or workflow, is crucial. Over-applying this method to genuinely simple changes would introduce unnecessary friction and cognitive overhead, negating the efficiency gains. Founders must establish clear criteria for when to invoke this multi-step process, potentially through automated checks or explicit team guidelines. The prompt engineering itself also matters; a vague request will yield vague options. The founder's skill in articulating the problem concisely yet comprehensively to the AI remains a critical input for relevant outputs.

LANDING

The core lesson from Faure's approach is that speed in software development is often mismeasured. True velocity comes not from the fastest initial code commit, but from minimizing future re-work and technical debt. By externalizing the option generation to an AI and explicitly defining trade-off axes, founders can elevate their decision-making process, ensuring that even minor changes are considered through a lens of long-term system integrity and operational cost.

Pull quote: “He notes that choosing option (a) would have led to three hours of re-work a week later.”