Back to careers

FOR SOFTWARE ENGINEERS · FORWARD-DEPLOYED PATH

From shipping code to shipping outcomes.

Forward-deployed and product engineers sit with the people who use the software. They find the real problem, build with AI inside the customer's own systems, and own whether it works. This path teaches that work in stages, with evidence you can show and a named human who signs each one off.

It is a skills path, not a job pipeline. We do not guarantee jobs, interviews or any earnings, and the market for these roles is small and new.

Join the engineer waitlist Read the evidence first
  1. 1Discover
  2. 2Data
  3. 3AI flows
  4. 4Deploy
  5. 5Pilot
  • 5stages, from strong engineer to independent forward-deployed engineer
  • ~420 hplanning estimate, part-time over several months, not yet tested
  • 3capstones on synthetic data, with Kenya-style scenarios
  • 0job guarantees. Every claim below carries a source and a date.

Where this stands today

The Pawanax Academy is taking a founding-cohort waitlist. This engineer track is designed and not yet taught. We will pilot it with a small group, measure what happens and publish the result. 10 of the 20 lessons below build on lessons already in the Academy curriculum. The rest are new for this track.

THE ROLE

What a forward-deployed engineer does

Embedded, outcome-owning engineering. The title is new and its meaning varies, so here is the definition we use.

A forward-deployed engineer (FDE) works close to a customer, often inside their environment. They find the real problem, build a working system on the customer's own data and systems, get it into production, and feed what they learn back into the product. The role is associated with Palantir, and accounts of its origin differ. Several AI and enterprise software firms now describe similar roles in public postings, including OpenAI, Anthropic, Databricks and Ramp.

A product engineer works on the core product for every customer and owns outcomes rather than tickets. The two overlap. Ramp's write-up on its forward-deployed team calls generalisation a core principle: repeated customer work should become product.

We read 16 postings in full, from 11 companies. All 16 asked for direct work with customers, ownership of delivery to production, and clear communication with technical and non-technical people. 11 required production AI or language-model systems. The sample is small and almost all US and European, with none in Kenya, and five of the pages carried removal notices, so treat it as a snapshot.

How the neighbouring roles differ
RoleWhere in the customer lifecycleMain outputWrites production code for the customer?
Forward-deployed engineerAfter the sale, embedded, long termA working production system in the customer's environmentYes
Product engineerCore product, all customersA shared product capability, with ownership of outcomesYes, for the core product
Solutions engineerBefore the saleA demo, proof of concept or technical validationLimited, often on sample data
Applied AI engineerVaries widelyA model, agent or retrieval feature for a product or customerYes

Titles blur. Some roles labelled forward-deployed are closer to pre-sales or consulting, so check the job content and not the title.

THE EVIDENCE

What the evidence says, and what it does not

Demand is real but small. Whether this is the future of software engineering is an opinion, and we do not claim it.

  • Reported

    US postings for forward-deployed engineers on Indeed reportedly rose from 643 to 5,330 between April 2025 and April 2026.

    That is one job board, reported second-hand, measured from a small starting base. It counts postings, not hires or filled roles.

    LeadDev, 23 Jul 2026, citing Indeed

  • Primary

    The US Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow 10 percent from 2025 to 2035.

    Forward-deployed work is a niche inside a much larger occupation. Keeping general software skills keeps more options open.

    US Bureau of Labor Statistics, Occupational Outlook Handbook

  • Opinion

    Credible practitioners say this model is spreading. Credible critics say it can be services work under a product title.

    Barry McCardel, who worked at Palantir and now runs Hex, argues that teams focused on customer margins are often doing professional services and should say so. Pragmatic Engineer describes the ability to say no as part of doing the role well.

    Barry McCardel, FDE culture

  • Reported

    Travel is often stated, and it varies a lot.

    Ten of the 16 postings we read state travel as a percentage, from 20% to 70%. Palantir's commercial posting says 25%.

    Palantir posting, Lever

  • Our judgement

    The strongest version of the idea is narrower than the headlines.

    Judgement about customer workflows, data reality, evaluation and safe deployment is not removed by coding agents. Whether embedded engineering becomes a dominant software role is contested, so we teach these as overlapping skills and not a single guaranteed track.

    Our own judgement, not a sourced finding.

The honest pitch: some engineers now do customer-embedded, outcome-owning work with AI systems. Here is what it involves, which skills it uses and how to tell whether it is for you.

THE SKILLS

The skills, and what proves each one

Drawn from 16 postings read in full and from practitioner write-ups. Each skill has an artefact a reviewer can check. Feeling confident is not evidence.

Rare in postings, central in practice

  • Evals and observability. Only 3 of 16 postings name evals, yet practitioners treat evaluation as what separates a demo from a product.
  • Handling incidents inside a customer's environment. Named in 3 of 16.
  • Saying no and holding scope. Named in 0 of 16, yet central in the practitioner accounts.
  • Adoption and change management. Named in 2 of 16.
  • Measuring outcomes against a baseline. Named in 1 of 16.

Overrated as hiring signals (our judgement)

  • Fine-tuning models. Named in 0 of 16 postings. Knowing when not to fine-tune is more useful.
  • MCP expertise. Named in 1 of 16. Worth learning, not a hiring signal.
  • Framework-first language-model work. Anthropic's own agent guide advises starting with the model API directly.
  • Vendor certifications, unless the role is a vendor-partner role.
  • Standalone prompt engineering. It is a small part of building applications, not a skill by itself.
  • Deep Kubernetes administration at early levels. Infrastructure-as-code literacy matters more.

Levels are our judgement, loosely anchored to the experience bands in the postings (about 1+, 3+ and 5+ years). They are not hiring thresholds.

Technical

  • T1Full-stack production deliveryTable stakesNamed in 16 of 16 postings
    1. LearnerA small full-stack app deployed, with tests and CI. Can trace one request end to end.
    2. PractitionerOwns deploy, logs and rollback for one service. Pull requests reviewed and comments addressed.
    3. Independent FDETakes a customer workflow to production inside their stack. Handover runbook written. The customer uses it without help.
    4. LeadA reference architecture reused by at least two deployments. Reviews other engineers' designs.
  • T2Data integration and messy dataTable stakesNamed in 7 of 16 postings
    1. LearnerCleans a dataset with a documented issue log and before-and-after counts.
    2. PractitionerAn ingestion pipeline with retries and idempotency, tested with bad-input fixtures.
    3. Independent FDEA live integration with the customer's systems of record. Reconciliation report and a signed data contract.
    4. LeadReusable connectors used across customers. Governance decisions documented.
  • T3APIs and enterprise systemsTable stakesNamed in 6 of 16 postings
    1. LearnerA client for a real REST API with authentication and pagination, with tests.
    2. PractitionerWebhook or callback handling, a sandbox-to-production switch and idempotency keys.
    3. Independent FDEAn integration into a system of record under the customer's change control, with a cutover plan and reconciliation after go-live.
    4. LeadAn integration standard the team uses. Security reviews passed for a multi-customer pattern.
  • T4Language-model application buildingTable stakesNamed in 15 of 16 postings
    1. LearnerA prompt-driven feature with schema-validated output and a documented fallback.
    2. PractitionerA tool-calling flow with cost and latency logged per request.
    3. Independent FDEA customer workflow with guardrails and human review, and a written reason for choosing a workflow over an agent.
    4. LeadTeam defaults for patterns, and documented cases where the team chose not to use a model.
  • T5Agents and orchestration, safelyEveryone mentions it, few show itNamed in 6 of 16 postings
    1. LearnerA single tool loop with a step limit and a stop condition.
    2. PractitionerPermission scopes, sandboxing and per-step logs. Tool descriptions tested on sample inputs.
    3. Independent FDEAn agent in a customer environment with approval gates and rollback. No unapproved actions in the logs.
    4. LeadA guardrail policy used by several deployments, with documented handoff rules between agent and human.
  • T7Evals and observabilityDifferentiatorNamed in 3 of 16 postings
    1. Learner20 to 50 labelled cases for one feature, run on every change.
    2. PractitionerReads traces and builds an error taxonomy with counts. Checks any model judge against human labels and reports the agreement.
    3. Independent FDEOwns the eval suite for a deployment, built with the customer's domain expert, and gates releases on it.
    4. LeadShared eval tooling used by three or more teams. Trains others.
  • T8Deployment, security and infrastructureTable stakesNamed in 10 of 16 postings
    1. LearnerA containerised app with secrets handled correctly and documented deploy steps.
    2. PractitionerInfrastructure as code, least-privilege access and deploy logs.
    3. Independent FDEA deployment into a customer's cloud account or private environment. Security review signed off. Data residency respected.
    4. LeadDeployment archetypes reused across customers. Leads compliance planning.
  • T10Unfamiliar code and debuggingTable stakesNot named in any of the 16 postings

    No posting names this explicitly, but it is load-bearing in practice. Our judgement: postings under-state it.

    1. LearnerTraces one request through an unfamiliar repository and writes a one-page map.
    2. PractitionerFixes a bug in code they did not write, with a regression test. Uses logs and traces.
    3. Independent FDEDiagnoses across the network, identity, data and model layers, with hypotheses written down and tested.
    4. LeadTeaches the method. Repeat-incident fixes are merged by the team.
  • T11Incidents in a customer's environmentDifferentiatorNamed in 3 of 16 postings
    1. LearnerShadows an on-call rotation and writes an incident timeline.
    2. PractitionerOn call for a service. Follows a runbook. Writes a blameless postmortem with action items.
    3. Independent FDELeads an incident in a customer environment, sends status updates to customer leads, restores service and ships the follow-up fixes.
    4. LeadDesigns escalation and on-call for multi-customer deployments. Reviews incident trends.

Customer and deployment

  • C1Discovery interviewsEveryone mentions it, few show itNamed in 12 of 16 postings
    1. LearnerRuns three structured interviews from a script. Notes and summary written.
    2. PractitionerRuns discovery alone with a frontline user. A workflow map with direct quotes.
    3. Independent FDERuns discovery across executives and frontline staff. A first use case with a named success metric and sponsor sign-off.
    4. LeadSets discovery standards and reviews other people's briefs.
  • C2Scoping ambiguous problemsTable stakesNamed in 13 of 16 postings
    1. LearnerBreaks a given task into subtasks with estimates and flagged unknowns.
    2. PractitionerTurns an ambiguous request into a milestone plan with explicit assumptions and risks.
    3. Independent FDEScopes a multi-workstream deployment around the customer's gates: security, procurement and data access.
    4. LeadMakes scoping and capacity decisions across several customers.
  • C4Adoption and change managementDifferentiatorNamed in 2 of 16 postings
    1. LearnerWrites a how-to for one workflow.
    2. PractitionerRuns a training session and collects usage data afterwards.
    3. Independent FDEOwns an adoption plan with usage targets, handles resistance and reports adoption to the sponsor.
    4. LeadAn adoption playbook used across customers.
  • C5Written and live communicationTable stakesNamed in 16 of 16 postings
    1. LearnerClear pull-request descriptions and a ten-minute demo to a mixed audience.
    2. PractitionerDesign documents accepted without a rewrite. Demos that answer the audience's actual question.
    3. Independent FDEExecutive briefs that drive a decision. Leads live working sessions with customer engineers and executives.
    4. LeadSets writing standards and reviews other people's customer-facing documents.
  • C7Saying no and holding scopeDifferentiatorNot named in any of the 16 postings

    No posting names this explicitly. Practitioner accounts of the role treat boundary-setting as central, so we teach it deliberately.

    1. LearnerFlags a scope change in writing.
    2. PractitionerDeclines an out-of-scope request and offers a named alternative.
    3. Independent FDENegotiates trade-offs with options and holds the boundary under pressure. Keeps a scope-change log with decisions.
    4. LeadSets policy on custom work versus product features.
  • C8Commercial scopingDifferentiatorNamed in 3 of 16 postings
    1. LearnerExplains a simple return-on-effort estimate and its assumptions.
    2. PractitionerBuilds a proof of value with success criteria agreed in advance.
    3. Independent FDEProvides input to a statement of work and anticipates procurement and legal steps.
    4. LeadShapes deals and documents the decision to decline unfit ones.

Product

  • P2Prototype to productEveryone mentions it, few show itNamed in 10 of 16 postings
    1. LearnerStates the prototype's limits in a README.
    2. PractitionerPorts a prototype into the product repository with tests.
    3. Independent FDEProductises a customer pattern as a versioned module used by at least two customers.
    4. LeadDecides build versus buy for platform features.
  • P3Metrics and outcome measurementDifferentiatorNamed in 1 of 16 postings
    1. LearnerDefines one metric and how it will be measured.
    2. PractitionerInstruments usage events and reports weekly.
    3. Independent FDETies a deployment to a customer outcome with a baseline and a post-deployment number.
    4. LeadDesigns company-level metrics for deployments.
  • P4Feedback into the core productEveryone mentions it, few show itNamed in 12 of 16 postings
    1. LearnerLogs field issues with reproduction steps.
    2. PractitionerWrites reproduction-backed issues and contributes eval cases.
    3. Independent FDETurns field patterns into roadmap items with deployment evidence attached, and closes the loop with the customer.
    4. LeadRuns the feedback system and sets its priorities.

THE PATH

The path: five stages, each signed off by a person

Built from the work itself: discovery, messy data, evaluated AI workflows, safe deployment, then a pilot and a handoff.

Entry requirement: you can ship a production service with tests and code review, and you have handled an incident. We check this with a portfolio review and a short live coding and debugging session, not your CV.

No public, standard forward-deployed curriculum exists. Palantir, OpenAI, Anthropic and Ramp describe the role, but none publishes a new-hire curriculum. This path is our own design, built from the role's real work and from learning-science sources. Hours and pass thresholds are planning targets we will test in a pilot.

Who signs it off

  • The AI coach checks each artefact against the rubric, gives line-level feedback and generates practice variants. Its scores are advisory only.
  • A mentor, who is a senior practitioner, runs the role-plays and reviews the work.
  • Voluntary domain faculty, such as a clinic operations lead or a credit officer, check that scenarios and data are realistic.
  • A security or privacy reviewer signs the security and privacy artefacts.
  • Every stage gate needs a named human signature. No stage is passed by the AI coach alone.

How a stage is passed

  • Each stage gate needs all of that stage's rubric dimensions at 3 out of 4 or higher, and a human signature.
  • The final independent capstone needs 3 or higher on every dimension and 4 on at least two, signed by two humans.
  • A score of 1 on safety and privacy is an automatic stop, whatever the other scores.

  1. Stage 1: Customer-facing foundations

    50 h

    Run a 45-minute discovery call with a simulated customer, write a one-page scope with explicit non-goals, and explain a technical trade-off in plain language.

    4 lessons
    • 1.1Discovery and problem framing12 h
      You learn
      Separate a stated request from the underlying problem. Ask about current workarounds, frequency, cost of failure and who else is affected.
      You practise
      Three recorded role-plays with a simulated customer.
      Evidence you keep
      Interview notes, a problem statement and a table of what you heard versus what you inferred.
      Signed off by
      A mentor scores the transcript, with consent.

      Builds on Academy lessons: 5.1 Problem framing5.4 Expert interviews

    • 1.2Scoping and saying no10 h
      You learn
      Turn a request into two or three options with cost, risk and time. Define non-goals and a kill criterion.
      You practise
      Rewrite a vague 'dashboard by Friday' request into three scoped options.
      Evidence you keep
      A scope document with non-goals and a kill criterion.
      Signed off by
      A mentor plays a pushing customer and a faculty member reviews.
    • 1.3Writing for non-engineers12 h
      You learn
      Plain language, decision-first structure and checking comprehension.
      You practise
      Rewrite a technical incident note for a clinic manager and write a one-page brief for a savings-co-operative board.
      Evidence you keep
      Two documents and a comprehension check with two non-engineer readers.
      Signed off by
      A faculty member runs the check. The readers' answers must match the intended decision.
    • 1.4Data map, consent and sensitive data16 h
      You learn
      Build a data-flow map, classify sensitive fields, minimise collection and name the legal basis to confirm with counsel.
      You practise
      Map a synthetic clinic referral flow from end to end.
      Evidence you keep
      A data inventory and a data-flow diagram with classification.
      Signed off by
      A privacy-literate faculty member. This is training, not legal advice.

      Builds on Academy lessons: 8.1 AI policy and law

    Gate: All four lessons signed.

  2. Stage 2: Messy data and integration

    70 h

    Profile an unknown data source and write a data contract, build an idempotent ingestion job, resolve entities across systems with measured accuracy, and design exception queues for human resolution.

    4 lessons
    • 2.1Profiling and data contracts16 h
      You learn
      Nulls, duplicates, mixed date formats, mixed-language free text, missing keys and unit errors. Write down what is allowed to be wrong.
      You practise
      Profile three synthetic extracts with planted defects.
      Evidence you keep
      A profiling report, a data contract with tolerances and a list of rejected records with reasons.
      Signed off by
      A mentor checks the contract against the planted defects. It must catch at least 80%.
    • 2.2Entity resolution and idempotent ingestion18 h
      You learn
      Match the same person or member across systems. Reruns must not duplicate rows.
      You practise
      Match records across three synthetic systems, rerun the job and diff the output.
      Evidence you keep
      A pipeline and a reconciliation report with precision and recall on a hand-labelled sample of 200 pairs.
      Signed off by
      A mentor reviews the labelled sample and a reviewer reruns the job.
    • 2.3Reconciliation and exception queues18 h
      You learn
      Money, weight and count mismatches. Design a queue where a human resolves each item and the decision is recorded.
      You practise
      Reconcile synthetic mobile-money records against delivery or weighing slips.
      Evidence you keep
      An exception log with resolution codes, and unresolved items explained.
      Signed off by
      A faculty member from a co-operative or credit setting checks the queue fits real operations.
    • 2.4Integration under failure18 h
      You learn
      CSV drops, flaky APIs, slow links and partial writes. Retries with backoff and dead-letter handling.
      You practise
      A failure-injection test on the Stage 2 pipeline.
      Evidence you keep
      A test report showing behaviour under each injected fault.
      Signed off by
      A reviewer runs the fault suite independently.

    Gate: All four lessons signed. Capstone A data work is finished here.

  3. Stage 3: Language-model workflows, built and evaluated

    80 h

    Choose the simplest workable pattern and justify it, run error analysis before writing evals, build an eval suite with calibrated judges, and design least-privilege tools with guardrails and red-team tests.

    4 lessons
    • 3.1Choosing the pattern14 h
      You learn
      A single call with retrieval, a workflow (routing, chaining, parallel steps, evaluator and optimiser) or an agent. Cost, latency and compounding-error trade-offs.
      You practise
      Three task briefs. Build the non-agent baseline first for each.
      Evidence you keep
      A decision record with the baseline score and a reason to add complexity, or not.
      Signed off by
      A faculty member reviews the reasoning and a mentor challenges the choice.

      Builds on Academy lessons: 3.1 Agent loop anatomy3.3 Decomposition

    • 3.2Error analysis before evals20 h
      You learn
      Read realistic traces, label the earliest failure, cluster and count.
      You practise
      Label 100 synthetic traces for a clinic referral triage task. A second labeller labels 30.
      Evidence you keep
      An error taxonomy with counts and the agreement between labellers.
      Signed off by
      A mentor checks agreement and a faculty member checks the failure categories are real.

      Builds on Academy lessons: 4.4 Trace mining

    • 3.3Building and calibrating evals24 h
      You learn
      A golden set of at least 150 cases, code-based checks where possible, and a model judge only after its agreement with human labels is measured.
      You practise
      Build the eval suite, calibrate the judge and add a regression run to CI.
      Evidence you keep
      The eval suite, a judge-versus-human agreement table and a regression report.
      Signed off by
      A human calibration review. The mentor signs the statement that the judge is trustworthy for these categories.

      Builds on Academy lessons: 4.1 Deterministic checks4.2 Judge calibration

    • 3.4Tool design, guardrails and red-teaming22 h
      You learn
      Least privilege, tool descriptions as clear interface documents, human approval for irreversible actions, and prompt injection hidden inside uploaded documents.
      You practise
      Build a tool set for the capstone agent and run 20 hostile-document tests.
      Evidence you keep
      A tool specification and a red-team log with pass or fail per case and the fix.
      Signed off by
      A security-literate reviewer signs the red-team log.

      Builds on Academy lessons: 2.3 Tool error design3.5 Permissions8.2 Agent security

    Gate: All four lessons signed. Capstone A is completed at the end of this stage.

  4. Stage 4: Deploying into a customer environment safely

    70 h

    Profile a customer environment, write a threat model, plan a staged rollout with a rehearsed rollback, and run a privacy operations check that includes a breach tabletop.

    4 lessons
    • 4.1Environment discovery12 h
      You learn
      Network limits, identity provider, device fleet, data residency, offline and low-bandwidth operation, and who can approve changes.
      You practise
      Fill in the environment profile for a synthetic savings-co-operative branch network.
      Evidence you keep
      An environment profile and a gap list.
      Signed off by
      A faculty member checks realism against the scenario.
    • 4.2Security baseline and threat model18 h
      You learn
      Secrets handling, role-based access, log hygiene with no personal data in logs, dependency scanning and the common language-model application threats.
      You practise
      A threat model for a document-checking assistant.
      Evidence you keep
      A threat model and a security checklist with evidence per item.
      Signed off by
      A security reviewer signs.

      Builds on Academy lessons: 8.2 Agent security

    • 4.3Staged rollout and rollback20 h
      You learn
      Shadow mode, then assisted mode, then automated with approval. Feature flags. A rollback that is rehearsed, not only written.
      You practise
      Run the rollout in staging, execute a rollback drill and time it.
      Evidence you keep
      A runbook and a rollback drill log with the time taken and what broke.
      Signed off by
      A reviewer witnesses the drill. Our design target is a rollback in under 15 minutes.

      Builds on Academy lessons: 3.4 Human gates

    • 4.4Privacy operations and breach response20 h
      You learn
      Data minimisation, retention, de-identified test data, and the breach notice path and timelines. Coordinate with the customer's counsel.
      You practise
      A breach tabletop: a synthetic leak of member data through an agent output.
      Evidence you keep
      A privacy note, which is not legal advice, and a tabletop record with decisions and timings.
      Signed off by
      A privacy-literate faculty member and a role-played customer counsel. Legal sign-off is the customer's.

      Builds on Academy lessons: 8.1 AI policy and law

    Gate: All four lessons signed. Capstone B is completed at the end of this stage.

  5. Stage 5: Pilot, value, handoff and product feedback

    64 h

    Design a pilot with success criteria set in advance, measure value honestly including negative results, hand off to customer staff, and turn repeated customisation into a product proposal.

    4 lessons
    • 5.1Pilot design12 h
      You learn
      Baseline measurement, success criteria and stop rules written before launch, sample size, and who is excluded and why.
      You practise
      Write a pilot plan for Capstone C.
      Evidence you keep
      A pilot plan, written in advance, with metrics and stop rules.
      Signed off by
      A mentor and a faculty member. The plan must name a baseline.

      Builds on Academy lessons: 5.3 Risk and liability

    • 5.2Measuring value honestly18 h
      You learn
      Time-and-motion measurement, error rates, adoption and counterfactuals. Uncertainty ranges, and what to do when value is not shown.
      You practise
      Run a simulated two-week pilot on synthetic logs and write the report.
      Evidence you keep
      A pilot report with uncertainty and at least one negative finding.
      Signed off by
      A faculty member checks that the claims match the data.
    • 5.3Handoff and enablement18 h
      You learn
      Runbooks, ownership transfer, training for customer staff, and what the agent must not do.
      You practise
      Hand off the Capstone C system to a role-played customer team.
      Evidence you keep
      A handoff pack, a recorded walkthrough with customer-proxy staff and an ownership matrix.
      Signed off by
      A role-played customer sign-off form plus a mentor.
    • 5.4Feeding learnings back to product16 h
      You learn
      Spot repeated customisation, generalise a feature and weigh the maintenance burden.
      You practise
      Write a product proposal from three customer cases.
      Evidence you keep
      A proposal with evidence, a maintenance cost estimate and what to stop building.
      Signed off by
      A product engineering lead reviews.

    Gate: All four lessons signed, then the independent capstone is scored by two humans.

About 334 hours of lessons plus about 90 hours of capstones. This is a planning estimate we have not yet tested. Browse the Academy curriculum.

THE CAPSTONES

Three capstones, all on synthetic data

No employer material and no real patient, member or farmer records. Every dataset has planted defects so the integration and eval lessons have something to catch.

  • The AI coach may generate data and tests, and a human checks the generator's assumptions.
  • Agents may draft. The final decision step is always human.
  • Any statement about value is labelled as simulated.
  • Cost and latency are reported per 1,000 cases.
A24 h

Clinic referral triage network

Completed at the end of Stage 3

Who it is for
A programme manager for a county network of 12 synthetic clinics who wants faster, safer routing of referrals to the district hospital.
The problem
Referral notes arrive as free text in English, Swahili and a mix of both, with missing fields and inconsistent facility names. Triage nurses lose time sorting and chasing missing information.
Synthetic data
12 clinic profiles, 3,000 referral notes and 400 patient identifiers with planted duplicates. 15% of notes miss a required field, 5% carry a conflicting age or date, 10% mix languages and each facility has three spellings.
Constraints
The system only suggests a routing category and a missing-information list, and a nurse decides. It must work with intermittent connectivity. Start with the simplest workable approach.

You deliver

  • Data contract and entity-resolution report
  • A routing and missing-information workflow with a tool set
  • An eval suite of at least 150 golden cases, an error taxonomy and a calibrated judge
  • A 10-minute demo to a clinic manager role-play and a one-page write-up
B26 h

Savings co-operative loan-document assistant

Completed at the end of Stage 4

Who it is for
The operations manager of a synthetic savings and credit co-operative with 8 branches who wants loan packets checked faster before the credit committee meets.
The problem
Each loan packet holds ID copies, income records, guarantor forms and a member statement. Officers check completeness and cross-check figures by hand, and errors cause delays and rework.
Synthetic data
600 synthetic member packets with 4 to 7 documents each, with OCR noise. Planted issues: a missing guarantor signature, mismatched income between documents, an expired ID and a member duplicated across branches.
Constraints
The system never approves or declines credit. It produces a checklist with evidence links, and the committee decides. Every suggestion and every human override is logged. Document content is untrusted, so a prompt-injection test is mandatory. Access is read-only.

You deliver

  • A threat model and security checklist
  • A staged rollout runbook and a rollback drill log
  • A red-team log with at least 20 hostile-document cases
  • A demo to a credit-officer role-play and a board write-up of risks and what was not automated
C40 h

Agricultural co-operative harvest intake and reconciliation

Independent, at the end of Stage 5

Who it is for
The treasurer of a synthetic agricultural co-operative with 1,500 smallholder members and 6 collection points, who wants payouts to match delivered produce weighted by grade.
The problem
Weighing slips are on paper, transcribed late, sometimes in mixed units and with grade disputes. Monthly reconciliation is manual, which causes delays and disputes.
Synthetic data
6 collection points and 25,000 delivery records over one season. Planted defects: unit mismatches, duplicate slips, transcription errors, payout entries with no matching delivery and two conflicting price schedules.
Constraints
The agent may propose reconciliations. Releasing money needs two human approvers. It works offline at collection points and syncs later. The pilot has a baseline and must report a negative finding if one occurs.

You deliver

  • A pilot plan with metrics and stop rules set in advance
  • A simulated two-week pilot report with uncertainty and at least one negative finding
  • A handoff pack with an ownership matrix and a recorded walkthrough
  • A product proposal, a 10-minute demo and a one-page write-up

How the work is scored

Each dimension is scored from 1 (not met) to 4 (met with clear judgement beyond the brief). Two human raters score a 20% sample blind, and we track the AI coach's scores against the human scores.

  • Discovery and scoping
  • Data integration
  • AI workflow and evals
  • Safety and privacy
  • Deployment and rollback
  • Writing for non-engineers
  • Value measurement
  • Handoff and product feedback
  • Judgement with AI agents

WITH AI CODING AGENTS

Working with AI coding agents without losing judgement

Coding agents change the skill mix toward verification, specification and debugging. The evidence on learning is early, narrow and mixed, so the path builds in checks.

  • Primary

    In an Anthropic trial of 52 mostly junior engineers learning an unfamiliar library, the AI-assisted group scored 50% on a comprehension quiz against 67% for the hand-coding group.

    The speed difference was not statistically significant. People who delegated code generation scored lowest, and people who asked conceptual questions scored higher. The sample was small, comprehension was measured right after the task, and Anthropic is an AI vendor.

    Anthropic, AI assistance and coding skills, Jan 2026

  • Primary

    In a METR trial of 16 experienced open-source developers on 246 issues, developers took 19% longer with AI tools allowed.

    They had expected a 24% speed-up and still believed AI had sped them up by 20% afterwards. METR calls the result a snapshot of early-2025 tools in one setting and marks it out of date. The lesson we keep is the gap between what people believe and what they measure.

    METR, July 2025

The rules we practise

  1. Explain before acceptingDo not merge code you cannot explain line by line.
  2. Write the check firstDefine tests or eval cases before asking an agent to implement.
  3. Predict and timeEstimate the time with and without the agent, record the actual, and compare.
  4. Keep a decision logRecord what the agent suggested, what you accepted or rejected, and why.
  5. No-AI checkpointsEach stage has a short task done without agents and graded by a human.
  6. Least privilegeGive a coding agent only the directories, credentials and commands it needs. No production credentials in learning environments.
  7. Documents are untrustedAgents must not follow instructions found inside data, tool output or web pages.
  8. Simple firstStart with a single call or a workflow before an agent, and know what runs underneath any framework.

We have not measured whether these rules improve learning. We will measure it in our own pilot and publish the result.

THE HIRING BAR

What employers say they look for

Mostly two to five years of production or customer-facing work, not a degree. The strongest evidence is one deployed project, documented honestly.

  • Experience: the stated minimum clusters at 3 to 5 years. Palantir's commercial listing asks for 1+ years and an Anthropic Paris role asks for 8+. A vendor analysis of about 1,000 postings puts 60% of those stating a level in the 3-to-5 band, which is directional only.
  • Degree: rarely a hard requirement in the postings we read. 'A bachelor's degree or equivalent' is typical wording.
  • Stack: Python appeared in 14 of 16 postings and TypeScript or JavaScript in 10. The stack is a means, not the bar.
  • Travel and clearance: ten of 16 state a travel percentage, and some US government roles require a security clearance. Ask about both before you commit.

The interview loop, as reported

  1. A decomposition case: scope a vague, non-code business problem out loud, define success, propose a first version and name a trade-off and a risk.
  2. A coding or debugging round, and sometimes reading code you did not write under time pressure.
  3. A practical build or take-home.
  4. Behavioural rounds about customers, ownership and communication.

Prep guides also describe a customer role-play round, but we found no company that documents it. We use role-play as practice, not as a promise of what you will face. Anthropic's public candidate guidance says take-homes are done without AI unless the posting says otherwise, so read each employer's rule.

A clean-room portfolio

Hiring-manager advice is consistent: one real project with a written account of what broke outweighs many polished demos. Use only public or synthetic data.

Core: one deployed project

  • A working system with a public URL or a recorded run, built on public or synthetic data.
  • A README a stranger can follow: setup, assumptions, what is not handled, next steps.
  • An architecture diagram and a deployment note covering where it runs, how it is monitored and how to roll back.
  • A written account of what broke, your first wrong guess, what found the cause and what changed.
  • An evaluation set and results tied to a version.
  • Known limits and cost per run, stated plainly.

Customer-facing artefacts

  • A discovery document for a clearly fictional persona: problem, users, current workflow, what they said and did not say, open questions.
  • A one-page summary for a non-technical manager.
  • A runbook covering how to run it, how to hand it over and what the customer's team must own.
  • A scope-change log showing one requirement change and how the design absorbed or refused it.

Clean-room rules

  • Use only public datasets, synthetic data or data you generated, and check the licence of every dataset and library you publish.
  • Label every customer as fictional. Never describe a fictional persona as a real client.
  • Do not reuse a former employer's code, documents, customer names, metrics or screenshots.
  • Do not claim production traffic, revenue or customers you do not have.

READ THIS BEFORE YOU COMMIT

Before you commit: the risks

This is a skills course, not a placement service. Read this section and decide whether the skills would still be useful if these roles shrink or change.

  • The market could shift

    Forward-deployed work is a small, new category. Employers could cut these teams, move the work in-house or fold it into existing roles.

  • AI tools could change the work

    Coding agents already compress some implementation. The split between human and AI tasks is not settled. Evaluation, governance and customer context may matter more than today's deployment skills, but that is not proven.

  • The role may not suit you

    It can involve heavy travel, on-site work in unusual environments, client pressure and limited control over outcomes. Practitioners report burnout, though it is not measured.

  • Demand is concentrated

    Most postings come from a small number of employers and a few AI labs, and many are described loosely.

  • Growth figures are unreliable

    Reported percentages come from recruiters, vendors and a single job board, from different baselines.

  • Software roles remain the larger market

    Learners who keep general software engineering skills keep more options.

What we commit to

  • We show our sources and their dates, and update this page when the evidence changes.
  • We say whether a statement is primary data, a secondary report, an opinion or our own judgement.
  • We do not quote earnings figures as expected outcomes.
  • We describe the travel, scope and on-call expectations of the roles we teach toward, using employer postings as the reference.
  • Enrolment is a learning decision. Nothing in the course is a condition of employment.

Before you join the waitlist, read the risks above. Consider whether the skills would still be useful if forward-deployed roles shrink or change. If the answer is no, this may not be the right course for you.

Who this is for, and who should not take it

  • Software engineers with some production experience who want to work closer to customers and outcomes.
  • Engineers who are comfortable with ambiguity and want to learn evaluation and safe deployment.
  • Engineers who want a portfolio of clean, documented work.
  • Anyone looking for a guaranteed job, interview or income.
  • People who dislike client pressure, travel or unclear scope.
  • Anyone who wants a certificate recognised by a named employer. No such certification exists in the sources we reviewed.

KENYA AND AFRICA

In Kenya and across Africa

Demand shows up in health, banks and client-facing firms. The legal load is heaviest around health data, so the path uses synthetic data from the start.

Job boards showed forward-deployed and applied-AI postings in Kenya between April and October 2026, including one embedded in a government health programme, and banks are hiring for data and AI roles. These are job-board listings that we have not verified with the employers. We found no Kenya-wide count and no Kenyan engineer unemployment figure.

Integration surfaces an African forward-deployed engineer meets

  • M-Pesa Daraja APISTK Push, customer-to-business and business-to-customer flows, callbacks, retries and reconciliation.Production needs go-live approval from Safaricom. Check the official developer portal before relying on any endpoint detail.
  • Digital Health Agency, KHIS and DHIS2Connecting facility systems to national reporting and mapping to DHIS2 metadata.The Digital Health Agency publishes standards, and the older KHIS interoperability framework is several years old.
  • FHIR implementation guidesBuilding and validating FHIR resources for emergency, patient summary and claims flows.Some guides are community or vendor publications and not agency-issued, so check who published each one.
  • Bank and data modernisationData pipelines, APIs over core banking and assistants for relationship staff.Hiring signals are strong but we found no source on specific systems or standards.
  • Low-bandwidth, offline-first designQueue and sync, low-end devices, Swahili and mixed-language text, and power and connectivity gaps.Every capstone includes an offline or intermittent-connectivity constraint.

Guardrails the curriculum designs around

  • The Data Protection Act 2019 restricts how health data may be processed.Capstones use synthetic data, and Lesson 1.4 teaches consent-scoped data flows.
  • The Digital Health Act 2023 creates certification and data-custodian duties for health systems.Learners practise deployment against these constraints, not around them.
  • The Office of the Data Protection Commissioner has issued guidance on health data and on cross-border transfers.Lesson 4.4 includes a breach tabletop and a data-residency check.
  • Employer confidentiality applies to people who have just left a job.The clean-room rules in the portfolio checklist apply to every artefact.

This is research, not legal advice. We have not verified section numbers against the statutes, so we do not cite them. Check with counsel before any real deployment.

Remote work from Kenya usually runs through payout platforms such as Payoneer or Wise, or through an employer-of-record service. Fees and verification delays are common, and whether you count as a contractor or an employee depends on the facts of the arrangement, so get tax and employment advice. We make no promise of remote work.

QUESTIONS

Frequently asked questions

Direct answers, including the ones that do not flatter us.

What is a forward-deployed engineer?

An engineer who works close to a customer, often inside their environment, to find the real problem, build a working system on the customer's data and get it into production. The title is new and its definition varies, so we describe the definition we use at the top of this page.

How is a forward-deployed engineer different from a product engineer?

A forward-deployed engineer works with one customer at a time and ships into their environment. A product engineer works on the core product for all customers. They overlap, and the best forward-deployed engineers turn repeated customer work into product.

Is forward-deployed engineering the future of software engineering?

We do not claim that. It is an opinion that credible people hold and credible people dispute, and no source we found measures it. The US Bureau of Labor Statistics projects employment of software developers, quality assurance analysts and testers to grow 10 percent from 2025 to 2035, so forward-deployed work is a niche inside a larger occupation.

Will this path get me a job?

We do not guarantee jobs, interviews or any earnings, and nothing in the course is a condition of employment. The path teaches skills used in forward-deployed and product engineering work and helps you build clean, documented evidence of them.

How much experience do I need?

You should be able to ship a production service with tests and code review and have handled an incident. Postings we read most often ask for two to five years of production or customer-facing work, and a degree is rarely a hard requirement.

Which programming languages do I need?

No particular stack is required. In the 16 postings we read, Python appeared in 14 and TypeScript or JavaScript in 10.

Do AI coding agents make this path unnecessary?

Nobody knows the long-run split between human and AI work. Current evidence suggests agents shift effort toward verification, specification, evaluation and debugging, which is why those get the most time here. We also build in no-AI checkpoints, because the early evidence on learning with agents is mixed.

Can I use projects from my current or former employer?

No. Every artefact uses public data, synthetic data or data you generated. Do not reuse an employer's code, documents, customer names, metrics or screenshots.

Who signs off the work?

People. The AI coach gives feedback and advisory scores, and every stage gate needs a named human signature. The final capstone needs two.

Is there an official forward-deployed engineer certification?

Not in the sources we reviewed. This is an independent course. It is not affiliated with Palantir, OpenAI or any other employer.

When does it start?

There is no start date yet. The founding-cohort waitlist is open, and we will pilot the engineer track with a small group, measure the results and publish them.

Ready to start, or want to teach it?

Join the engineer waitlist
Teach as a Forward-Deployed Teaching Fellow Voluntary · not paid at this time

See all open rolesBrowse the Academy curriculum

Sources and dates

Built from public job postings and practitioner write-ups, researched on 2026-10-25. Last updated 2026-10-25. We update this page when the evidence changes.

  1. US Bureau of Labor Statistics: Software developers, quality assurance analysts and testers Employment projection 2025 to 2035. Accessed 2026-10-25. Confidence: High, primary.
  2. Anthropic: How AI assistance impacts the formation of coding skills 52 participants, 50% versus 67% comprehension, limits. Accessed 2026-10-25. Confidence: High, primary, vendor-run.
  3. METR: Early-2025 AI and experienced open-source developers 16 developers, 246 issues, 19% slower, forecast versus belief. Accessed 2026-10-25. Confidence: High, primary, marked out of date by authors.
  4. LeadDev: The rise of the forward-deployed engineer Reported Indeed posting growth and critic views. Accessed 2026-10-25. Confidence: Medium, secondary.
  5. Pragmatic Engineer: What are forward-deployed engineers? Role definition, scoping-validation-delivery phases, ability to say no. Accessed 2026-10-25. Confidence: Medium, partly paywalled.
  6. Ramp Builders: Forward-deployed engineering Selection axes, generalisation as a core principle, no published curriculum. Accessed 2026-10-25. Confidence: High for what it says.
  7. Barry McCardel: FDE culture Consulting-drift critique. Accessed 2026-10-25. Confidence: Medium, author has a position.
  8. Palantir forward-deployed software engineer posting (Lever) 1+ years, 25% travel, responsibilities. Accessed 2026-10-25. Confidence: High, primary posting.
  9. Databricks forward-deployed engineer posting, Seoul 7+ years, 20% travel, feedback to product. Accessed 2026-10-25. Confidence: High, primary posting.
  10. Databricks forward-deployed engineer posting, public sector 5+ years, clearance, 20 to 25% travel. Accessed 2026-10-25. Confidence: High, primary posting.
  11. Bloomberry: I analyzed 1,000 FDE jobs Experience-band comparison, direction only. Accessed 2026-10-25. Confidence: Medium, vendor data.
  12. Anthropic: Building effective agents Start simple, workflows versus agents, tool design. Accessed 2026-10-25. Confidence: High, primary, dated.
  13. Anthropic: Candidate AI guidance Take-home and interview AI-use rules. Accessed 2026-10-25. Confidence: High, primary.
  14. Hamel Husain: Your AI product needs evals Evals and error analysis before building judges. Accessed 2026-10-25. Confidence: High, practitioner.
  15. Simon Willison: Agentic engineering patterns Agentic engineering versus vibe coding, test-first practice. Accessed 2026-10-25. Confidence: High, practitioner.
  16. Stack Overflow Developer Survey 2025: AI Trust in AI output and debugging burden. Accessed 2026-10-25. Confidence: High, primary survey.
  17. Google Cloud: 2025 DORA report AI adoption, throughput and stability. Accessed 2026-10-25. Confidence: High, summary of report.
  18. OWASP Top 10 for LLM Applications 2025 Prompt injection and excessive agency. Accessed 2026-10-25. Confidence: Medium, read through secondary summaries.
  19. Kirschner, Sweller and Clark (2006), Why minimal guidance does not work Worked examples for novices, fading support with expertise. Accessed 2026-10-25. Confidence: Medium, abstract-level.
  20. Kenya Digital Health Agency: emergency FHIR implementation guide Agency role in KHIS, DHIS2 and standards. Accessed 2026-10-25. Confidence: Medium to high.
  21. Office of the Data Protection Commissioner: Guidance note on processing of health data Guidance exists. We could not extract the text, so we cite no detail from it.. Accessed 2026-10-25. Confidence: Medium, existence only.
  22. Safaricom Daraja developer portal Official source to verify M-Pesa API details. Accessed 2026-10-25. Confidence: Referenced, not fetched.

Markdown version of this page: /careers/engineers.md. Pawanax is a healthcare AI company based in Nairobi, Kenya. Careers · Teach with us · Academy