Prompt engineering is dead. What counts is the code that checks the model's answer.

Why the prompt does not solve the problem

Some job titles carry their own replacement in the name. The telephone operator. The typesetter. The webmaster. The prompt engineer is joining the list.

This is not a provocation. It follows from how the technology works.

A prompt is a text instruction to a language model. The model builds its answer from probabilities. The same instruction with the same input therefore does not always produce the same answer. For an experiment at your desk that is fine. In a business process that runs a few thousand times a month it is an operational risk. Every deviating answer is a case somebody has to check.

The companies that work with AI dependably do not optimise prompts. They build systems. They wrap the model’s answer in ordinary code that catches errors, checks results and only then triggers an action. The prompt is a detail in that, not the strategy.

This is the same step computing has taken with every new layer of abstraction. Nobody writes machine code by hand today. You build tools that take care of it. That is exactly what is happening to prompts right now.

What the history of programming says about this

In the 1950s programmers wrote machine code. Every instruction was written down as a sequence of numbers. Errors were hard to find.

In the 1960s assembly arrived. Short command words replaced the number sequences. The programmer still had to keep the hardware in mind.

In the 1970s and 80s came high-level languages such as C and Pascal. A translation program, the compiler, turned them into machine code. The programmer thought in logic, no longer in registers.

From the 1990s on, libraries and frameworks took over whole tasks. Nobody writes their own sorting algorithm today.

Prompt engineering is the assembly phase of AI. Developers write text instructions, test variations and collect examples that happen to work well. The human remains the translator between intention and execution.

Function calling, tool use and splitting work across several specialised agents are the compiler phase. The system translates an intention into a checked action. The human sets goals and limits.

The decisive point: assembly programmers did not become redundant because they were bad. A higher layer made their manual work unnecessary. The same is happening to polishing prompts.

How working with prompts changed in four phases

Phase 1, prompt templates (2022 to 2023): Companies discover that the wording of the instruction determines the quality of the answer. Collections of role prompts, format instructions and examples appear. The human is a prompt craftsman.

Phase 2, step-by-step reasoning (2023 to 2024): Researchers show that models deliver better results when asked to think in intermediate steps. Quality rises, the spread remains. The same instruction gives a different result tomorrow than today.

Phase 3, function calling (2024 to 2025): OpenAI, Anthropic and Google offer structured output formats. The model no longer answers with prose but with a record in a given format, something like “send an email to this address with this subject”. The prompt now steers actions, not texts.

Phase 4, several agents (2025 to 2026): Single model calls are replaced by systems of specialised agents. One agent distributes the task. One gathers data. One executes. One checks the result. The prompts are the internal connecting piece between these building blocks. Nobody outside the system sees them.

In phase 1 the prompt was the product. In phase 4 it is a detail generated by the architecture.

Where prompt-only systems fail in daily use

Imagine a prompt processing incoming invoices. Most of the time it reads the data correctly. Sometimes it invents an invoice number, mixes up gross and net or misses a line item. With a few hundred invoices a month that produces cases every month that somebody has to correct by hand. Each one delays a payment.

No prompt, however refined, solves this. The problem is not the wording but the missing check. What helps is a checking layer of ordinary code: it receives the model’s answer, checks structure and values and only writes something to the target system once every check has passed.

The pattern we work with in projects has four stages. The model reads out the data. A checking program verifies that all fields are present and have the right type. A rule set checks the values against the business rules. A confidence value decides whether the result continues automatically or a person looks at it. In projects we often see that only this setup turns an experiment into a process you can leave running. The model does not get better. The architecture compensates for its weakness.

Aspect	Prompt only	Prompt plus checking layer
Answer format	Requested in the prompt	Enforced by the interface
Error handling	In the prompt, such as “do not answer with”	In code, against schema and rules
Errors in operation	Show up only in spot checks	Caught or handed to a person
Model swap	Retest every prompt	Model interchangeable, checks stay
Traceability	Hard, the answer comes from the model	Every check is in the log

A typical case from credit assessment

A financial services firm handles a few thousand applications a month. The first approach is prompt-based: a model reads the application, assesses the risk and writes a recommendation as text. After a few weeks of fine-tuning the recommendation agrees with the analysts in most cases. That sounds good until you do the sums. A double-digit percentage of deviations across a few thousand applications means hundreds of cases every month that somebody has to re-check. The re-checking eats the savings.

The architectural approach looks different. The model only reads structured data out of the application: name, income, credit score, collateral. A fixed rule set assesses the risk against defined thresholds. A lookup system pulls comparable cases from the firm’s own history. A confidence value decides whether the case is decided automatically or goes to an analyst.

The effect: most applications go through without human involvement. The analysts only see the borderline cases. How large that share is depends on your starting point, on the quality of the applications and on how strictly you set the threshold.

The prompt in this system is trivial. It says, in essence: “Read the following fields out of the document.” No role description, no elaborate examples. The intelligence is not in the prompt. It is in the code that processes the answer.

What this means for cost and staffing

The prompt approach is faster to build. The architectural approach needs more development time up front because schema, rule set and thresholds have to be designed and tested. In return the ongoing effort for re-checking drops noticeably and the checking layer stays in place when you change the model.

That is exactly why job ads for prompt engineers miss the actual need. It resembles the social media managers of around 2012 who spent all day optimising posts. A few years later that was a basic skill of every marketing team and the dedicated role disappeared. Writing good prompts will become as ordinary in development teams as SQL or Git. Nobody hires a Git engineer.

What companies need instead: people who build checking layers and rule sets. People who run the infrastructure for agents. People who maintain the data behind lookup systems. None of these roles has prompt in the title.

The four layers of the checking layer

Layer 1, fixed answer format: The model is not asked for text but for data in a given format. Function calling and tool use enforce that through the interface. The error source “wrong format” disappears because the interface accepts nothing else.

Layer 2, check against a schema: Every answer is checked against a fixed description of the expected fields. If a required field is missing, it is rejected. If a field has the wrong type, it is rejected. If a number is outside the allowed range, it is rejected. This is not AI. It is ordinary code of the kind that has been written for decades.

Layer 3, business rules: Checked data runs through a rule set. Credit application above a set amount? Additional review. Invoice amount deviates too far from the contract amount? Forwarded. Customer status blocked? Rejected. These rules are business logic and do not change with the model.

Layer 4, confidence value and routing: A separate mechanism rates how certain the answer is. High certainty: execute automatically. Low certainty: a person decides. The threshold lives in the code, not in the prompt.

The model keeps making mistakes. The architecture catches them, the way a compiler catches typos before the program runs.

Why a fixed answer format makes prompt tricks unnecessary

The prompt approach for an invoice reads something like: “Read the amount, invoice number and due date from the following invoice. Answer exclusively as JSON with the keys amount, invoice_number and due_date. If a field is missing, set null. Do not invent values.”

That works most of the time. Sometimes the model still answers with prose, invents a number or writes “approx. 1,500 EUR” instead of a figure.

The fixed-format approach instead defines a function with typed fields: amount as a number, invoice number as text, due date as a date. The model has to answer in this format. The interface rejects everything else. The format errors are gone. The content errors are caught by layers 2 to 4.

That is the difference between a prototype and a system you can leave running.

What you can check now

First: Look at your existing AI processes. If one of them rests only on a well-worded prompt, without schema, without rule set, without a threshold for handing over to a person, then a prototype is running in production.

Second: Measure the actual error rate. Not the one from the demo but the one from live operation across many transactions. In projects we often see that nobody knows this number. That alone is a finding.

Third: Build the four layers. Fixed format, schema check, business rules, threshold. This setup is independent of the model. If a better one appears tomorrow, you swap it and the checks stay.

Fourth: Do not hire prompt engineers. Look for developers with experience handling language models who can build checking layers.

If you are unsure where your process sits between prototype and system, you can talk it through with us: Contact. Whether a rebuild pays off depends on your starting point and can only be answered on the concrete process.

Further reading: Death of Chatbots | The Firewall Is Me | Why Your Most Valuable Employee Is a Vector | Legacy Tax