4/6 · The responsibilities around context engineering
A map of context engineering responsibilities: architecture, specifications, agent identity and evaluation, with practical directions for existing skills.
Jump to summary ↓
Florian BruniauxContext Engineering · Part 4/6
TL;DR
I think most people keep the job they have and grow a new layer under it: the AI wave raises the floor under existing roles more than it creates new ones. Context engineering as a discipline gets absorbed by harness engineering, yet I still expect “context engineer” to be a real job title within two years, because that work still needs people who answer for it. What counts is demonstrated work and the skills behind the responsibilities, not the label.
| 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.
AIDD live: from feature work to harness maintenance
At 42:00 in the October 16, 2026 AIDD live session, I describe that shift in my own work. I started as the first developer at Méthode Aristote. As other people joined and produced more changes, I spent more of my time maintaining the harness, investigating failures and deciding what to change in the workflow. I still wrote features for a gap, an integration or a complex task.
That account puts concrete work behind the role: someone needs time to investigate why a check failed and maintain the tools other people rely on. It describes my responsibilities in one team, without establishing a hiring trend or a staffing ratio. These remarks come from the AIDD live, distinct from the October 12 Dev With AI talk, with automatic captions and a few opening minutes missing.
In my IFTTD conversation with Bruno Soulez, I revisit who builds this system and how reducing line-by-line review changes the maintainer’s work.
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. She tells it across her career, so it is not necessarily an Adobe engagement.
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.
Make the responsibilities assignable: a maintainer owns each control and its failure tests, an authorized actor owns acceptance of the change, and a named owner protects verification capacity. One person may hold several responsibilities. The arrangement should still explain who handles a stale proof, a contradictory review or a result that nobody can currently verify.
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. 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.
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
Go Further in the Claude Code Guide
Practical resources selected to help you take the next step.
These resources provide adjacent lenses. They are not maturity stages.