Practitioner-focused article on forward-deployed engineering and software factories and what they mean for engineering leaders and founders.
Introduction — The Middle Is Disappearing
What forward-deployed engineering and software factories mean for how you hire, organize, price, and build.
For twenty years, the archetypal software engineer sat comfortably in the middle of a value chain. A product manager gathered requirements, a designer drew the screens, and the engineer — insulated from the customer on one side and from the deployment machinery on the other — turned a spec into code. That “build features against a backlog” product engineer was the center of gravity of the whole profession.
That center is now being pulled apart from both ends.
At one end, engineers are being pushed outward, toward the customer, into the messy specifics of a single account’s data and workflows — the discipline the industry now calls forward-deployed engineering. At the other end, engineers are being pulled upward, away from writing code by hand and toward orchestrating fleets of AI agents that write it for them — the pattern now branded the software factory. Two tracks at this summer’s AI Engineer World’s Fair in San Francisco were devoted to exactly these ideas, and that is no coincidence. They are two halves of the same structural shift.
The through-line is simple, and worth internalizing: AI is collapsing the cost of writing code, and in doing so it is repricing everything around the code. When the typing is cheap, the scarce work moves to the two things software has always been worst at — understanding what a specific customer actually needs, and reliably shipping correct systems at scale. Forward-deployed engineering answers the first. The software factory answers the second. This piece is about what both mean for practitioners.
The Front Line — Forward-Deployed Engineering
Start with a definition, because the term is slippery. Natalie Meurer, who leads a 120-plus-person agent-engineering organization at the customer-service AI company Sierra, argues the role resists a fixed job description on purpose: a forward-deployed engineer (FDE) is “defined more by accountability to customers than by the shape of the role or the work you are doing” (Latent Space, July 2026). An FDE is not a sales engineer running demos, nor a consultant delivering a deck of recommendations. They embed with a customer, own production code inside that customer’s environment — and own the outcome.
Why is this suddenly everywhere? Because general-purpose models created a very specific gap. A frontier model is astonishing in the abstract and useless until someone wires it into the one workflow a particular enterprise runs — the data nobody trusts, the legacy system nobody documented, the process one person in finance understands. That “last mile” is where value now lives, and it can’t be shipped in a box.
Meurer’s sharper point is what AI does to the role itself: “When code becomes cheap to author, it also becomes easier to translate customer insights directly into a product. Product engineering and forward deployed engineering are therefore converging. If you are a product engineer, you should be talking to customers. If you are a forward deployed engineer, you should be building the product. I think that is new.”
The hiring signal is loud. OpenAI and Anthropic both staff forward-deployed / applied-AI teams (Anthropic’s specs ask FDEs to ship “MCP servers, sub-agents, and agent skills” into production; OpenAI lists the roles at $162K–$280K plus equity). Amazon Web Services announced a billion-dollar organization to embed engineers directly in customer AI projects (The New Stack, June 2026); Salesforce says it will build a thousand-person FDE team; Google Cloud’s CEO has publicly called for the same. LinkedIn, per Computerworld, found forward-deployed roles to be the fastest-growing AI job category it tracks — up 42-fold between 2023 and 2025. Even discounting for title inflation, the direction is unambiguous: the frontier labs and the hyperscalers have concluded that adoption, not model quality, is the binding constraint — and that closing it takes engineers sitting next to customers.
The Factory Floor — Software Factories, Old and New
“Software factory” is an older term with a new meaning, and it helps to hold both.
The established meaning comes from industrial and defense software. Japanese electronics giants built “software factories” from the late 1960s (Hitachi’s dates to 1969) to impose manufacturing-style discipline — reuse libraries, quality control, standardized process — on software production. The U.S. Department of Defense revived the idea over the past decade: Kessel Run, Platform One, and more than fifty accredited “software factories” (per the DoD CIO’s 2024 State of DevSecOps report) provide pre-secured, standardized CI/CD pipelines — “paved roads” — so teams inherit compliance instead of re-earning it. In both eras, the factory standardized the pipeline around human-written code.
The 2026 meaning goes a layer up: it automates the labor itself. Warp CEO Zach Lloyd, who keynoted the software-factory track, describes the shift as moving “from interactive development to automated development.” Instead of a human prompting an agent turn by turn, an orchestration system runs the whole main loop of engineering — “triage, specification, implementation, review, verification, shipping and monitoring” — with humans supervising the factory floor rather than typing on it (Latent Space, July 2026). Warp’s platform for this is called Oz; it coordinates multiple models and coding agents across sandboxes.
In an internal memo he later published, Lloyd put the identity shift in the title: We are now factory engineers, not product engineers. “The job of engineers is no longer to write code,” he wrote. “It’s to build an internal machine — a cloud software factory — that builds the products for them.” His prediction: within roughly a year, every significant software project will have “some engine of code — something resembling a factory — continuously driving it forward.”
Warp is not alone, which is the point. Factory.ai orchestrates autonomous “Droids”; Cognition’s Devin can now manage fleets of other Devins and, the company says, commits 89% of Cognition’s own code; Cursor engineers describe running “hundreds of concurrent agents” behind a planner/worker/judge architecture; GitHub’s Copilot has walked, step by dated step, from “pair programmer” to an autonomous coding agent that reviews its own diffs. A New Stack writer who used three orchestration platforms in a single week proposed a name for the emerging human role: fleet commander.
The relationship between old and new is worth stating precisely, because it tells you what to build. The old factory industrialized the delivery of software; the new one is trying to industrialize its production. They share a goal — make software repeatable instead of heroic — and, critically, the new depends on the old: teams that already had fast, disciplined pipelines are the ones absorbing agent output without drowning. As one widely cited analysis (Luca Rossi with CircleCI’s CTO) put it, the bottleneck was never the coding.
Why These Are the Same Story
Set the two trends side by side and the symmetry is obvious. Forward-deployed engineering pushes the engineer toward the customer. The software factory pushes the engineer toward the orchestrator. What both remove is the comfortable middle — the engineer whose entire job was translating an internal spec into code, touching neither the customer nor the deployment machinery. Cheap code hollows out that middle from both sides.
This is why swyx (Shawn Wang), who convened both tracks, argues engineering is “definitionally the last job”: as AI automates more of the work of building software — even the work of training the models — what remains is the human-owned last mile of turning capability into a working, trusted system. Meurer expects the current alphabet soup of titles — GTM engineer, forward-deployed engineer, agent engineer, AI engineer — to dissolve back into “different parts of the engineering craft,” with new jobs we haven’t named yet.
The practitioner takeaway is not “learn prompt engineering.” It is that the two durable specializations are proximity to the customer and command of the factory — and the best engineers will move fluidly between them.
Follow the Money — Services-as-Software, Pricing, and Margins
None of this would matter to a founder if it didn’t change the P&L. It does, in three connected ways.
1. The market is getting bigger and stranger. Sequoia’s Julien Bek argues that AI lets a vendor sell the work rather than the tool — and that “for every dollar spent on software, six are spent on services.” His framing distinguishes copilots (which sell a tool to a professional who stays in the loop) from autopilots (which sell the finished outcome to whoever owns the budget for the work). “The next trillion-dollar company,” he writes, “will be a software company masquerading as a services firm.” That is exactly the logic behind forward-deployed engineering: if you sell outcomes, someone has to guarantee the outcome inside the customer’s reality.
2. Pricing is migrating from per-seat to usage- and outcome-based. Sierra bills per resolved conversation; Intercom’s Fin popularized a flat $0.99-per-resolution model and, in 2026, broadened the billable unit from “resolutions” to “outcomes.” Foundation Capital frames the 2026 software-stock selloff it half-jokingly calls the “SaaSpocalypse” as the market absorbing a hard truth: seat counts stop growing when a team does more with fewer people. But outcome pricing is not a free lunch, and the honest voices say so. Sierra’s own retrospective is blunt: “Outcome-based pricing is more complex than seat-based or consumption pricing — operationally, contractually, accounting-wise. People telling you it’s simple are selling something.” It only works “where the software is highly autonomous and highly attributable.” Where it isn’t, buyers get surprise invoices — a documented failure mode.
3. Margins no longer look like classic SaaS. When every interaction burns inference, gross margin behaves like a cost of goods sold, not a rounding error. ICONIQ’s cross-industry data shows AI-native gross margins climbing but still well below the old ~80% ideal — roughly 41% in 2024, 45% in 2025, and a projected 52% in 2026 — with inference a growing share of the cost base. Lloyd’s version: software production is becoming “a variable cost, not an R&D expense — it’s going to show up as COGS on the P&L.” If you’re modeling an AI business on 80-point gross margins, redo the model.
The Moat Question
If code is cheap and any competitor can match your build velocity, where does defensibility come from?
The most useful answer in circulation is a16z’s deliberately provocative one: trade margin for moat. Joe Schmidt argues that the implementation-heavy, lower-margin work of getting enterprises live — “enterprises buying AI are like your grandma getting an iPhone: they want to use it, but they need you to set it up” — is not a drag on the business but the moat itself, exactly as heavy services investment was for Salesforce, ServiceNow, and Workday before they became high-margin platforms.
NfX frames the same idea as sequencing: win early on distribution and speed (the “bailey”), then retreat to durable defenses — real workflow lock-in, switching costs, continuously generated data (the “motte”). Both agree on what is not a moat anymore: raw feature-shipping speed, and static piles of proprietary data a foundation model has effectively already seen. Bessemer adds a complementary read — that value is shifting from owning the system of record to owning the system of action that actually executes the workflow.
The Uncomfortable Parts
A credible read has to name the counter-evidence.
The factory may not work yet. A pointed VentureBeat critique warns that “most companies think they’re building a software factory — they’re actually just shipping bugs faster,” and that the winner “isn’t the one that generates the most code, it’s the one that generates the fewest defects downstream.” And several of the most-quoted productivity numbers — a consultancy’s claim about a streaming company writing “no human code since December,” or a payments company’s “1,300 PRs a week” — trace to single, un-corroborated sources and should be treated as marketing until a primary source confirms them.
The labor question is more serious. The best evidence available — a Stanford Digital Economy Lab study using payroll data from the largest U.S. provider — finds a 16% relative decline in employment for early-career workers (ages 22–25) in the most AI-exposed occupations, with software development explicitly named, and the adjustment coming through hiring rather than pay. Crucially, the effect concentrates where AI automates rather than augments. a16z, for its part, flatly rejects the broad replacement narrative (“Will AI replace software developers? Of course not”) and notes that the most AI-savvy enterprises are hiring more engineers. Both can be true at once: total engineering demand rises while the bottom rung of the ladder thins. For a leader, that’s not abstract — it’s a decision about whether you’re still training juniors, and how.
A Playbook for Monday
Concretely, for engineering leaders and founders:
- Decide whether you sell a tool or sell work. If your domain still needs human judgment, build the copilot and sell to the professional. If your model reliably closes the loop, sell the outcome to whoever owns the labor budget — and staff forward-deployed engineers to guarantee it.
- Treat forward deployment as a moat investment, not a PMF failure. Budget for embedded engineers on your top accounts, and build the feedback wire that turns the third bespoke fix into a product feature. If it never generalizes, you have a consultancy, not a platform.
- Model inference as COGS from day one. Instrument per-transaction cost, route between cheap and frontier models, and price with that cost curve in view. Don’t promise outcome pricing in a domain where you can’t cleanly attribute the outcome.
- Start automating your own factory at the bottleneck. Take Lloyd’s advice literally: find the most annoying, repetitive loop in your own workflow — triage, code review, flaky-test triage — and put an agent loop on it before you try to automate everything. The discipline you build (fast CI, traceability, evals) is the precondition for everything else.
- Reframe the roles now. Make “context engineering” — the prompts, rules, and edge cases an agent runs on — a first-class artifact with the rigor you gave a PRD. Build explicit human-sign-off checkpoints for high-stakes output. And protect a path for junior engineers, because the automating-versus-augmenting line is where your future senior talent is decided.
The Shape of the Team in 2027
Put it together and the org chart of a strong software team starts to look different from the one most of us grew up with. Fewer people in the middle writing features against a backlog. More people at the front line, embedded with customers, accountable for outcomes. More people on the factory floor, designing and supervising the agent loops that do the typing. The same engineer may do both in the same week.
The reassuring part, for anyone who actually likes building, is what stays human. The customer’s real problem still has to be understood by someone accountable for solving it. The factory still has to be designed, tuned, and trusted by someone who owns whether it ships correct software. AI has made the code cheap. It has made judgment, context, and accountability more valuable than ever — and those, not the typing, were always the job.
Sources
Primary interviews (Latent Space, July 1, 2026, from the AI Engineer World’s Fair)
- “Forward Deployed Engineers and the future of software engineering” — Q&A with Natalie Meurer, Head of Agent Engineering, Sierra.
- “Warp CEO Zach Lloyd on why software factories are the next phase of coding.”
Forward-deployed engineering & the future of the craft
- Zach Lloyd, “We are now factory engineers, not product engineers,” Warp (June 2026).
- swyx (Shawn Wang), RedMonk interview on the “AI Engineer” and the “last job” thesis (July 2025).
- “Here’s one career emerging from the AI shift: forward-deployed engineers,” Computerworld (May 2026) — LinkedIn 42x growth stat, Google Cloud.
- “AWS’s $1B forward-deployed engineering org,” The New Stack (June 2026).
- OpenAI and Anthropic careers pages (FDE / Applied AI roles, comp ranges, deliverables).
Software factories
- DoD CIO, State of DevSecOps (2024) — “over 50” software factories; Platform One; Kessel Run.
- Michael Cusumano, Japan’s Software Factories (historical origin).
- Factory.ai, Cognition (Devin), Cursor (“Scaling Agents”), GitHub Copilot coding-agent announcements (2025–2026).
- Luca Rossi & Rob Zuber (CircleCI), “The Era of the Software Factory” (Feb 2026).
- Benjamin Rogojan, “Most companies think they’re building a software factory…,” VentureBeat (June 2026).
Economics, pricing, moats, labor
- Julien Bek, “Services: The New Software,” Sequoia Capital (March 2026).
- Foundation Capital, “Taking Stock of the SaaSpocalypse” (June 2026).
- Joe Schmidt, “Trading Margin for Moat,” a16z (June 2025); Appenzeller & Li, “The Trillion Dollar AI Software Development Stack,” a16z (Oct 2025).
- NfX, “How AI Companies Will Build Real Defensibility” (July 2025); Bessemer, “Roadmap: AI Systems of Action” (May 2025).
- Sierra, “Outcome-based pricing for AI Agents” (Dec 2024) and “Outcomemaxxing” (June 2026); Intercom, “From resolutions to outcomes” (March 2026).
- ICONIQ, State of AI — AI-native gross-margin trajectory (41%→45%→52%).
- Brynjolfsson, Chandar & Chen, “Canaries in the Coal Mine?” Stanford Digital Economy Lab (Nov 2025).
Note: a small number of widely circulated productivity figures (e.g., specific per-company “PRs per week” claims) trace to single or vendor-marketing sources and are flagged as unverified in the text.