Quick summary: If you already use coding agents to build apps, what you still need to learn to become a Forward Deployed Engineer (FDE) mostly lies outside writing code: understanding business processes, connecting systems, and getting a solution into production. A practical way to start is to pick a problem someone currently handles by hand, measure the baseline, build a trial version, then check the results. Your portfolio should show measured results, not just a list of AI tools you know how to use.
You can use a coding agent to build a UI, write an API (Application Programming Interface), and fix bugs in a single session. Once software goes into a company, you also have to settle where the data lives, who is responsible if an invoice is wrong, and how work continues when the system breaks.
A specific Anthropic Applied AI FDE job posting, taken down on June 18, 2026, asked for production experience and customer-facing work, as Anthropic's listing on Built In shows. In roughly 1,000 FDE job postings analyzed by Henley Wing Chiu, published on Bloomberry on November 18, 2025 and updated January 25, 2026, 60% of the postings that listed required experience asked for 3 to 5 years.
Formal training paths such as the Claude Frontier Academy, announced by Anthropic on October 2, 2026, are currently nomination-only, and the first cohort is engineers from consulting firms and large corporations. For someone who is already a software engineer or a vibe coder (someone who has AI write most of the code from plain-language descriptions), I lean toward teaching yourself through a real business problem.
An FDE brings technology to bear on a problem inside the customer's operating environment. You can read part 1: What is a Forward Deployed Engineer (FDE)? for the role, and part 2: FDE or rebranded consulting? for how technical delivery differs from consulting.
What is missing if you already use coding agents and want to be an FDE?
You need to fill the skills that sit between code and business results, not necessarily learn another coding agent. Nguyễn Phi Vân splits FDE skills into five groups: technology, AI, business, system integration, and working with people. Her post, published October 6, 2026, is in Vietnamese.
The table below is my own judgment of the gaps that people who already use coding agents are likely to have:
| Skill group | What you usually have, and what is missing |
|---|---|
| Technology | You can build an app, but you need to read, debug, and take responsibility for the code the agent writes, the database, and the deployment. |
| AI | You can write prompts, but you need to understand LLMs (Large Language Models), RAG (Retrieval-Augmented Generation), agents, MCP (Model Context Protocol), and evals, especially when not to use AI. |
| Business | You can take requirements, but you need to find the real problem, the person accountable, and the KPI (key performance indicator). |
| System integration | You can call an API, but you need to work with data and live systems such as a CRM (Customer Relationship Management) or an ERP (software that runs operations such as accounting, inventory and purchasing). |
| People | You can discuss requirements, but you need to observe, listen, explain risk, and speak up when you are solving the wrong problem. |
You can fill these gaps through a trial project in five steps: observe the current state, decide where AI is needed, build a trial version, write evals and set human checkpoints, then measure before and after and hand over.
Step 1: pick a real problem and observe before you build
Pick a small process that people currently do by hand, that has an owner, and that you can measure before changing it. Throughout this guide I use a hypothetical scenario that has not been deployed or measured: a small distribution company where an employee spends hours each week reconciling invoices across Excel, accounting software, and photos sent over Zalo (a messaging app widely used in Vietnam).
You need to understand the process before deciding what to build. The fact that AI can read an invoice photo does not prove the company needs an AI system.
Learn the problem with the customer
The first step is discovery: learning the problem with the customer. Watch the person who handles the invoices, then ask:
- When does the work start, and what state marks it as finished?
- Who does each step, and who confirms the result?
- Where does the data live, and who has access?
- How long does one run take, and how many times a week does it happen?
- What errors are common, and at which step are they caught?
- What happens if an error is missed?
- Which KPI has to change for the company to see this as an improvement worth keeping?
Record when one run starts and ends, and watch for cases where the employee has to re-check. Those notes give you the baseline for comparison later.
Break the problem down until you can verify it
Palantir calls this skill "technical decomp": taking a high-level business problem, breaking it down, and designing the solution down to individual lines of code. An FDE needs to understand the business goal and stay self-directed when facing unfamiliar technology, as Palantir describes in "Dev versus Delta" (April 8, 2019).
For the invoice process, you can decompose it like this:
| Task in the process | Data needed | Done when |
|---|---|---|
| Receive the invoice | Photo or file of the invoice | You know which document to process |
| Extract information | The fields on the invoice | You have data to reconcile |
| Reconcile | Invoice and accounting data | You can tell matches from mismatches |
| Handle discrepancies | The differing fields and the source document | An employee confirms how to resolve it |
| Record the result | The confirmed status | The decision can be traced |
Write down the unknowns separately instead of filling them with guesses. The same approach appears in Fable 5 and the unknowns problem: fix the map before you code.
Done with this step when: You can describe the current workflow, you have sample data you are allowed to use, you know how to measure the baseline, and you have agreed the success criteria with the owner.
Common mistake: You only listen to a manager's description and build to it, while the employees handle exceptions a different way.
Once you understand the process, you need to decide which part actually needs AI.
Step 2: decide whether you need AI
Use ordinary automation for the parts with clear rules, and consider a model only for the parts that read information that is hard to standardize.
Nguyễn Phi Vân counts knowing when not to use AI as part of the FDE skill set. Colin Jarvis, Head of Forward Deployed Engineering at OpenAI, also stresses Occam's razor: in most LLM development, the simplest solution is usually the best. See Nguyễn Phi Vân's post and Colin Jarvis at OpenAI.
Draw the line in the invoice process
| Task | Suggested approach | Reason |
|---|---|---|
| Read Excel | Ordinary code | The data is already structured |
| Fetch accounting data | Connect to the existing system | No model needed to read structured data |
| Read invoice photos | Consider a model | Document layouts can vary |
| Compare amounts | Deterministic rules | There are clear checks |
| Handle discrepancies | Employee confirms | A wrong decision has business consequences |
| Save results | Ordinary code | Needs operations you can verify |
Check whether the information in the photo already exists in the accounting software. If the data is already there, re-reading it from an image may only add complexity.
An LLM can be one option for extracting information from images. Even so, its output still has to pass a check. RAG (letting a model look up documents before answering) and agents (programs that call tools and loop through steps to finish a task) should only appear when the requirement truly calls for them.
Record your technical decisions
Before writing code, write down:
- What does not use AI: The steps with clear rules.
- What may use AI: The reading and interpretation work that simpler approaches cannot handle.
- Input data: The fields the model is allowed to receive.
- Output: A structure your code can check.
- Human checkpoints: Cases with missing or conflicting data.
- Fallback: How work continues when the model is not working.
Done with this step when: Every task has an approach, a reason for the choice, and a plan for failure.
Common mistake: You use a model to do an exact comparison, or turn a simple task into several chained agents, which raises token cost and latency.
At this point the coding agent has a clear enough spec to start building.
Step 3: build a trial version with a coding agent, but keep your judgment
Use a coding agent to quickly build one complete processing path, but you must understand and take responsibility for the code it produces. Nguyễn Phi Vân stresses that knowing how to vibe code and paste in whatever the AI gives you is not enough to be an FDE; you also need to read code, debug, and understand the systems that are running. See her post.
Build one complete path first
The trial version can take sample data, extract the needed fields, reconcile them, and produce a list of discrepancies for an employee. You do not need it to fix accounting data automatically or support every document type yet.
Invoice data you are allowed to use
|
v
Read and normalize
|
v
Validate data
|
v
Reconcile the figures
|
+-----+------+
| |
v v
Match Mismatch
| |
v v
Record Employee
result reviews
|
v
Record decisionBefore handing over the work, settle with the business owner: the key used to match both sides (for example the invoice number), which fields to compare, the format of each field, and how to handle missing or duplicate data. The agent should not guess these rules. Then you can give the coding agent one part at a time, with specific inputs, outputs, and error conditions. For example, with hypothetical values:
Context:
Build a trial version of invoice reconciliation.
Task:
Take normalized invoice data
and compare it with sample accounting data.
Constraints:
- Match on invoice number.
- Compare: invoice date (YYYY-MM-DD), tax ID,
total amount (integer, VND).
- Example: invoice 0001234, 2026-10-01, 0101234567, 5500000
vs. accounting 5000000 -> total amount mismatch.
- Do not modify the source data.
- Return match or mismatch for each field.
- Distinguish missing data from differing data.
- Do not confirm mismatches on your own.
- Write tests for valid and invalid input.
Before writing code:
State your assumptions about the data structure
and any cases that are not yet defined,
then stop and wait for my confirmation.After each part, read the path the data takes and run the tests. If the agent creates a write API and you cannot explain when it gets called, that part is not ready for production.
Integrate with existing systems
An app that works on sample data does not guarantee it connects to the company's workflow. The Excel file may be edited by hand, the photos sit in Zalo, and the accounting software has its own access mechanism.
Settle two things before integrating:
- Data source: How can you read and update data in a way the company allows? Which connection methods does the existing system support?
- Access: Who may read or write the data? Is that permission limited to the scope of the job?
If you do not yet have permission to connect, you can use sample data or a legitimate export. Access has to be resolved with the owner, not worked around by bypassing the system's limits.
When should you package something as a skill or an MCP server?
Once an operation is stable and likely to repeat, you can package it for reuse.
MCP, a protocol that connects models to outside data and tools, lets a model connect to the tools you expose. An MCP server can bring controlled operations into the workflow, while a skill holds instructions for doing a task. A sub-agent (a child agent that the main agent hands work to) fits when one piece of work needs to be split out.
In an Applied AI FDE posting, Anthropic lists MCP servers, sub-agents, and agent skills as production deliverables, per the listing on Built In.
Colin Jarvis describes how OpenAI's team turned bespoke apps into plugins and skills on a shared harness (the layer that controls agent behavior) built around Codex. By OpenAI's own figures for the deployment he describes, this setup removed about 90% of the custom code per project; when expanding to a new team, they swap the connector or MCP server and build new evals, as he writes in his post at OpenAI.
For the invoice problem, you can keep the data normalization as a component to reuse once it has been verified. Palantir also points out the trade-off between putting a feature into the core platform and building a custom version to ship fast for the immediate need.
Done with this step when: The trial version handles one full flow of valid data, produces results you can check, and does not change data outside the agreed scope.
Common mistake: You build several reusable layers before you know what the workflow needs, or you only test with clean data.
A trial version that works still has to prove its results are correct and safe.
Step 4: write evals and set human checkpoints
Build an eval set and decide which decisions a human must confirm before the system runs in production.
Evals (a set of scenarios with known answers, used to measure quality after every change) show you whether a change to a prompt, model, or code lowers quality. Colin Jarvis describes a case where an OpenAI FDE team sat with a semiconductor customer's engineers to build evals around real work, in his post at OpenAI.
Turn business scenarios into evals
You can start with the scenarios below and have the owner confirm the answers:
| Scenario | Expected result |
|---|---|
| Invoice and accounting data match | Report a match |
| Amounts differ | Report the exact differing field |
| Invoice number missing | Report it as missing, do not fill it in |
| Photo is unreadable | Ask for a manual check |
| Several records could be duplicates | Do not pick one to confirm |
| Data outside the permitted scope | Refuse to process |
| Accounting system does not respond | Do not assume success |
Each case needs an input and an answer confirmed by someone who knows the business. Store the prompt version, the code, and the eval set so you can re-check after every change.
Do not just count how many cases the system returns a result for. A confidently presented wrong answer can cause more harm than a system that says it could not read the document.
Set human checkpoints
Gartner, in a statement from Mukul Saha dated September 29, 2026, stresses defining decision rights and the boundary between automation and human oversight, as Gartner's press release states.
For the invoice process, I would start with two checkpoints.
First: confirm uncertain data. When a photo is blurry or a field is missing, the system hands the document to an employee instead of filling in a value.
Second: confirm before changing business data. The system can produce a list of discrepancies, but an authorized person must confirm before any accounting figure is changed.
Only widen the level of automation when you have verification evidence that matches the consequences of the operation.
Control the risk of running live
Nguyễn Phi Vân points to situations such as AI making up information, API failures, agents making mistakes, rising costs, and attacks on the system, in her post.
Before production, you need an answer to six questions:
- Wrong information: How does the system detect and handle data the model got wrong?
- Wrong action: What stops the agent from changing data before it is confirmed?
- API errors: If a step fails halfway, how does the system recover its state?
- Cost: Who tracks tokens and caps the number of model calls?
- Attacks: Can malicious input make the model act outside its scope?
- System changes: If a database or API changes its structure, is that caught before bad data reaches later steps?
Keep evals separate from guardrails (safety limits). Evals check output quality; guardrails control operations and execution limits. How the control layers in a coding agent are organized is covered in an article on Claude Code's hook mechanism and config layers. Those layers protect you while writing code; the deployed app still needs its own permission checks.
Done with this step when: You have an eval set you can re-run, answers confirmed by the business owner, clear human checkpoints, and a plan for when the system fails.
Common mistake: You let the model confirm all of its own answers, or you use test results on sample data as the only basis for allowing writes to real data.
Once quality is verified, you need to measure the effect on the work.
Step 5: measure before and after, then hand over
Measure the same process before and after you apply the solution, then hand it over so people in the company can run it themselves.
Nguyễn Phi Vân argues an FDE portfolio should show which process was improved, how the time changed, and where humans check, in her post.
Measure results you can compare
| Metric | Before deployment | After the trial |
|---|---|---|
| Time to process one invoice | [your measurement] | [your measurement] |
| Invoices processed per period | [your measurement] | [your measurement] |
| Confirmed error rate | [your measurement] | [your measurement] |
| Cases needing manual review | [your measurement] | [your measurement] |
| Related operating cost | [your measurement] | [your measurement] |
The cells in the table are where you fill in the figures you measured yourself.
Keep the measurement conditions comparable. If employees used to handle simple documents, and the trial version only receives the hard ones, the average time will be skewed by how complex the work is.
A drop in handling time also does not prove success if the error rate rises or the review workload moves to someone else. For the AI part, count token cost and waiting time too.
Hand over so the company can run it
Gartner, in the same September 29, 2026 statement from Mukul Saha, says FDE contracts tend to fail structurally before they fail technically. One success criterion is whether the company can manage, optimize, and extend the system after the delivery team leaves, per Gartner's press release.
Whoever takes over needs to know how to operate the system, recognize failures, and fall back to the manual process when needed. Prepare:
- Workflow diagram: The steps and the systems involved.
- Operating guide: How to start, check, and finish one run.
- Access rights: Who may view or change the data.
- Eval set: The cases to re-run when the system changes.
- Incident handling: How to pause and return to the manual process.
- Owner: Who takes over operations and decides on changes.
If only you know how to recover from an ordinary failure, the handover is not complete. The line between delivering a technical product and creating long-term dependence is also analyzed in FDE or rebranded consulting?.
One-page portfolio template
You can use the table below as a frame for your portfolio:
| Section | What to write |
|---|---|
| Problem | The process to improve and the type of company |
| Current state | Who does it, the manual method, the starting measurements |
| Scope | The data you were allowed to use and the limits of the deployment |
| Solution | The automated parts, the AI parts, the integrated systems |
| Technical decisions | Why you chose this approach and which ones you rejected |
| Verification | The eval set, pass criteria, and human checkpoints |
| Results | Before and after measurements, cost, and the limits of the measurement |
| Handover | The recipient, operating documentation, and incident handling |
State the true status of the project, even if you have not measured post-deployment results. With company data, publish only what you have been allowed to, while keeping enough detail about how you verified it for readers to understand your work.
Done with this step when: You have comparable measurements, can explain the limits of the results, and someone in the company has taken over operations.
Common mistake: You report only the time saved and ignore the cost of review and operations, or you treat a demo as a proven production system.
A small portfolio is still worth something if it reflects the work and the evidence honestly.
Frequently asked questions
You can start from many backgrounds, but you need to separate what you can teach yourself from what the FDE jobs currently being hired for require.
Can you become an FDE if you are not a software engineer?
Possibly, but you still need enough technical grounding to take responsibility for a solution that goes into production.
Nguyễn Phi Vân sees people who build AI-centered products as able to grow toward FDE, while stressing the ability to read code and understand operating risk, in her post.
In the roughly 1,000 FDE postings from Revealera data analyzed by Henley Wing Chiu, published on Bloomberry on November 18, 2025 and updated January 25, 2026, Python appeared in 66% of postings, TypeScript in 35%, AWS in 32%, GCP in 22%, and Azure in 18%. On the AI side, agents appeared in 35%, LLM experience in 31%, and RAG in 12%. Among postings that listed years of experience, 60% required 3 to 5 years and 12% required 0 to 2 years; 68% of the roles in the dataset required travel.
One specific Anthropic Applied AI FDE posting, taken down on June 18, 2026, required 3 years or more in a customer-facing technical role, strong Python, and production experience with LLMs, including advanced prompt engineering (tuning the instructions you send to a model), agent development, and eval frameworks.
The job covered building Claude applications inside customer systems, delivering components such as MCP servers, sub-agents, and agent skills, and feeding repeatable deployment patterns back to the Product and Engineering teams. The posting listed a salary of 200,000 to 300,000 USD per year and an estimated 25% travel, both applying to that specific role, as the listing on Built In shows.
In my view, someone coming from vibe coding can start with a small workflow while learning to read, test, and debug the code the AI produces. Being able to build on your own is only the starting point; being able to explain and handle what happens when the system is wrong is what moves you closer to FDE work.
Do you need another AI certificate?
None of the sources used here identifies a specific AI certificate as a requirement for working as an FDE.
Nguyễn Phi Vân advises starting from a real business problem instead of taking many courses. The path she proposes runs through understanding the process, finding the data, designing the solution, building, integrating, testing, measuring, and deploying, per her post.
On October 2, 2026, Anthropic announced the Claude Frontier Academy with a 100 million USD commitment and a goal of 10,000 Frontier Deployed Engineers by the end of 2027. The program is by nomination and includes a multi-day live deployment simulation and a 12-week residency in which participants lead a real Claude project at their own company. The first cohort includes engineers from Accenture, Bain, Capgemini, Deloitte, McKinsey, Morgan Stanley, and a few other organizations.
If you are not in those programs, I would prioritize a problem where someone who knows the business confirms the results. You can learn what you need as you hit specific problems, instead of waiting to finish many courses before you start practicing.
Where can you find a trial problem in Vietnam?
Look inside your own job or at a small business you know, where someone is willing to explain the workflow and let you measure the results.
For context, PwC Vietnam's Hopes and Fears 2025 survey of more than 1,000 workers found 38% using generative AI daily, against a global average of 14%, which suggests generative AI is already familiar to part of the workforce surveyed, per PwC Vietnam.
I would prioritize a process where you can reach the people who do the work and where someone is responsible for receiving the results. For the invoice reconciliation problem, you need the company's permission to observe, to use suitable data, and to agree on how you will verify results before you build.
A small problem with a business owner involved lets you practice both the technical side and the way an FDE works.
When should you stop a trial project?
Stop or narrow the trial when you cannot measure the value, nobody will take over operations, or the AI part adds complexity without improving the work.
You cannot measure the baseline
If you do not know the manual handling time and how errors are identified, you have no basis for judging the results. You can narrow the scope to one step you can measure before developing further.
The code you have written is not evidence in place of baseline figures.
Nobody will take the system back
If the company does not name someone to confirm results and handle incidents, you are not in a position to hand over. Adding more features may make the system depend even more on whoever built it.
Keep it at trial scope until someone takes responsibility for operating it.
Ordinary automation already solves it
If the data is structured and the reconciliation rules are clear, a script can do the job without a model. Adding an agent can increase API calls, token cost, and latency, and it creates more failure cases you have to explain to employees.
I would accept throwing away code already written, or downgrading the system from an agent to a scheduled script, when that is enough to do the job and is easier to verify. Trading flexible automatic handling for a workflow that is easy to understand, predictable, and fixable is reasonable when it keeps the trust of the people who do the business work.
Use this piece in your agent
Get an API keyCopy the text below and paste it into Claude Code, Codex or whichever agent you use. The agent reads the piece and checks it against the repo you have open.
Read "A path to becoming an FDE with AI coding: the skills you need and your first trial project" on modernEngineer and apply it to this repo.
1. Call the content_get tool of the modernengineer MCP server with locale "en", slug "lo-trinh-tro-thanh-fde". If MCP is not connected or access is refused, read the page https://modernengineer.dev/en/library/lo-trinh-tro-thanh-fde instead.
2. Summarize the main steps of the piece and point out which apply to this repo.
3. Propose concrete changes and ask me before editing any file.Connect MCP in Claude Code (once)
claude mcp add --transport http modernengineer \
https://api.modernengineer.dev/mcp \
--header "Authorization: Bearer <API key>"This piece is open to everyone: without MCP, the agent can still read it straight from the link.
- Version
- v1.0.0
- Updated
- 29/10/2026
- Licence
- All rights reserved
- Slug
- lo-trinh-tro-thanh-fde
