"EXAMPLES ONLY" STRATEGY:
Prompt: [few-shot examples of concise code]
→ First answer: -20% tokens
→ After "improve it": bloats as if there were no examples ❌

"INSTRUCTIONS ONLY" STRATEGY:
Prompt: "Write the minimum. No defensive code unless asked. No docstrings if the name is obvious."
→ First answer: -56% tokens
→ After "improve it": adds fewer tokens ✓

"COMBO" STRATEGY (the sweet spot):
Prompt: [explicit rules] + [examples] + "Write the minimum code that works"
→ First answer: -70% tokens
→ After "improve it": minimal bloat ✓✓

One prompt is the system prompt. The revision is a separate request asking for improvements.

Task: You're working with Claude/ChatGPT on a Python script that processes CSV reports. You want minimalist code that won't balloon when you ask it to add error handling.

Prompt (system prompt or at the start of the chat):

I value minimal, working code. No defensive programming unless explicitly required. No docstrings if the function's purpose is obvious from its name and signature.

Good example:
```python
def parse_csv(path):
    return pd.read_csv(path)

def calc_stats(df):
    return {
        'total': len(df),
        'unique_users': df['user_id'].nunique(),
        'avg_by_type': df.groupby('event_type')['value'].mean().to_dict()
    }
```

Write the minimum code that works.

Then the task:

Write a Python CLI script: scan a directory for CSV files, check that the columns (timestamp, user_id, event_type, value) are present, compute statistics (total events, unique users, average value per type), and save the result to JSON.

After the first answer, the revision:

Improve the code: make it more readable, add error handling, make it modular.

Result: The model produces a compact first version (~760 tokens instead of ~2560 with no guidance). On revision it adds error handling sparingly: roughly +126 tokens instead of +266 for the "bare" model. Defensive constructs (try/except) take up a bigger share of the code, but the code itself stays lean.

The LLM weakness: RLHF trains models to be "helpful", which often means wordy. Without constraints, a model piles on docstrings, comments, "just in case" checks and helper functions. The code passes the tests but is 2-3x bigger than it needs to be.

The two control mechanisms work differently:

• Examples (few-shot) work through imitation of surface form. The model copies the pattern: short functions, no comments, minimal code. But this doesn't create a rule; it's a template for one particular moment.
• Instructions work as operational constraints. "No docstrings if the name is obvious" is a testable rule the model applies on every generation.

Why examples get "forgotten" on revision: when you ask it to "improve error handling", the model gets a new task. The examples at the top of the prompt were about the format of the first answer. Instructions are about how to work in general, so they keep applying.

Control levers:

• Specific instructions → the more precise the rule ("no docstrings if the name is obvious"), the more strictly it's followed
• Examples → set the format baseline, especially for the first answer
• Order → rules placed before examples act as context for the examples

I value {output_style}. {rule_1}. {rule_2}. {rule_3}.

Good example:
{example_in_target_format}

{final_directive}.

Placeholders:

• {output_style}: the result you want, e.g. "minimal working code", "concise answers with no fluff", "structured reports without repetition"
• {rule_1-3}: concrete constraints, e.g. "no X unless Y", "only Z when W"
• {example_in_target_format}: 1-2 examples of the desired output
• {final_directive}: a short summary, e.g. "Write the minimum code that works", "Get straight to the point"

⚠️ Tested on a single task: a Python CLI script. The effect may differ for other kinds of work: essays, analysis, creative writing.

⚠️ One model: Gemini 2.5 Pro. The principle is universal (instructions vs. examples), but the exact compression numbers may differ for Claude/GPT.

⚠️ Two turns: only one revision cycle was tested. Over 5-10 iterations the effect could compound or fade; nobody knows yet.

⚠️ Minimalism ≠ readability: aggressive compression can make code harder for other people to understand. The study didn't measure subjective readability.

The team ran 160 code-generation sessions (40 for each of the 4 strategies) with Gemini 2.5 Pro. The task was always the same: a Python CLI for processing CSV files. Turn one was generation; turn two was a standard request to "improve readability, error handling, modularity".

What they measured: token count, share of defensive code (try/except and checks), documentation density, number of functions. Functional correctness was a binary test (works / doesn't work).

Why the results are convincing: 99% of the code passed the tests under every condition, so the differences in style have nothing to do with solution quality. The effects are huge: Combined vs. Control = d = -10.97 on the first turn (a "gigantic" effect size in statistical terms). On revision, Examples bloated exactly like Control (d = 0.01, zero difference), while Combined added 140 fewer tokens.

Unexpected insight: examples increased modularity (more functions), while instructions decreased it: the model read "minimum code" as "fewer abstractions". Style is multidimensional, and different mechanisms push on different dimensions.

Instructions System Prompt:

I value minimal, functional code. No defensive coding unless explicitly required.
No docstrings unless function purpose is non-obvious from the name and signature.

Write the minimum code that works.

Examples System Prompt:

def parse_csv(path):
    return pd.read_csv(path)

def calc_stats(df):
    return {
        'total': len(df),
        'unique_users': df['user_id'].nunique(),
        'avg_by_type': df.groupby('event_type')['value'].mean().to_dict()
    }
```

**Combined:** both blocks together, instructions first.

**Context:** the researchers tested how the system prompt affects code style during generation and during later revision.

---

## Adaptations and Extrapolations

> 💡 **Adapting it for text (not code):** the same principle works for any task where style matters.

**Example: concise chat answers:**
```
I value short, concrete answers. No opening phrases like "Great question!". Don't repeat the question. No "it depends on the context" caveats if a direct answer is possible.

Good example:
Q: Which language should I learn for data science?
A: Python. The most libraries, jobs and learning materials.

Get straight to the point.
```

> 🔧 **Technique: add "testable" rules**

Replace abstract rules with concrete, conditional ones:
- ❌ "Be brief"
- ✅ "Answer in 3 sentences or fewer unless the question needs a detailed explanation"
- ❌ "No fluff"
- ✅ "No opening phrases. Start with the substance."

Concrete rules are easier to "check", so the model follows them better.

> 🔧 **Technique: restate the rules when revising**

When you ask it to improve or extend something, remind it of the constraints:
```
Add error handling. Stay minimal: only the checks that are necessary.

This makes up for instructions "fading" over long conversations.

Paper: "Show and Tell: Prompt Strategies for Style Control in Multi-Turn LLM Code Generation"

Author: Jeremiah Bohr, University of Wisconsin Oshkosh

Data and code: https://github.com/jeremiahbohr/show-and-tell

Key references from the paper:

• Min et al. 2022, "Rethinking the Role of Demonstrations" (why few-shot works through imitation of form)
• Ouyang et al. 2022, RLHF and instruction-following (why instructions persist)
• Laban et al. 2025, "LLMs Get Lost in Multi-Turn Conversation" (the context-fading problem)