I recently started learning Forward Deployed Engineering alongside my System Design studies.
I expected the first lessons to be mostly about Generative AI, LLMs, tools and application architecture.
Instead, one of the first lessons was much more fundamental:
Before building the requested solution, understand the problem behind the request.
That sounds obvious.
But it changes how I think about engineering.
"We need an AI chatbot."
Imagine an e-commerce company tells an engineer:
"We need an AI chatbot."
The obvious reaction is to start thinking about:
- Which LLM should we use?
- Which framework?
- How should we design the API?
- Should we use RAG?
- How should we write the prompts? But the request itself may not describe the actual problem.
The company might actually be experiencing:
- Long customer-support resolution times
- Repetitive work for support executives
- Inconsistent answers
- Increasing support costs
- Too many routine requests
- Lack of support outside business hours So the real requirement could be something closer to: Reduce the time required to resolve customer problems without reducing accuracy or customer trust.
Now the engineering problem looks different.
The chatbot is no longer the requirement.
It is one possible implementation.
Request vs requirement
This distinction was one of my biggest takeaways from the first FDE lesson.
A useful engineering flow is:
Customer Request
↓
Understand Business Problem
↓
Understand Existing Workflow
↓
Identify Constraints
↓
Design Technical Solution
↓
Integrate With Existing Systems
↓
Test & Evaluate
↓
Production
This is different from simply receiving a feature request and immediately implementing it.
The engineer has to discover what the system actually needs to accomplish.
Then comes another problem: the LLM cannot do everything
Suppose a customer says:
"Cancel my order and refund my payment."
An LLM can generate a convincing sentence:
"Your order has been cancelled."
But the sentence itself doesn't cancel an order.
A production system needs something more like:
Customer Request
↓
LLM understands intent
↓
Application validates request
↓
Cancellation API
↓
Order / Database System
↓
Confirmed Result
↓
Customer Response
Now we have engineering questions.
Is the customer authorized?
Has the order already shipped?
Is the order actually cancellable?
What happens if the API fails?
What if the model identifies the wrong order?
Should a large refund require human approval?
How do we audit the operation?
How do we test it?
How much latency is acceptable?
How much does each interaction cost?
The LLM is only one component of the system.
An LLM doesn't automatically know the company
A general-purpose LLM may understand concepts like refunds, payments and deliveries.
But it doesn't automatically know the company's current:
- Refund policy
- Customer order history
- Delivery status
- Payment records
- Inventory
- Internal procedures
- Customer permissions The application therefore has to provide relevant information and connect the model with the systems that contain it.
Conceptually:
Customer Question
+
Company Policy
+
Customer Data
+
Previous Conversation
↓
LLM
↓
Grounded Response / Action
This is where AI application engineering becomes much more interesting to me.
The challenge isn't simply "use an LLM."
The challenge is building everything around the LLM so that the overall system behaves reliably.
What FDE adds to this
From my first lesson, I understand Forward Deployed Engineering as being close to the environment where the real problem exists.
An FDE works with customers, business teams, operations and engineering teams to understand the workflow, identify the actual problem, build a solution and help take it into production.
That means the role sits at an interesting boundary:
Real Customer Problem
↕
Forward Deployed Engineer
↕
Product + Data + APIs + Engineering
The technical solution is only part of the work.
Understanding the problem is also engineering work.
A lesson I want to carry forward
One sentence from this learning session stayed with me:
Don't start with the technology. Start with the problem.
It is easy to become excited about LLMs, agents, RAG, tools and frameworks.
But a production system still needs to solve a real problem.
And that means understanding:
Problem → Workflow → Constraints → System → Integration → Evaluation → Production
I'm going to continue this FDE + Generative AI journey alongside my System Design learning.
The goal isn't simply to learn how to call an LLM API.
The goal is to learn how to turn a real-world problem into a reliable engineering system.
Top comments (0)