Prompt engineering in 2026: what's still worth writing in the prompt

March 31, 2026. Michael Heap, who maintains trello-cli, opens a terminal and gives an agent one sentence: “Add support for showing card details”. A few minutes later he has a command. It shows the title, the description and the labels. It doesn’t show the due date, which is the thing he needs most. It doesn’t show checklists at all. He’s close to shutting the laptop.

Then he realizes the agent did exactly what he asked. He just never said which details. On the second try he writes five sentences: which flags, which fields, what to do when a value is missing, what happens when a checklist has more than 10 items. This time the command works right away. Heap says something that would have taken him an hour was done in minutes. The model didn’t change. Only what the model knew changed.

That’s prompt engineering at the end of 2026. Not magic words. Writing requirements.

What died since 2023, and what stayed

First, what died. In 2023 prompt engineering was a bag of tricks: “think step by step”, repeat your intent three times, promise the model a tip. The blogger yiblet wrote back then that it would be a profession for a few years. In May 2026 he came back to it in a post called Prompt Engineering Is Permanent and admitted he was only half right: “That notion of Prompt Engineering is largely gone.” 2026 models understand plain language, and reasoning models think without being asked.

What stayed: once the model doesn’t just answer but also acts, meaning it writes files, calls APIs, sends messages, the prompt has to describe the boundaries too. What to do, what not to do, when to ask, when to stop, what counts as success.

What it isn’t: a job title. The author of The Infrastructure Mindset blog, after four decades in infrastructure, went looking for the engineering discipline behind prompts and mostly found posts saying “be specific” and “iterate”. About most of what’s online, he’s right. That doesn’t mean there’s nothing to learn here. It means most of what you need to learn sits outside the prompt.

What moved into context and the harness

Most of what we used to cram into the message moved to other layers. Pasting docs into the prompt became context engineering: what the agent sees, from where, and when. “Make sure it works” became the harness: a test suite the agent runs itself and an exit code it reads. “Think step by step” became a parameter on a reasoning model.

Anthropic’s Claude Code guide says it plainly: most best practices come from one constraint. The context window fills up fast, and performance drops as it fills. One debugging session can burn tens of thousands of tokens. In practice, the text you type is a small part of what the model reads.

So what’s left inside the prompt? Intent, boundaries, and the definition of “done”. No harness will invent those for you.

Five things that still change the result

Each one with a before and after. The prompts are in English because that’s how most teams write to agents, but the principle doesn’t depend on the language.

1. Write the end state, not the topic. This is Heap’s story, with his prompt almost word for word:

# before
Add support for showing card details

# after
Add a card:show command that accepts --board and --list as flags.
Output the card title, description, due date, any attached checklists and labels.
If any of these values do not exist, skip the header for that section.
If checklists have more than 10 items, add a "+ X more" entry.

2. Give it a check it can run. Anthropic put it best:

Claude stops when the work looks done. Without a check it can run, “looks done” is the only signal available, and you become the verification loop: every mistake waits for you to notice it. — Anthropic, Best practices for Claude Code

# before
Fix the date parsing bug. Make sure it works.

# after
Fix the date parsing bug in src/parse.ts.
Run `npm test -- parse` after every change.
You're done when all tests pass, including one new test
that reproduces the bug and failed before your fix.

3. Boundaries: what’s off limits and when to stop. yiblet wrote that when a chatbot misunderstands you, you get a bad answer, and when an agent misunderstands you, it might change a database. In July 2025 that’s exactly what happened to Jason Lemkin with Replit’s agent, which deleted a production database in the middle of a code freeze.

# before
Clean up the old migration files.

# after
Clean up files older than 2025-01 in db/migrations/ only.
Do not touch db/seeds/ and do not run any migration.
If a file is referenced from code, list it and stop. Ask before deleting.

4. A new chat instead of the fifth correction. The the.scapegoat.dev blog describes this exactly: one more regenerate, one more “no, I meant this”, and the context fills with noise that makes the next answer worse.

# before (5th message in the same chat)
no, the other config, not that one, and keep the old flag

# after (new chat)
Goal: add --dry-run to deploy.sh.
Config: config/prod.yaml (not config/staging.yaml).
The existing --force flag must keep working.

5. Break it down when it doesn’t hold. Same blog: if the model can’t do the task, split it into smaller problems. The first step is a plan, not code.

# before
Migrate auth to the new session library, update tests and docs.

# after
Step 1 only: read src/auth/ and write PLAN.md:
which files change, in what order, what could break.
Don't edit code yet. I'll review the plan first.

How do you know the new version is actually better and doesn’t just look better? That’s part 3.

When it isn’t a prompt problem at all

Anthropic says this on the overview page: not every failing eval is fixed with a prompt, and sometimes latency and cost improve faster if you just switch models. Before touching the prompt at all, they ask for three things: a definition of success, a way to test it, and a first draft.

the.scapegoat.dev lists four reasons a model fails: you phrased it badly, the model really can’t do it, you got unlucky because the model is probabilistic, or something else broke, like a broken tool or a provider serving a quantized version. Only the first one is solved in the prompt. Rewriting the same instruction for the third time? Stop and check the other three.

My take: half the prompt engineering we see on teams is an attempt to solve in text something that should be a schema or a test. Prompts dozens of lines long begging “always return valid JSON”, when what’s missing is Structured Outputs and one line of validation. Every instruction that moves into code is an instruction the model can no longer forget.

What to try this week

• Take the last prompt that failed on you and write one line under it: “Done means…”. Nothing to write? You found the bug.
• Give a model Heap’s original request and ask it to come up with five questions before it writes any code. The answers to those questions are the prompt that was missing.
• In Claude Code: set up a status line that shows how much context you’ve burned, as Anthropic recommends, and run /clear between tasks.
• In OpenAI: if you’re asking for JSON in plain text, switch to Structured Outputs. And stop reading output[0].content[0].text. OpenAI says explicitly that it isn’t safe, because the output can contain tool calls and reasoning. Use output_text.

And if your prompt doesn’t hold up in a fresh chat, without all the history behind it, it isn’t a prompt. It’s a conversation.