Hi, I'm Xiao Aba.
In the AI era, I find coding more and more boring...
It used to take me half a day to write an API; now I hand the requirements to AI, and by the time I've poured myself a glass of water, it has generated the code, comments, and tests.
It felt great at first, but over time my daily work became more and more like a mechanical assembly line—copy the requirements, wait for generation, check for errors, fix and submit—almost no thinking required.
So I entered a daydream: is there a job where I can keep doing technical work without sitting at my desk waiting for requirements all day?
Right then, I came across a job posting with a monthly salary of 100,000: DeepSeex was hiring an FDE.
FDE?
At first glance, I thought the acronym stood for Frontend Developer Engineering, i.e., a frontend developer.
I was puzzled: a frontend job paying 100,000 a month? Since when did frontend make a comeback?
I clicked into the job details, and it was nothing of the sort.
FDE stands for Forward Deployed Engineer, a role that has become especially hot in the AI industry over the past two years.
Simply put, many companies want to use AI to boost efficiency, but they can't even articulate what the first step should be—what problem to solve, where to start, and who will ultimately use it; they may not have figured that out themselves. What an FDE does is go on-site with the customer and turn these vague requirements into a system that can go live and that people actually use.
Huh, that's interesting? Isn't that exactly the kind of work I want to try?
So I casually submitted my resume, and to my surprise, just 2 days later, I was hired by DeepSeex, this AI company!
However, since I had no FDE experience, they only offered me a starting salary of 70,000 a month.
That's fine—I was already quite satisfied.
So I decisively shut down my company, "Yuyuan Network," and reported to the new company the next day.
My mentor was called "Nailong Masike," a seasoned FDE with two and a half years of practice.
On my first day, he didn't bother with small talk and directly assigned me my first project: the client was a garment factory that produces suspenders.
Understanding the client's goals
Before the project started, Masike took me and a sales colleague to a meeting at the garment factory. The production manager, the maintenance supervisor, and the person in charge of information systems were all present.
The production manager said: We want to build an AI repair-reporting assistant to make it easier for workers to report repairs, and to keep maintenance records. Once we have more data, ideally it could even predict when machines will break down.
Masike asked: How much machine operating data does the factory have now?
The meeting room suddenly fell silent...
The maintenance supervisor flipped through his notebook and said, somewhat awkwardly: Right now we only have a machine inventory, paper repair slips, and chat logs in our work group. We've never specifically collected data like temperature, vibration, or running time.
Without this historical data, AI cannot learn the patterns of change before a machine fails, so prediction is out of the question.
Masike thought for a moment and said: Then let's first streamline the repair-reporting process, have AI help workers organize repair reports, and at the same time save each fault description and repair result in a structured way. This solves the immediate efficiency problem while also accumulating data for future fault prediction.
The production manager agreed to this plan. Then the person in charge of information systems added a requirement: repair-report audio and maintenance records must stay on the factory's own servers, and the new system must not directly modify the existing data.
At this meeting, everyone set aside the idea of predictive maintenance for now, and we settled on just one goal: first get the repair-reporting process working, so workers can report repairs faster and maintenance records are more complete.
But to figure out exactly how to do it, we had to go into the workshop.
Going on-site for research
The next day, the production manager assigned Master Wu from Workshop A to show me around. Master Wu had worked at this factory for many years; he operates a sewing machine more skillfully than I type on a keyboard, and if a machine sounds even slightly off, he can tell right away.
First, I followed Master Wu through the complete repair-reporting process.
- When a machine has a problem, the worker first calls the team leader, who then contacts the maintenance staff. The call itself takes only a dozen seconds, but afterward the fault situation has to be relayed repeatedly.
- When the maintenance staff arrive on-site, they have to re-confirm which machine it is, when the problem started, and what the symptoms are.
- After the machine is fixed, the worker still has to fill out a repair report. Some write it on paper, some post it in the work group chat, and some, once busy, simply forget to record it. The next time a similar fault occurs, the maintenance staff can hardly find the previous solution from these scattered records.
Wow, what a mess!
But clever me quickly had an idea: workers speak the problem into their phones, AI automatically organizes it into a repair ticket, and the ticket is pushed to the maintenance staff. Once the machine is fixed, the maintenance staff record the result via voice or quick-select options.
The whole process looked like just 3 steps, and I even thought this project would be easy.
A mere FDE—no big deal~
However, as I talked more with Master Wu, I realized things weren't that simple...
The same machine: Master Wu calls it "Machine No. 3," Master Kang calls it "the old flat-bed," but its official name in the factory's computer is "Workshop A Flat-bed Sewing Machine No. 03."
If the AI can't even figure out which machine a worker is talking about, everything afterward is useless. So Masike had me first record all the various names workers use for each machine, and figure out the mapping between these nicknames and the official numbers.
Who would have thought—I assumed that once I got the project I'd go back and write code, but instead I was standing in the suspender workshop with a notebook, recording machine nicknames.
Honestly, at this point I was already feeling a bit uneasy: isn't FDE a technical role? How did I end up doing odd jobs? Other people's onboarding is reading docs; my onboarding is memorizing machine nicknames???
After walking through the process and recording the machine nicknames, we re-examined the goal. In the meeting room, the client had thought "AI helps workers report repairs," but on-site we discovered the real bottleneck was the flow of information from workers to maintenance staff: workers can't clearly say which machine it is, fault information gets lost through repeated relaying, and after the repair, no record is left behind.
So we adjusted the goal: workers only need to clearly describe the problem; AI handles organizing the ticket, filling in missing information, and helping maintenance staff look up similar past records. As for why the machine broke and how to fix it, that's still the maintenance staff's call.
Defining the plan and acceptance criteria
Back in the meeting room, Masike threw out a question: two weeks from now, what will we deliver that satisfies the client?
I scratched my head and said: Just develop the AI repair-reporting system and deploy it, right?
Masike shook his head: "Deployed" is not an acceptance criterion. The client doesn't care what you deployed; they care whether workers report repairs faster and whether maintenance records are kept. Both sides need to agree in advance on specific numbers—only meeting them counts as successful delivery.
So we went through the repair records from the past week and found that maintenance staff took an average of over 6 minutes to receive complete fault information, and after machines were fixed, fewer than half of the repairs had a recorded result.
Based on this data, we agreed with the client on 4 acceptance metrics:
- Repair information must reach the maintenance staff within 2 minutes, and tickets must no longer be sent to the wrong workshop
- At least 90% of repair tasks must have a complete record
- At least 80% of pilot workers must actually use the new process
- In addition, the AI's accuracy in organizing key information must reach 90% before the system can enter trial use in the workshop.
Once the criteria were confirmed, I got Master Wu to join me for a round of testing in a quiet office.
Master Wu spoke into the phone: Machine No. 3 has been making a clunking noise lately.
Although the AI didn't mishear a single word, it matched the work order to Workshop B.
After analysis, the reason was simple: both workshops had a machine called "Machine No. 3."
What a headache—the AI understood Mandarin, but not this factory's "factory talk"!
So I gave up on the approach of having the AI identify machines based solely on workers' verbal descriptions, and instead put QR codes on every machine. This practice is actually quite common in manufacturing—many factories' equipment management systems rely on scanning codes to locate machines. Workers first scan the code to confirm which machine it is, then describe the fault.
I first verified the machine numbers and locations with the colleague in charge of information systems, bound each QR code to its corresponding machine, and then spent an entire day sticking them up one by one in the workshop.
Before joining, I thought an FDE's tech stack was frontend, backend, data, and AI.
Only after entering the factory did I realize I'd damn well also have to know how to stick up QR codes???
After a few more days on the job, I felt I could add a line to my resume: stickers applied straight, bubble-free, blazingly fast.
Building the eval set
After QR code scanning solved the problem of "the AI can't tell which machine it is," I thought the biggest obstacle had been cleared.
But Code Ripper didn't see it that way. He said: Master Wu says one sentence and the AI happens to answer correctly—that only counts as getting a demo to run. To truly meet delivery standards, you need to test with several hundred real repair records and see whether the overall accuracy is good enough.
This kind of testing is generally called Evals in the AI industry. You can think of it as preparing a fixed set of exam questions for the AI. Every time you adjust the prompt, model, or processing logic, you rerun the same batch of cases to see whether accuracy has improved.
Evals are a crucial part of how an FDE runs AI projects. When customers accept a project, they won't just watch you demo one or two cases—they'll want to see the actual accuracy from several hundred real data points.
Once we understood this, we started preparing the test data. The factory's maintenance supervisor and I dug out a stack of paper repair tickets from the past year—many pages had yellowed and were stained with machine oil. The records in the work group chat were just as haphazard: some people wrote "needle broke," some wrote "broken needle," and some left only "same as last time."
It took us two days to sort out 300 real cases from these materials.
As expected, the first round of testing failed quickly.
Words that were perfectly clear in the office weren't necessarily clear in the workshop. With hundreds of sewing machines running simultaneously, the background noise was loud, and the AI often heard "thread break" as "power outage" and "skipped stitch" as "dropped needle."
After running all 300 tests, only 81% of the key information was extracted correctly—well short of the original 90% acceptance standard.
Moreover, past repair records were hard to search: the same fault had several different names in different workers' mouths, so the AI couldn't find the truly relevant historical records.
To address these problems, we did several rounds of targeted optimization: first, we added noise reduction to the speech recognition stage. Then we added an error-correction dictionary of common workshop expressions (for example, automatically correcting "power outage" to "thread break" in an equipment context), and reorganized the paper repair tickets and group chat records into the database with unified terminology.
After rerunning the full test suite, accuracy improved from 81% to 93%, meeting the acceptance standard.
Of course, this eval set wasn't something to use once and throw away. After the system went live, newly emerging failure cases would be continuously added to it as the basis for the next round of optimization.
On-site trial and revision
After the eval set passed, the system entered a trial in Workshop A.
And then it failed again...
Although overall accuracy had reached 93%, there was still that 7% of cases where the AI would get things wrong. Not quite reassured, I added a confirmation form to the interface: after workers described the problem, they had to check each item the AI had filled in—machine name, problem type, and time of occurrence—before submitting.
After swiping through two screens, Master Wu asked me: I used to just make a phone call and be done in ten-odd seconds, and with your thing I have to stare at a form for ages?
I felt a bit guilty. The customer originally wanted to reduce the time workers spent reporting repairs and filling out forms, yet out of fear of AI errors, I had added a whole pile of confirmation steps for the workers.
When Code Ripper learned about the situation, he started ripping into me.
He said, 93% accuracy already exceeds the acceptance standard. To guard against that 7% of errors, you're making 100% of workers do an extra full page of form-filling every time—the math doesn't work. Better to let the AI judge for itself when it's unsure, and only ask a follow-up question when it's uncertain; in most cases it should just submit directly.
That made sense to me, so I revised it accordingly. The AI would only ask a follow-up question when it hadn't heard clearly or was missing key information, no longer making workers check everything every time. After maintenance staff fixed a machine, they could also record the outcome via quick-select options or voice.
During the on-site trial, Code Ripper and I reported progress to the production manager and sales colleagues every two days. I spent my days testing with workers and collecting feedback, and my nights back at the hotel revising the system and rerunning the eval set—it was exhausting.
But coordinating all parties was far harder than writing code. The production manager wanted to see results quickly, the colleague in charge of information systems worried the new system would disrupt normal production, and frontline workers were reluctant to add steps to their workflow. All these concerns pulling in different directions had to be addressed one by one before the system had a chance to be truly adopted.
Launch and acceptance
After the two-week pilot ended, we carried out acceptance testing item by item against the previously agreed metrics.
The delivery time for repair information dropped from over 6 minutes to under 2 minutes, there were no more cases of work orders sent to the wrong workshop, the complete-record rate for repair outcomes rose from less than half to over 90%, and more than 80% of pilot workers started using the new repair reporting process.
After meeting the acceptance standards, the production manager agreed to roll the system out to other workshops. The sales colleagues took the acceptance results and continued discussing follow-up cooperation with the customer.
On the second day after the system was rolled out to Workshop B, the maintenance supervisor called me. Workshop B had several special machine models, and the terms workers used to describe faults were completely different from Workshop A's—the AI started mismatching again...
So I had to rush to the site that same day, add a batch of new error-correction rules, add the failure cases to the eval set, and rerun the tests before the Workshop B system finally stabilized.
So painful...
Unlike ordinary outsourcing, where you deliver and leave, once the system is live and something goes wrong, an FDE has to rush to the site and fix it yourself, first thing.
At the project wrap-up, Code Ripper had me organize the system's configuration methods and common issues into documentation, and walk the colleague in charge of information systems through the routine maintenance process.
He said: An FDE can't leave the customer helpless without you—you have to make sure their team can take over on their own, otherwise you'll be getting endless calls later.
After completing the handover, I finally returned to the company. We brought the lessons learned from this project back to the product team, including the QR code binding solution, the speech error-correction method for noisy workshop environments, and the approach to structuring repair records. The product manager felt the speech processing capability for noisy environments could be built into a general-purpose module and incorporated into the product, so other manufacturing customers could use it directly.
My reflections
Only after finishing this project did I truly understand what the FDE job is.
Before, I thought it was just going to the customer's site to write code. Actually doing it, I found it far more complicated than I'd imagined.
An FDE must first confirm the customer's real goals, pulling unrealistic requirements back within the bounds of what the current data and conditions can support. Then follow frontline users through the real workflow to find the genuine problems hidden in daily operations. Then define the solution and quantifiable acceptance metrics, develop the system, build the eval set, and move into on-site trials. Revise repeatedly based on user feedback until the system actually runs and people use it. Finally, bring the on-site experience back to the product team to make the product better.
The specific work of FDEs varies quite a bit across companies. Some focus purely on technical delivery, with dedicated staff handling business matters. But at many companies, FDEs also participate in technical assessments during the pre-sales stage, and even help customers discover new AI use cases to drive follow-up collaboration. Some FDEs serve several customers at once, while others are stationed at a single customer site for months. But the core is the same: standing between the customer and the technology, turning vague problems into systems that can go live, get used, and generate business value.
I think this job is not easy at all—in fact, it's quite challenging.
OpenAI's current FDE role requires up to 50% travel, and on real projects you may need to stay on-site at a customer for weeks or even months. Beyond front-end, back-end, and AI application development skills, you also need to be able to break down vague problems, establish eval methods, handle enterprise-grade system integration and production deployment, and communicate smoothly with customers' technical leads, business leads, and frontline employees all at once.
If you enjoy studying real businesses, are willing to work with people from different industries, and can build systems with your own hands and watch them being used, this job can be very fulfilling. If you just want to quietly write code, aren't willing to travel or work on-site, or don't want to deal with vague requirements, FDE may not be for you. By steadily learning AI programming and AI application development, you can still find a good direction.
OK, that's all for this share. If you also want to learn AI programming or AI application development, check out my free open-source Zero-Basics AI Programming Tutorial and original hands-on AI application development projects.
I'm Yupi, continuously sharing AI programming tips. If you found this useful, remember to like, save, and follow.
Do you have friends working as FDEs? Or have you had a similar on-site experience yourself? Feel free to share your thoughts in the comments.