What Changes When Forward-Deployed Engineers Use Coding Agents

The job stops being implementation

The obvious thing to say about coding agents and forward-deployed engineering is that agents make the work faster. That is true and it is the least interesting part.

The substantial change is to what the role is. A forward-deployed engineer used to be the person translating between a vendor’s product and a customer’s technical environment, and the translation was performed largely by writing code. With a capable agent, the engineer increasingly becomes the person supervising another software-producing system operating inside someone else’s environment.

That is a different job. It has different scarce resources, different failure modes, and a different definition of what the engineer needs to know.

The leverage is real

Start with why organizations are doing this, because the incentive is strong and dismissing it would be wrong.

An agent can explore an unfamiliar repository far faster than a person reading it cold. It can produce adapters, migration scripts, data transformations, test suites and glue code at a rate that changes what is economically viable for a single customer. Work that previously could not be justified for one deployment becomes justifiable. An FDE organization that could staff ten concurrent deployments may be able to staff considerably more.

For a business whose gross margin is determined by how much human engineering each customer consumes, this is not a marginal improvement. It is the difference between a services shape and a software shape.

So the adoption is rational. The question is what it changes about the risk.

The asymmetry gets wider

An FDE already operated with a context deficit: less institutional knowledge than the engineers who maintain the system, under a deadline. That was the defining condition of the role before agents existed.

Now add a collaborator with a much more severe version of the same deficit. The agent brings strong general knowledge of how software is usually built and no knowledge whatsoever of why this customer’s system is built the way it is. It cannot distinguish a deliberate boundary from an accident. It cannot tell a current decision from one superseded eighteen months ago. It has no sense of which oddities are load-bearing.

What it does have is throughput.

The arrangement that breaks is review

This is the part that deserves arithmetic rather than assertion.

Before agents, the safety mechanism in forward-deployed work was that the engineer produced changes at human speed, and someone with more context reviewed a meaningful fraction of them. That someone was often a customer-side engineer who knew why the system was shaped as it was. The mechanism was slow, informal, and it mostly worked, because the volume was low enough that the scarce context could be applied to most of it.

Agent-assisted work does not preserve that ratio. The volume of proposed change rises sharply. The pool of people who hold the relevant architectural context does not rise at all: it is a fixed set of long-tenured engineers at the customer, who have their own work, and who were not hired to review a vendor’s output.

So one of three things happens, and all three are bad.

• Review becomes the pacing constraint and the throughput gain evaporates, which removes the reason for adopting agents in the first place.
• Review becomes shallow, checking that the code works rather than whether it respects commitments the reviewer would have to go and look up. Functional correctness is much easier to assess than architectural compatibility, so this is what shallow review converges on.
• Review is delegated to people without the context, at which point it is confirming that the change does what it says, not that the change was permitted.

Notice that the second and third outcomes both produce an approving reviewer and a violated constraint. The process looks healthy from the outside. The signal that used to make review work is simply no longer present.

Instructions do not transfer; constraints do

The common response is to give the agent better briefing: a detailed instruction file describing the customer’s conventions, the architecture, the things not to do.

This helps and it degrades in a specific way. Instructions are advisory input competing with everything else in the context window, including the immediate task, which is concrete and pressing while the constraint is abstract and was mentioned earlier. As sessions lengthen and context is compacted, the summarizer keeps what looks relevant to the current step. The task survives. The rule that governed it is frequently what gets dropped.

The distinction that matters for an FDE is between two kinds of artifact:

Only the second kind survives the conditions under which forward-deployed work actually happens. And crucially, only the second kind protects against the constraint the engineer did not know to write down, because it fires on the change rather than depending on a briefing that was authored from incomplete knowledge.

What this means for multi-customer leverage

There is a second-order effect here that matters for FDE organizations specifically.

If the thing that makes agent-assisted deployment safe is a set of compiled constraints derived from the customer’s architecture, then that artifact is per-customer and reusable across the whole engagement. It is produced once, early, and every subsequent piece of agent work in that environment is evaluated against it.

That changes the shape of the engagement. The expensive, judgement-heavy part moves to the front: establishing what must remain true in this environment, with the customer’s own architects, while there is still time to ask. The implementation that follows can run at agent speed against a known boundary.

It also produces something the customer keeps. Which addresses the oldest problem in the model.

What the resequenced engagement looks like

If the constraint set is the thing that makes agent-assisted delivery safe, then it has to be built before the agent is pointed at anything, and that reorders the first phase of an engagement.

The conventional shape is discovery running in parallel with early implementation: the engineer learns the environment while starting to build in it, because both are urgent and the schedule has no room for a sequential pass. Architectural understanding accumulates as a side effect of doing the work, which is acceptable when the work proceeds at human speed and each change is an opportunity to be corrected.

That shape stops being defensible when the implementation phase compresses. If an agent can produce in two weeks what previously took eight, then the eight weeks of ambient architectural learning that used to happen alongside it does not happen. The understanding has to be front-loaded or it does not exist.

In practice the resequenced version looks like this. The first phase is explicitly about establishing commitments rather than producing code: identify what this system actually depends on remaining true, confirm with the people who would know, determine which of those reduce to a mechanical check, and activate those. It produces very little that looks like progress to a delivery manager, which is the main obstacle to adopting it.

The second phase runs at agent speed against a known boundary. Violations surface as verdicts rather than as review comments, which means they surface to the engineer directing the agent rather than to a customer reviewer who has to explain a constraint they assumed everyone knew.

The trade is real and should be stated plainly: you spend more of the engagement before writing code, in exchange for the implementation phase being both faster and less likely to produce work the customer’s platform team rejects. Whether that trade is worth making depends on how much of the customer’s architecture is load-bearing, which is itself a thing you can measure at the start rather than assume.

The handoff finally has an artifact

Forward-deployed engagements end and the engineer leaves. Historically what remained was a working system, a README, and reasoning that walked out of the building. The customer’s team inherits an implementation whose deliberate choices are indistinguishable from its accidental ones, which is precisely the condition the previous piece described, now inflicted on the customer by the vendor.

Agents make the volume problem worse, because there is simply more code per engagement carrying unstated reasoning.

But the constraints the FDE had to establish in order to direct an agent safely are exactly the handoff artifact that was always missing. They are explicit, scoped, machine-checkable, and they keep working after everyone involved has moved on. The work of making architectural intent external stops being documentation overhead nobody has time for and becomes a prerequisite for operating agents at all.

That is an unusually favourable alignment of incentives. The thing that makes the engagement safe is the same thing that makes the handoff durable.

Where the judgement still lives

None of this eliminates the engineer, and claims in that direction should be treated with suspicion.

Deciding which commitments are real, which are vestigial, which reduce to a mechanical check and which genuinely require human conversation is architectural judgement, exercised with the customer, and there is no version of this where an agent does it unsupervised. The separation between what can be enforced and what should stay a matter for review is exactly the kind of call that needs a person who understands both the system and the organization.

What changes is where that judgement is spent. Less of it goes into writing the integration, because the agent can do that. More of it goes into establishing the boundary the integration has to respect, early, while the customer’s architects are still in the room.

For an FDE organization the practical implication is a resequencing. The first week of an engagement stops being discovery-then-build and becomes: find out what this system actually commits to, determine how much of it would currently stop a contradicting change, and close the gap on the decisions that matter before pointing an agent at the codebase.

That first question has a concrete answer, and it can be measured against a real repository rather than estimated.