Prompt Quality = Output Quality: Three Parameters of a Good Prompt

The framework scores a prompt on three parameters:

1. GOAL CLARITY

• Is it clear WHAT needs to be done?
• Is there any ambiguity in the wording?

2. INFORMATION COMPLETENESS

• Is there enough data to do the job?
• Are the constraints, context, and conditions spelled out?

3. LOGICAL CONSISTENCY

• Are there contradictions between the requirements?
• Do any conditions conflict with each other?

Each parameter affects how much the model has to fill in on its own. The more it has to fill in → the higher the risk of errors.

L0 — EXPERT (fully prescriptive) Everything is detailed: goals, data, constraints, context. The model doesn't guess — it just executes.

L1 — EXPERIENCED (partially prescriptive)
The basics are clear, but the details are fuzzy. The model fills the gaps from experience.

L2 — JUNIOR (non-prescriptive) Only the general structure. Critical details are missing. The model fills in a lot.

L3 — BEGINNER (extremely non-prescriptive) Only the business requirement, often with contradictions. The model has to guess almost everything.

Task: Evaluate a business idea — a coffee shop in a residential neighborhood of Chicago.

Bad prompt (L3):

Is opening a coffee shop a good idea?

The problem: No context → the model answers with generic lines like "it depends on location and competition."

Good prompt (L0):

Evaluate a business idea: a grab-and-go coffee shop in a residential neighborhood of Chicago
(15 minutes from the nearest L station).

Context:
- Neighborhood: residential, lots of apartment buildings, few places to eat
- Target audience: local residents, people working remotely
- Competitors: 1 Starbucks a 10-minute walk away, other chains are far
- Format: coffee to go, average ticket ~$5
- Goal: break even within 12 months

Evaluate: potential demand, the competitive landscape, the main risks.

Result: A concrete analysis with a foot-traffic estimate, competitive advantages, and clear risks instead of generic talk.

+ Chain-of-Thought:

{the same task as above}

Reason step by step:
1. Demand analysis
2. Competitive landscape
3. Financial risks
4. Final conclusion

Result: You see the model's line of reasoning → it's clear why it reached that conclusion, not just the final verdict.

+ Self-Correction:

{the same task as above}

After the analysis: reread your answer and check — did you miss
anything important? Fill in any factors you overlooked.

Result: The model finds the gaps in its own analysis and adds important factors (seasonality, permit requirements, foot traffic at different times of day).

The LLM's weakness: With incomplete information, the model fills the gaps with assumptions. But it doesn't pick the safest or most correct option — it picks the simplest one, the "path of least resistance."

How the problem unfolds:

1. Vague prompt → lots of ambiguity
2. The model is forced to invent the context
3. It picks the simplest solution (often the wrong one)
4. The output contains errors or risks

Why CoT helps: It forces the model to think out loud, step by step. Instead of an instant "easy answer," the model breaks down the task and shows its reasoning → less room for dangerous assumptions.

Why Self-Correction helps: The model checks its own work — looking for missed factors, contradictions, risks. It's like a "second read" — it often catches what it missed the first time.

Control levers:

• Detailed context → less guesswork → more accurate results
• Explicit constraints → the model doesn't invent its own → safer output
• Step-by-step (CoT) → you see the logic → you can check it
• Self-check (Self-Correction) → the model catches its own mistakes

Check your prompt before you hit send:

✅ GOAL CLARITY

• Is it clear WHAT needs to be done?
• Is there any ambiguity in the wording?
• Is the desired output format specified?

✅ INFORMATION COMPLETENESS

• Is there enough data to do the job?
• Are all the constraints listed?
• Is the necessary context there?

✅ LOGICAL CONSISTENCY

• Are there contradictions between the requirements?
• Do any conditions conflict?
• Does the task's logic hang together?

For complex tasks, add:

1. Chain-of-Thought (step-by-step reasoning):

{your task with full context}

Think out loud: break the task into steps and show your reasoning
at each stage.

2. Self-Correction (self-check):

{your task with full context}

When you're done: reread the result, find gaps or mistakes,
fix them and fill in what's missing.

The combo (maximum protection):

{your task}

1. Reason step by step
2. When you're done — check yourself and fix any issues

⚠️ Not a cure for every error: Even a perfect prompt doesn't guarantee correctness on tasks where the model lacks the knowledge or reasoning ability.

⚠️ The effect depends on complexity: For simple tasks the difference between L0 and L3 is minimal. The effect shows up on tasks that require logic and complete information.

⚠️ Self-Correction can add hallucinations: Sometimes the model "finds" problems that don't exist. Evaluate its edits critically.

The team built the CWE-BENCH-PYTHON benchmark — 1980 prompts for generating code prone to different types of vulnerabilities. For each of the 165 tasks they wrote four versions of the prompt (L0→L3), tightly controlling length and avoiding any explicit mention of security. Then they added two variations of each prompt (lexical and structural changes) to test how robust the results were.

They tested 10 models — from CodeQwen-7B to GPT-4o — and compared vulnerabilities in the generated code via automated analysis using expert patterns for each CWE type. The consistency of the result was striking: regardless of the model, going from L0 to L3 increased vulnerabilities 1.5–2.5x. The effect was strongest on tasks that require logic (error handling, access control).

The variation tests showed that the trend holds when the wording changes — so it's really about the quality of the specification, not particular words.

Then they tested CoT and Self-Correction on the same benchmark. CoT reduced vulnerabilities by 13-27% on complex tasks (CWE-284), and Self-Correction by 15-23%. The mechanisms work: explicit reasoning and self-checking compensate for a vague prompt.

Practical insight: Even without any special security instructions, clear task wording is critical. Vagueness = dangerous assumptions. CoT and Self-Correction are accessible tools for reducing risk.

💡 Adaptation for any task:

The principles apply well beyond code. Any task benefits from:

• A clear goal
• Full context
• Logical consistency

Example — writing a text:

❌ L3: "Write an article about AI" ✅ L0: "Write a 1500-word article about using AI in marketing, aimed at small business owners. Format: case studies + practical tips. Tone: friendly, no technical jargon."

🔧 Technique: Preventive self-check

Instead of Self-Correction AFTER the result, ask the model to account for the risks up front:

{your task}

Before you start: think about which mistakes or omissions are typical
for this kind of task. Account for them in your solution.

Effect: The model avoids typical mistakes in advance instead of fixing them after the fact.

🔧 Technique: Explicit Constraints

Add clear boundaries to the prompt, even if they seem obvious:

Evaluate a business idea: {description}

Analysis constraints:
- Facts only, no assumptions
- If there's not enough data, say exactly what's needed
- Cite a source or experience for every claim

Effect: The model doesn't make things up but works with what it has → fewer hallucinations.

Is Your Prompt Poisoning Code? Defect Induction Rates and Security Mitigation Strategies
Bin Wang, YiLu Zhong, MiDi Wan, WenJie Yu, YuanBing Ouyang, Yenan Huang, Hui Li
Shenzhen Graduate School, Peking University

The CWE-BENCH-PYTHON benchmark is publicly available (see the paper for the link)