What a forward deployed engineer does before the first line of code
May 17, 2026 · Zachary Meyer
There is a temptation, when you bring in an engineer, to measure value by how fast they start writing code. With embedded AI work, that instinct is exactly backwards. The code is the cheap part. The expensive part is being certain you are building the right thing, in an environment where it can actually run, against a definition of done everyone agreed to.
So before a forward deployed engineer writes anything, here is the work.
1. Pin down the problem and the metric
“Do something with AI” is not a problem statement. The first job is to convert ambition into a bounded problem with a measurable success criterion — a number, a threshold, a defined outcome that someone with authority will sign off on. If we cannot write that sentence together, no amount of code will fix it.
2. Map the real environment
Demos run on clean data and open permissions. Production does not. The engineer maps the actual systems, data sources, identity model, and constraints the solution will live inside — including the parts nobody mentions until week three. The architecture is shaped by this reality, not by a reference diagram.
3. Surface security and compliance up front
The fastest way to lose a quarter is to design as if security review happens at the end. We capture the regulatory and contractual obligations, the data classifications, and the access model before the architecture is fixed, so the build is designed to pass — not retrofitted to.
4. Define how quality will be judged
AI systems fail in ways traditional software does not. Before building, we agree on how output quality will be evaluated, where a human stays in the loop, and what “good enough to ship” means in measurable terms. That evaluation harness is part of the plan, not an afterthought.
5. Write down the plan and the gates
The output of this phase is not a deck. It is a scoped agreement: the problem, the metric, the architecture, the security plan, and the gates at which you approve moving forward. Everyone signs. Then the code starts — and because the hard questions are already answered, it moves fast.
Skipping this phase does not save time. It defers the hard questions to the moment they are most expensive to answer: in production, under review, with a stakeholder watching.
Curious how this maps to your situation? See How We Work or book a discovery call.