Context engineering is requirements gathering wearing a new hat

There is a job posting doing the rounds for a Context Engineer. The responsibilities list is: gather the information a system needs to do a task correctly, structure it so it can be consumed, identify what is missing, and check the output against what was asked for.

That is a business analyst. That has been a business analyst since the 1980s.

My position is that this is good news, not an insult. Context engineering is requirements gathering, and the fact that it has an old name means we are not starting from zero. The mistake is not the rebrand. The mistake is what teams do with the rebrand, which is to hand the work to whoever is most comfortable with the tooling rather than to whoever is best at the actual skill, which is finding out what people meant.

The skill transfers almost completely

Everything a good analyst does maps onto this directly. Elicitation: asking the question behind the question, because the stakeholder who asks for a report usually wants a decision. Ambiguity hunting: noticing that “recent” appears in a requirement three times with three different meanings. Boundary work: establishing what is explicitly out of scope, which is the half of a specification that almost nobody writes down.

All of that transfers. So does the hardest part, which is knowing when a requirement is a genuine constraint and when it is one person’s preference that has been repeated until it acquired the texture of a rule.

What does not transfer is a single load-bearing assumption. The analyst was writing for a reader who shared the room. Underspecification was not laziness, it was correct economics: full precision is expensive, and a colleague with six months of context will ask when unsure. So you wrote “handle errors sensibly” and it worked, because the person reading it had watched last quarter’s incident.

Requirements gathering, as practised

• Happens in a phase, at the front
• Reader shares your context
• Gaps produce a question in Slack
• Output is prose, read once
• Cost paid per project

Context engineering, as needed

• Happens per ticket, continuously
• Reader has fluency and no stake
• Gaps produce a confident invention
• Output is consumed on every run
• Cost paid per unit of work

What actually changed is the failure mode

An underspecified requirement given to a person produces a question, or silence and a wrong build that someone notices in review because it looks odd.

An underspecified requirement given to an agent produces something internally coherent, well-structured, confident, and wrong against your repository. This is what the field has started calling context blindness: output that would be correct in some plausible codebase, referencing APIs that do not exist here and conventions we abandoned two years ago.

That is a different class of defect. It does not look like a mistake. It looks like a competent contribution from someone new, which is precisely the kind of contribution that gets waved through when a reviewer has eleven other things open.

The LinearB 2026 benchmarks give the shape of what that does downstream: agentic pull requests show 5.3 times longer pickup time, median review duration up 441.5 percent, and the share of PRs merged with zero review up 31.3 percent. Reviewers are not lazy. They are being handed a volume of plausible-looking work that the old review reflexes were never calibrated for.

The phase became a per-ticket cost, and that is the whole problem

Here is the part I think teams underestimate.

Requirements gathering was survivable as a discipline because you paid for it once. A project got an analysis phase, someone senior did the elicitation, and the output amortised across months of building.

Context work does not amortise like that. It is per unit of work. Every ticket needs the relevant slice of the system, the constraints that apply here, the conventions that govern this directory, the things that are deliberately not being changed. Some of that is reusable and can live in the repository. A meaningful amount is specific to the change.

So a discipline that used to be a phase you could resource is now a tax on every ticket. And taxes on every ticket get skipped under pressure, on the tickets that matter most, by the person with the least slack. That is not a character failing, it is what happens to any per-unit cost that has no visible per-unit benefit to the person paying it.

Reusable, put it in the repoConventions, architectural boundaries, the error-handling pattern, what the module is for

Reusable, put it in the ticket templateOut-of-scope defaults, the review bar, what "done" requires here

Not reusable, someone must write itWhich of three plausible interpretations of this request is the intended one

So hire for the old skill, not the new label

The practical consequence is that the person you want for this is not the person with the most prompt-craft. It is the person who reads a request and immediately asks the three questions nobody thought of. That is a specific, teachable, unglamorous skill, and there are people in your organisation who already have it, some of them with business analyst on an old CV.

What they need is not training in models. It is permission to spend the time, and a place to put the output where it will be read.

Where this breaks down

The label is doing real work and I am being dismissive. Calling it requirements gathering risks importing the whole apparatus that came with it: sign-off gates, a separate function, a template with fourteen mandatory fields. If the rebrand is what gets teams to do the work without dragging that in, the rebrand has earned its keep. I still think naming the lineage is worth more than the risk, but it is a real risk.

Some of it genuinely is new. Retrieval strategy, chunking, deciding what goes in a system prompt versus what gets fetched on demand, managing a token budget: none of that has an analogue in 1990s analysis. It is engineering, and calling the whole discipline requirements gathering understates that half.

Analysts have a bad track record. The profession’s reputation was earned partly through genuinely awful practice: documents nobody read, sign-off theatre, distance from the building. Pointing at that lineage approvingly invites people to reproduce its worst habits.

The per-ticket tax may be temporary. If tooling gets substantially better at assembling context from the repository itself, the manual portion shrinks, and I will have built an argument on a cost that is falling. My honest read is that the reusable part shrinks and the intent part does not, because no amount of retrieval tells you which of two reasonable readings the requester meant.

Not every ticket needs it. A copy change does not need a context pack. Applying this uniformly is how good practices become box-ticking, and the discrimination about where it pays is itself a skill.

The takeaway

Context engineering is requirements gathering with one assumption removed: that the reader shares your context and will ask when unsure. Everything else about the discipline survives, which means you do not need to invent it and you should not pretend it is new.

What changed is the economics. A cost that used to be paid once per project is now paid once per ticket, and the failure mode moved from an obvious wrong build to a plausible one.

If you take one thing into next week: take the last three tickets an agent got wrong and sort the missing information into the three rows above. If most of it was reusable, you have a repository problem, not a specification problem, and you have been paying per ticket for something you could have paid for once.