A developer sits down to build a feature using an AI coding assistant. She types a clear, specific prompt. The model returns something plausible but off-target. She tries again, rephrases, gets closer. Third attempt, still not quite right. She eventually gets what she needs, but it took four rounds of back-and-forth that felt more like negotiating than building.
This is not a prompting problem. It is a systems problem. And it is where most practitioners are stuck right now.
The ability to type a coherent prompt is no longer a differentiator. It is the floor. The developers, analysts, and operators who are getting consistent output from AI systems are not just writing better prompts. They are working across four separate disciplines, most of which have nothing to do with the sentence they type into a chat box.
What the Stack Actually Contains
Simple chat prompting is now table-stakes literacy. Professional AI work runs on four distinct engineering disciplines.
The four disciplines are Prompt Craft, Context Engineering, Intent Engineering, and Specification Engineering. They operate at different layers, solve different problems, and require different skills. Most practitioners have partial fluency in the first and almost none in the other three.
Prompt Craft is the one everyone knows. It covers how to phrase a request, how to structure instructions, how to use few-shot examples, how to set tone and format. It matters. Done well, it reduces ambiguity and improves first-pass output. Done poorly, it creates noise. But Prompt Craft only controls what goes into a single exchange. It says nothing about what the model knows coming in.
Context Engineering controls that. It is the discipline of deciding what information a model has access to when it processes a request. This includes what you load into the context window, how you structure that content, what you leave out, and how you sequence it. A model asked to review a codebase has no useful context if it only sees one file. An agent asked to draft a client proposal needs background on the client, the engagement scope, and any prior decisions. Feeding that context well is not obvious work. Load too much and the model buries the signal in noise. Load too little and it fills in the gaps with whatever it can infer. The decisions are consequential and nontrivial.
Intent Engineering sits one layer above that. It covers the gap between what a user asks for and what they actually need. A product manager who asks an AI to "summarize last quarter's performance" might need a narrative for a board deck, a table for a budget conversation, or a set of flags for an ops review. All three are valid summaries. All three are different outputs. Intent Engineering is the discipline of surfacing that underlying need before any prompt is written. It often means asking better questions of yourself before you ask anything of the model.
Specification Engineering closes the stack. It is the discipline of turning intent into a precise, unambiguous instruction set that an AI system can execute without constant correction. This matters most in agentic workflows, where a model is not answering a question but completing a multi-step task with real-world outputs. Specification Engineering borrows from technical writing, systems design, and software requirements work. It requires knowing what constitutes a correct output, what edge cases matter, and how to describe both without writing a novel.
Where Things Break
Most practitioners operate exclusively in Prompt Craft and wonder why results are inconsistent. The answer is usually upstream.
Context problems are the most common failure. A model that produces a confidently wrong answer is often working from incomplete or poorly structured input. The user sees a bad output and blames the model or the prompt. The failure was upstream, in what got loaded and how.
Intent problems are subtler. They show up when output is technically competent but misses the point. The model did exactly what it was asked to do. The ask was wrong. That is the "garbage in, garbage out" problem restated for natural language: vague intent produces coherent-sounding output that does not serve the actual need.
Specification problems are the most expensive. In an agentic workflow, a poorly specified task can run for minutes or hours before producing output that is subtly wrong in ways that are hard to catch. An agent asked to "update the client records" with no specification of what "updated" means, which records, or what triggers a flag will make reasonable-looking decisions that do not match what the operator intended. Catching that downstream is expensive.
The Tradeoffs in Building This Stack
Treating these as four separate disciplines means accepting four separate learning curves.
Prompt Craft is learnable quickly. Most professionals can reach functional competence in days through deliberate practice. The ceiling is lower than people assume, though. Beyond a certain point, better prompts cannot compensate for bad context or unclear intent.
Context Engineering takes longer because it requires understanding how models actually process information. Token limits, retrieval patterns, chunking strategy, and context window placement all affect output in ways that are not intuitive until you have seen them fail in practice. A developer building RAG systems will pick this up faster than a non-technical operator, but the concepts are accessible. The investment pays off quickly in more consistent results.
Intent Engineering is the hardest to teach because it requires meta-cognitive work that most knowledge workers have never made explicit. The skill is not technical. It is the ability to step back from a task and ask: "What does a good outcome actually look like here?" That sounds simple. In practice, under time pressure, with a capable-looking AI system waiting for input, most people skip it.
Specification Engineering requires the most time to develop because it draws on skills from adjacent disciplines. Technical writers, product managers, and systems engineers have most of what they need. Others will find it unfamiliar. The payoff is proportional: agentic workflows with tight specifications produce reliable, repeatable outputs. Loose specifications require constant supervision and correction, which eliminates most of the efficiency gain that made the workflow worth building.
What to Actually Do
Pick the layer where you are losing the most work and fix that first.
If your outputs are inconsistent despite clear prompts, audit your context. What does the model actually have access to when you send that request? Is it the right information? Is it structured in a way the model can work with? Start there.
If your outputs are technically correct but miss the point, work on intent before you work on prompts. Write down what a successful output looks like before you type anything. Be specific about format, audience, and purpose. That five minutes of upfront work saves more time than any prompt optimization.
If you are building agentic workflows and they require constant correction, treat them as specification problems. Write the task as if you were handing it to a contractor who will not ask clarifying questions. Define what done looks like. Define what partial completion looks like. Define the edge cases you care about.
If you are training a team, do not teach prompting in isolation. Prompting without context, intent, or specification is a partial skill set. It produces practitioners who can get decent answers from a chat interface but cannot build reliable AI workflows. That gap will grow, not close, as AI moves from assistive to autonomous.
The full stack is four layers deep. Most people are working at one. That is where the leverage is, and right now almost nobody is competing for it.