Forward-Deployed Engineering Is More Than AI Coding

A practical note on why forward-deployed engineering is really about turning messy business problems into working systems.

AI has made building software prototypes much faster.

A developer can connect to a model API, generate some code, add a user interface, and demonstrate an AI-powered workflow in a surprisingly short time.

That is useful, but it is only a small part of the real problem.

The harder problem begins when the prototype needs to work inside an actual organization.

Real workflows involve existing systems, data, permissions, business rules, exceptions, users, security requirements, evaluation criteria, and operational constraints.

This is where Forward-Deployed Engineering (FDE) becomes useful.

The purpose of FDE is not simply to write AI code.

It is to reduce the distance between a real business problem and a system that can actually be used.

FDE sits between consulting and engineering

Traditional consulting and traditional software engineering often start from different places.

A consultant may begin with questions such as:

• How does the current process work?
• Where is time being lost?
• Which decisions require human judgment?
• Which systems are involved?
• What should change?

A software engineer may begin later:

• What API should we build?
• What data model should we use?
• How should the service be deployed?
• How do we test it?
• How do we monitor it?

Forward-deployed engineering connects these two sides.

A typical workflow looks more like this:

Business problem
      ↓
Discovery
      ↓
Workflow mapping
      ↓
Problem definition
      ↓
Technical design
      ↓
Prototype
      ↓
Evaluation
      ↓
Integration
      ↓
Production deployment
      ↓
Feedback and iteration

The engineer stays close to the problem throughout the process.

That distinction matters.

A technically correct system can still fail if it solves the wrong problem. A good process design can also fail if nobody can turn it into reliable software.

FDE tries to own the space between the two.

AI makes this more important, not less

Access to AI models is becoming easier.

Calling an LLM API is no longer a significant technical advantage by itself.

The difficult questions are usually somewhere else:

• What information should the model receive?
• Which steps should use AI and which should remain deterministic?
• Which company systems need to be connected?
• What happens when the model is wrong?
• How should output be evaluated?
• Where should human approval remain?
• What happens when an external API fails?
• How do we know whether the system is actually improving the workflow?
• How does a prototype become something people can depend on?

These are system questions rather than prompt questions.

This is one reason we think AI projects benefit from a forward-deployed approach.

The model is one component inside a larger workflow.

1. Understand the workflow before automating it

A good FDE project does not begin with:

Where can we add AI?

It begins with:

How does the work happen today?

That means understanding the people, information, decisions, systems, and repeated steps involved.

For example, a process may currently involve:

Customer request
      ↓
Email
      ↓
Manual classification
      ↓
Document lookup
      ↓
Internal system
      ↓
Human decision
      ↓
Report
      ↓
Customer response

The opportunity may not be to automate everything.

It may be enough to automate information collection, classification, preparation, or validation while keeping the important decision with a person.

Understanding that boundary is part of the engineering work.

2. Translate business problems into technical systems

Business requirements rarely arrive as clean technical specifications.

A user may say:

This process takes too long.

The engineering questions then become:

• Which step is actually slow?
• What information is needed?
• Which systems contain that information?
• Can the step be automated safely?
• What should happen when automation fails?
• What does a successful outcome look like?

The FDE has to translate between these two languages.

This is similar to enterprise software implementation: understand the workflow first, then turn it into a system design.

The difference is that modern AI systems often allow much faster experimentation.

3. Build the smallest useful end-to-end system

A prototype should answer a question.

It should not exist simply to demonstrate that an AI model can generate an impressive response.

A useful first version might connect:

Real input
   ↓
Application logic
   ↓
AI model
   ↓
Business rules
   ↓
Existing data
   ↓
Evaluation
   ↓
Human review
   ↓
Real output

Even if the first implementation is small, it should represent the real workflow closely enough to expose the difficult parts.

Those difficult parts often become visible only after something is actually built.

4. Treat AI as a component, not the whole architecture

AI systems still need ordinary software engineering.

Depending on the project, this may include:

• APIs
• databases
• authentication and authorization
• background jobs
• queues
• external integrations
• logging
• testing
• version control
• containers
• cloud infrastructure
• monitoring

The AI layer adds another set of questions:

• prompt and context management
• model selection
• structured outputs
• tool use
• retrieval
• latency
• cost
• failure handling
• evaluation
• model changes
• guardrails

The architecture therefore needs to handle both normal software failures and AI-specific uncertainty.

5. Evaluation is part of the product

One of the most important questions in an AI system is surprisingly simple:

How do we know that it works?

A demo can look convincing while still failing frequently in real use.

For this reason, evaluation should not be something added at the end.

It should be designed together with the workflow.

Depending on the application, evaluation may involve:

• expected outputs
• business rules
• test cases
• quantitative metrics
• human review
• historical examples
• regression tests
• failure classification

For software engineering systems, evaluation may go even further.

A generated patch, for example, should not be considered correct simply because an AI agent produced it or because one test passed.

The system may need additional tests, requirement checks, or independent verification.

This principle applies beyond software development.

AI should be evaluated against the outcome the workflow actually requires.

6. Production is different from a demo

A prototype asks:

Can this work?

A production system asks many more questions:

What happens when it does not work?

What happens when:

• the model API times out?
• a document is malformed?
• a database is unavailable?
• the same request arrives twice?
• the model returns an unexpected structure?
• a user does not have permission to access the requested information?
• the underlying model changes?
• the workload becomes ten times larger?

Forward-deployed engineering has to consider these questions because the goal is not simply to produce a demonstration.

The goal is to create something that can become part of normal work.

Where this approach is useful

Not every business problem requires an FDE.

The approach is particularly useful when a problem combines business workflow complexity and technical implementation.

Examples may include:

• AI-assisted internal workflows
• document processing and review
• customer-support automation
• software engineering and testing workflows
• internal knowledge systems
• reporting and analysis pipelines
• integration between existing business systems
• repetitive operational processes
• human-in-the-loop decision support

These projects usually cannot be solved by installing one generic AI tool.

They require understanding how the organization already works.

How Lunapapa approaches FDE

At Lunapapa, we see forward-deployed engineering as a natural extension of our approach to workflow automation.

The starting point is not the model.

The starting point is the process.

Our perspective combines experience from enterprise workflow and functional consulting, software engineering, software testing and evaluation, and practical AI automation.

This is useful because AI implementation increasingly requires all of these perspectives at the same time.

A project may require understanding a business process like a consultant, designing the system like a software engineer, evaluating its behavior like a tester, and iterating quickly like a product team.

The objective is not to add AI everywhere.

The objective is to identify where software, automation, and AI can make a real workflow simpler, faster, more reliable, or easier to evaluate.

FDE is also a feedback loop

Forward deployment should not end when software is delivered.

Real users expose assumptions that were invisible during design.

They reveal:

• missing edge cases
• unnecessary steps
• confusing interfaces
• incorrect assumptions
• new automation opportunities
• failures that were difficult to reproduce in development

That information should flow back into the system.

Understand
   ↓
Build
   ↓
Deploy
   ↓
Observe
   ↓
Evaluate
   ↓
Improve
   └────────→ repeat

This feedback loop is one of the most valuable parts of working close to the customer.

Practical lesson

AI has dramatically reduced the cost of producing code.

But producing code was never the entire problem.

Organizations still need to decide what should be built, how it should connect to existing work, how correctness should be evaluated, how failures should be handled, and how the system should improve after deployment.

That is the space where forward-deployed engineering becomes valuable.

The value of an FDE is not simply writing more AI code. It is shortening the distance between a business problem and a working system.

For us, that means staying close to both sides: understanding the workflow and being able to build the technology behind it.

If your organization has a repeated workflow where AI or automation looks promising, but moving from an idea to a reliable working system is the difficult part, that is exactly the kind of problem a forward-deployed engineering approach is designed to address.