The 2026 Prompting Formula — Shattering the “Step-by-Step” Myth

For most of the last few years, one phrase did more work in prompt engineering than any other: think step by step. It appeared in system prompts, in internal playbooks, in nearly every “best prompts” listicle. It worked, too. Asking a model to externalise its reasoning reliably improved accuracy on multi-step problems, and teams built entire prompt libraries around the idea.

In 2026, that instruction is often the single most expensive line in your prompt, and frequently the one making your output worse. Not because the underlying insight was wrong, but because the models changed underneath it. Understanding exactly what changed, and what to do instead, is the difference between a prompt that costs a few hundred tokens and one that quietly burns thousands on every call.

What actually changed

Chain-of-thought prompting was a workaround. Early large language models produced their answer token by token with no dedicated space to work a problem out, so if you wanted deliberation you had to manufacture it in the visible output. Telling the model to reason aloud gave it room to compute before committing to an answer.

Reasoning models removed the need for that trick. Across the major families, including Anthropic’s extended thinking modes, OpenAI’s reasoning models, and Gemini’s thinking capability, deliberation now happens as a built-in phase before the response is generated. The model already reasons. It has been trained to allocate internal effort to the problem, and in most implementations you can control how much effort it spends through a parameter rather than through prose.

This is the crux of the shift. Chain-of-thought moved from being something you prompt for to something you configure. When you keep prompting for it anyway, you are not adding capability. You are adding instructions on top of a process that is already running.

Why step-by-step now backfires

Three distinct failure modes show up when teams carry old prompting habits into reasoning models.

Double reasoning. The model reasons internally, then follows your instruction to reason again in the visible output. You pay for both passes, and the second pass is usually a lower-quality restatement of the first. The user waits longer to read something the model had already worked out.

Constrained exploration. This one is subtler and more damaging. When you prescribe a reasoning procedure, first identify the variables, then list assumptions, then evaluate each option in turn, you are imposing your structure on a process that would otherwise adapt to the problem. For genuinely hard problems, the model’s own approach is frequently better than the one you scripted. Prescriptive reasoning instructions act as a ceiling, not a floor.

Token inflation with no accuracy return. Reasoning tokens are billed and they count against output limits. A prompt that triggers verbose visible reasoning on a task that needed none is pure waste, repeated on every single call. At the scale of a production workflow, this is where budgets quietly disappear.

The 2026 formula

The modern structure is less about instructing the model how to think and more about removing ambiguity from what you want. Four components, in this order:

1. Context. Who is asking, what situation this sits in, what the reader already knows. Not background for its own sake, only what changes the answer.
2. Task. One clear instruction, stated directly. If you need three things, that is often three prompts.
3. Constraints. Length, tone, what to exclude, what to do when information is missing. Constraints prevent far more rework than reasoning instructions do.
4. Output contract. The exact shape you want back: a format, a schema, a section list. This is the highest-leverage line in most prompts.

Notice what is absent. There is no instruction about how to think, no persona padding, no “take a deep breath” ritual. The reasoning is handled by the model’s configuration. Your prompt’s job is specification.

Direct prompting versus reasoning prompting

The practical question is not which style is better, but which task needs which. A workable decision rule:

Use direct prompting when the task is retrieval, transformation, classification, extraction, summarisation, formatting, or routine drafting. These are the overwhelming majority of production calls. They have a knowable correct output and no meaningful solution space to explore. Sending them to a reasoning model with a high effort setting is like chartering a freight aircraft to post a letter.

Use reasoning when the task involves multi-step logic, genuine ambiguity, competing trade-offs, mathematical or code correctness, or a decision where being wrong is costly, which is increasingly the case as AI in cybersecurity reshapes both attack and defence. Here, the internal deliberation earns its cost.

The expensive mistake most teams make is not choosing wrongly once. It is choosing a single default for every call in the pipeline. Routing tasks by type, cheap and direct for the bulk, reasoning for the hard minority, tends to cut spend substantially while improving quality on the tasks that matter, because the hard tasks finally get the effort budget they need.

Token budgeting as a design discipline

Token budgeting is usually treated as a cost-control afterthought. It is better understood as a design constraint that improves output.

Start by auditing where tokens actually go. In most production prompts the distribution is lopsided: a long static system prompt accumulated over months, a large block of retrieved context of which a fraction is relevant, few-shot examples that predate the current model, and only then the actual user input. The reasoning phase and output sit on top of all of it.

Four adjustments deliver most of the savings:

• Prune legacy few-shot examples. Many exist to fix behaviour that current models get right unprompted. Remove them, test, and keep only those that measurably change output.
• Tighten retrieval before it reaches the prompt. Filtering at the retrieval layer is cheaper than paying the model to read and ignore irrelevant passages.
• Set effort deliberately. Where a thinking budget or effort level is exposed, treat it as a per-task decision, not a global default.
• Cap the output contract. A specified length or schema prevents drift and makes cost predictable.

Where the platform supports prompt caching, structure prompts so the stable portion sits at the front and the variable portion at the end. That ordering alone can meaningfully reduce the cost of repeated calls against a large shared context.

How this looks in practice

Claude. Anthropic’s guidance for extended thinking runs against old instincts: give the model a clear objective and let it determine its own approach, rather than scripting the steps. Claude also responds strongly to explicit output contracts and to XML-style tags that separate context from instruction. A practical pattern is to put reference material inside tagged blocks, state the task plainly beneath it, and specify the response format, then control depth through the thinking budget rather than through phrasing. Teams migrating older prompts often find that deleting the reasoning scaffolding improves results immediately.

ChatGPT and the OpenAI reasoning models. The documented advice for reasoning models is to keep prompts simple and direct, and to avoid explicit chain-of-thought instructions. The lever that matters is the reasoning effort setting. A useful discipline is to run the same evaluation set at low and at high effort and compare: on many routine tasks the outputs are indistinguishable, which is a direct signal that the higher setting is wasted spend. Reserve it for the tasks where the gap is real.

Gemini. Gemini’s thinking capability is similarly configurable, and its very large context window creates a distinct temptation: because you can paste an entire corpus, teams do. Long context is a capability, not a strategy. Relevance still beats volume, and a focused context window usually produces a sharper answer than an exhaustive one, at a fraction of the cost. Gemini also rewards clear structural separation between supplied material and the instruction operating on it.

The common thread across all three: specify the output, configure the reasoning, and stop narrating the process. This is also why prompt engineering belongs in the security skill set rather than being filed away as a writing tip.

A before and after

Abstraction only goes so far, so here is the pattern applied to a task any security team will recognise: turning a vulnerability scan finding into something a business owner can act on.

The 2023-era prompt. You are an expert cybersecurity analyst with twenty years of experience. Think step by step. First, carefully read the finding below. Second, consider its severity. Third, think about the business impact. Fourth, reason through the remediation options one by one, weighing each carefully. Take your time and show all your reasoning before giving your final answer. Then write a summary for a non-technical stakeholder.

That prompt has a persona preamble that changes little, four prescriptive reasoning steps that override the model’s own approach, an instruction to show reasoning that nobody will read, and a vague final deliverable. The most important part, what the summary should actually contain, gets one clause at the very end.

The 2026 rewrite. Context: the reader is a business unit owner with no security background who must decide whether to fund remediation this quarter. Task: assess the finding below and recommend a course of action. Constraints: no jargon without a plain-language gloss; state explicitly if severity depends on details the scan does not capture; do not recommend anything requiring tooling not already in use. Output: a two-sentence risk statement, a recommended action, an estimate of effort in engineer-days, and one sentence on the consequence of deferring to next quarter.

The rewrite is shorter, says nothing about how to think, and is far harder to answer badly. Every ambiguity that would have produced a vague response has been closed off in advance. On a reasoning model, depth is then set through the effort parameter rather than through the words, which means the same prompt can be tuned for cost without being rewritten.

Run both against a batch of real findings and the difference is usually obvious in the outputs, and stark in the token counts. That comparison, on your own tasks with your own evaluation set, is worth more than any general guidance including this article.

When step-by-step still earns its place

The myth worth shattering is that step-by-step is universally good, not that it is universally bad. It remains genuinely useful in three cases.

First, with non-reasoning models. Smaller and faster models without an internal deliberation phase still benefit from externalised reasoning, exactly as before. If your pipeline routes bulk work to a lightweight model, the old technique still applies there.

Second, when the reasoning is the deliverable. In training material, audit trails, tutoring, or any context where a reader needs to follow the logic, you are not asking the model to think aloud in order to think better. You are asking for an explanation as the product. That is a legitimate output requirement, and it belongs in the output contract rather than being framed as a thinking instruction.

Third, when a process must be followed exactly. Regulatory checks, incident response procedures, and compliance workflows sometimes require a specific sequence regardless of what the model would choose. Here the structure is a control, not a performance technique, and imposing it is correct.

A practical migration path

If you have a prompt library built on older assumptions, work through it in this order.

1. Inventory every prompt and label the task type: retrieval, transformation, or genuine reasoning.
2. Strip explicit chain-of-thought instructions from anything hitting a reasoning model, and test against a fixed evaluation set rather than by impression.
3. Replace deleted scaffolding with a stronger output contract. Most quality lost in the strip comes back through specification.
4. Route by task type so routine calls stop paying a reasoning premium.
5. Measure tokens per call before and after, and keep measuring. Prompt libraries drift back toward verbosity without a periodic audit.

The teams getting the most out of these models in 2026 are not the ones with the most elaborate prompts. They are the ones who worked out which tasks deserve deliberation, configured that deliberation explicitly, and spent their remaining effort on being unambiguous about what they wanted back. The formula got shorter. The thinking moved inside the model. What is left for us is specification, and that turns out to be the part that was always doing the heavy lifting.

Building the skill across a team

Prompting well is now a working competency rather than a niche specialism, and it is one of the few skills that pays back immediately across an entire organisation. CyberNova’s Foundational AI Skills course covers this ground in depth as part of our AI skills training for professionals, from how models actually work through to prompt engineering, AI risk, and responsible deployment. For organisations rolling this out more broadly, the same material is available as corporate AI training alongside our cybersecurity training in South Africa.