4/6 · The responsibilities around context engineering

The shift	Prompt engineer was wave one. Context engineer is the role this series describes
The cluster	Overlapping responsibilities around production agents; titles are not standardized
Harness engineer	Fights AI entropy: code that looks fine per file but drifts as a system
Spec engineer	Makes requirements explicit and reviewable; a spec does not guarantee correct implementation
Agent identity architect	Owns scoped authentication, permissions and credential isolation
AI eval engineer	Builds structured evaluations and calibrates human and automated judgment

The first three parts of this series covered the work: why context degrades, how to keep a configuration honest, and which tools cut the cost. This one covers the people, and specifically context engineering jobs: new labels overlap with responsibilities that already existed in engineering teams. If you want the hands-on execution side of what these roles actually do day to day, the L0-to-L5 playbook is the practitioner’s version of this same shift.

The useful starting point is the work behind the title: someone designs the information and tools a model receives, then checks how that setup behaves. The guide keeps related responsibilities and skills at cc.bruniaux.com/roles. This article maps that work; it does not measure hiring volume, salary distributions or the growth of individual job titles.

The more interesting story is the cluster of roles that formed around it.

---

From prompt engineer to context engineer

Andrej Karpathy coined “vibe coding” in early 2025, then got behind a more precise frame for the serious version of the work: context engineering, a term Tobi Lütke had just put into circulation. Philipp Schmid at Google put it cleanly: context engineering is providing the right information and tools, in the right format, at the right time.

The scope expands from formulating a request to organizing the information, tools and state behind it. Prompt design remains part of that work. Teams may assign these responsibilities to existing platform, product or staff engineering roles rather than create a separate title.

---

Four responsibilities around production agents

Four responsibilities help organize the problems that arise around production agents. The labels below are useful descriptions, not a standardized occupational classification.

The harness engineer. Martin Fowler put a name to this one, and the idea now has its own survey literature (arXiv:2605.18747, “Code as Agent Harness”, May 2026). The problem it solves is counter-intuitive. The risk with AI in a codebase isn’t that agents write bad code, it’s that they write code that looks fine file by file and drifts as a system. Run enough agents and the architecture erodes without any single change being wrong. The harness engineer builds the infrastructure that holds the line: watchdogs, architectural linters, the machinery that keeps a fleet of agents producing something a human can still maintain. As Fowler put it, a raw model is not an agent, it becomes one when connected to a harness. The title is not standardized yet. Right now it’s absorbed into platform and staff engineering roles, which is exactly where pioneering titles live before they get their own line on a job board.

The spec engineer. A specification gives the implementation and its reviewers an explicit reference: expected behavior, constraints and acceptance examples. A separate reviewer can compare the result with that reference. The specification itself still needs review, and having one does not imply a perfect pass rate. The responsibility is to keep intent precise enough for an agent, readable enough for the product team and stable enough to compare with the delivered change.

The agent identity architect. This one was born from a documented attack. Simon Willison named the “lethal trifecta”: give an agent access to private data, expose it to untrusted content, and let it communicate externally, and you have an exfiltration path. The role exists because companies handed agents the keys before anyone built the locks. The agent identity architect designs how agents authenticate, what they’re scoped to do, and how privilege escalation gets blocked when one agent chains tool calls into another. Guillaume Lours described one concrete implementation for high-autonomy agents: a micro-VM with network-level credential injection, where the agent receives credentials via a man-in-the-middle proxy and never sees them directly (ep 360). The agent is constrained not by its own policy but by what the infrastructure is willing to hand it. This work requires IAM depth and an explicit owner for authentication and permission boundaries.

The AI eval engineer. This responsibility is to make regressions observable with defined test cases, acceptance criteria and versioned results. Human review and LLM judges can both contribute, but both need calibration. A separate verifier is an evaluation design choice; its independence and error rate still need to be checked. Louis Pinsard’s IFTTD account discusses asynchronous LLM judgment as a way to collect production feedback without placing every check in the user’s response path. Whether a check may run asynchronously depends on what it is supposed to prevent.

---

What happened to the role you already have

Most people won’t take one of those titles. They’ll keep the one they have and grow a new layer underneath it.

The clearest case is the plain software engineer becoming an AI engineer, a role that combines software delivery with model integration and evaluation. The work is recognizable: build software, but with LLM integration, evaluation, and product judgment about model limits added to the stack. Not a researcher who trains models, not a pure integrator either.

Two phrases should not be mistaken for jobs. “AI-native engineer” is a baseline increasingly expected of everyone rather than a role you apply for. “Vibe coder” is a method, and no serious company puts it on a requisition. The AI wave raises the floor under the hats people already wear more than it creates new hats.

The exception is the early stage. The founding AI engineer is a genuine hybrid, part engineer, part product owner, part technical co-founder, typically aimed at people with 0 to 4 years of experience who are comfortable owning a feature end to end and already use these tools daily. The leverage is large in both directions, which is the whole appeal and the whole risk.

---

A deployed interface can still miss the user’s work

Léa Buendé, an FDE at Adobe, recounts in IFTTD episode 373 an engagement with field engineers accustomed to paper manuals. Her chatbot proposal did not fit how they searched for information. The account spans her career; it does not establish that this engagement happened at Adobe.

That is a concrete adoption responsibility for the role: observe actual users completing a task, discover what information they provide and check whether the interaction fits their environment. A working integration demonstrates implementation. Adoption requires evidence from use. This single case does not establish that search is generally better than chat.

What this means if you’re the one reading it

Existing experience supplies useful starting points. QA and technical writing can support specification and validation work; cloud and IAM experience can support identity design; system design can support harness work. These are possible directions. Demonstrated work and the missing skills matter more than a new label.

Build a bounded example, document the decisions, add an evaluation and record where your current skills were insufficient. For non-technical knowledge work, the Cowork guide provides a different entry point. No fixed transition time follows from this map.

The first three parts gave the practice: context, maintenance and tooling. These responsibilities describe who can own that work once several people depend on it.

Part five shows what that practice looks like when six developers share the same instruction system: profiles, a sync pipeline, CI gates that catch drift before it reaches production.

From the field, via IFTTD episode transcripts: Louis Pinsard, ep 338 on async LLM-as-judge in production; Guillaume Lours, ep 360 on credential isolation for autonomous agents; Antonio Goncalves, ep 357 on AI vocabulary as the 2026 baseline.

If you’ve moved into one of these roles, or watched your own job quietly turn into one of them, I’d like to hear which part of the description matched and which part the recruiters got wrong.

---

YSNK

(You should now know)

• Responsibilities can overlap and sit inside existing jobs; the titles are not a standardized career ladder
• A specification is a reference to review, not proof of a correct implementation
• Scoped permissions and credential isolation need technical enforcement beyond an instruction to the agent
• Human reviewers and automated judges both need calibration; an independent verifier is not automatically a reliable one
• Existing skills suggest directions to explore, while demonstrated practice establishes what a person can currently do