Most AI engineers build demos. You’ll build the production system a client’s business actually depends on.
Team: AI Delivery Practice
Location: Remote (Ukraine/Europe)
Employment: Full-time
Reports to: Head of AI Delivery/Engineering, not Sales, not Customer Success
Travel: Typically 20–30%, concentrated around engagement kickoffs and go-live weeks, confirmed with you per engagement, not a surprise
The Job, Honestly
Most AI engineering jobs let you perfect a demo. This one doesn’t. You get one client, one real opportunity, and six to twelve weeks to turn it into something running on live traffic — in their environment, on their data, with their security team watching. Then you do it again, for a different client, in a different industry, with a different set of constraints.
Success here isn’t measured in closed tickets. It’s measured in production adoption, business impact, and whether the client can run what you built without you standing over their shoulder.
If that sounds like the fun part of the job rather than the exhausting part, keep reading.
The AI Practice
You won’t be the only person figuring this out. Delivery patterns each engineer builds — a guardrail design, an eval harness, a way of scoping a RAG project so it doesn’t die in week 6 — get written down and reused by the next person on the next engagement. You’re not starting from zero each time, and neither is the person after you.
Engagements span the kind of variety a single-product company can’t offer: a RAG system on a client’s live data one quarter, an agent with real write-access and real guardrails the next, a legacy enterprise stack under regulatory constraints after that.
What the Work Actually Looks Like
Discovery through production — not discovery through a slide deck
• You sit with the client’s team — their repos, their data, their stand-ups — and find the AI opportunity worth betting six weeks on, not the one that looks best in a pitch
• You analyze their business processes, data landscape, and existing systems well enough to translate a business problem into a production-ready AI architecture
• You prototype it, validate it with real end users, and iterate on measurable outcomes before you’ve convinced yourself it’s right
• You ship it — and you’re still the one on call when it breaks in week two of production, not someone who inherits your code
• You capture what you learned so the next engagement, and the next engineer, start a little further ahead than you did
Before the contract is even signed
• Sales brings you into scoping calls, because “can this actually ship in 6–12 weeks” is an engineering judgment, not a sales one — and what you say shapes what gets sold
The actual engineering, once you’re in
• Production LLM applications — agents, RAG, orchestration — built on whatever stack the client’s environment actually runs on, not the stack that’s most fun to write in
• Integrations into whatever the client already has: their APIs, identity provider, cloud, messaging systems, the legacy piece nobody wants to touch
• Reliability work that never shows up in a demo: tool-call guardrails, retries, fallbacks, human-in-the-loop checkpoints
• Eval pipelines, golden datasets, and observability — because the job isn’t done at go-live, it’s done when the client can run the thing on their own
• The unglamorous optimization work: latency, cost, security, maintainability — whatever the client’s actual bottleneck turns out to be
Who Tends to Thrive Here
Less a checklist, more a description of the person who’s already done a version of this job:
• You can talk in detail about a production AI system you shipped for an external customer — what they wanted at kickoff, what they wanted at launch, and why that changed. This matters more to us than any line on your CV
• 5+ years as a commercial software engineer, with strong fundamentals and the ability to pick up whatever stack a given engagement requires — we hire for engineering depth
