Why AI Needs Forward-Deployed Engineers [Testμ 2026]

The Need Behind the Title

She parks one idea at the centre of the room and leaves it there for the whole talk. Nobody wakes up needing a forward-deployed engineer. They wake up with a need.

Her definition of client covers both worlds: in services it is the customer, in a product company it is your own organisation.

The trigger is always something that has to change, whether a competitor moving faster, a regulator asking, or a board losing patience. And every client arrives with limited money, limited time and limited attention as a fact of life rather than a complaint.

What gets built inside those constraints still has to carry quality and still has to hit the problem they came with. Every role the industry has invented is an arrangement for producing that, which is why she starts from the outcome rather than the title.

The Industry Definition

She notes that a surprising number of talks on this role never define it, because everyone already carries an image of it.

Reading the posted job descriptions at AWS, OpenAI and Palantir, she finds the industry fairly consistent: a senior engineer embedded with the customer, comfortable with ambiguity, able to take work from prototype to production, bringing deep technical craft alongside real customer interaction. She credits Palantir with probably coining the term, hedging it as her impression.

What she does next is unusual for a talk framed as a challenge. She declines to knock the definition, calling it a good one that the industry has needed and will keep needing.

Her argument is that it is incomplete rather than wrong, and she promises three things: a working definition, a competency model covering the whole job, and a playbook.

Two Extensions

The first extension is ownership. Not the ticket, not the artifact, but the change in the client’s world.

The second is that the loop runs both ways: you carry what the field teaches back into your own product and platform. She calls that return half of the loop half the value of the role, and the reason FDEs mattered in the first place.

Her composite definition is an engineer deployed into a client’s world who owns an outcome end to end, from discovery through production to what the field teaches next.

The exclusions are as useful as the definition. It is not a demo engineer, not a consultant who disappears at handover, and not support with a better title.

An Old Role, Newly Affordable

She then lists the older names for the same person: the consultant who could actually build, the architect who did not vanish after the diagram, the tech lead who talked to the business rather than only to a Jira card.

Her claim from decades of practice is simple enough to test against your own experience. Put someone with real technical agency close to the real problem, and good things happen faster.

Strip the title off the picture and four things remain: a need for something to change, constraints, the qualities that have to hold, and an outcome.

Her definition of a real outcome is the one to keep: something that keeps working after you have left the room, and keeps surviving reality. Team shape, process, tooling, AI and job titles are all implementation decisions around that.

Dissolving the Badges

She describes delivery as a set of activities, each historically wearing a badge. Understand and decompose the need, business analysts. Shape the interaction, designers. Build it, developers. Challenge it, testers. Secure it, security. Make it deployable, operations. Watch it run and learn from the field, support.

Then she points out what she never said: which of those a human does, which a machine does, or how many humans are involved.

The lifecycle describes what must happen. It says nothing about headcount or titles.

An FDE is therefore a configuration that puts more of those activities inside the span of one technically capable person close to the customer, with AI carrying a share of the execution. The split between human and machine inside each activity varies by organisation and by project.

Because it is a configuration rather than a job title, it can be designed well, which is what the rest of the talk is for.

The Judgement Gap

For decades the expensive part of software was execution: typing, debugging, integrating, coding. That cost is precisely why the work was split across many specialists in the first place.

GenAI collapsed it, which is what lets engineers move upstream and outward.

The second line on her slide is the one that did not move: the cost of judgement, meaning knowing what good looks like, what to verify, and when to escalate.

Her worked consequence is the sentence most worth arguing with. An engineer who gets a chunk of their week back has not thereby acquired discovery skills, stakeholder skills or threat-modelling judgement. What they have acquired is an invitation to build them.

The gap between those two lines is the real skill set, and the rest of the session is about closing it.

Collecting Lenses

Her framing for the first skill is that every role around you is a compressed bundle of judgement, which is to say a way of seeing.

• A good business analyst hears what was not said.
• A good tester refuses to take the happy path, or any path, for granted.
• Security sees trust boundaries and abuse paths where others see features.

Same system, same light, different refraction. And she is explicit about the limit: the FDE is not doing everyone’s job and does not replace the business analyst or the SRE.

The skill is collecting enough lenses to recognise what each discipline would see, and to know when to call for real depth. Because AI is doing the typing, that is where freed capacity can usefully go.

She adds a caveat that keeps the advice honest: it is a moving target, because a good analyst, a good tester and a good SRE are all rewriting their own definitions right now.

Growing the Questions

The second skill compresses to one line: breadth became cheap, depth did not.

Her example comes from her own discipline. Ask AI to secure an application and it will cover authentication, authorization, encryption, secure headers and an OWASP sweep, competently.

She then names the usual stopping point, which is asking whether the OWASP Top 10 has been covered and treating that as the end of the conversation.

What an experienced security engineer adds are the questions below the waterline. What are the trust boundaries. What happens when a tenant boundary changes. What leaks through logs and prompts. And what evidence would we need if we were in an incident, which she notes is the question paying a lot of people’s salaries, because incidents travel along the supply chain.

The Competency Model

She is fair to the existing material. Academies and white papers on the role are generally strong, and the better courses add customer interaction. Her objection is that build is one column of three.

Her evidence is why these engagements actually fail, and none of it is code: the stakeholder nobody thought about, scope that was never sliced properly, expectations not set uniformly, escalations that arrived weeks too late.

• Build - system architecture and quality engineering, the column most training already covers well.
• Delivery - discovery and problem framing, scoping and sequencing under real constraints, risk and dependency management, and pace with predictability. Her line here: clients forgive slow, they do not forgive surprises.
• Connection - listening for what was not said, narrative and expectation setting, telling the truth about uncertainty in a way a client can act on, influence without authority as a guest in someone else’s org chart, and organisational politics, which she calls very real and badly underrated.

She asks people to grade themselves honestly at three depths across the model: awareness, working capability meaning you can carry a normal case safely, and depth meaning you are the person others call.

The Six-Step Playbook

• Follow one problem past your boundary - refuse to stop at my code is done. Sit in discovery calls, watch the rollout, read an incident record. One end-to-end problem teaches more than ten job descriptions.
• Borrow another discipline’s lens for a month - attack your own assumptions like a security tester, join a threat-modelling session, sit in user research.
• Build one area of real depth - an anchor, so the breadth does not stay shallow.
• Use AI as a pairing partner, not an oracle - make it argue against your design, and verify the claims that matter yourself, because it is only as good as you know how to drive it.
• Practise client conversations - shadow first if you never have, then set expectations before they are set for you, and narrate trade-offs in the client’s language.
• Lead without the title - build your escalation map, ask for help out loud, and bring the client’s own people with you. A good FDE is never a lone wolf.

The fourth and sixth are the ones people skip. Asking for help out loud is framed as a strength peers learn from rather than an admission, which is a deliberate correction to how senior engineers usually behave.

The Leader’s Half

Her third takeaway is aimed at leaders, and it is the one that makes the other two possible. None of the six steps happen unless the surrounding system supports them.

The failure she has watched is specific. Because the technical parts got easier first, organisations declared development fast without moving anything else.

If the engineer speeds up and the system around them does not, the outcome does not work. Concretely: quality conversations, security reviews and decisions still running at pre-AI pace while delivery runs at AI pace means the gap lands on the client, where it is visible.

She is careful not to dismiss structured learning, while insisting a two-week academy alone will not close it, because the environment is what creates judgement. Her prescription is pairing across disciplines inside real work: you can accelerate exposure, but there is no instant version of experience.

Two Extremes to Avoid

She closes by naming two positions she has watched organisations take, both wrong in opposite directions.

The first is that AI made engineers superhuman, so a handful of generalists will ship everything. The second is that delivery is complicated, so keep everything inside the existing boundaries and do not touch the boxes.

The opportunity sits between them: recompose delivery around the outcome, keep the expertise that changes the outcome, automate the work that does not, and grow people so they can safely carry the wider span.

The question she asks teams to take back is a better one than the usual. Not how many roles AI can eliminate, but what thinking must still happen for this outcome to be good, and what is the cheapest trustworthy way to make that thinking happen.

Her answer is deliberately conditional. Sometimes it is an FDE on a strong platform, sometimes a compact cross-functional team, and the outcome should choose rather than the fashion.

She ends where she began. The client still has a need, still has limited resources, still does not care what any of us call ourselves, and wants something that keeps working after the demo. So do not copy the title, copy the conditions.

This session was part of Testμ Conf 2026, which ran across three days of sessions on agentic engineering and quality. Registrations for the next edition are already open on the Testμ Conference 2027 page.