We Do Not Write Prompts Anymore, We Build Systems That Prompt Themselves

Two things happened in this industry in the same week.

On one side, the claim that "prompt engineering is dead" went viral. On the other, Anthropic published a twenty-seven minute workshop on how to write prompts for Claude. Same week, same industry, two exactly opposite messages.

That contradiction is not really a contradiction. Both are true, because they are talking about different layers. This article separates what is happening at which layer.

Quick Answer: Prompt engineering is not disappearing, it is changing layers. What died were the tricks: "you are an expert" role play, the "think step by step" formula, the tipping and threatening lines meant to manipulate the model. Those worked in 2023 because models were weak at following instructions. What did not die is the work itself: deciding what the model gets to see. The difference is that this decision is no longer made in a chat box, it is made in your codebase. System instructions, tool descriptions, which document loads when, and what checks the model's output. Today an agent's failure is almost never "the prompt was bad." It is "the context was wrong."

Table of Contents

• The viral claim and the quote nobody can verify
• The tricks that genuinely died
• The rising layer: context engineering
• How we do this ourselves
• What did not die
• Where you still write prompts by hand
• Glossary
• Frequently asked questions
• Checklist

The Viral Claim and the Quote Nobody Can Verify

The best known version of the claim circulating on social media is a line attributed to Andrew Ng: "prompting will die in six months, loops and graphs are what replace it."

We could not verify that quote. Trace the sentence and the only source you find is the post making the claim. What Ng actually wrote is different. In his own words, agentic workflows prompt the model multiple times; instead of taking the model's output directly, you run several turns so it can build step by step toward a better result. His documented position is not "prompting dies" but "more prompting, inside a loop."

We say this up front because in this field the distance between hype and data is wide. Attaching a striking quote to a real conference video has become an engagement format. Do not make an architecture decision on a sentence whose source cannot be traced.

There is still a real observation underneath the claim. The dosage is just exaggerated.

The Tricks That Genuinely Died

Many techniques that worked in 2023 are now either ineffective or harmful. These really did die, and if they are still sitting in your prompts you should clean them out.

The common thread: every one of these existed to compensate for a model weakness. Once the weakness closed, the compensation became redundant. Worse, some now actively hurt. Shout "NEVER do this" at a model that follows instructions well and it will take the rule too seriously, refusing things it should have done.

The Rising Layer: Context Engineering

This is where the work moved rather than vanished. The industry is settling on the name context engineering.

A simple ratio makes it concrete: while a multi-step agent runs, roughly five percent of what the model sees is the instruction you wrote. The other ninety-five percent is context. Retrieved documents, tool definitions, conversation history, the code the agent just read, the error output of the test it just ran. Designing that ninety-five percent is where the leverage sits today.

That is why, when an agent fails now, the problem is almost never "the prompt was written badly." The model saw the wrong thing, or did not see the thing it needed.

System instructions

These define who the model is, which rules it follows and what it must never do. This used to be the whole job. Now it is the starting point.

Tool descriptions

When you give an agent a tool, that tool's description field is a prompt. It is the thing that decides when the model calls the tool.

The most common bug in enterprise projects is contradictory tool descriptions. If one tool says "use this for customer data" and another says "use this for all data queries," the model cannot resolve the contradiction and picks at random. Tool descriptions need to be treated as first-class context, not as a field you fill in afterwards.

Progressive disclosure

Giving the model what it needs at the moment it needs it, instead of loading everything up front. Put twenty documents and fifty tools in context at once and you both raise cost and scatter the model's attention. The right approach is to fetch the relevant thing at the relevant time.

Loops and evaluation

Instead of expecting a correct answer in one shot, you build a loop where the model can check and correct its own output. Run the test and feed the error back, add a verifier step, score the result against a rubric. This is what Ng actually describes: reflection, tool use, planning and multi-agent collaboration.

How We Do This Ourselves

This section is not theory. In our own projects the prompts do not live in a chat box, they live in the repository.

Every project has a rules file at its root that loads automatically into every AI session working on that project. It contains writing rules, performance patterns, commit behavior, and which file to read when. One example:

## Git & Commit rules

**Commit target (MANDATORY):** when told "commit," commit to the
branch currently checked out. Do NOT open a new branch, do not
switch branches. If "commit" is said while on `main`, the commit
goes directly to `main`. This is a deliberate choice.

This rule OVERRIDES Claude Code's default behavior of
"open a branch first if this is the default branch."

The important part is the last line: we are deliberately overriding the model's default behavior. We do not retype this in a chat box every session. We wrote it once, it went into version control, and it applies to every session working in that repository. When the rule changes, a pull request opens and it gets discussed.

The same file holds a table saying which document to read for which task, and it explicitly says "these files do not load automatically, open them before you start." That is progressive disclosure in its simplest form. We do not bloat context up front, we fetch when needed.

The third example is tool descriptions. We run an MCP server on our site, and the description of every tool it exposes determines when a model calls it. We put this sentence in the server's introduction response:

This server is read-only: it cannot submit contact or quote
requests. To start an inquiry, direct the user to the contact
or quote page returned by get_company_info.

That is a prompt. But it does not live in a conversation, it lives inside the protocol and goes automatically to every agent that connects. We state the constraint to the agent at the protocol level.

What the three have in common: none of them is a one-off message. All of them are versioned, reused, reviewed infrastructure. That is where prompt engineering went.

What Did Not Die

Now the other side of the coin. Here is what the "prompting is dead" content skips.

Writing instructions is still writing. A system instruction is a prompt, and so is a tool description. The layer changed but the skill is the same: telling the model what you want without leaving ambiguity. A badly written tool description produces exactly the same outcome as a badly written prompt.

Anthropic published a prompting workshop the same week. If the people building the model are still teaching how to write prompts, "prompting is dead" is at minimum early.

As models improve, the cost of a prompt falls, not its value. Strong models make it easier to recover from a bad instruction. But the return on a good instruction did not disappear. If anything, when an agent runs many steps, ambiguity at the start compounds at every step.

Some tricks dying is not all of them dying. Role assignment died, describing the output format did not. "Think step by step" died, breaking a task into parts did not.

Where You Still Write Prompts by Hand

Talking about building systems does not mean everything becomes automatic. You still sit down and write a prompt in these situations:

• Exploration and prototyping. You do not build a system to find out whether an idea works. You try it.
• One-off tasks. Translating a text or tidying a list does not need infrastructure.
• Writing the system instruction itself. The thing that builds the system is also text, and somebody has to write it.
• Debugging. When an agent misbehaves, the only way to separate a context problem from an instruction problem is to try by hand.

So "we do not write prompts anymore" is not quite literally true. The accurate version: we are moving from writing one-off prompts to writing prompt systems that run again and again.

Glossary

• Prompt engineering: designing the input text to get the output you want from a model.
• Context engineering: designing everything the model sees: instructions, documents, tool definitions, history and tool output.
• System instruction: the persistent instruction given at the start that defines the model's role, rules and limits.
• Tool description: the text telling the model what a tool does and when to call it. Effectively a prompt.
• Progressive disclosure: fetching information when needed instead of loading all of it up front.
• Agent loop: a working pattern where the model produces output, evaluates it and retries with corrections.
• Reflection: the pattern where a model critiques and revises its own output.
• Eval: a repeatable test measuring whether a prompt or system change actually helped.
• Context bloat: unnecessary documents and tool definitions filling the context window and degrading performance.

Frequently Asked Questions

Is it still worth learning prompt engineering? Yes, but not as a standalone profession. The skill of telling a model clearly what you want is the same skill you use writing system instructions and tool descriptions. What changed is where it gets applied.

Is the prompt engineer title disappearing? As a separate title, largely yes. But the work is not disappearing, it is dissolving into software engineering. The person doing it today is usually the person building the system.

Should we clean up our old prompts? Yes. Role assignments, all-caps pressure and "think step by step" written for older models cause over-triggering and needless length on new ones. Remove them and measure.

What does a system that prompts itself actually mean? A setup where the context is assembled at runtime by the system itself. It decides which document to fetch, which tool to call and what to ask next. You write the rules behind those decisions rather than the individual messages.

Is this too heavy for a small team? No. In its simplest form it is a text file. Putting a rules file in the repository and taking your tool descriptions seriously are two steps that pay off regardless of team size.

Checklist

• Remove role assignment, threats and tipping lines from your prompts
• Reduce all-caps pressure; state the rule once, with its reason
• Drop "think step by step" on thinking models
• Move system instructions out of chat and into the repository
• Review your rules file like normal code, through a pull request
• Treat tool descriptions as first-class context and clear up contradictions
• Do not load everything up front; fetch when needed
• Measure before claiming a change helped
• On agent failures, look at context first, not the instruction
• Revisit your instructions whenever the model version changes

Closing

"Prompt engineering is dead" is an exaggerated version of a correct observation. What died were the tricks, and good riddance; most of them existed to paper over model weaknesses.

What did not die is the job of deciding what the model gets to see. That job grew and moved. It now lives in a rules file under version control, in a tool description, in an evaluation test, rather than in a chat box. The text you write is still text, but it no longer runs once and disappears. It runs again every session.

The practical advice is plain: clean out the old tricks, move your instructions into the repository, take your tool descriptions seriously, and do not claim a change worked without measuring it. We run AI architecture and integration work under our AI Solutions service and technical leadership under CTO as a Service. For the hidden cost of generating code with AI see our Knowledge Debt article, and for the role that does this work in the field see our Forward Deployed Engineer article.