# From software engineer to forward-deployed engineer: a skills path built on evidence Published 2026-10-25. Last updated 2026-10-25. Researched 2026-10-25. Publisher: Pawanax (https://pawanalife.com). Canonical: https://pawanalife.com/careers/engineers 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. ## 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. ## 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* | Role | Where in the customer lifecycle | Main output | Writes production code for the customer? | | --- | --- | --- | --- | | Forward-deployed engineer | After the sale, embedded, long term | A working production system in the customer's environment | Yes | | Product engineer | Core product, all customers | A shared product capability, with ownership of outcomes | Yes, for the core product | | Solutions engineer | Before the sale | A demo, proof of concept or technical validation | Limited, often on sample data | | Applied AI engineer | Varies widely | A model, agent or retrieval feature for a product or customer | Yes | Titles blur. Some roles labelled forward-deployed are closer to pre-sales or consulting, so check the job content and not the title. ## 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. Source: [LeadDev, 23 Jul 2026, citing Indeed](https://leaddev.com/career-development/the-rise-of-the-forward-deployed-engineer-fde). - **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. Source: [US Bureau of Labor Statistics, Occupational Outlook Handbook](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm). - **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. Source: [Barry McCardel, FDE culture](https://www.barry.ooo/posts/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%. Source: [Palantir posting, Lever](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0). - **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, 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 skills #### T1 Full-stack production delivery (Table stakes; named in 16 of 16 postings) - **Learner:** A small full-stack app deployed, with tests and CI. Can trace one request end to end. - **Practitioner:** Owns deploy, logs and rollback for one service. Pull requests reviewed and comments addressed. - **Independent FDE:** Takes a customer workflow to production inside their stack. Handover runbook written. The customer uses it without help. - **Lead:** A reference architecture reused by at least two deployments. Reviews other engineers' designs. #### T2 Data integration and messy data (Table stakes; named in 7 of 16 postings) - **Learner:** Cleans a dataset with a documented issue log and before-and-after counts. - **Practitioner:** An ingestion pipeline with retries and idempotency, tested with bad-input fixtures. - **Independent FDE:** A live integration with the customer's systems of record. Reconciliation report and a signed data contract. - **Lead:** Reusable connectors used across customers. Governance decisions documented. #### T3 APIs and enterprise systems (Table stakes; named in 6 of 16 postings) - **Learner:** A client for a real REST API with authentication and pagination, with tests. - **Practitioner:** Webhook or callback handling, a sandbox-to-production switch and idempotency keys. - **Independent FDE:** An integration into a system of record under the customer's change control, with a cutover plan and reconciliation after go-live. - **Lead:** An integration standard the team uses. Security reviews passed for a multi-customer pattern. #### T4 Language-model application building (Table stakes; named in 15 of 16 postings) - **Learner:** A prompt-driven feature with schema-validated output and a documented fallback. - **Practitioner:** A tool-calling flow with cost and latency logged per request. - **Independent FDE:** A customer workflow with guardrails and human review, and a written reason for choosing a workflow over an agent. - **Lead:** Team defaults for patterns, and documented cases where the team chose not to use a model. #### T5 Agents and orchestration, safely (Everyone mentions it, few show it; named in 6 of 16 postings) - **Learner:** A single tool loop with a step limit and a stop condition. - **Practitioner:** Permission scopes, sandboxing and per-step logs. Tool descriptions tested on sample inputs. - **Independent FDE:** An agent in a customer environment with approval gates and rollback. No unapproved actions in the logs. - **Lead:** A guardrail policy used by several deployments, with documented handoff rules between agent and human. #### T7 Evals and observability (Differentiator; named in 3 of 16 postings) - **Learner:** 20 to 50 labelled cases for one feature, run on every change. - **Practitioner:** Reads traces and builds an error taxonomy with counts. Checks any model judge against human labels and reports the agreement. - **Independent FDE:** Owns the eval suite for a deployment, built with the customer's domain expert, and gates releases on it. - **Lead:** Shared eval tooling used by three or more teams. Trains others. #### T8 Deployment, security and infrastructure (Table stakes; named in 10 of 16 postings) - **Learner:** A containerised app with secrets handled correctly and documented deploy steps. - **Practitioner:** Infrastructure as code, least-privilege access and deploy logs. - **Independent FDE:** A deployment into a customer's cloud account or private environment. Security review signed off. Data residency respected. - **Lead:** Deployment archetypes reused across customers. Leads compliance planning. #### T10 Unfamiliar code and debugging (Table stakes; named in 0 of 16 postings) No posting names this explicitly, but it is load-bearing in practice. Our judgement: postings under-state it. - **Learner:** Traces one request through an unfamiliar repository and writes a one-page map. - **Practitioner:** Fixes a bug in code they did not write, with a regression test. Uses logs and traces. - **Independent FDE:** Diagnoses across the network, identity, data and model layers, with hypotheses written down and tested. - **Lead:** Teaches the method. Repeat-incident fixes are merged by the team. #### T11 Incidents in a customer's environment (Differentiator; named in 3 of 16 postings) - **Learner:** Shadows an on-call rotation and writes an incident timeline. - **Practitioner:** On call for a service. Follows a runbook. Writes a blameless postmortem with action items. - **Independent FDE:** Leads an incident in a customer environment, sends status updates to customer leads, restores service and ships the follow-up fixes. - **Lead:** Designs escalation and on-call for multi-customer deployments. Reviews incident trends. ### Customer and deployment skills #### C1 Discovery interviews (Everyone mentions it, few show it; named in 12 of 16 postings) - **Learner:** Runs three structured interviews from a script. Notes and summary written. - **Practitioner:** Runs discovery alone with a frontline user. A workflow map with direct quotes. - **Independent FDE:** Runs discovery across executives and frontline staff. A first use case with a named success metric and sponsor sign-off. - **Lead:** Sets discovery standards and reviews other people's briefs. #### C2 Scoping ambiguous problems (Table stakes; named in 13 of 16 postings) - **Learner:** Breaks a given task into subtasks with estimates and flagged unknowns. - **Practitioner:** Turns an ambiguous request into a milestone plan with explicit assumptions and risks. - **Independent FDE:** Scopes a multi-workstream deployment around the customer's gates: security, procurement and data access. - **Lead:** Makes scoping and capacity decisions across several customers. #### C4 Adoption and change management (Differentiator; named in 2 of 16 postings) - **Learner:** Writes a how-to for one workflow. - **Practitioner:** Runs a training session and collects usage data afterwards. - **Independent FDE:** Owns an adoption plan with usage targets, handles resistance and reports adoption to the sponsor. - **Lead:** An adoption playbook used across customers. #### C5 Written and live communication (Table stakes; named in 16 of 16 postings) - **Learner:** Clear pull-request descriptions and a ten-minute demo to a mixed audience. - **Practitioner:** Design documents accepted without a rewrite. Demos that answer the audience's actual question. - **Independent FDE:** Executive briefs that drive a decision. Leads live working sessions with customer engineers and executives. - **Lead:** Sets writing standards and reviews other people's customer-facing documents. #### C7 Saying no and holding scope (Differentiator; named in 0 of 16 postings) No posting names this explicitly. Practitioner accounts of the role treat boundary-setting as central, so we teach it deliberately. - **Learner:** Flags a scope change in writing. - **Practitioner:** Declines an out-of-scope request and offers a named alternative. - **Independent FDE:** Negotiates trade-offs with options and holds the boundary under pressure. Keeps a scope-change log with decisions. - **Lead:** Sets policy on custom work versus product features. #### C8 Commercial scoping (Differentiator; named in 3 of 16 postings) - **Learner:** Explains a simple return-on-effort estimate and its assumptions. - **Practitioner:** Builds a proof of value with success criteria agreed in advance. - **Independent FDE:** Provides input to a statement of work and anticipates procurement and legal steps. - **Lead:** Shapes deals and documents the decision to decline unfit ones. ### Product skills #### P2 Prototype to product (Everyone mentions it, few show it; named in 10 of 16 postings) - **Learner:** States the prototype's limits in a README. - **Practitioner:** Ports a prototype into the product repository with tests. - **Independent FDE:** Productises a customer pattern as a versioned module used by at least two customers. - **Lead:** Decides build versus buy for platform features. #### P3 Metrics and outcome measurement (Differentiator; named in 1 of 16 postings) - **Learner:** Defines one metric and how it will be measured. - **Practitioner:** Instruments usage events and reports weekly. - **Independent FDE:** Ties a deployment to a customer outcome with a baseline and a post-deployment number. - **Lead:** Designs company-level metrics for deployments. #### P4 Feedback into the core product (Everyone mentions it, few show it; named in 12 of 16 postings) - **Learner:** Logs field issues with reproduction steps. - **Practitioner:** Writes reproduction-backed issues and contributes eval cases. - **Independent FDE:** Turns field patterns into roadmap items with deployment evidence attached, and closes the loop with the customer. - **Lead:** Runs the feedback system and sets its priorities. ## 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. ### Stage 1: Customer-facing foundations (50 hours) 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. #### 1.1 Discovery and problem framing (12 hours) - 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, 5.4 #### 1.2 Scoping and saying no (10 hours) - 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.3 Writing for non-engineers (12 hours) - 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.4 Data map, consent and sensitive data (16 hours) - 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 **Gate:** All four lessons signed. ### Stage 2: Messy data and integration (70 hours) 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. #### 2.1 Profiling and data contracts (16 hours) - 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.2 Entity resolution and idempotent ingestion (18 hours) - 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.3 Reconciliation and exception queues (18 hours) - 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.4 Integration under failure (18 hours) - 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. ### Stage 3: Language-model workflows, built and evaluated (80 hours) 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. #### 3.1 Choosing the pattern (14 hours) - 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, 3.3 #### 3.2 Error analysis before evals (20 hours) - 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 #### 3.3 Building and calibrating evals (24 hours) - 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, 4.2 #### 3.4 Tool design, guardrails and red-teaming (22 hours) - 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, 3.5, 8.2 **Gate:** All four lessons signed. Capstone A is completed at the end of this stage. ### Stage 4: Deploying into a customer environment safely (70 hours) 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.1 Environment discovery (12 hours) - 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.2 Security baseline and threat model (18 hours) - 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 #### 4.3 Staged rollout and rollback (20 hours) - 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 #### 4.4 Privacy operations and breach response (20 hours) - 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 **Gate:** All four lessons signed. Capstone B is completed at the end of this stage. ### Stage 5: Pilot, value, handoff and product feedback (64 hours) 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. #### 5.1 Pilot design (12 hours) - 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 #### 5.2 Measuring value honestly (18 hours) - 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.3 Handoff and enablement (18 hours) - 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.4 Feeding learnings back to product (16 hours) - 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. ## 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. ### Capstone A: Clinic referral triage network (24 hours; 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 ### Capstone B: Savings co-operative loan-document assistant (26 hours; 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 ### Capstone C: Agricultural co-operative harvest intake and reconciliation (40 hours; 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 ## 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. Source: [Anthropic, AI assistance and coding skills, Jan 2026](https://www.anthropic.com/research/AI-assistance-coding-skills). - **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. Source: [METR, July 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). ### The rules we practise 1. **Explain before accepting.** Do not merge code you cannot explain line by line. 2. **Write the check first.** Define tests or eval cases before asking an agent to implement. 3. **Predict and time.** Estimate the time with and without the agent, record the actual, and compare. 4. **Keep a decision log.** Record what the agent suggested, what you accepted or rejected, and why. 5. **No-AI checkpoints.** Each stage has a short task done without agents and graded by a human. 6. **Least privilege.** Give a coding agent only the directories, credentials and commands it needs. No production credentials in learning environments. 7. **Documents are untrusted.** Agents must not follow instructions found inside data, tool output or web pages. 8. **Simple first.** Start 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. ## 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. ## 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. Not for: - 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. ## 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 API.** STK 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 DHIS2.** Connecting 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 guides.** Building 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 modernisation.** Data 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 design.** Queue 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. ## 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](https://pawanalife.com/academy?persona=engineer#waitlist) - [Teach as a Forward-Deployed Teaching Fellow](https://pawanalife.com/careers/forward-deployed-teaching-fellow) (Voluntary ยท not paid at this time) - [See all open roles](https://pawanalife.com/careers#open-roles) - [Browse the Academy curriculum](https://pawanalife.com/academy/curriculum) ## Sources and dates 1. [US Bureau of Labor Statistics: Software developers, quality assurance analysts and testers](https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm). Employment projection 2025 to 2035. Accessed 2026-10-25. Confidence: High, primary. 2. [Anthropic: How AI assistance impacts the formation of coding skills](https://www.anthropic.com/research/AI-assistance-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](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). 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](https://leaddev.com/career-development/the-rise-of-the-forward-deployed-engineer-fde). Reported Indeed posting growth and critic views. Accessed 2026-10-25. Confidence: Medium, secondary. 5. [Pragmatic Engineer: What are forward-deployed engineers?](https://newsletter.pragmaticengineer.com/p/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](https://engineering.ramp.com/post/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](https://www.barry.ooo/posts/fde-culture). Consulting-drift critique. Accessed 2026-10-25. Confidence: Medium, author has a position. 8. [Palantir forward-deployed software engineer posting (Lever)](https://jobs.lever.co/palantir/dab396d4-2f14-4796-aac0-0d82883dccf0). 1+ years, 25% travel, responsibilities. Accessed 2026-10-25. Confidence: High, primary posting. 9. [Databricks forward-deployed engineer posting, Seoul](https://www.databricks.com/company/careers/professional-services-operations/forward-deployed-engineer-8540455002). 7+ years, 20% travel, feedback to product. Accessed 2026-10-25. Confidence: High, primary posting. 10. [Databricks forward-deployed engineer posting, public sector](https://www.databricks.com/company/careers/professional-services-operations/forward-deployed-engineer-fde---public-sector-8611108002). 5+ years, clearance, 20 to 25% travel. Accessed 2026-10-25. Confidence: High, primary posting. 11. [Bloomberry: I analyzed 1,000 FDE jobs](https://bloomberry.com/blog/i-analyzed-1000-forward-deployed-engineer-jobs-what-i-learned/). Experience-band comparison, direction only. Accessed 2026-10-25. Confidence: Medium, vendor data. 12. [Anthropic: Building effective agents](https://www.anthropic.com/engineering/building-effective-agents). Start simple, workflows versus agents, tool design. Accessed 2026-10-25. Confidence: High, primary, dated. 13. [Anthropic: Candidate AI guidance](https://www.anthropic.com/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](https://hamel.dev/blog/posts/evals/index.html). Evals and error analysis before building judges. Accessed 2026-10-25. Confidence: High, practitioner. 15. [Simon Willison: Agentic engineering patterns](https://simonwillison.net/2026/Feb/23/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](https://survey.stackoverflow.co/2025/ai). Trust in AI output and debugging burden. Accessed 2026-10-25. Confidence: High, primary survey. 17. [Google Cloud: 2025 DORA report](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-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](https://owasp.github.io/www-project-top-10-for-large-language-model-applications/assets/PDF/OWASP-Top-10-for-LLMs-v2025.pdf). 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](https://www.tandfonline.com/doi/pdf/10.1207/s15326985ep4102_1). 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](https://fhir.dha.go.ke/ig/ems/background.html). 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](https://www.odpc.go.ke/wp-content/uploads/2024/02/ODPC-Guidance-Note-on-Processing-of-Health-Data.pdf). 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](https://developer.safaricom.co.ke). Official source to verify M-Pesa API details. Accessed 2026-10-25. Confidence: Referenced, not fetched.