The Great Prompting Illusion

For a while, prompt engineering looked like the defining skill of the new AI era. Whoever knew how to give a large language model the right instructions, assign it a suitable role, choose good examples and specify the output format got markedly better results. A small discipline grew around that ability, with prompt libraries, training courses and new job titles, and working well with AI came to mean, above all, writing particularly effective instructions.

That assumption is now under pressure from three directions. Research suggests that advanced models no longer benefit equally from the traditional techniques. Frameworks are emerging that optimise prompts automatically. And agents carry out complex workflows, call external systems and organise parts of their own execution. Together these developments raise an uncomfortable question: have we spent years trying to compensate with ever more sophisticated language for something that was always a problem of system architecture?

My argument in this post is that we have.

We have treated prompt engineering for too long as the solution to problems that are really problems of knowledge organisation, software architecture and institutional governance.

This does not mean that prompts will disappear. It means that their place in the larger system needs to be reconsidered.

What the research shows

In July 2026, ACM Transactions on Software Engineering and Methodology published a study by Wang and colleagues with the pointed title Do Advanced Language Models Eliminate the Need for Prompt Engineering in Software Engineering? The authors re-evaluated established prompting techniques on three software engineering tasks (code generation, code translation and code summarisation) using GPT-4o and the reasoning model o1. Their central finding is that techniques developed for earlier models “may provide diminished benefits or even hinder performance when applied to advanced models”, and that for reasoning models a simple zero-shot prompt is sometimes the more effective choice.

The study does not show that prompt engineering has become unnecessary in general. It covers particular models, three tasks and defined experimental conditions, and the preprint dates from November 2024, so the models it calls advanced are already a generation old. What it does show is a direction. As models become better at interpreting tasks, developing solutions and checking intermediate results, prescribing each step of their reasoning becomes less useful, while precise objectives, relevant information, verifiable requirements and meaningful feedback become more important. The guiding question shifts from how do I phrase the prompt so that the model gives the answer I want? to what information, tools, constraints and quality criteria does the system need to perform the task reliably? That is not the end of instruction, but a change in what instruction is for.

Prompts are being optimised by machines

A second indication comes from research on automatic prompt optimisation. In June 2026, researchers at Google and UCLA introduced APEX, a method that improves prompt optimisation by selecting the evaluation data dynamically. Across three benchmarks (IFBench, SimpleQA Verified and FACTS Grounding) and under a fixed budget of 5,000 evaluation calls, APEX outperformed the initial prompt by an average of 11.2 percent on Gemini 2.5 Flash and 6.8 percent on Gemma 3 27B. These are results for specific benchmarks and conditions, not a general performance gain for AI applications.

The broader implication is nevertheless significant. If a system can generate, compare and refine prompts on its own, the manual formulation of instructions becomes, at least in part, an automatable engineering task. Human expertise does not become superfluous, but it moves: developers and domain experts increasingly have to define what is to be optimised, how success is measured and which constraints must not be violated. An optimiser can improve performance against a given objective. It cannot establish whether that objective is appropriate, whether the assumptions behind it hold, or whether the resulting behaviour is institutionally legitimate. Every engineering discipline knows the underlying principle: optimising a single component is not the same as designing a reliable system. Automation does not remove the responsibility for specification; it makes specification more important.

From prompt engineering to context engineering

The major model providers have shifted their own perspective as well. In September 2025, Anthropic described context engineering as the natural progression of prompt engineering. The difference is more than a change of name. Prompt engineering is mainly concerned with how instructions are worded, whereas context engineering asks which information a model should receive, at which moment and in what form. A model in a real application never works from the user's prompt alone. Its behaviour is shaped by system instructions, retrieved documents, structured data, tools, conversation history, intermediate results and stored state, and together these make up its operational context.

The task is not simply to supply more information. Even very large context windows do not guarantee that everything in them is processed equally well, and excessive, contradictory, outdated or irrelevant context can degrade the result. Context engineering is therefore above all a matter of selection, structure and relevance: which information is necessary, which source is authoritative, which facts are current, which statements contradict each other, what the system may access and what has to be verified before it can be used. These are no longer linguistic questions. They are questions of information architecture.

Context engineering does not solve everything, though. Delivering the right information at the right moment does not ensure that its meaning, its relationships and the conditions under which it is valid are represented correctly. That leads to a dimension of AI engineering that is regularly underestimated.

The missing dimension: semantics

Language models are remarkably good at recognising linguistic patterns, identifying relationships and producing plausible interpretations. That does not mean they reliably grasp what a term means inside a particular organisation. Take customer. Depending on the application, a customer may be a natural person, a legal entity, a contractual counterparty, a beneficial owner or a member of a customer segment, and a sales application, a risk system and a regulatory report may all use the same word for different business objects. The same ambiguity surrounds product, responsibility, approval, risk, project and organisational unit.

A model may infer the intended meaning from context, and sometimes it will be right. Sometimes it will choose a reading that is linguistically plausible and institutionally wrong. A better prompt can reduce that risk, but it cannot remove the ambiguity if the organisation's own definitions are unclear.

This is where semantic models and ontologies come in. An ontology describes not only concepts but also their relationships, properties and, where appropriate, formal constraints. It can state, for example, which role may approve a particular category of transaction, under which conditions, and how that authority relates to other responsibilities. Knowledge of this kind can be modelled explicitly, versioned, validated and reused across applications, which is fundamentally different from explaining the same concepts in natural language prompt after prompt. An ontology does not make an AI system correct by itself: its definitions can be incomplete, outdated or wrong, and integrating it into an application takes careful design. Its value lies in making relevant organisational knowledge explicit, manageable and, at least in part, machine-checkable. Instead of explaining again and again what we mean, we can begin to model the meaning of our concepts systematically.

An example: when a prompt becomes an architecture

Consider an assistant in a bank that is meant to assess whether project proposals are ready for a portfolio decision. A prompt-centred approach might begin like this:

“You are an experienced project portfolio manager. Analyse the following project proposal. Evaluate its strategic relevance, risks, resource requirements and priority. Consider the applicable governance requirements and give a well-founded recommendation.”

Such a prompt can produce useful output, but it leaves the essential questions open. It does not say which strategic objectives currently apply, which risks matter for the decision, which resources are actually available, which projects compete for the same scarce capacity, who is entitled to approve a prioritisation, or what evidence must exist before a proposal counts as ready for decision. A model may make assumptions or point out gaps, but for an institutional decision process that is not enough.

An architecture-based approach starts elsewhere. First the relevant business concepts are defined: project, strategic objective, resource, constraint, dependency, risk, decision proposal, governance body and approval. Then their relationships are modelled explicitly. A project supports one or more strategic objectives, requires resources and may depend on other projects; a prioritisation decision belongs to a designated body and has to rest on defined information. These relationships can be represented in a semantic model, and the relevant sources are connected to it: the project portfolio, resource planning, risk registers, strategy documents and governance policies. The AI system can then retrieve information, assess proposals, identify missing evidence and prepare recommendations, while the authority to approve stays with the responsible body.

Technical controls can be added on top. The system can flag a proposal as incomplete when a required risk assessment is missing, check whether the claimed capacity actually exists, and refuse to record a decision as approved until an authorised person has completed the approval step. Here the distinction between probabilistic interpretation and deterministic enforcement becomes visible. The language model interprets unstructured documents, extracts information and drafts recommendations; mandatory authorisation checks, formal approvals and binding constraints are enforced by mechanisms outside the model.

The difference from the original prompt is substantial. Instead of expecting a single instruction to make up for missing institutional knowledge and governance, the language model becomes one component of a larger architecture in which information, rules, processes, permissions and responsibilities are managed explicitly and connected through controlled interfaces. This is where professional AI engineering begins.

Programming, not prompting

A particularly instructive approach is DSPy, a framework from Stanford NLP research whose motto is programming, not prompting. Instead of treating hand-crafted prompt text as the central development artefact, DSPy lets developers express a task as a modular program: they define inputs, expected outputs and processing modules, and optimisers then search for suitable instructions and examples against evaluation criteria. The prompt does not disappear, but its exact wording becomes the result of an optimisation rather than a fixed text written entirely by hand.

The point is not that language models can work without prompts. The point is that the specification of an application can be separated from some of the concrete wording that implements it, and that human effort shifts towards task definition, program structure, evaluation and optimisation targets. Software engineering has seen this before. Developers do not write every machine instruction by hand; they work at higher levels of abstraction through programming languages, compilers, libraries and frameworks. Something similar may be happening in AI engineering. Manual prompt work will not vanish, but it is likely to become one technique among several rather than the dominant way of controlling AI systems. The central competence moves from formulation to specification, and from individual instructions to system design.

Agents make architecture more important

The spread of AI agents gives this shift real consequences. A conventional chatbot mainly produces answers. An agent can also select tools, retrieve information, carry out tasks, interact with other applications and change operational systems, and that changes the risk profile fundamentally. When a model only drafts a text, a person can review it before anything happens. When an agent modifies records, triggers transactions or starts workflows, new questions arise: whether it was authorised to act, which information it used, which rules applied, what exactly happened, and how errors can be detected, explained, corrected or reversed.

OpenAI's A Practical Guide to Building Agents describes agents as systems built from models, tools and instructions, complemented by orchestration and guardrails. The broader lesson is that advanced AI applications increasingly require the engineering discipline we know from complex software systems.

It would be a mistake, however, to conclude that every application needs an elaborate multi-agent architecture. Anthropic's Building Effective Agents explicitly warns against unnecessary complexity, and for many applications a single model call, retrieval-augmented generation or a clearly structured workflow is entirely sufficient. That counterargument matters. The aim is not to replace prompt engineering with the most elaborate agent architecture available, but to choose the simplest architecture that meets the actual requirements. A summarisation task does not need an institutional ontology and a network of autonomous agents; a system that prepares consequential decisions or initiates operational actions may need considerably more structure and control. Professional engineering is not defined by maximum complexity, but by complexity that is justified, manageable and verifiable.

Governance cannot be prompted into existence

The limits of a prompt-centred approach are most visible in AI governance. An organisation might instruct its model: “Follow all internal policies, comply with applicable regulations, protect personal data and never perform unauthorised actions.” The intention is reasonable, but as a control mechanism on its own the instruction is insufficient. The model would have to know which policies apply, when and with what consequences, and, more importantly, the system itself has to prevent unauthorised actions through technical safeguards.

This is the fundamental difference between a behavioural instruction and enforceable governance. An instruction can describe expected behaviour; access control can prevent unauthorised access. A policy can state that a decision requires approval; a workflow can enforce that approval before the action is executed. A role description can explain responsibilities; an authorisation system can restrict operations accordingly. These mechanisms complement each other, but they are not interchangeable.

The security problems of language models sharpen the point. OWASP ranks prompt injection as the leading risk for LLM applications: attackers place malicious instructions in user input, retrieved documents or other external content, and a system that accepts them without separation and safeguards may produce misleading output or carry out unauthorised operations. Security therefore cannot rest solely on the model's ability to recognise and refuse such instructions. It also needs technical permission boundaries, controlled tool access, validation, monitoring and, where appropriate, human approval.

The NIST AI Risk Management Framework organises AI risk management around four functions, Govern, Map, Measure and Manage, and its broader perspective makes the same point: trustworthiness does not emerge from a well-crafted instruction but from systematic governance across the whole life cycle. Governance is then not a compliance step added downstream. It belongs in the design and development of the system itself.

From software architecture to institutional architecture

The argument can be taken one step further. When AI systems carry out tasks, use tools and prepare decisions on behalf of an organisation, it is not enough for them to work correctly in a technical sense. They also have to operate within the institutional structure of the organisation that deploys them. Organisations are not merely collections of data and processes; they consist of responsibilities, decision rights, hierarchies, roles, procedures, obligations and informal practices, and these structures determine which actions are legitimate in a given context. An AI system can produce a technically plausible recommendation and still act wrongly in institutional terms, for example by ignoring the authority of a governing body or by treating an advisory recommendation as a binding decision.

This creates an additional engineering task. We have to model not only what information exists and how concepts relate, but also which actors may perform which actions under which conditions. Business architecture, ontologies, process models, policy frameworks and governance models can address this task when they are combined well. Such an architecture can distinguish between a professional recommendation, a formally permissible decision and an action that is actually authorised. These distinctions are fundamental to institutions, and they are often missing from experimental AI applications.

I therefore propose an additional perspective, which I call Semantic & Institutional AI Engineering. I do not use the term for an established industry standard, but as a conceptual frame that connects three dimensions. The technical dimension covers models, interfaces, tools, data flows and execution mechanisms. The semantic dimension covers concepts, relationships, domain rules and conditions of validity. The institutional dimension covers responsibilities, decision rights, organisational authority, control obligations and legitimate actions. Only by combining all three can we build AI applications that are not merely functional but also governable by the organisation that runs them. This matters most for enterprises, financial institutions, public administrations and other organisations that operate in complex regulatory and institutional environments.

What good AI engineering requires

If these arguments hold, organisations will have to reconsider how they develop AI applications. The quality of an application should not be judged by whether a single prompt produces an impressive answer in a demonstration, but by whether the whole system works reliably under realistic operating conditions.

That begins with clear requirements: the application addresses a well-defined problem, and its performance is assessed against meaningful, verifiable criteria. It needs a reliable information base, which means identifying the relevant sources, assessing their quality and currency and enforcing access rights. For more complex use cases, domain concepts and their relationships may have to be modelled explicitly; ontologies can add considerable value there, although not every application needs one. Orchestration has to ensure that tools are used appropriately, dependencies are respected and failures are handled systematically. Evaluation has to test the system not only under normal conditions but also on edge cases, incomplete information, contradictory evidence and adversarial input. And responsibility for development, deployment, operation, monitoring and change has to be clearly assigned.

None of these requirements is new. Most have been central to software engineering and enterprise architecture for decades. What is new is their weight in systems whose behaviour is partly probabilistic and cannot always be specified the way conventional deterministic software can. That makes explicit architecture, systematic testing and effective governance more important, not less.

The competence that will matter

Is prompt engineering, then, still a professional skill with a future? That depends on what the term means. If it means giving AI systems clear objectives, providing relevant information and formulating sound requirements, it remains valuable. If it means mainly experimenting with ever more elaborate wording to steer model behaviour, it describes an activity that more capable models and automated optimisation are already transforming.

The more important competence, in my view, is the ability to design AI systems as integrated technical, semantic and institutional systems. That includes translating business problems into system requirements, structuring knowledge and connecting trustworthy sources, distinguishing between tasks that suit probabilistic models and those that require deterministic enforcement, and embedding institutional rules, responsibilities and controls in the architecture. This is not a rejection of generative AI. On the contrary: as models become more capable, the range of possible applications grows, and with it the importance of designing the conditions under which these systems operate.

The end of a shortcut

Perhaps we are not witnessing the end of prompt engineering, but the end of a shortcut. The hope that a sufficiently sophisticated prompt could make up for missing domain knowledge, unclear responsibilities, poor data and inadequate software architecture was always questionable. For simple applications it may be pragmatic and effective; for complex, business-critical systems embedded in institutions it is not enough.

The future does not lie in giving up the human ability to instruct AI. It lies in integrating that ability into a broader discipline of professional AI engineering, one that draws on software engineering, context engineering, knowledge modelling, business architecture, evaluation and AI governance, and that may have to treat institutional architecture itself as an explicit part of system design. The real problem is not that we are bad at prompting. It is that we are trying to replace missing architecture with language. The decisive question is no longer how to write a better prompt, but how to engineer a better system.

Sources

• Wang, G., Sun, Z., Ye, S., Gong, Z., Chen, Y., Zhao, Y., Liang, Q. and Hao, D. (2026). Do Advanced Language Models Eliminate the Need for Prompt Engineering in Software Engineering? ACM Transactions on Software Engineering and Methodology. Preprint: arXiv:2411.02093, November 2024.
• Wang, F., Si, S., Hsieh, C.-J. and Dhillon, I. S. (2026). APEX: Automated Prompt Engineering eXpert with Dynamic Data Selection. arXiv:2606.11459, 9 June 2026.
• Stanford NLP. DSPy: Programming, not prompting, language models.
• Anthropic (2025). Effective context engineering for AI agents. 29 September 2025.
• Anthropic (2024). Building effective agents.
• OpenAI (2025). A practical guide to building agents.
• OWASP (2025). LLM01:2025 Prompt Injection. OWASP Top 10 for LLM Applications.
• National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1.

This post combines published research and established engineering practice with my own conceptual interpretation. “Semantic & Institutional AI Engineering” in particular is proposed as a perspective, not presented as an established standard.

New posts by email: subscribe to the newsletter. One email per post, no tracking.