Prompt Engineering Is Dead. Context Engineering Is the Job Now.

I keep a folder of old prompts. Not for nostalgia. I kept them because for about two years they were the most valuable text I owned, and at some point in early 2026 I opened the folder, read three of them, and realized I had not used any of them in months.

One of them was a 400-word instruction I had tuned obsessively through the back half of 2024. It told a model how to summarize a multi-file code diff. It had a worked example, a list of seven things to never do, a phrase I had tested against four alternatives because that exact phrase produced cleaner output, and a closing line in capital letters that I genuinely believed was load-bearing. I had treated that prompt like a precision instrument. I had been a little proud of it.

The moment that ended it was unremarkable. I was wiring up a new agent, I needed diff summaries, and I did not want to dig the old prompt out of the folder. So I typed one plain sentence: summarize what changed in this diff and why it changed. No example, no list of forbidden behaviors, no capital letters. The model did the plain thing. It did it as well as the 400-word version. It did it better in one respect, because the old prompt’s seventh forbidden behavior had been overcorrecting and clipping detail the new model kept. The instrument I had tuned for a year had been replaced by a sentence, and the sentence won.

That is a small story, and I am not telling it to mourn a prompt. I am telling it because that small story is the whole industry right now. The craft we spent two years building, the craft with conference talks and six-figure job titles and a small library of folklore, quietly stopped being the bottleneck. The work did not disappear. It moved. And almost nobody renamed their job to match where it went.

What prompt engineering used to be

I want to describe the magic-words era honestly, because it is easy to be smug about it in hindsight and the smugness is not earned. Prompt engineering was real work, and for a while it was the highest-leverage work you could do with a language model.

The early instruction-tuned models were genuinely fragile. They followed instructions, but unevenly. They would honor a constraint phrased one way and ignore the same constraint phrased another way. They would obey “do not include a preamble” and ignore “respond with only the answer,” or the reverse, and which one worked depended on the model, the temperature, and the phase of the moon. So you learned the folklore. You learned that “think step by step” measurably improved reasoning. You learned that giving the model a role, you are a senior engineer, you are a careful editor, shifted output quality in a direction you wanted. You learned that examples in the prompt, few-shot, often beat any amount of description. You learned that the order of your instructions mattered, that the model weighted the end of the prompt more heavily, that a constraint buried in the middle of a long instruction would get dropped.

None of that was superstition. It was empirical. People ran the comparisons, posted the results, and the good findings replicated. Chain-of-thought prompting was a real discovery with a real paper behind it. The craft had genuine technique inside the folklore, and the people who got good at it produced measurably better output than the people who did not.

The market believed it too, which is the clearest sign of how seriously the craft was taken. For a stretch of 2023 and 2024, “prompt engineer” was a job title with a salary attached, sometimes a startling one. There were prompt marketplaces where people sold individual prompts for a few dollars each. There were courses, certifications, and a small shelf of books promising to teach the magic phrasing. There were leaked system prompts traded like sports cards, dissected line by line for the trick that made a particular product work. I am not mocking any of it. It was a rational response to a real situation: the wording genuinely mattered, the good wording was genuinely hard to find, and a thing that is valuable and scarce gets a price. The prompt economy existed because the prompt was, for a brief window, the highest-leverage artifact in the whole stack.

What that economy quietly assumed was permanence. A prompt marketplace only makes sense if a good prompt holds its value, the way a good piece of code holds its value. But a prompt’s value was never intrinsic. It was entirely a function of a model weakness, and it was denominated in that weakness. When the weakness shrank, every prompt in every marketplace lost value at the same time, for the same reason, and no amount of craftsmanship in the prompt itself could stop it. You cannot build a durable asset on top of a temporary deficiency. The prompt engineers who lasted were the ones who understood, even then, that they were not really selling sentences. They were selling an understanding of how models behave, and that understanding is the part that survived.

But look closely at what that craft actually was, because the shape of it explains why it died. Prompt engineering optimized the wording of a fixed instruction. The input was a task, the output was a sentence or a paragraph, and the skill was finding the phrasing of that paragraph that the model responded to best. It was a sentence-level craft. The unit of work was the clause. And the entire reason the craft had value was that the models were bad at the one thing the craft compensated for: reliably doing what you plainly asked.

That last point is the one that matters. Prompt engineering was never really a discipline of its own. It was a workaround. It was the scar tissue that formed around a specific model weakness. And scar tissue has a short shelf life once the wound heals.

Why prompt engineering stopped being the bottleneck

The wound healed. Quietly, across 2024 and 2025, instruction-following stopped being the thing models were bad at.

You can watch it happen in the post-training. Every frontier lab poured enormous effort into instruction tuning and preference optimization, and instruction-following was the headline target. Each model generation followed plainer instructions more reliably than the last. The capital letters stopped mattering. The role-play preamble stopped mattering, because the model already behaved like a careful engineer when you asked it to do careful engineering work. The seven-item list of forbidden behaviors stopped mattering, because the model stopped doing five of the seven things unprompted. The marginal return on a cleverly worded prompt fell, generation over generation, until it rounded to zero for most ordinary tasks.

LangChain put the mechanism plainly in their writing on context engineering. A model produces a bad output for one of two reasons: the model was not capable enough, or the model was not given the right context to succeed. And then the line that matters: as the models get better, the first reason gets rarer, so the second reason accounts for more and more of what goes wrong. Capability stopped being the constraint. What you fed the model became the constraint.

This is not a claim that models became perfect. They did not. They still fail. The point is narrower and more specific: they stopped failing at the thing prompt engineering existed to fix. When a model failed in 2023, a reasonable first guess was that you had worded the prompt badly, and re-rolling the phrasing was often the cheapest fix. When a model fails in 2026, wording the prompt differently is almost never the fix. The model understood you fine. It failed because it did not have the right information in front of it, or it had the right information buried under the wrong information, or it had so much information that it lost the thread. Those are not wording problems. You cannot phrase your way out of them.

So the craft did not so much die as get its foundation removed. Prompt engineering was a high-skill response to model fragility. The fragility went away. The skill had nowhere to stand.

What context engineering actually is

The replacement already has a name, and the name arrived almost exactly when the shift became undeniable.

In June 2025, two people put the term into wide circulation within about two weeks of each other. Shopify’s CEO Tobi Lütke posted that he liked “context engineering” over “prompt engineering” because it described the core skill better: the art of providing all the context for a task to be plausibly solvable by the model. A few days later Andrej Karpathy endorsed it directly, and his framing is the one that stuck. People associate prompts with the short task descriptions you type in day-to-day use, he wrote, but in every industrial-strength LLM application, context engineering is the delicate art and science of filling the context window with just the right information for the next step. The term was not invented from nothing; practitioners had been circling the idea for a while. But mid-2025 is when it got a name the whole field agreed to use.

Here is the definition, stated plainly so it can be quoted on its own. Context engineering is the practice of designing what goes into a model’s context window for a given task: which documents are retrieved, which memory is carried forward, how tool results are formatted, in what order everything is arranged, and what gets dropped when space runs short. It treats the context window as a system to be engineered, not a text box to be filled.

That last contrast is the entire shift in one sentence. Prompt engineering treated the context window as a text box. You stood in front of the box and you wrote the best sentence you could write. Context engineering treats the same window as the output of a system: a pipeline of retrieval, memory, formatting, ordering, and pruning decisions, every one of which you control, every one of which changes the result. The prompt is still in there. It is now one component among five, and usually not the one that decides whether the task succeeds.

Anthropic, in their guide on context engineering for agents, frames it as the natural progression of prompt engineering rather than its rejection, and that framing is fair. The question changed shape. Prompt engineering asked: what words should I use. Context engineering asks: what configuration of context is most likely to produce the behavior I need. The first question has a sentence for an answer. The second question has an architecture for an answer. That is the promotion. The job went from writing a sentence to designing a system, and the people who only learned to write the sentence got left holding a skill the models had absorbed.

The five jobs of context engineering

If context engineering is a system, it helps to name its parts. The window in front of the model on any given step is assembled by five separate jobs, and each one is a place real engineering work now lives. I will name them and number them, because the whole point is that this is a discipline with components, not a vague vibe.

Job one is Retrieval. Deciding which external information enters the window, and how it gets selected. This is the job everyone already half-knows under the name RAG, but retrieval is broader than a vector search over a document store. It is every decision about pulling in information the model does not already have: which knowledge-base chunks, which past conversations, which files from a repository, which rows from a database. The hard part is not the fetching. The hard part is precision. Retrieve too little and the model is missing what it needs. Retrieve too much and you have buried the signal, which, as the next section will show, is its own failure mode. Retrieval is a selection problem wearing a search problem’s clothes.

Job two is Memory. Deciding what persists across steps and sessions, and in what compressed form. An agent that runs for an hour cannot carry its entire history forward; the history is too big and most of it is noise. So you decide what to remember. You decide that the user’s stated goal persists verbatim, that the architectural decision made in step four persists, that the 200 lines of tool output from step nine get summarized down to the one fact that mattered. Memory is the difference between an agent that knows what it is doing and an agent that re-derives its situation from scratch every few steps, badly.

Job three is Tool-result formatting. Deciding how the output of a tool call enters the window. When an agent calls a tool, an API, a search, a database query, the raw result is rarely in a shape the model uses well. A database returns 500 rows; the model needs four of them and a count. An API returns a deeply nested JSON blob; the model needs three fields. A file read returns 2,000 lines; the model needs the function it asked about. Tool-result formatting is the job of turning raw tool output into the smallest high-signal representation that still answers the question. Skip this job and your context window fills with machine exhaust.

Job four is Ordering. Deciding the sequence in which information sits in the window. This is the job that sounds least like engineering and is, in the research, one of the most consequential. Models do not weight their context uniformly. Where a fact sits changes how well the model uses it. Ordering is the deliberate placement of the most important information where the model actually attends to it, and the deliberate avoidance of burying a critical instruction in a low-attention zone. The next section is entirely about why this job is real.

Job five is Compaction. Deciding what to drop, and when. Context windows are finite, and long-running agents will exceed them. Compaction is the job of compressing the window when it fills: summarizing the history so far, preserving the decisions and the open threads, discarding the redundant tool output and the dead ends. Anthropic describes their compaction approach as passing the message history back through the model to summarize it, preserving architectural decisions and unresolved bugs while discarding redundant tool results, then continuing with that summary plus the few most recently touched files. They name the hard part exactly right: the art is in the selection of what to keep versus what to discard, because aggressive compaction loses subtle context whose importance only becomes clear later. Compaction is lossy by definition. Doing it well is engineering.

Why does ordering and selection beat wording?

I called ordering a real job and promised evidence. Here it is, and it is the part of this argument that the research settles rather than my opinion.

Start with the finding that named the problem. In 2023, Nelson Liu and colleagues at Stanford published “Lost in the Middle: How Language Models Use Long Contexts”, later published in the Transactions of the Association for Computational Linguistics. They ran a clean experiment. They gave models a question and a set of documents, exactly one of which contained the answer, and they moved that answer document around. When the answer sat at the start of the context or the end of it, the model found it. When the same answer sat in the middle, accuracy fell off a cliff. On a 20-document multi-document question-answering task, moving the answer from the first position to the tenth dropped accuracy by more than 30 percentage points. Same model. Same question. Same answer. Same words. The only thing that changed was where the answer sat in the window, and the result changed by a third.

Sit with that for a second, because it is the cleanest possible proof of the thesis. You cannot word your way out of lost-in-the-middle. The instruction was identical in every run. The model’s capability was identical. The only variable was an ordering decision, a context-engineering decision, and it was worth thirty points of accuracy. No prompt phrasing in the history of the craft ever bought you thirty points for free.

Then the problem got worse, or rather, got better understood. In July 2025 the team at Chroma published “Context Rot: How Increasing Input Tokens Impacts LLM Performance”. They tested 18 frontier models, the current generation, GPT-4.1, Claude Opus 4, Gemini 2.5, the models that were supposed to have long context solved. Every one of them degraded as input length grew. Not at the context limit. Well before it. Adding tokens to a window that was nowhere near full still made the model perform worse, and it did so non-uniformly, in ways that were hard to predict from the outside.

Context rot has three compounding mechanisms, and all three are context-engineering problems by their nature. The first is lost-in-the-middle, the positional effect already described. The second is attention dilution: transformer attention is quadratic, so every token you add competes with every other token for the model’s finite attention budget, and a window stuffed with marginal information dilutes the model’s focus on the information that mattered. The third is distractor interference, and this one is the quiet killer. Content that is semantically similar to what you need, but not actually what you need, does not just take up space. It actively misleads the model. A retrieval step that pulls eight nearly-relevant documents to surface the one relevant one has not helped the model. It has handed the model seven high-quality distractors.

It is worth making distractor interference concrete, because it is the least intuitive of the three and the one that breaks the most retrieval systems. Imagine a support agent answering a question about a refund policy. The retrieval layer searches the knowledge base and, tuned for recall, pulls the eight most similar passages. One is the current refund policy. The other seven are: last year’s refund policy, the refund policy for a different region, an internal note about refund exceptions, a marketing page that mentions refunds, and so on. Every one of those seven is semantically close to the query, which is exactly why the search returned them, and every one of them is wrong for this question. The model now has to not just find the right passage but actively resist seven plausible, on-topic, incorrect ones. A retrieval step that felt successful, it found the answer, after all, has handed the model a harder problem than it would have had with two well-chosen passages. The Chroma study measured this directly: as the similarity between the distractors and the real target rose, performance fell faster with length. The near-misses hurt more than the obvious junk, because the near-misses are the ones the model cannot dismiss.

Put the three mechanisms together and the conclusion is not subtle. More context is not better. The naive instinct, the model is struggling, give it more information, is often exactly wrong, because the additional information dilutes attention and adds distractors faster than it adds signal. The skill is not maximizing what the model sees. The skill is curating what the model sees: the smallest set of high-signal tokens that makes the task solvable, arranged so the model attends to the parts that matter. That is selection and ordering. Those are jobs one and four. They are worth more, measurably, than any wording of job five.

This is also why prompt engineering could not have survived as the central craft even if the models had stayed fragile. Prompt engineering operates on one component of the window. Lost-in-the-middle and context rot are properties of the whole window. A craft scoped to a sentence was never going to fix a problem that lives at the level of the system.

What this means for how you build

If you build with language models, the practical consequence is a reallocation of where your effort goes, and it is a large reallocation.

The old effort budget went mostly to the prompt. You spent your time tuning instructions, testing phrasings, collecting few-shot examples, maintaining a library of prompts that worked. That was the high-leverage work, so that is where the hours went. If you are still spending your hours there, you are polishing the one component that the model improvements already handled, and you are probably not touching the four components that now decide whether your system works.

The new effort budget goes to the pipeline. It goes to your retrieval layer: is it precise, or is it dumping ten chunks where two would do, and have you measured the difference. It goes to your memory design: what does your agent carry forward, in what compressed form, and have you ever actually inspected the carried-forward context to see if it still makes sense ten steps in. It goes to tool-result formatting: when your agent calls a tool, does the raw result hit the window, or does something shape it down to the part the model needs first. It goes to ordering: do you know where in your assembled context the critical instruction sits, and is that a place the model attends to, or is it stranded in the middle. It goes to compaction: when a long run fills the window, what gets dropped, and did you choose, or did a default truncation choose for you.

Notice what kind of work that is. None of it is wordsmithing. All of it is systems work: data pipelines, state management, output formatting, measurement. It looks like ordinary software engineering, because it is ordinary software engineering, applied to the specific problem of what a model sees. The most useful instinct you can carry into 2026 is to stop treating a bad model output as a prompting failure and start treating it as a context-assembly failure. Ask what was in the window, not how the sentence was phrased. The answer is almost always in the window.

This reallocation has a cost, and it is worth naming so it does not surprise you. Building a real retrieval layer, a real memory design, a real compaction step is more work than tuning a prompt. A prompt you could iterate on in an afternoon. A context pipeline is infrastructure, and infrastructure takes longer to build than it takes to wish for. So the honest version of this advice is that moving from prompt engineering to context engineering will, for a while, feel slower. You are trading a fast, shallow lever for a slow, deep one. That is the same shape as the productivity dip I described in the automation paradox: the investment front-loads, the payoff arrives later, and the teams that panic during the slow part never reach the fast part. The context-engineering payoff is real. It just does not arrive on the same afternoon you started.

There is a debugging payoff to this shift that is easy to miss. When prompt wording was the suspected cause, debugging meant re-rolling phrasings, which is guesswork with extra steps. When context assembly is the suspected cause, debugging means inspecting the actual window: what got retrieved, what got remembered, what the tool returned, in what order it all landed. That is something you can look at. It is concrete. A context-engineering failure has a crime scene. A prompt-engineering failure had a hunch.

Why context engineering matters most for agents

Everything so far applies to a single model call. With agents, the stakes multiply, because an agent is not one call. It is a long chain of calls, and every link in the chain inherits and mutates the context window.

Picture a coding agent on a routine task: read an issue, find the relevant files, make a change, run the tests, fix what broke. That is maybe forty model calls. Watch what happens to the context window across those forty calls if nobody is engineering it. Call one is clean: the issue, a system prompt, room to think. By call eight, the window holds three full file reads, two of them 1,500 lines long, most of which the agent glanced at once and never needed again. By call twenty, it holds the raw output of six tool calls, a failed test run printed in full, and a sub-task summary that was itself getting long. By call thirty-five, the original issue, the actual goal, is a small block of text sitting in the deep middle of a window stuffed with machine exhaust. Lost-in-the-middle is no longer a paper. It is the agent forgetting what it was asked to do, on call thirty-five, because the request is now buried exactly where the research said it would be ignored.

This is the agent failure mode that gets misdiagnosed constantly. The agent drifts, loops, redoes work it already did, or quietly abandons a constraint from the original instruction, and the instinct is to blame the model’s reasoning or rewrite the system prompt. Neither is the cause. The cause is that the context window degraded across the run, and nobody engineered it to degrade gracefully. The model did not get worse between call one and call thirty-five. Its working memory got worse, because the working memory was an unmanaged pile.

Anthropic, in their writing on context engineering for agents, frames the core principle as treating context as a finite resource with a real attention budget, and finding the smallest set of high-signal tokens that maximizes the chance of the outcome you want, at every step. For a single call, you can sometimes get away with ignoring that principle, because a single clean window forgives a lot. For an agent, you cannot get away with ignoring it for even a few steps, because the window is cumulative and the noise compounds. Every job from the five, retrieval, memory, tool-result formatting, ordering, compaction, runs not once but on every step of the loop. An agent is context engineering applied forty times in a row, and the quality of the agent is mostly the quality of that applied forty times. This is also why memory and the economics of carrying context forward deserve their own treatment, which Govyn covers in detail in the real cost of AI agent memory; the short version is that context is not free, and an agent that hoards it pays twice, once in money and once in lost-in-the-middle.

There is a connection here to a failure pattern I have written about before. In why your multi-agent AI system keeps failing, the research showed that most multi-agent breakdowns trace to coordination, specifically to the handoff between agents, where one agent’s output becomes another agent’s input. That handoff is a context-engineering problem in disguise. What an agent passes to the next agent is a context-assembly decision: how much of its work to include, in what form, in what order. A structured, curated handoff is good context engineering. A raw transcript dumped between agents is bad context engineering, and it is the exact mechanism behind a large share of multi-agent failures. The discipline does not stop at the boundary of a single agent. It is the connective tissue of the whole system.

What I am still wrong about

I have written 3,000 words declaring a craft dead, so let me be honest about where the obituary is too aggressive. A method you cannot poke holes in is a method you have not understood.

Prompt craft is not 100% dead, and the title is a deliberate overstatement of a true thing. There is a residue of genuine prompt-level skill that the model improvements did not absorb, and in specific places it still earns its keep. Output formatting is one: getting a model to produce a precise structure, a strict JSON schema, a particular report layout, still benefits from careful instruction and a worked example. The model will follow a plain instruction, but the edges of a complex format are still a place where wording moves the result. Eval rubrics are another: when you are writing the instruction that a judge model uses to grade outputs, the phrasing of that rubric materially changes the grading, and that is prompt engineering by any honest definition. I have written separately about why I run my own eval suite, and the judge rubrics in that suite are the one place I still tune wording the old, obsessive way.

There are whole domains where the residue is thicker. Jailbreak research and red-teaming are adversarial wording games at their core; that craft is alive and will stay alive. Working with smaller or older models, the ones running on-device or on a tight budget, still rewards prompt-level care, because those models retain the fragility the frontier models shed. If your model is small, prompt engineering is not dead for you yet. The death I am describing is a frontier phenomenon, and the frontier is not the whole world.

And the boundary between the two crafts is genuinely blurry. Is a system prompt prompt engineering or context engineering. It is a prompt, so the first. It is a persistent piece of curated context that you decide the shape and placement of, so the second. The honest answer is that context engineering absorbed prompt engineering rather than replacing it; the prompt became one managed component of a larger system, and “prompt engineering is dead” really means “prompt engineering stopped being the whole job and became a sub-task of a bigger one.” That is less punchy than the title. It is also more accurate, and you should hold the title and this paragraph in mind together.

What I am most uncertain about is the timeline of the next shift. Context engineering is hard right now partly because the model has no good way to manage its own context, so a human engineer has to. It is plausible that within a generation or two, models get materially better at managing their own context windows: deciding what to retrieve, what to forget, what to compress, on their own. If that happens, context engineering follows prompt engineering toward the same quiet sunset, and some third discipline gets a name. I do not think we are close to that. But I did not think the prompt folder would go stale either, and it did. The only safe prediction is that the bottleneck moves again, and the job is to keep noticing where it went.

How to retrain yourself for context engineering

If you spent the last two years getting good at prompts, none of that learning was wasted; you learned how models behave, and that knowledge transfers. But the daily practice has to change. Here is the retraining, as concrete as I can make it.

1. Inspect the window before you touch the prompt. The next time a model gives you a bad output, do not re-roll the wording. Find a way to see the exact, fully-assembled context that went into the model on that call, every token of it. Most of the time the failure is visible right there: a missing document, a stale memory, a tool result that buried the answer. You cannot engineer a window you have never looked at, and most people have never looked at theirs.

2. Measure your retrieval precision, not just its recall. Recall asks whether the needed information made it into the window. Precision asks how much junk came with it. Most retrieval setups are tuned for recall and never measured for precision, which is how windows fill with distractors. Pull the documents your system retrieved for ten real queries and count, by hand, how many were actually used. The number is usually worse than you hoped, and it is the highest-value thing you can fix.

3. Treat tool output as raw material, not as finished context. Audit every tool your agent can call. For each one, look at the raw result and ask what fraction of it the model actually needs. Where the answer is “a small fraction,” put a formatting step between the tool and the window. Raw tool output flowing straight into context is the most common unforced error I see.

4. Design your compaction deliberately, before you need it. Do not let a default truncation decide what your long-running agent forgets. Decide it yourself: write down what must survive a compaction, the goal, the key decisions, the open threads, and what is safe to discard, the redundant tool output, the dead ends. Then tune the compaction step against real traces, maximizing recall first, then trimming for precision, the way Anthropic describes.

5. Order with attention in mind. Stop thinking of the window as an unordered bag. Place the most important instructions and the most relevant retrieved information where the model attends best, near the start and the end, and treat the middle as the low-attention zone it has been measured to be. This costs nothing and the lost-in-the-middle research says it is worth real accuracy.

6. Build the smallest window that works, then add only what you can justify. Default to less context, not more. Start each task with the minimum you believe the model needs, watch it fail, and add information one piece at a time, only when you can name what the missing piece was. This is the opposite of the maximalist instinct, and context rot is the research that says the maximalist instinct is wrong.

7. Learn the adjacent systems skills. Context engineering is a data-pipeline discipline. If retrieval, embeddings, state management, and output schema design are not things you are comfortable with, those are now core to working with models, not optional extras. The most useful course of study for an AI engineer in 2026 is not a prompt-pattern catalog. It is the boring, durable craft of moving the right data to the right place.

The job did not get smaller

I started by mourning a folder of old prompts, so let me end somewhere honest about what actually happened to that folder.

Nothing in it was wasted. Every hour I spent learning how models respond to instructions taught me how models think, and that knowledge is exactly what makes the new work tractable. The folder did not become worthless. It became a relic of the first stage of a discipline that grew up. The craft did not die. It got promoted, from the sentence to the system, from a workaround for fragile models to a real engineering discipline with five named jobs and a research literature telling you which ones matter most.

That promotion is good news, even if it stung the people who only learned the sentence. A field where the bottleneck is clever wording is a field built on folklore, and folklore does not compound. A field where the bottleneck is retrieval precision and memory design and compaction strategy is a field built on engineering, and engineering compounds. The work got harder. It also got more honest, more measurable, and more worth doing. The job did not get smaller when prompt engineering died. It got larger, and it got a better name.

So open your own folder. Read three old prompts. Notice that the model does the plain thing now without them. Then go look at what is actually in your context window, because that is where the next two years of the work is, and it has been waiting for you to stop polishing the sentence and start engineering the system.