0Pricing
Claude Architect · Leçon

Décisions pilotées par le modèle ou codées en dur

Laissez le modèle décider et réservez le code aux garanties.

Décisions pilotées par le modèle ou codées en dur est une leçon Claude Architect gratuite sur CoddyKit. Ceci est la leçon 2 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Claude Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Claude Architect comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Two Ways to Decide

Every agent you build has to make decisions. Who makes them is the design choice.

There are two options:

  • Model-driven: Claude looks at the situation and chooses the next step.
  • Hard-coded: your code forces the step, no matter what.

The rule for the exam: let the model decide, and reserve hard code for guarantees you cannot afford to get wrong.

Why the Model Should Drive

Real tasks are open-ended. The order of steps is not known in advance.

A customer message might need one lookup, or three. A research task might branch in ways you cannot predict. Claude reads the live context every turn and adapts.

If you hard-code the path, you freeze the agent into one rigid script. It breaks the moment reality differs from your plan. So the default is: give Claude tools and let it choose.

The Agentic Loop

Here is the model-driven loop. You send the full message history every turn (the model keeps no state). Then you inspect stop_reason:

  • tool_use → run the tool, append the result, loop again.
  • end_turn → the model is done. Stop.

The model decides what to do; your code just executes and loops.

while True:
    resp = client.messages.create(
        model="claude-opus-4-8",
        max_tokens=16000,
        tools=tools,
        messages=messages,  # FULL history every turn
    )
    messages.append({"role": "assistant", "content": resp.content})

    if resp.stop_reason == "end_turn":
        break
    if resp.stop_reason == "tool_use":
        results = run_tools(resp.content)
        messages.append({"role": "user", "content": results})

Stop on the Signal, Not the Words

How do you know the agent is finished? Terminate on stop_reason — never by scanning the text for words like "done" or "finished".

Parsing text for completion signals is a classic anti-pattern. The model might say "I'm done thinking" mid-task, or never say "done" at all. The structured stop_reason is the real, reliable signal.

# WRONG — parsing text for a completion word
if "done" in resp.content[0].text.lower():
    break

# RIGHT — terminate on the structured stop signal
if resp.stop_reason == "end_turn":
    break

Iteration Caps Are a Safety Net

You may add a maximum number of loop iterations. That is fine — but understand its role.

An iteration cap is a safety net that stops a runaway loop. It is never the primary stop mechanism. The primary stop is always stop_reason == "end_turn".

If your agent normally finishes only by hitting the cap, the decision logic is broken — you are hard-coding what should be model-driven.

MAX_TURNS = 20  # safety net only

for turn in range(MAX_TURNS):
    resp = client.messages.create(
        model="claude-opus-4-8", max_tokens=16000,
        tools=tools, messages=messages,
    )
    messages.append({"role": "assistant", "content": resp.content})
    if resp.stop_reason == "end_turn":
        break  # the REAL exit
    messages.append({"role": "user", "content": run_tools(resp.content)})

When Code Must Guarantee

Now the other half of the rule. Some outcomes are too important to leave to a probabilistic model.

A prompt is roughly 90% reliable — it usually follows instructions, but not always. For rules with financial, legal, or safety consequences, "usually" is not good enough.

For those, you reserve hard code, which is 100% deterministic. This is the one place where you take the decision away from the model.

Hooks Enforce the Hard Limits

The deterministic tool for this is a hook. A hook intercepts an action and can block it before it ever happens — with 100% certainty.

Classic example: "never refund more than $500." You do not write that as a prompt instruction. You write it as an outgoing-call hook that blocks any refund over the limit, every single time.

Hooks for guarantees, prompts for judgment.

# Deterministic policy hook — runs before the refund tool executes
def before_process_refund(tool_input):
    if tool_input["amount"] > 500:
        return {
            "block": True,
            "reason": "Refunds over $500 require human approval.",
        }
    return {"block": False}

Programmatic Preconditions

The same idea applies to preconditions — things that must be true before an action runs.

Example: never process a refund until the customer's identity is verified. Prompt guidance ("please verify identity first") is only ~90% reliable. A programmatic precondition — block process_refund until get_customer returns a verified ID — is a deterministic guarantee.

Code enforces the precondition; the model still decides everything else.

def before_process_refund(tool_input, state):
    # Deterministic precondition: identity must be verified first
    if not state.get("customer_verified"):
        return {"block": True,
                "reason": "Call get_customer and verify identity before refunding."}
    return {"block": False}

Don't Over-Hard-Code

The mistake in the other direction is just as costly: hard-coding decisions that the model should make.

If you wrap every step in branching if/else logic, you have rebuilt a rigid pipeline and thrown away Claude's adaptability. The agent can no longer handle the unexpected case.

Reserve hard code for the narrow set of guarantees — money, law, safety, required preconditions. Everything else stays model-driven.

A Clean Division of Labor

Put it together as a division of labor:

  • Model decides: which tool to call, in what order, when the task is complete, how to recover from an unexpected result.
  • Code guarantees: policy ceilings (refund ≤ $500), required preconditions (verified ID), and the loop terminating on stop_reason.

The model drives the trajectory. Code draws the hard boundaries it can never cross.

Fixed Pipelines vs Adaptive

One nuance: not every task is open-ended.

  • For a known, sequential process, a fixed pipeline (prompt chaining) is fine — the steps really are fixed.
  • For an open-ended investigation, use adaptive decomposition and let the model choose its path.

So "let the model decide" applies where the path is genuinely uncertain. Where the sequence is truly known, structure is appropriate — just don't force structure onto problems that need adaptability.

Quick Check

A support agent must never issue a refund above $500. Refunds at or below $500 should be handled smoothly within the conversation. What is the architect-grade design?

Key Takeaways

Remember the rule: let the model decide; reserve code for guarantees.

  • Default to model-driven decisions — Claude adapts to live context.
  • Drive the agentic loop and terminate on stop_reason, never by parsing text.
  • Iteration caps are a safety net, not the primary stop.
  • Use hooks and programmatic preconditions for financial, legal, or safety rules — 100% deterministic vs a prompt's ~90%.
  • Don't over-hard-code: guarantees are a narrow boundary, not the whole agent.

Questions Fréquemment Posées

La leçon « Décisions pilotées par le modèle ou codées en dur » est-elle gratuite ?

Oui — le texte complet de « Décisions pilotées par le modèle ou codées en dur » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Claude Architect, passe à CoddyKit PRO. Le cours Claude Architect comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Décisions pilotées par le modèle ou codées en dur » ?

Laissez le modèle décider et réservez le code aux garanties. Tu pratiques Claude Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer Claude Architect ?

Aucune expérience préalable n'est requise. Claude Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 2 sur 4.

Combien de temps prend la leçon « Décisions pilotées par le modèle ou codées en dur » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon Claude Architect ?

Oui. Chaque leçon Claude Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Qu’est-ce qui rend un système agentique
  2. Décisions pilotées par le modèle ou codées en dur
  3. Quand utiliser un agent
  4. Vue d’ensemble de la boucle agentique
← Retour à Claude Architect