An Australian IT services company just posted a role called "Forward Deployed Engineer Lead (Principal Applied AI Engineer)." The job is to sit between anxious executives and production AI, turning "we want to use AI" into deployed systems that actually do something. It is a beautifully written job description for a person whose entire job is to make themselves structurally redundant.
What the role actually does
A Forward Deployed Engineer Lead at a consultancy does three things, in this order.
First, they walk into a client — a bank, a retailer, a logistics company — and listen to executives describe a strategic ambition. "We want to reduce claims processing time." "We want to personalize offers." The FDE Lead translates that ambition into a solution concept: which parts are AI-addressable, what the architecture looks like, what it costs, how long it takes.
Second, they build it. They assemble a small team, design the system, write code, deploy it, and make sure it runs in production without embarrassing anyone.
Third, they coach. They set engineering standards, hire people, review work, and build reusable platforms so the next engagement starts from a template instead of a blank page.
The posting says they expect to scale from 20 engineers to over 100. That is the sound of a consultancy building an army of people who sit between AI technology and AI buyers. The technology that army deploys is the same technology that can deploy itself.
How AI eats this role, course by course
Course one: the listening and translation
The FDE Lead's first skill is translating executive ambition into technical architecture. This is a structured conversation: listen to a business problem, ask clarifying questions, map the problem to a solution pattern, and produce a document describing the architecture.
An AI system does this today. You build a pipeline that starts with a transcript of the executive intake meeting, feeds it into a model prompted with a structured extraction framework — business objective, constraints, data availability, regulatory requirements, success metrics — and produces a solution concept document. The model has read every enterprise architecture pattern, every case study, every reference implementation. It does not need to have "seen this before" at three other clients. It has seen all of them.
The clarifying questions? The system generates those too, ranked by information gain. An executive answers them in a chat interface. The system iterates. By the end of the session, you have a solution concept that is commercially viable, technically feasible, and scoped for enterprise scale — the exact three criteria the posting lists.
The FDE Lead's value here was supposed to be judgment: knowing which ambitious ideas are technically realistic and which are fantasy. That judgment is increasingly a function of asking the model to stress-test its own proposal against constraint checklists: data lineage, model latency, integration complexity, regulatory exposure, change management burden. The model does not get tired. It does not get seduced by a charismatic CIO. It does not bill for the privilege of being wrong.
Course two: the architecture and delivery
The posting asks for "production-ready solution architectures and delivery plans." This is where the FDE Lead earns their consulting rate — designing the system that will actually run.
Here is how that looks automated.
A pipeline takes the solution concept and generates a reference architecture: which services, which data flows, which models, which APIs, which guardrails. It selects from a library of pre-built patterns — RAG over enterprise documents, classification over structured data, agentic workflows over multi-step processes — and adapts them to the client's constraints. It produces an architecture diagram, a data flow diagram, a security review checklist, and a delivery plan with milestones.
Then it starts building. Agent-assisted development is how engineering works now. A single engineer with a fleet of coding agents takes the generated architecture and implements it. The agents write the integration code, the data pipelines, the evaluation harnesses, the deployment scripts. The human reviews, redirects, and signs off.
The posting's own language gives this away: "focusing engineering effort on solving business problems rather than writing code for its own sake." That sentence is an admission that the code-writing part is already not the bottleneck. If the code is not the bottleneck, the person whose core skill is directing code-writing is not the bottleneck either.
Course three: the coaching and standards
The FDE Lead sets the engineering standard for the track: solution architecture patterns, testing, evaluation, production readiness. This is documentation work — the creation of templates, checklists, and rubrics.
A system maintains these standards by analyzing every completed engagement — what worked, what failed, what caused production incidents — and updating the patterns automatically. The "engineering standard" becomes a living document generated from real deployment data, not a PDF that a principal engineer updates quarterly when they remember.
Hiring? The system screens candidates against the patterns it has defined. It generates technical interviews from the actual problems the consultancy has solved. It evaluates answers against a rubric derived from the standards. The human interviewer becomes a sign-off step, not an evaluation step.
Where it breaks
Here is what does not automate cleanly: the politics.
A consultancy sells trust. The client is not just buying a system; they are buying the feeling that someone competent is responsible for it. When the CFO asks "is this safe?" they want to look a person in the eye. When the project is three months late, the client wants to yell at someone who can feel bad about it. When the board asks who is accountable, "an AI system" is not yet an acceptable answer, and it may never be.
The FDE Lead's deepest function is being the human shield between the client's anxiety and the technology's indifference. That function does not automate. It is the same function that kept enterprise architects employed through the cloud migration era: not technical expertise, but the social contract that says a human is on the hook.
There is also the sales motion. The FDE Lead does not just deliver; they help sell the next engagement. They build relationships. They read the room. They know when to promise more and when to under-promise. AI can generate a proposal, but it cannot take a client to dinner and make them feel like they are buying a partnership, not a product.
The verdict
The posting describes a role that scales from 20 to 100 people. That is the consultancy's bet: that clients will pay a premium for humans who stand between them and AI.
The irony is that the role's own job description — "small expert teams directing agent networks" — describes the exact structure that makes those 100 people unnecessary. If a small team can direct agent networks to do the work, the consultancy does not need 100 people to direct them. It needs the agent networks, and a few people to direct the directors.
The FDE Lead is not wrong about the future of engineering. They are just wrong about whether they will be part of it. They are building the machine that replaces the person who builds the machine. And they are doing it with a grin, because the posting makes it sound like a promotion.
The real job, if you read between the lines, is to automate the job. The only question is whether the person who does it gets to keep the title after the work is done — or whether the title becomes a courtesy, like "head of cavalry" in an army that no longer uses horses.
If you are the kind of consultancy that sells AI transformation, and you are hiring 100 people to deliver it, ask yourself whether you are building a team or building a demonstration. Your clients are going to ask the same question — and they are going to have a model help them answer it.
