Jul 26, 2026 Forward Deployed Engineer AI Engineering 14 min read

Skills Every Forward Deployed AI Engineer Needs

By Arjun Jaggi  ·  Part 5 of 6: Forward Deployed Engineer Series  ·  Jul 26, 2026
← Part 4: FDE vs SE FDE Series  ·  Part 5 of 6: FDE Skills Next: FDE in Enterprise AI →

Every FDE skill exists in service of a single goal: delivering a working pilot that answers a real customer question on real customer data within a constrained time window. The skills that matter most are not the ones that look impressive on a resume. They are the ones that determine whether the system works on Thursday night before Friday's demo.

There is a tendency when listing skills for any role to compile everything that could be useful and present it as a comprehensive checklist. That approach produces lists that describe a mythical superhero rather than a hireable person. This is especially true for the FDE role, which sits at the intersection of software engineering, AI systems, customer engagement, and domain expertise.

The approach here is different. Rather than listing everything that could be useful, this post focuses on the skills that are genuinely determinative: the ones whose absence reliably causes FDE engagements to fail, and whose presence reliably causes them to succeed. Some skills that appear on standard job descriptions are not on this list because they are nice-to-have rather than load-bearing.

Tier One: Non-Negotiable Technical Skills

Core Technical
Python
Fluent enough to build a complete data-to-output pipeline without consulting syntax references. This includes data manipulation with pandas or equivalent, HTTP requests to APIs, basic file I/O, and error handling. Not expert-level optimization; practical fluency under time pressure.
LLM APIs
Able to call foundation model APIs, write prompts that produce structured outputs, handle context limits, implement basic retrieval-augmented generation, and reason about latency and cost tradeoffs. The FDE who does not understand token costs will build pilots that are too expensive to productize.
SQL
Able to query structured data sources: joins, aggregations, window functions, and basic performance reasoning. Most enterprise data is in relational or semi-relational systems. The FDE who cannot query independently is blocked every time they need data that requires more than a direct table read.
REST APIs
Able to read API documentation, authenticate using common patterns (API key, OAuth2, bearer tokens), handle errors and rate limits, and build lightweight wrapper functions. Virtually every enterprise system integration goes through an API.
Git
Able to maintain a clean repository that the product team can read and extend after the engagement ends. Not advanced git gymnastics; the ability to commit meaningfully, branch for experimentation, and produce a repository that is not a single-file pile of hacks.

A concrete example of what Tier One looks like in practice: a customer has 40,000 PDF contracts stored in an S3-compatible storage system. They want to know which contracts contain a specific liability clause with variations in phrasing. The FDE should be able to build and run the following type of pipeline in a single day:

import boto3, anthropic, json

s3 = boto3.client('s3', ...)
client = anthropic.Anthropic(api_key="...")

def extract_clause_presence(doc_text: str, clause_desc: str) -> dict:
    response = client.messages.create(
        model="claude-opus-4-5",
        max_tokens=256,
        messages=[{
            "role": "user",
            "content": f"""Does the following contract contain a clause
matching this description: {clause_desc}?

Contract text:
{doc_text[:6000]}

Respond as JSON: {{"present": bool, "excerpt": str_or_null, "confidence": "high"|"medium"|"low"}}"""
        }]
    )
    return json.loads(response.content[0].text)

results = []
for obj in s3.list_objects_v2(Bucket='contracts')['Contents']:
    text = extract_text_from_pdf(obj['Key'])  # custom PDF parser
    result = extract_clause_presence(text, "limitation of liability")
    results.append({"file": obj['Key'], **result})

This is not elegant engineering. It is the kind of working, readable code that can be shown to the customer's technical lead and extended by a product engineer in the handoff. Tier One is about building this kind of thing confidently and correctly under pressure.

Tier Two: High-Value AI-Specific Skills

AI Systems
RAG
Retrieval-augmented generation is the most common pattern in enterprise AI deployments. The FDE should be able to build a basic RAG pipeline: chunk documents, embed them, store in a vector index, retrieve by similarity, and pass retrieved context to a model. Understanding chunking strategy and embedding model choice matters because these decisions affect output quality on domain-specific content.
Prompt Eng
Able to write prompts that reliably produce structured outputs (JSON, specific formats) rather than free-form text. Able to diagnose prompt failures: the model is not following the format, the model is hallucinating, the model is inconsistent across similar inputs. Able to iterate quickly toward reliable prompts using small test sets.
Eval
Able to build a lightweight evaluation set: 20-50 inputs with known expected outputs, a scoring function, and a way to run the pipeline against the set and summarize accuracy. The FDE who cannot evaluate their own outputs quickly cannot tell the customer how well the system works or track improvements during the build.
Cost model
Able to estimate API costs for the pilot's actual usage pattern and extrapolate to the customer's full scale. A pilot that costs $50 to run may cost $50,000 per month at production scale, which changes the business case. The FDE who surfaces this early avoids the post-pilot conversation where the customer discovers the economics do not work.

Tier Three: Discovery and Communication Skills

Technical skills get the pilot built. Discovery and communication skills determine whether the pilot is the right thing to have built and whether the customer trusts it when they see it.

Discovery and Communication
Questioning
Able to ask questions that surface root problems rather than stated problems. The stated problem is usually a symptom. The root problem is where the real value lives. The FDE who builds a solution to the stated problem often builds something technically correct that the customer does not actually use because it did not solve the real problem.
Scoping
Able to write a scoping document that defines the pilot in one page: goal, data, success criteria, explicit exclusions, timeline. The scoping document is the FDE's primary tool for managing expectations, preventing scope creep, and ensuring that Friday's demo is evaluated against the right criteria.
Register
Able to switch communication register between technical and executive audiences in the same meeting. Lead with outcome for executives. Lead with mechanism for technical leads. Never use vendor vocabulary when customer vocabulary is available. This is a practiced skill, not a personality trait.
Limitation framing
Able to describe what the system does not do clearly and without defensiveness. "The system handles 80% of contract types accurately. The 20% that it handles less well are contracts with non-standard indemnity clauses, which we flagged for human review." This kind of honest framing builds more trust than a demo that avoids failure cases.

The T-Shape: Depth Plus Range

The most useful mental model for thinking about FDE skill development is the T-shape: a horizontal bar of broad knowledge across many domains, and a vertical bar of genuine depth in one or two areas.

The horizontal bar covers the basics of all skills listed above, enough to be competent and credible in each area. The FDE who has no SQL can be blocked by a data access problem. The FDE who cannot write a basic RAG pipeline cannot deliver the most common AI pilot pattern. Horizontal breadth prevents blockers.

The vertical bar is where the FDE becomes genuinely hard to replace. An FDE with deep healthcare domain expertise builds faster in healthcare engagements, earns trust sooner, and produces better scoping documents because they know the workflows, the regulations, and the failure modes before they arrive. An FDE with deep prompt engineering depth can iterate toward reliable outputs faster than one who is learning prompt design on the job.

The choice of what to put in the vertical bar is a strategic career decision. Domain expertise compounds with industry experience and is hard to acquire quickly, which makes it more durable as a differentiator than any specific technical tool. Technical tools change; domain patterns are more stable. An FDE who has worked with healthcare payer data across five engagements has pattern recognition that is worth more than expertise in any particular API that the healthcare payer systems expose.

FIG 01: T-shaped FDE: illustrative profile with breadth across all skill areas and depth in selected ones
Breadth across all skill areas RAG Healthcare SQL Legal

Skills That Are Overrated for FDEs

Understanding what not to spend time on is as important as understanding what to invest in. Several skills appear frequently in FDE job descriptions but are less determinative of actual engagement success than they appear.

Deep ML theory. The FDE who can describe backpropagation and transformer attention mechanisms in detail but cannot build a working RAG pipeline in a new environment is less useful than one with the opposite profile. The FDE is a practitioner, not a researcher. ML theory is background knowledge that helps when something goes wrong, but it is rarely the bottleneck in an engagement.

Advanced DevOps. Kubernetes expertise, CI/CD pipeline design, and infrastructure-as-code are valuable in product engineering. In a two-week pilot, they are usually a distraction. The pilot runs on whatever the FDE can spin up quickly. Production infrastructure is a handoff concern, not a pilot concern.

Presentation design. A well-designed slide deck is not what makes an FDE demo successful. A working system on real data is. FDEs who spend Thursday evening designing slides instead of running test cases are optimizing the wrong thing. The most effective FDE demos are often visually minimal and technically deep, because the audience is looking for evidence the system works, not for visual polish.

How to Build the Skill Set Intentionally

The FDE skill set cannot be acquired through reading alone. Every skill on the list above is built through doing, and the most effective doing is building pilots on real problems with real data and real constraints.

Concretely: find a problem in your organization or community that could benefit from an AI application. Run a mini discovery sprint to define the scope. Build a working pipeline in one week. Show it to the people whose problem it was. Write a one-page description of what you built, what you learned, and what would be required to take it further. Repeat this three or four times. Each iteration builds the pattern library, the debugging instinct, and the communication reflex that characterize effective FDE work.

The Forward Deployed Engineer course is structured around exactly this progression. Each module teaches one phase of the engagement arc, and the capstone requires completing a full pilot from discovery through handoff on a realistic scenario with real constraints. The skills compound across modules in the way they compound across real engagements.

Build These Skills Through Practice

The Forward Deployed Engineer course teaches every skill on this list through realistic scenarios: a discovery sprint, a scoping exercise, a pilot build, a demo, and a handoff. Each module builds on the last. Free, six modules, practical.

Start the Course

References

  1. Lewis, P., et al. (2020). Retrieval-augmented generation for knowledge-intensive NLP tasks. arXiv:2005.11401. Foundational paper on the RAG pattern used in most enterprise AI deployments.
  2. Yao, S., et al. (2022). ReAct: Synergizing reasoning and acting in language models. arXiv:2210.03629. On AI systems that interact with external data sources.
  3. Dreyfus, S. E., & Dreyfus, H. L. (1980). A Five-Stage Model of the Mental Activities Involved in Directed Skill Acquisition. University of California, Berkeley.
  4. Sommerville, I. (2010). Software Engineering (9th ed.). Addison-Wesley. On the distinction between practice-oriented and theory-oriented technical competency.
  5. Kay, A. C. (1993). The early history of Smalltalk. ACM SIGPLAN Notices, 28(3), 69-95. On the value of "learning by doing" in technical skill acquisition.
  6. Chen, L., Zaharia, M., & Zou, J. (2023). FrugalGPT: How to use large language models while reducing cost and improving performance. arXiv:2310.11409. On cost modeling for LLM API usage in deployment contexts.
  7. Liang, P., et al. (2022). Holistic evaluation of language models. arXiv:2211.09110. On evaluation methodology for LLM outputs in applied settings.