A small software problem used to die in a budget meeting. If solving it required six engineers and six months, the value had to be large enough to justify the team. AI coding tools are changing that threshold, which means thousands of narrower problems may suddenly become worth solving.
The evidence is promising, but context matters. A 2026 paper in Management Science, a peer-reviewed journal about business and operations, reported field experiments with 4,867 developers at Microsoft, the software company; Accenture, the consulting firm; and one large US company. Developers with an AI coding assistant completed about 26% more tasks in those settings. The finding shows that AI assistance can raise output in some large-company workflows. It does not mean every developer becomes 26% faster.
Another experiment shows why that limit matters. METR, a nonprofit that evaluates advanced AI systems, found that 16 experienced developers working on public software projects took 19% longer with early-2025 AI tools. A 2026 update saw signs of improvement with newer tools but said the estimate was still unreliable because developers and tasks most likely to benefit were choosing not to take part. These studies tested different work, so one does not cancel the other. Together they show that AI can reduce implementation effort, but only when the tool fits the task and the surrounding workflow.
I think the strategic signal is strong enough to act on. As the cost of producing code falls across a growing set of tasks, the scarce skill moves toward understanding what should be built and making it work in the real world.
AI coding gains are real in some settings and uneven in others. The larger shift is that lower implementation cost makes more software worth attempting, moving value toward problem understanding and real-world fit.
Cheap code creates more reasons to build
The usual response to cheaper coding is to ask how many developers a company can remove. I think that misses the bigger opportunity. When the cost of building falls, the number of problems we can afford to solve rises.
Think about a planning tool for one factory, a claims check used by one insurance team, or a workflow for a specialist supplier. Many such systems never passed the old business case because they could not support a long development project. Faster implementation changes the economics, even when each system serves a small group.
This creates a useful paradox. AI lowers software cost, companies can build more software, and that software reaches narrower problems. Yet narrow problems often contain more local rules, limits in existing systems, and human judgment. Cheaper code therefore pulls valuable engineering work closer to the business rather than pushing it away.
Lower software cost can expand demand instead of merely reducing headcount. As companies tackle more specialized problems, local context becomes a larger part of the engineering work.
The valuable work moves upstream
A forward-deployed engineer, or FDE, is an engineer who works directly with a customer or business team to discover the problem, build the system, put it into production, and improve it through use. Palantir, a US data-software company founded in 2003, says it pioneered the role by embedding engineers with customers. In its 2020 filing with the US Securities and Exchange Commission, Palantir said time in the field helped improve its software platforms.
The title has since spread. OpenAI, the company behind ChatGPT, currently describes its FDEs as owning discovery, project scope, system design, building, and production rollout alongside customer engineers and people who know the business. That is different from waiting for a finished specification and turning it into code.
The operating loop is: Observe → Understand → Build → Evaluate → Learn → Improve. The FDE watches how work actually happens, connects the necessary systems and data, builds a first version, then studies where it fails. I think this loop matters more as implementation speeds up because every fast build becomes a chance to learn, not a reason to stop listening.
That focus is supported by RAND, a nonprofit and nonpartisan research organization. In 2024, RAND interviewed 65 experienced data scientists and engineers and found recurring causes of AI-project failure: teams chose the wrong problem or measure of success, built something that did not fit the workflow, lacked usable data, or could not support the system after deployment. These are failures of understanding and integration before they are failures of code.
The FDE owns the path from discovery to production rather than only the implementation step. Its value comes from shortening the learning loop between real work, software behavior, and the next improvement.
The rule that was never written down
Consider an illustrative insurance scenario, not a reported client case. An insurer wants to automate part of claims handling, so an FDE sits beside an experienced claims handler and watches the work. The AI recommends approving a claim, but the handler rejects it because the damage happened before the policy renewal.
The missing rule requires comparing two dates, yet it was never properly documented. This is tacit knowledge: know-how that people use in real work but have not fully written down. A model trained on the available process guide cannot follow a rule that the guide does not contain.
The valuable engineering work begins with the expert's correction. The FDE adds the date comparison to the workflow, saves the failed claim as an evaluation case, meaning a test with a known correct result, and runs the system again. Future changes must pass that case before release, so one human judgment becomes a lasting control.
This is also why human involvement cannot be added at the end. The US National Institute of Standards and Technology, a standards agency within the Department of Commerce, describes AI systems as socio-technical, meaning their results depend on technology, people, and the organization around them. Its AI risk framework calls for domain input, tests that match real use, production monitoring, and review of human overrides. In plain language, teams need to test the system against real work and keep checking it after release.
The claims example shows where the scarce work moves: discovering a hidden rule, turning it into a control, and testing it repeatedly. AI supplies implementation speed, but people still define what a correct outcome means in context.
Meanwhile in sci-fi
Arrival (2016)
In the 2016 science-fiction film Arrival, linguist Louise Banks tries to understand alien visitors by learning the full meaning of their written language, not by matching one symbol to one English word.
The mapping to forward-deployed engineering is direct: context-blind implementation can produce a neat but wrong answer, while embedded learning reveals what a decision means and feeds that meaning back into the system.
The new engineering unit is a three-way partnership
A domain expert is the person who knows how a particular job works, including its exceptions and signs of quality. The emerging unit is therefore Domain expert ↔ FDE ↔ AI. The expert supplies context and judgment, the FDE turns that knowledge into a working and testable system, and AI supplies growing implementation capacity.
This makes the domain expert more important, not less. Without that person, the team can automate the written process while missing the real one. Without the FDE, the expert's knowledge may remain trapped in conversation. The relationship works when both can watch the system, question its output, and improve it together.
I think one FDE will increasingly arrive with an invisible engineering team. AI agents, software that can carry out multi-step tasks with tools, can help write code, inspect data, and run tests. The FDE directs that capacity, checks its work, limits what it can change, and keeps responsibility with named people. More output is useful only when the team can judge it.
The pattern reaches beyond engineering as AI takes on more production and people spend more time on context, judgment, evaluation, and directing the work. It also changes consultancies. Selling implementation capacity becomes a weaker proposition when implementation gets cheaper. A stronger one is the ability to enter an organization, understand how it really works, collaborate with its experts, and turn that knowledge into a functioning AI-enabled system that the organization can eventually own.
The core AI-era team links domain judgment, embedded engineering, and machine capacity. This gives one FDE greater reach, but it also makes evaluation, limits, and clear human ownership more important.
A forecast leaders can test
The FDE is most useful when a workflow is valuable, full of exceptions, and difficult to specify from a meeting room. A normal product team may be the better answer when requirements are stable, the workflow is already understood, and long-term ownership is clear. The point is not to rename every engineer.
A bounded engagement should start with a named business owner and a measured starting point. Before building, the team sets limits on data and system access, a clear quality threshold, and the person who can stop the rollout. The engagement should also have an end. Ownership passes to a local team that can run and improve the system, or the work stops if it cannot beat the old process on quality and total cost.
The evidence behind this article is mostly from US organizations and does not provide a comparable Nordic production case. Nordic and European leaders should treat the FDE as a model to test locally, not a title to copy. That test should include the right workforce representatives, a supplier exit path, human stop rights, and cost per correctly handled outcome before the build begins.
This is a forecast, and it should be possible to prove it wrong. If FDE-style teams cannot improve the time to an accepted outcome, the quality of that outcome, actual use, and clean transfer of ownership, then the role may remain a useful niche rather than the shape of engineering to come.
Still, I think the direction is right. The old software contract was, “Tell me what to build and I'll code it.” It is becoming, “Tell me the problem and I'll build it.” The next step is more ambitious: “Show me how your business works and I'll help figure out what we should build.”
AI is making software cheaper and faster to build, but that does not eliminate the need for engineers. It changes where valuable engineering work happens. The sharp question is no longer only, “How many developers will we need when AI writes the code?” It is, “What could our engineers do if writing the code was no longer the limiting factor?”
Forward-deployed engineering is a testable operating model, not a universal title change. If it works, engineering value will move closer to context, judgment, evaluation, and the people who know what a good outcome looks like.
