# How Think Before Coding Handles Ambiguous Requirements in LLM Workflows

> Learn how Think Before Coding addresses ambiguous requirements in LLM workflows by surfacing assumptions, enumerating interpretations, and seeking user clarification before coding.

- Repository: [multica-ai/andrej-karpathy-skills](https://github.com/multica-ai/andrej-karpathy-skills)
- Tags: deep-dive
- Published: 2026-04-19

---

**The Think Before Coding principle forces LLMs to treat unclear requests as explicit decision points by surfacing assumptions, enumerating multiple interpretations, and requesting user clarification before generating any implementation code.**

When large language models receive vague prompts like "add a logger to the service," they risk generating code based on hidden assumptions that diverge from user intent. The `multica-ai/andrej-karpathy-skills` repository solves this through the **Think Before Coding** principle, documented in [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) and [`skills/karpathy-guidelines/SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md), which mandates a structured disambiguation protocol as a prerequisite to code generation.

## The Four Sub-Rules of Think Before Coding

According to section 1 of both [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) and [`SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/SKILL.md), the principle enforces four concrete actions when an LLM detects ambiguity:

### State Assumptions Explicitly

The model must list every premise it is about to adopt. Instead of silently assuming "logger" means a file-based rotating logger, the LLM states: "I assume you want a file-based logger with rotation instead of console output."

### Present Multiple Interpretations

Enumerate all plausible meanings without choosing one silently. For the logging example, the model generates a bulleted list: console logger for every request, file-based logger with rotation, or structured JSON logger for monitoring stacks.

### Push Back When Warranted

If one interpretation introduces unnecessary complexity, the model must suggest simpler alternatives. It explicitly asks: "A simpler approach would be a basic console logger; should I continue with that?"

### Stop When Confused

When the model cannot disambiguate with available information, it must halt execution and ask clarifying questions rather than proceeding with a guessed interpretation.

## The Disambiguation Workflow Loop

The implementation creates a conversational loop that satisfies the broader **Goal-Driven Execution** principle (the fourth guideline in the repository). The workflow follows these steps:

1. **Parse Request and Detect Ambiguity** — Identify ambiguous tokens like "it," "them," "the file," or "default."
2. **Generate Assumption/Interpretation List** — Inline with the prompt, create explicit lists of assumptions and alternative interpretations.
3. **Emit Clarification Questions** — Present the user with specific choices or questions to resolve ambiguity.
4. **Await User Response** — Pause execution until the user provides clarification, then repeat the loop until a single unambiguous path remains.

This process directly addresses the two failure modes highlighted in the repository's [`README.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md) section "The Problems": **wrong assumptions** and **missing trade-offs**. By surfacing interpretations explicitly, the model no longer "just runs along" with guessed meanings, and each alternative's cost/benefit becomes visible to the user.

## Practical Implementation in Python

The repository provides a conceptual pattern for implementing this protocol. The following helper demonstrates how an LLM-based agent might internalize the Think Before Coding principle:

```python
def think_before_coding(request: str):
    """
    Detect ambiguities, surface assumptions, and ask for clarification.
    Returns either:
      - a list of interpretations + a clarifying question, or
      - a single concrete plan when unambiguous.
    """
    # 1️⃣ Detect ambiguous tokens (e.g., "it", "the file", "default")

    ambiguous = ["it", "them", "the file", "default", "some"]
    flags = [word for word in request.lower() if word in ambiguous]

    if not flags:
        # No obvious ambiguity – proceed directly

        return {"plan": f"Implement: {request}"}

    # 2️⃣ Build possible interpretations

    interpretations = [
        "Interpretation A: … (assume X)",
        "Interpretation B: … (assume Y)",
        # …more as needed

    ]

    # 3️⃣ Ask user to pick / clarify

    clarification = (
        "I see several possible meanings:\n"
        + "\n".join(f"- {i}" for i in interpretations)
        + "\n\nWhich one should I follow, or can you provide more detail?"
    )
    return {"question": clarification}

```

In a real conversation, this manifests as:

```text
User: "Add a logger to the service."
Assistant (Think Before Coding):
I notice the request could mean:
- Add a console logger that logs every request.
- Add a file-based logger with rotation.
- Add a structured JSON logger used by the monitoring stack.

Which logging style do you need, or should I suggest a minimal approach?

```

## Source Files and Architectural Context

The Think Before Coding principle is codified across three key files in the `multica-ai/andrej-karpathy-skills` repository:

| File | Role | Location |
|------|------|----------|
| [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) | Central markdown defining the four principles, including the full Think Before Coding text. | [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) § 1 |
| [`skills/karpathy-guidelines/SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md) | Machine-readable skill definition used by Claude plugins; repeats the principle for automated enforcement. | [`SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/SKILL.md) § 1 |
| [`README.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md) | High-level motivation mapping the principle to real-world problems (wrong assumptions and missing trade-offs). | [`README.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md) § "The Problems" |

Together, these files create an architectural backbone that enforces disambiguation as a prerequisite to code generation, rather than an optional afterthought.

## Summary

- **Think Before Coding** requires LLMs to treat ambiguous requirements as explicit decision points rather than hidden assumptions.
- The principle mandates four concrete actions: stating assumptions explicitly, presenting multiple interpretations, pushing back on unnecessary complexity, and stopping to ask clarifying questions when confused.
- Implemented in [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) and [`skills/karpathy-guidelines/SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md), this protocol prevents the failure modes of wrong assumptions and missing trade-offs documented in the repository's [`README.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md).
- The workflow creates a disambiguation loop that parses requests, detects ambiguity, generates interpretation lists, and awaits user clarification before proceeding to code generation.

## Frequently Asked Questions

### What is the "Think Before Coding" principle in the Andrej Karpathy Skills repository?

The Think Before Coding principle is the first guideline defined in [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) and [`skills/karpathy-guidelines/SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md) that forces LLMs to resolve ambiguous requirements before writing code. It requires the model to explicitly state assumptions, present multiple interpretations, push back on complexity, and ask clarifying questions rather than silently guessing user intent.

### How does Think Before Coding prevent wrong assumptions in LLM-generated code?

By mandating that the model stop and enumerate all possible interpretations of ambiguous terms like "it," "default," or "the file," the principle surfaces hidden assumptions that would otherwise be baked into generated code. The model must present these interpretations as explicit choices to the user, ensuring the selected path aligns with actual requirements rather than inferred ones.

### What are the four sub-rules of the Think Before Coding principle?

The four sub-rules are: **State assumptions explicitly** (list every premise the model adopts), **Present multiple interpretations** (enumerate all plausible meanings without silent selection), **Push back when warranted** (suggest simpler alternatives when an interpretation introduces unnecessary complexity), and **Stop when confused** (halt execution and ask clarifying questions when disambiguation is impossible).

### Where is the Think Before Coding principle documented in the repository?

The principle is documented in three primary locations: [`CLAUDE.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md) (section 1) serves as the central human-readable definition; [`skills/karpathy-guidelines/SKILL.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/skills/karpathy-guidelines/SKILL.md) (section 1) provides the machine-readable version for Claude plugin enforcement; and [`README.md`](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/README.md) (section "The Problems") explains the high-level motivation and maps the principle to specific failure modes it prevents.