Forward Deployed Engineering

How I became a forward deployed engineer without a software engineer title

The title is new; the work is old. Twelve years of enterprise deployments plus public, measured AI work. The honest path, artifacts included.

By Simon Gonzalez de Cruz (follow the build in public on X @KyaniteLabs_). 2026-08-24. The honest version, no resume inflation.

You do not need a software engineer title to do forward deployed work, and my path is the proof. I hold no FDE badge from an AI lab. What I have is twelve years of deploying enterprise systems for real organizations, then a period of building and measuring AI on my own hardware with everything published. That combination is the job. This post is the path exactly as it happened, with the artifacts, and without inventing anything.

Let me be precise about what I am not claiming, because this industry runs on inflated claims. I was never employed as a software engineer. I never worked at Palantir or an AI lab. If you want those lines on a resume, this is not your post. If you want to do the work and be findable by it, it is.

Phase one: twelve years of deployments nobody called FDE

Enterprise learning systems: Workday, SuccessFactors, Cornerstone, for organizations of more than 8,000 people. That work was forward deployment in everything but name. Configuration for a real customer's strange requirements. Integrations with whatever systems already existed. Data migrations where an error means a person's training record disappears. Rollout, training, and then ownership in production, for years.

The transferable skills from that world: reading a messy real workflow and finding where it actually breaks, writing for non-engineers, and treating go-live as the beginning, not the end. If you have done this kind of work in ERP, CRM, medical systems, or industrial software, you already have phase one. You just have not labeled it.

Phase two: own the whole stack, then measure it

The modern version of the job needs AI-specific skills. I built them in public, on my own hardware, because that removes every excuse. The rig is a $1,400 GMKtec EVO-X2 mini-PC running a 27B model locally. Everything below is linked and reproducible.

  • Serving in production. The model runs always-on with watchdogs, restart recovery, and queue discipline. The complete measured serving story, with the upstream llama.cpp bug we caught, bisected, and validated the fix for, is on this blog.
  • Benchmarking with intervals. 93% HumanEval (28/30, frozen subset) and 67% LiveCodeBench-30 (20/30, Wilson 95% interval 49 to 81). Published with conditions, seeds, and raw logs.
  • An eval with my name on it. delegation-bench: 495 trials, 29 cells, certified floors, a sabotage cell, walk-away certification. This artifact does more work than any title. Details in evals are the FDE skill nobody lists.
  • Shipped open source people actually use. A video-editing MCP server, Kinocut, with merged upstream contributions. Integration glue is the daily texture of forward deployed work.

The exact recipe, if you want to copy it

Step one: take a domain where you already know what "working" means. Step two: buy or rent hardware you control, or use cloud if you must, and run a real model workload on it. Step three: measure something honestly and publish the number with its interval and its conditions. Step four: build an eval for a decision someone actually makes. Step five: keep the system running unattended and write down what breaks.

Do those five things and you will have what interviewers for these roles are actually probing for: evidence you can find the leverage point, build with evals, and own it in production. None of the five steps requires a title. All of them produce artifacts with your name on them.

The honest gaps

What this path does not give you: the internal referral networks of a big lab, experience with frontier-scale training runs, and the specific brand names that recruiters filter on. Those are real costs and I will not pretend otherwise. The compensation is that everything you claim is checkable, and the buyers who care about checkable are the buyers worth having.

Start with the series: what a forward deployed engineer actually does, the title decoder, and the eval skill.

Want this work done in your environment instead of reading about it? Implementation intake. Every artifact cited: delegation-bench (evals), qwen38-27b-strix-halo (serving), simongonzalezdc (Kinocut and other repos). Conditions for all numbers: $1,400 GMKtec EVO-X2, Qwen3.8-27B Q4_K_XL, llama.cpp.

Work with Kyanite

Want this working in your environment?

If this post describes a Kyanite tool or result you need, implementation help can cover setup, advising, docs, examples, checks, and a usable handoff.

Fit boundary

Kyanite offers help grounded in its tools, products, and build practice. Broader consulting routes through PuenteWorks.

Keep following the system.

The One-Line Bug That Crashed Our Fast Lane: finding, fixing, and measuring a speculative-decoding crash on a $1,400 mini-PC

Spec decoding crashed our fastest lane on day one. The bug was one missing line in our fork; the fix bought +17.7% and a surprise about draft quantization.

Two models, one $1,400 mini-PC: the paired numbers, failures included

A 35B reasoning model now runs shoulder to shoulder with our daily 27B on one $1,400 box, at the same time. Every number paired, same problems, same machine. The failures are in here too.

Evals are the FDE skill nobody lists: my 495-trial public benchmark

The market says it cannot find people who can build AI evals. The skill is learnable and I published mine: 495 trials, certified floors, sabotage cell, open source.

Forward deployed vs solutions engineer vs implementation vs customer engineer: the title decoder

Four titles, one job family, different coding bars. A decoder that reads any posting and tells you what you are actually signing up for.

What does a forward deployed engineer actually do? A demo on a $1,400 mini-PC

The straight answer, then the receipts: the whole FDE job run end to end on a $1,400 mini-PC, with public evals.

The Delegation Card: we asked a $1,400 mini-PC to take our jobs

Not is-it-smart but can-you-hand-it-work-and-walk-away. 495 certified trials, then re-validated at deeper n after the product changed: 965 total, floors to 92.8%.

Qwen 3.8 27B on Strix Halo: the complete measured story

Every dial measured, every number public: the frozen optimal config for a 27B on a $1,400 mini-PC.

Lab Notes: the measured-knees method for reasoning effort

A methods note on reasoning-effort calibration. Thinking rescued 15/40 hards vs 4/40 off. On easy tasks it bought nothing. Publish the knee.

Lab Notes: 67% LiveCodeBench-30 on a $1,400 rig

20/30 = 67% LiveCodeBench-30 on a $1,400 mini-PC. Wilson 95% CI 49-81%. Easy 10/10, medium 8/10, hard 2/10. n=30 public subset. Not the card.

Lab Notes: we reverted a llama.cpp regression

We found a llama.cpp regression and reverted it. n=6 battery on a $1,400 rig: 0/6 slashes before, 5/6 after. Same Q4_K_XL. Not a quant story.

Lab Notes: 93% HumanEval on a $1,400 rig

28/30 = 93% HumanEval on a $1,400 mini-PC. Qwen3.8-27B Q4_K_XL. Temp 0, thinking off. Failures: 50 and 145. Raw log linked.

Lab Notes: the model that can't forget but can't remember

The number first: this model is 75% not a transformer. 48 of 64 layers keep a running state. On a $1,400 rig, load 198k once (1818s), then query in 9-27s.

Lab Notes: the basin was a bug

We published a basin. The serving binary was the hole. After the c7d8722 revert: 6/6 HIT at 198k. n=1 map of the fixed build.

Lab Notes: the KV verdict

The q8-to-q4 KV question from night 1 got its paired answer: same accuracy, zero tripwires, half the cache. Plus the label we had to correct in public when the server's counter beat our estimate.

Lab Notes: verdict night

A $1,400 mini-PC serving a 27B at 262k context asks one question: does capping thinking cost accuracy? The paired answer, the invalid first attempt it survived, and the doctrine that followed.

One mini-PC, one night, and the numbers that argued with themselves: tuning Qwen3.8-27B on Strix Halo

A fully measured night-and-evening of tuning a 27B dense model on a Strix Halo mini-PC: the honest bands, the reversal, the crash doctrine, and the EC detective story.

GPT-5.6 Sol vs. Terra vs. Luna: an evidence-based routing policy for coding agents

The practical GPT-5.6 split is Sol for discovery, Terra for bounded execution, and Luna for repeatable processing - with a different verification contract for each.

Agents need verifiable tools, not better prompt theater

The useful agent pattern is not a prettier prompt. It is a tool surface the agent can call, inspect, verify, and revise.

Repo history is a product signal

A repo is not just storage. It is evidence of decisions, repairs, release behavior, naming drift, test gaps, and what the builder actually knows how to finish.

Implementation help is part of the product surface

A useful open-source tool still needs a path from public repo to working environment. That path is product work, not an afterthought.

Why Kinocut matters

Kinocut gives AI agents callable handles on timelines, effects, Hyperframes, and finished media at kinocut.dev.

Infinite monkeys, LLMs, and the room around the machine

The argument behind the video: output quality is not just probability. It is architecture, filters, and human taste.

What a working AI tool needs before people can use it

A practical checklist for turning a working tool, workflow, or rough app into something other people can understand, install, and use.

MCP server implementation checklist

The checklist Kyanite uses to decide whether an MCP server is a toy, a usable tool, or something worth implementing.

Repo archaeology turns history into proof

Why commit history is one of the strongest proof sources for learning diagnostics, implementation help, and engineering trust.

AI discovery needs more than a sitemap

What Kyanite adds so search engines and AI assistants can understand the tools, products, proof, and support path.