PseudoScript is the most evidence-backed member of the PseudoLang family. The idea: write a prompt the way you would write pseudo-code. Decompose the task into numbered steps, name reusable operations as functions, store working values in variables, and use explicit control flow for conditions and repetition. You trade a paragraph's ambiguity for a procedure's clarity.
This is measured, not stylistic
Prompting with Pseudo-Code Instructions (Mishra et al.) rewrote 132 tasks as pseudo-code prompts and compared them against the same instructions in natural language. The pseudo-code versions won clearly, and the paper's ablations pinned down why: the structural clues, the function-style signatures, and even code-comment-style annotations each contributed. The mechanism is the headline — pseudo-code reduces the ambiguity that natural language carries by default. A paragraph leaves the order of operations, the branch conditions, and "what counts as done" implicit; a numbered procedure states them.
A complementary study, Code Prompting Elicits Conditional Reasoning, traced the gain to a concrete capability: code-formatted prompts improved the model's variable-state tracking — exactly the part of a multi-step procedure that prose tends to lose. Putting program structure into the reasoning steps themselves shows the same effect for generation tasks (Structured Chain-of-Thought).
What it looks like
INPUT: claim (free text), policy (structured)
let severity = classify_severity(claim)
1. Extract from claim: loss_type, loss_date, claimed_amount.
2. classify_severity(claim):
- major if claimed_amount > policy.threshold OR loss_type in policy.high_risk
- minor if claimed_amount < 500 AND loss_type in policy.fast_track
- else standard
3. IF severity == major: route to "adjuster_review"; do NOT auto-draft.
4. ELSE: check loss_date against policy.coverage_window; draft next step.
5. Return: {severity, route, drafted_message?}
A business analyst reads that as plainly as the desk procedure it encodes; an engineer reads it as a spec. That dual readability is the point. PseudoScript composes with everything else — a pseudo-code block lives perfectly well inside a vendor's instruction tags.
The line between structure and theatre
One caution keeps the technique honest. Structured notation is legitimate when the model acts on it and a human can maintain it. It becomes theatre when it is decorative — arrow chains and invented step-IDs like 1a. ExtractTerms → 2a that describe a state machine the model never runs. The model does not execute those arrows; they are prose in costume that buries the real instruction and break on the first edit. The working test: rewrite each line as a plain imperative — if the notation carried no instruction the model could follow, it was decoration. Keep what the model follows; cut what only you perform.
When to reach for it
PseudoScript pays off when the hard part of the task is its structure: multi-step workflows, branching logic, reusable procedures, anything you will run many times and want to version. It is overkill for a one-off question or an open-ended draft, where prose is faster. And on a strong reasoning model, keep only the load-bearing structure — the branch conditions and the output contract — and let the model handle the rest, rather than over-scripting every step.
