AI Engineer (Forward Deployed) You sit with the customer, then build and ship the system
You get placed on a business problem, not a ticket queue. You work out what actually needs to be true, then build and ship the system that makes it true, and you own it end to end.
You own the architecture, the code, the deployment, what happens when it breaks at 2am, and what it looks like three months later when the business has changed its mind twice. This is an engineering role. It is also a role where you'll be in the room with the customer. Both halves are real.
What forward deployed means here
You work with the customer, not downstream of them. You're there when the problem is described, rather than reading a spec someone else wrote after the conversation.
- You join the discovery calls and the working sessions, and you ask a developer's questions while the business owner is still there to answer them.
- You turn what you hear into functional and non-functional requirements yourself.
- You say “that is six weeks and here is why” or “that approach will not hold at your volume” in front of the client, and you keep the relationship.
- The gap between “we have this problem” and “here is a working thing you can click” is measured in days.
You're not an account manager or a solution consultant. You're the engineer who is close enough to the business to build the right thing on the first or second try.
Compound engineering
We don't want you typing every line by hand, and we don't want you accepting whatever the agent produced. We want you building a system that ships software.
You direct coding agents rather than prompt them. You write the instructions, the context, and the checks that make an agent reliable on this codebase and this domain. You review what comes out with real judgment about where the model is strong and where it quietly guesses. And you leave each engagement with a sharper setup than you walked in with, so the next feature lands faster than the last.
Your leverage should grow with every cycle. Your throughput in month six should embarrass your throughput in month one.
- If you've used Claude Code or Cursor mostly as a better autocomplete, that isn't this role yet. It's a fine place to start from.
- If you've built harnesses, subagents, instructions, and evaluation loops so that a substantial feature lands correctly while you review rather than type, that's exactly this role.
We're tech agnostic, and we mean it
We don't hire for a stack. We hire for engineering fundamentals and judgment. You'll meet whatever the customer already has, and that varies a lot across our accounts.
| Frontend | React, Next.js, Angular, plain TypeScript |
|---|---|
| Backend | Node, Python, .NET, Java |
| Data | Postgres, SQL Server, MongoDB, vector stores, and warehouses such as Snowflake or BigQuery |
| Cloud | Azure, AWS, GCP |
| AI | Anthropic, OpenAI, Azure OpenAI, open models, agent frameworks, retrieval, evals |
| Legacy and enterprise | AS/400 and green screen systems, ERP, long-lived line of business apps |
Nobody knows all of these, and we don't expect you to. The bar is that you're useful inside a week in an unfamiliar stack, because you understand what a web framework and a database are doing underneath, and where the failure modes live. A good signal: you explain a technology choice as a tradeoff. A better one: you've changed your mind about a stack you used to defend.
You think about software end to end
Most engineers stop at “the feature is merged.” We need you to carry the whole thing.
- Functional requirements
- What the system does, drawn from a conversation rather than a document.
- Non-functional requirements
- How fast, for how many users, at what cost per transaction, with what uptime, under what data residency and audit rules, and what the system does when the model is slow, expensive, or wrong. In enterprise AI work these usually decide a project. The demo almost always works.
- Deployment
- Environments, CI/CD, rollback, configuration and secrets, and infrastructure as code. You ship it yourself.
- Operations
- Structured logging, tracing, token and cost monitoring, and alerting. You know something is wrong before the customer calls.
- Security
- Authentication and authorization, single sign-on into the customer's identity provider, role models, data handling, and least privilege. OWASP principles applied in code, not recited in a review.
These are complex enterprise systems
Expect integrations with systems nobody has fully documented, single sign-on, role models with real consequences, security reviews, data that can't leave a region, audit trails someone will actually read, and three stakeholders who disagree with each other. The hard part is rarely the model. It's making something trustworthy enough that a regulated business will put it in front of its own customers.
What are we looking for?
- Four to ten years building and shipping software. The fundamentals matter far more than the number.
- You've shipped something end to end that real people used, and you can describe what broke in production and what you changed.
- You've built with LLMs in production, not only in a notebook, and you know what retrieval, context design, evals, and guardrails actually cost.
- You can draw a system architecture on a whiteboard with no preparation and defend every box on it.
- You have opinions about what not to build. The strongest signal we see is someone who has talked a customer out of something.
- You're comfortable when the requirements are a conversation, and you're the one who turns the conversation into the document.
- You can explain a technical tradeoff to a CFO and to a staff engineer in the same hour, differently.
Nice to have, not required: experience with legacy modernization, a regulated industry, or a system you inherited from someone who had left.
How do we interview?
We tell you up front, so you can decide whether it sounds like a good day.
- Round 1A build session with agentsAgents are allowed and encouraged. You use your own tools, and we watch how you direct them, what you check, and what you refuse to accept.
- Round 2Something you builtWe go deep on one system you owned: what the business needed, what you chose, and what you got wrong.
- Round 3Whiteboard architecture, unpreparedWe describe a real customer problem and you design in front of us. We're watching how you ask questions, not whether you land the perfect design.
- Round 4A conversation with leadershipYou meet the people you'd work for, and you decide whether we're right for you too.
There's no algorithm puzzle round.
Why Damco
Damco has built software for enterprises for thirty years. That means real customers with real systems and real budgets, which is harder to find than it sounds: most AI roles are either research with no customer, or a product team with one.
We're rebuilding how we deliver around AI from the inside. You'd be early in that, close to the people deciding what it becomes, and your opinions would land somewhere.