This article comes from the WeChat public account: Budong Jing, author: Jing Shu, original title: "The Hottest New Job in the AI Industry Exposes an Awkward Fact | Budong Jing Website"
Over the past three years, when many people walked into the office, the first thing they noticed was often not a new button on the screen, but a workstation missing beside them.
"Artificial intelligence" and "layoffs" are appearing in the same news stories more and more frequently. AI has become a variable that management cannot avoid when recalculating staffing needs. Many occupations are being broken down into tasks that machines can participate in, undercut, or even take over.
In an article a few days ago, I discussed a recent prediction by Musk: by the end of 2027, AI will be able to complete any digital task at superhuman levels, and what temporarily falls outside its capability boundary is work that requires "shaping atoms."
This is a radical prediction, and task capability does not mean jobs will disappear at the same pace. But it makes the dividing line very clear: labor that can stay entirely on screens, in text, code, and databases is more likely to fall within the capability boundary of AI models.
Even earlier, Nassim Taleb posted a tweet saying that all occupations invented in the 20th century would hardly escape AI's impact. Among the "people not threatened by AI" he listed were plumbers, gardeners, chefs, elephant trainers, and circus performers—almost all ancient jobs that rely on the body, on-site presence, and concrete materials.
I call the underlying pattern here the "reverse historical evolution law of AI replacement": the later humanity invented a job and the more it depends on abstract symbols, the more likely it is to be hit first.
So white-collar work bears the brunt—AI is like a white-collar compressor.
However, the same technological explosion is also creating new jobs and pushing some old ones to the center of the value chain. Over the past two years, a role that has become red-hot again at AI companies is called FDE, Forward Deployed Engineer, which can be literally translated as "Forward Deployed Engineer." It spans engineering, consulting, sales, and implementation: walking into customer organizations, connecting data and legacy systems, understanding processes, handling exceptions, and staying on top of things until the model is truly adopted.
There is an irony hidden here: an industry that sells automation currently most wants to hire people who can personally enter organizations and understand reality on behalf of machines.
The rise of the FDE is like a cross-section, revealing where human labor will migrate once intelligence becomes cheap: from producing answers to understanding context, driving adoption, and bearing consequences.
To understand why this role suddenly became critical, we must start with a blank timestamp.
According to Vinoo Ganesh's recollection, in 2013, a Palantir trading data system encountered a blank timestamp at a bank.
The blank value was read by the system as the starting point of Unix time, January 1, 1970. The database then dutifully created a storage interval for every 10 minutes thereafter, generating about 2.3 million keyspaces in one go. The server's memory was exhausted; to restart, it would theoretically require 14TB of memory.
This system had always performed well in environments engineers could control. The design was methodical, and the tests passed. Until it encountered real financial data. Real data has missing fields, uses strange formats, preserves errors for years, and then makes everyone so accustomed to them that they no longer seem like errors.
Ganesh was a product engineer at Palantir at the time. Afterward, he began flying to customer sites to fix things he had previously been unable to see. He later summarized this experience very accurately: what they lacked was not a more complete requirements document, but the fact that no one was ever standing in that building, accountable for the gap between design and everyday reality.
That is how he became an FDE.
Thirteen years later, in 2026, Ganesh recently called the FDE "the hottest job in the AI industry" in an article. This is certainly not a rigorous job ranking, but it reflects market dynamics.
In May 2026, OpenAI specifically established a "deployment company" and, through the acquisition of the applied AI consulting and engineering firm Tomoro, brought in about 150 FDEs and deployment experts in one stroke; as of this writing, its careers page shows 24 positions when searching for FDE, spread across the US, Europe, and Asia. Anthropic is also hiring FDEs and corresponding managers. Andreessen Horowitz (a16z) held its first-ever eight-week FDE Fellowship this year, selecting 65 people from thousands of applications.
Multiple leading AI companies are hiring this kind of person who needs to enter customer organizations, understand processes, write code, drive adoption, and stay on top of things until the system truly runs.
Treating "hottest" as an industry-wide ranking, the evidence is not yet sufficient. Treating it as a thermometer, the reading is already very high.
This is somewhat awkward.
AI companies are supposed to sell machine intelligence. But the people they are currently scrambling to hire are understanding reality on behalf of machines.
The awkwardness exposed by the FDE boom is: cleverness alone is no longer enough to be a product.
Musk: By the end of 2027, AI will smash the rice bowls of all intellectual workers
"All occupations invented in the 20th century will hardly escape AI's impact!"
A hot job that cannot even clearly explain what it is
Ganesh once ran a rotation program at Palantir called Project Frontline, sending software engineers to the front lines; about 250 people participated. According to him, many of them later went on to lead deployment teams at companies like OpenAI, Anthropic, xAI, and Anduril.
Interestingly, this group of people who know FDE best still has no common definition.
Ganesh attended a peer dinner in San Francisco, where the table was seated with FDEs from Snowflake, Anthropic, and several startups. As they chatted, everyone discovered that the same job title contained several completely unrelated kinds of work: some were sales engineers who only joined on the second sales call; some carried sales quotas while also knowing how to write Python; some were more like consultants entering with project contracts; and some belonged directly to product teams.
Someone even seriously asked in the group: a consulting firm is already sitting at the client—how should our FDE divide responsibilities with them?
This is not what a mature profession looks like. But the definitional confusion precisely shows that companies have already seen a crack open between product and reality; they just don't yet know whether that crack should be the responsibility of sales, consulting, delivery, or product.
The most fascinating economics of traditional software is replication.
Once a product is written, it can be sold to a thousand companies. The first customer bears the development cost, while later ones only add a bit of server and support cost. Software has thus become one of capital's favorite businesses: revenue can grow detached from headcount, and the product can continue circulating detached from its maker.
Enterprise AI has run into a different reality. Even after reading all public financial rules, a model does not know that what this company calls "customer" is called customer in the sales department, client in the operations department, billing entity in the financial system, and org_id in the code. It can generate a perfect process, but it does not know who has the authority to approve exceptions at 11 p.m., nor which four-year-old spreadsheet the entire department will secretly switch to when that person is on vacation.
The model faces the general world. Companies live in their own dialects.
This gap has long existed in enterprise software. AI has magnified it, because the model's demo effect is so good. A beautiful chat window can let management see the future in 10 minutes; but going from demo to production requires passing through data permissions, legacy systems, approvals, compliance, performance reviews, office politics, and accountability. The capability is already on the table, but the organization has not yet built the road for it.
The FDE is the road builder.
Of course, the FDE is not a profession that sprang out of nowhere in the AI era. Palantir was doing similar work more than a decade ago, and sales engineers, implementation consultants, and solutions architects have existed even longer. What changed is their relative position. After general generative capability started becoming cheap, the gap between the model and the specific organization shifted from an after-sales cost to the critical pass determining whether the product can succeed.
AI did not invent on-site labor. It pushed on-site labor from a back-office cost to the center of the product.
The last generation to enter the asset class on a salary is being terminated
When AI has done the work for you, what ability does a person rely on to be paid by the market?
FDE: the digital blue-collar worker of the AI era
To put it even more bluntly, what an FDE does is blue-collar work in the digital world.
That said, blue-collar has never meant mindless. A good plumber has to judge where the leak is, what the pipe pressure is, and how the whole building is wired; get it wrong, and one kitchen can flood half a floor. The real condition of blue-collar work is that labor is tied to a specific site: wherever the fault is, the person has to go; whenever something breaks, they have to come back; whether the work has value depends not on how beautifully the proposal is written, but only on whether it gets fixed in the end.
The FDE is the same.
The customer's failures dictate his time, the customer's exceptions interrupt his plans, and whether the customer actually adopts the solution determines whether the project has value. Delivering code usually isn't the end. When the system breaks, someone still has to come back, find the cause that was never written down in the docs, fix it, and then explain the outcome to the specific people involved.
Software companies used to make their money from replication; what makes an FDE valuable is showing up on site. He faces one set of permissions after another, a few dirty tables nobody dares to delete, and a manager whose sign-off nobody dares to substitute for while he's on vacation. Every customer comes with their own quirks, and every deployment means going back down into the field.
AI hasn't driven programmers into the factory. It has turned them into repair workers of the digital world.
A plumber can't sit at headquarters and write a universal fix for a thousand leaky kitchens. What the FDE handles is all bits, yet his value is just as stuck to specific customers, specific relationships, and specific consequences. What he sells is no longer just a piece of code, but also his ability to rush to the scene, understand the chaos, and clean up the mess.
Whether this blue-collarization will change the commercial nature of software depends only on what a single fix ends up leaving behind. If it merely gets the current customer running again, the company is selling expensive billable hours; if it becomes a platform capability so that future customers don't have to pay the same tuition again, repair turns back into a product.
The FDE stands right on this hinge.
When intelligence becomes an industrial product, knowledge work starts to be re-priced as a service
The "reverse historical law of AI replacement" I've summarized roughly answers which professions are exposed to machines earlier. The FDE fills in another question: once code, reports, contracts, and analysis are mass-produced by models, how will the remaining human labor reorganize itself?
AI turns answers into industrial products, and turns implementation back into a craft.
Models are mass-producing code, reports, and analysis, while the FDE has to visit customers one by one. The unit cost of the former keeps falling, while the latter remains bogged down by exceptions, coordination, and accountability. The dirty work once hidden in software's back office hasn't disappeared—it has suddenly become the most expensive part.
The rise of one new job cannot offset the disappearance of many old ones. Nor should the FDE be used in the comforting story that "technology always creates more jobs." Public data isn't yet sufficient to compare the totals on both sides; what it truly reveals is a structural change: fewer people may be needed to produce answers, but the people needed to bring answers into reality move closer to the center of value.
This blue-collarization is happening inside the software industry itself. The price of generic code keeps falling, while the price of figuring out why one particular company's code won't run rises instead; answers increasingly resemble industrial products, while embedding answers into an organization and turning them into results increasingly resembles a service. Human value hasn't neatly retreated to farms, factories, and kitchens—it is also retreating to the repair sites of the digital world.
The economist William Baumol studied a class of relative price changes. A factory can use machines to raise output tenfold, but a string quartet can hardly compress a 40-minute performance into 4 minutes. As high-productivity sectors keep lowering unit costs, activities that still depend on people and time appear increasingly expensive. This later became known as "Baumol's cost disease."
This theory can't directly prove that the FDE will exist forever, but it explains why the current bottleneck has suddenly become conspicuous. The unit cost of a model writing a piece of standard code, producing a summary, or generating an analysis is falling fast. Finding where the customer is actually stuck, coordinating several departments that distrust each other, judging whether an anomaly can be handed to a machine, and finding someone willing to sign off after something goes wrong—these tasks improve in efficiency far more slowly.
So the faster the models get, the more expensive the parts that must wait for humans become.
In the past, professionals held the power to diagnose, the power to act, and the power to charge, all because they possessed answers others didn't have. Doctors knew the name of the disease, lawyers knew the statutes, engineers knew how to write programs. The stock of knowledge itself was the professional boundary.
Once models began supplying answers at scale, these powers were split apart. Someone who knows the answer may not be able to find the real problem; someone who can propose a solution may not be able to push the organization to adopt it; and a system that generates recommendations certainly won't automatically bear the consequences of those recommendations. Professional value has begun migrating toward three inseparable things: defining the problem, completing the intervention, and accepting accountability.
I've said before that "knowledge arbitrage is dead"—meaning the stock of knowledge is increasingly unable to command a premium on its own. The FDE pushes this judgment one step further: when answers can be copied infinitely, professional value migrates toward intervention, adoption, and consequences.
This still doesn't guarantee that workers will earn more. The added value could well be captured by platforms, employers, or powerful customers. The appreciation of service labor may also just mean one engineer being stuffed with more customers, subjected to finer surveillance, and saddled with vaguer responsibilities.
The market acknowledges that context is valuable, but pricing power doesn't necessarily shift into the hands of those who provide the context.
The real winners of the AI era aren't the people who can use AI, but the people who hold pricing power
While ordinary people grind away at AI, the masters are practicing something else
The model can read the entire workflow, but it can't read why she insists on using CSV
Ganesh told another story.
The startup he was at spent nearly a year trying to get customers to migrate their data format from CSV to Parquet. A data quality engineer blocked the migration every time. Her reasons kept changing: Parquet was worse, unusable, incomprehensible. The team talked to her about storage costs, compute efficiency, and pipeline optimization, and every correct argument hit a wall.
Eventually, they sent an FDE to sit beside her and watch how she worked.
Every day, this engineer downloaded CSV files from Amazon S3 to her Windows laptop, double-clicked to open them, and checked them line by line with her own eyes. That was her data quality tool. At the time, Parquet had no local viewer she could use directly. In her eyes, the so-called migration meant taking away her only pair of eyes and handing her a slide deck about "efficiency gains."
The team built a Parquet viewer that same night. Two days later, she approved the migration, and the data pipeline's runtime dropped from about 17 hours to 2 hours.
Why hadn't she stated the real reason earlier? Because from her position, it didn't even count as a "requirement." Double-clicking a file and scanning a few lines was a gesture left over from doing the work by hand for years. People can often tell you what they want, but rarely which habits have become part of their environment. A fish doesn't proactively report the specifications of the water.
The most important knowledge in enterprises often exists in exactly this way.
It hides in a spreadsheet nobody dares to delete after someone leaves, in two departments' different understandings of the same term, in the detours never drawn on the process diagram. The people holding this knowledge may not even realize they know it. Interviews can't draw it out, documents can't find it, and models naturally have nothing to reason from.
Technology has never run automatically on its own. It needs interfaces, permissions, operating habits, evaluation standards, maintainers, and accountable owners to form an environment. AI entering an enterprise is like an unfamiliar organism being dropped into an old ecosystem. The FDE appears to be deploying models, but is actually building an organizational environment in which it can survive.
Models manufacture answers; the FDE repairs the reasons answers can't act.
But don't romanticize this into the belief that humans forever hold some mysterious advantage. Logs, screen recordings, long-term memory, and more capable agents may all continue to swallow part of it. For now, the human advantage lies in one plain action: when a failure occurs, he knows to stop and look at what that person is actually doing.
One day, machines may learn to look, too.
A digital blue-collar worker—and possibly the last craftsman of the software industry
Here an interesting conflict emerges.
Harry Braverman worked for many years as an industrial worker. In 1974, in *Labor and Monopoly Capital*, he analyzed how management separated conception from execution: workers' knowledge was extracted, codified, and concentrated into the management system; a complete craft was broken down into motions that could be specified, measured, and replaced.
Many people mistakenly believe that "deskilling" simply means work no longer requires intelligence. What Braverman was really watching was control. Even if a person makes complex judgments all day long, as long as he cannot see the whole process, cannot set the pace, and has no authority to change the rules, he may still be in a state of deskilling.
AI is well suited to completing this extraction. The code, debugging methods, and architectural experience left behind by excellent programmers enter the model, and then return to everyone's screen in the form of tools. Headquarters engineers may increasingly do less building from scratch, and instead spend more time reviewing model output, handling escalated tickets, and fixing localized errors exposed by metrics. He still uses his brain, only his own knowledge increasingly resembles fuel for the platform.
The FDE may also head down this road. The client's timeline sets the pace, the sales commitments set the boundaries, and delivery metrics determine which problems are worth solving. The job title sounds like a special forces unit, but the actual experience may be closer to a repair crew lugging laptops from site to site.
But the sociologist Richard Sennett, in *The Craftsman*, offers another yardstick. He cares about how the hand and the mind correct each other through feedback from materials. A craftsman does not merely "think" and then hand the motions to someone else. He encounters resistance in the making, adjusts his judgment, and keeps learning from the new results.
Measured by this yardstick, the FDE may look more like the craftsman of the software age than the headquarters engineer.
He discovers problems, understands the business, writes code, watches people use it, revises the solution, and bears the consequences. He touches the entire chain from the moment a problem appears to the moment the system runs. The fragments scattered across product, sales, implementation, and customer support are rejoined in his hands.
AI has therefore not pushed the entire software profession in one direction. It has split the profession in two.
Generalized production near the model center increasingly resembles an assembly line. Deployment near the customer boundary increasingly resembles a craft. I would call this emerging split: deskilling at the center, reskilling at the edge.
This is not a conclusion you can draw from a job title; it depends on how the company designs its feedback loops. The job descriptions at OpenAI and Anthropic both require FDEs to write repeatable field patterns back into tools and products. If he only handles tickets and chases deadlines, Braverman's judgment is closer to reality; if he can go all the way from discovering a problem to changing the platform, then the complete process of making that Sennett describes truly appears.
The subtler point is that what the FDE repairs is often not just software.
Enterprises first stuff AI into old processes, having employees use it to write emails, reports, and code. After deep deployment, the FDE begins to redraw the processes: which steps get eliminated, which judgments are handed to machines, what counts as an anomaly, who anomalies get escalated to, and who retains veto power.
He begins to participate in designing the labor system of the client's company.
This work may eliminate a great deal of drudgery, or it may extract the judgment accumulated by frontline staff over many years and harden it into a set of rules they have no power to change. To judge whether it brings liberation or control, you only need to track one question: after the transformation is complete, who has more power to define "normal," who can change the rules, and who is responsible for explaining errors?
This is the real power of the FDE. Writing code is merely its most visible part.
Upward class mobility is coming to an end in the AI era
The privilege of the future is the ability to exit; the divergence of exits will matter more than the gap between rich and poor
Is the FDE a new kind of service industry, or scaffolding before the product matures?
Following this trend and logic, many people might conclude that the stronger AI becomes, the more software companies depend on people; the software business of the future will turn back into labor-intensive services.
That conclusion comes too early.
General-purpose technologies entering enterprises are often accompanied by costly organizational transformation. A study on the "productivity J-curve" describes one such path: enterprises first co-create processes, train staff, reshape business models, and accumulate intangible assets like software; the costs appear first, and the productivity gains may only show up later.
The FDE may be the temporary scaffolding of enterprise AI.
The data cleaning, connectors, eval frameworks, and operational templates they build in the field today may, tomorrow, partly make their way into the platform. OpenAI's own job description lists "turning effective patterns into tools, playbooks, and components, and using field feedback to change the product and model roadmap" as an FDE responsibility. A truly excellent FDE team should, in the long run, even aim to make itself unnecessary at every existing customer.
If the J-curve explanation holds, today's cohort of "digital blue-collar workers" is merely scaffolding before AI products mature. The labor required per generation of customers should decline, and field craft will gradually solidify into product. If headcount keeps growing in lockstep with customer numbers, that J-shaped curve never turns upward, and the company is still selling services.
This is precisely Ganesh's sharpest criticism of his peers.
He once spent an afternoon writing a piece of throwaway code for a client, naming the file simply "vinoo.groovy." "Vinoo" is his name, ".groovy" is the script file extension — in plain language, "the script Vinoo jotted down." It was never supposed to survive a week. A year later, it was still running inside a client organization of nearly a hundred thousand people, and the team maintained it for many more years.
A brilliant firefight did not become a product; it left only a long-term debt of favors and a technological fossil bearing the author's name. The fork between service and product hides in what happens after the fire is out.
If a field problem only satisfies the current customer and the next customer starts from zero, the company is selling expensive person-hours. But if that mistake changes the underlying platform so that later deployments are faster, cheaper, and more reliable, service labor has sedimented into an asset.
So don't just count how many FDEs a company has hired. The more valuable numbers are: can one FDE serve an ever-growing number of customers? Has the time from signing to production shortened for new customers? Is the proportion of field fixes that make it into the core product rising?
At present, I have not found enough public data to answer these questions. The hiring boom only proves that deployment labor is at the strategic center at this moment; it cannot prove that its total volume is growing, let alone that it will become a stable end state.
This is also the most honest thing about this role. It puts the costs of the AI economy, hidden behind demo videos, back on the table.
The old promise of software was: create once, copy infinitely. Enterprise AI today adds a line to the ledger: for every unit of intelligence sold, how many people must go in to interpret reality, change organizations, repair failures, and bear the consequences?
The answer is leaving the humans, but the consequences are not.
If an AI company must, with every sale of "intelligence," send in another person to understand reality on its behalf, what exactly is it selling?【Got it】