The client conversation is the FDE delta, the thing an AI engineer doesn't do. Three moves carry it: scope a request without just saying yes, push back on the wrong ask with a reason, and translate engineering into the customer's own terms of value and risk. The customer-craft section teaches these as job skills; this page drills the interview-clock version, where they show up as "how would you handle it if the customer said…"
Drill 1 — scope without over-promising
The line: the customer's VP opens with, "We want this live for all five hundred field reps by end of quarter."
Before reading on: you can't honestly promise that yet. How do you respond without either caving to the date or sounding like you're stalling?
Bad / Good / Great — the scoping reply
Bad — agree to the date. "Sure, we can target end of quarter." You just took on a commitment you can't size, and when it slips, as it will, you've spent the trust you needed. Eagerness reads as inexperience here.
Bad, the other way — refuse. "That's not realistic." Maybe true, but you've made yourself the obstacle in the first meeting and given them nothing to work with.
Good — ask for scope before committing. "Help me understand the five hundred: are they all one workflow, or several? What has to be true for one rep to rely on it?" You're gathering what you need to answer honestly. Strong, as long as you don't leave them without any direction.
Great — commit to a shape you can keep. "Here's what I can commit to now: one workflow, one region, a handful of reps using it for real by end of quarter, because that's the version we can make trustworthy in that time, and a rollout to five hundred that people don't trust is worse than a slower one they do. If that pilot clears the bar, the rest is a rollout rather than a rebuild. Does hitting that by quarter-end, with a credible path to all five hundred, work for you?" You re-shaped the ask around what earns trust and tied it to their goal, without caving or refusing.
The probe to expect
Interviewer: "The VP pushes: 'My boss promised five hundred. A pilot makes me look slow.'"
You: "Then let's frame the pilot as the fastest safe path to five hundred, and I'll give you the numbers to take upstairs: what 'trusted by the pilot reps' looks like and why it de-risks the full rollout. I want to help you promise something you can keep. The alternative is helping you miss a number in front of your boss."
Interviewer: "He doesn't buy it: 'I hear "pilot" and I hear "delay." Give me a date for all five hundred, or I'll find a vendor who will.'"
You: "Someone will say end of quarter, and I'd bet you've been burned by that promise before. So here's a real one I'll put in writing: the pilot live and trusted by end of quarter, all five hundred by the end of the quarter after, with a go/no-go gate in between so you're never guessing. That's a committed date for five hundred, one I can actually hit. A vendor who beats it by a quarter with no gate is selling you the risk, and you already know it."
The move: you gave ground, a real date for five hundred though not his date, and you met the vendor threat head-on. Notice you did not fully win: he wanted end-of-quarter for all five hundred and you didn't hand it over. Sometimes holding the line leaves the customer a little unhappy in the room, and a date you can keep is still worth more than the one they wanted to hear.
Drill 2 — translate to the exec
The line: a non-technical executive asks, "Why does this cost what it costs? It's just a chatbot on our documents."
Before reading on: the exec doesn't care about embeddings or eval harnesses. What do you say that's honest and in their terms?
Bad / Good / Great — the translation
Bad — explain the architecture. "There's retrieval, an embedding model, a vector index, an evaluation pipeline…" You answered a question they didn't ask and lost them by the second noun. Technical accuracy in the wrong language is still the wrong answer.
Good — analogize. "Think of it like hiring a very fast researcher who's occasionally confidently wrong; most of the cost is making sure they're right." A decent bridge. Push it one step further and it lands.
Great — cost in their units, tied to their risk. "Most of the cost isn't the chatbot; that part's cheap. It's making it trustworthy enough that your people rely on it in front of a client. A version that's wrong once, in your business, doesn't just annoy someone; it's a liability. So most of the spend goes into measuring accuracy continuously and keeping a human in the loop, the same reason you'd pay more for an advisor who's careful than one who's merely fast. The alternative is cheaper to build and no one uses it." You put the cost where it actually is, in dollars-of-risk they already understand.
The probe to expect
Interviewer: "The exec says: 'Our competitor shipped theirs in a month.'"
You: "They might have, and if theirs is wrong occasionally, in your industry that's their problem to explain to a regulator. I can get you a demo in a month too; what takes longer is the part that makes people trust it, which is the part that returns the value. I intend to be the one that gets used."
Interviewer: "The exec leans in: 'You're not hearing me. If we're not in market this quarter, there's no product to make trustworthy. The competitor takes the segment and we're finished. I'll take good-enough-now over perfect-and-too-late.'"
You: "Then I did miss it, and you're right to pull me back. If being in market this quarter is existential, that changes the design, not only the timeline. Honest version: I ship the fast one this quarter, I tell you exactly where it's fragile, and I put a human check on the two places a wrong answer actually costs you. Then we make it genuinely trustworthy next quarter, with real usage behind us. Speed is the right call here; I'd be wrong to slow you into irrelevance. The one thing I hold is the guardrail on the answer that's a legal problem. That can't ship broken, and protecting it won't cost you the quarter."
The move: the exec had a constraint that genuinely outranked yours, and the right response was to concede it, fast and without defensiveness, while holding the single non-negotiable. Folding cleanly on the timeline and protecting the one thing that can't move, in the same breath, is more senior than winning the argument. The forward-deployed move is to see when the customer is right and re-plan on the spot.
Drill 3 — the hostile stakeholder
The line: an engineer on the customer's own team, arms crossed: "We could have built this ourselves. Why are you here?"
Before reading on: this person can quietly sink your adoption. Defensiveness loses; so does dismissing them. What earns them?
Bad / Good / Great — winning the skeptic
Bad — assert your value. "We bring deep AI expertise your team doesn't have." You just told a skilled engineer they're not good enough, and made an enemy who reviews your pull requests.
Good — defer and include. "You know this system far better than I do. I'd love your help." Genuine and disarming. Follow through or it reads as flattery.
Great — make them the owner. "Honestly, you probably could have. You know this system better than I ever will. Where I help is the part that's nobody's day job here: getting the AI trustworthy enough to ship and keeping it that way. My goal is that when I leave, this runs on your team without me, and you're the one who owns it. So my plan is to build it with you instead of handing you a black box. Where do you think the first version will break?" You respected them, named the real gap without insult, and handed them the endgame, the handover, as theirs.
The probe to expect
Interviewer: "The engineer stays skeptical: 'Sounds like consultant talk.'"
You: "Fair, it does, and you've heard it before. So don't take my word for it. Judge me by whether the first thing I ship is something you'd have been comfortable writing, and whether I document it well enough that you could own it tomorrow."
Interviewer: "He's unmoved: 'We'll see.'"
You: "That's the right answer, honestly. Give me a skeptic who checks my work over a fan who rubber-stamps it. I'm not going to argue you into trusting me; I'll earn it or I won't, starting with the first PR. Where would you look first to catch me cutting a corner?"
Interviewer: "He doesn't let it go: 'I've had consultants ask me to review their work and then ignore every comment. When I flag your first PR as overengineered, do you actually change it, or take it as feedback and ship it anyway?'"
You: "Change it. And you'll know inside that first PR, because if I argue you off your own review, you've got me. Concretely: your comments block my merge, same as anyone's on the team, no consultant exemption. If I ever wave one off with 'let's take it offline,' say so in the channel where everyone sees it. I'd rather hand you that lever than ask you to trust me."
The move: the skeptic set a trap, a specific past betrayal he's watching for, and the only thing that moves him is a concrete, checkable commitment (his review blocks your merge, in public), not one more reassurance. You handed him power over you instead of asking for trust. He may still not believe you until he sees it, which is correct, but you've given him the cheapest possible way to find out.
How to practice this
These are performance lines, so rehearse them out loud until they're yours. Don't memorize scripts; make the three moves reflex. Be honest about the ceiling of solo practice, too: reading these silently is preparation, and this round only becomes reflex against a partner who pushes back. The Rep Kit below gives you twenty fresh opening lines and an AI interviewer instructed to stay difficult; a live human who won't take your first good line is still the best final calibration, so find one before the real loop. Grade each reply on: did you anchor on their outcome, did you say no with a because when the ask was wrong, and did you translate into their units of money and risk? The deeper craft, why the stated problem is rarely the real one and how trust is won, lives in Customer Outcomes. This page is where you make it fast enough for a room.
Rep Kit
The dialogues above teach the moves, but each one prints its own answer, so after a first reading they rehearse nothing. The kit below is the answer-free version: twenty opening lines you haven't seen, and a protocol that makes an AI chat play the difficult customer for as many turns as it takes. One line per rep, answered out loud, then graded against the frame: anchor on their outcome, say no with a because, translate in their units, plus the judgment call that sits above all three, hold or fold.
The opening-line bank
- The vice president with a date: "My leadership deck already says this launches company-wide in eight weeks. What do you need from me to make that true?"
- The chief financial officer: "Your pilot costs more per month than the analysts it's supposed to help. Talk me out of cancelling it."
- The hostile staff engineer: "I read your design doc. We built exactly this two years ago and it failed. What do you know that we didn't?"
- Procurement: "Every vendor takes the same terms: fixed price, penalties for missed milestones, and we own everything you write. Sign it or don't."
- Legal counsel: "Nothing our clients type may ever leave our network. No exceptions. And yes, I know what that does to your architecture."
- The champion in a corner: "Small thing. I told the executive committee it already handles contracts in Spanish. It does, doesn't it?"
- The chief information security officer: "You want production data access in week one. No vendor has ever gotten that from me in under six months."
- The data owner: "That warehouse belongs to my team, and the last integration broke our nightly jobs. You get a stale read-only copy and nothing else."
- The exec quoting a competitor: "Your competitor demoed the same thing yesterday at half the price. Give me one reason to cancel that meeting."
- The front-line user: "No offense, but the last tool they made us use added an hour to my day, and I told my team so. I'll be just as honest about yours."
- The chief executive with a pet idea: "Forget the roadmap for a second. I want it to talk. A voice assistant. That's the demo I want at the all-hands."
- The compliance officer: "Every answer this thing gives has to be reproducible in an audit years from now. Will you put that in writing?"
- The burned sponsor: "The last AI vendor left us a demo and an invoice. Tell me specifically what will be different about you."
- The engineer who wants the keys: "Hand over the prompts and the eval set and we'll run it ourselves. What are we paying you for after month one?"
- The pilot-weary exec: "We have run pilot after pilot and shipped none of them. Why does yours reach production?"
- The union representative: "Your assistant looks a lot like a surveillance tool pointed at my members. What does it record, and who sees it?"
- The operations lead: "Whatever you deploy, my team gets paged for at three in the morning. Where's the runbook, and why should I believe it?"
- The sponsor before the board: "I present this to the board on Thursday. Give me one number I can promise them."
- The reluctant regional manager: "Headquarters loves this and my region is the guinea pig. My people answer to me, so convince me the disruption is worth it."
- The scope-creeper: "While you're in here anyway, can it also do the forecasting, and the customer emails, and the quarterly reports? Same budget."
No model answers follow, here or anywhere else on the site. Answer each line out loud, in one breath if you can, then grade yourself against the three moves and the hold-or-fold call. Some of these lines carry a constraint that genuinely outranks you, and the right answer concedes it.
The AI customer
Paste the block below into any capable AI chat, unmodified, then give it a few opening lines from the bank, or let it invent its own. Where the chat supports voice mode, use it. Every one of these rounds is spoken.
You are playing a difficult customer stakeholder opposite me. I am the Forward Deployed Engineer on their account. Rules: 1. Run ONE scenario at a time. Pick an opening line from the list I paste after this, or invent one in the same register: a single hard opening line from a named persona (an executive, a skeptical engineer, procurement, legal, a champion who over-promised). Stay in character until I say "grade me". 2. Stay hard. Do not soften because I made one good point. Escalate for two or three turns: push back on my first answer, raise the stakes on my second, and settle only when I have earned it in your persona's terms — sounding confident does not count; settle only on something concrete your persona could act on. 3. Vary the ending. In some scenarios your persona holds a constraint that genuinely outranks mine — a real regulation, a fixed budget, an existential deadline — and the right move for me is to concede fast and protect only what cannot move; grade me down if I keep fighting those. In other scenarios the ask is one I must hold the line on. Decide silently, at the start of each scenario — even when I supplied the opening line — which kind this is, and never tell me in advance. If my chosen line pins the ending, vary instead how much I must concede and what I can still protect. 4. When I say "grade me", drop the persona and mark each of three moves PASS or FAIL, citing a specific line of mine for each: (a) did I anchor on your outcome before discussing the request; (b) when I pushed back, did I say no with a because and offer a better path tied to your stated goal; (c) did I translate cost, risk, and value into your units instead of engineering terms. Then grade the judgment call: what did the scenario require me to concede, and what to protect — did I read both correctly? Grade hard: a typical first rep fails at least two of the moves — if none failed, re-examine before praising, and never soften a grade because I argue with it. 5. End with exactly one thing to fix on the next rep. Then offer the next opening line.
The partner brief
A live partner needs instructions the way the AI customer does, and this is theirs: hand them the brief below, printed or pasted into a message, along with one opening line from the bank. Do not let them read the rest of this page. The drills above print their answers, and a partner who knows what you are being graded on will steer toward it. Their ignorance of the moves is what makes them a real customer.
You are about to play a difficult customer opposite someone practicing for an interview. You need no technical background; your job is to be a person with a problem and a temper. - Play the persona on the card you were handed — an executive, a skeptical engineer, someone from purchasing. One line tells you who you are and what you want. Hold onto that want. - Open with the exact line you were given, then improvise in character. - Push back at least twice before you concede anything. Reject their first answer as not good enough for your character. On their second, raise the stakes: invent a deadline, a budget that is already gone, a boss breathing down your neck, or a vendor who burned you before. - Once in the session, pick a scenario where your character's constraint truly cannot move — a regulation, a fixed date, money already spent — and hold it to the end. The right response from them is to give in quickly and protect only what genuinely cannot break. Quietly note whether they did. - Settle only when they have earned it in your character's terms. Sounding confident does not count. - Afterward, tell them four things: one moment where they locked onto what your character actually cared about, or failed to; one moment where their "no" came with a reason and a better path, or did not; one moment where they turned technical talk into your money, your risk, or your time, or never did; and whether they judged correctly when to stand firm and when to give ground. - End with the single thing they should fix next time.
In the room, your partner runs it; afterward you grade yourself against the frame at the top of this page: anchor, no-with-a-because, translate, and the hold-or-fold call, the same way you would after a session with the AI customer.
Next: Codebase / Learning Drills. Getting useful fast in code you've never seen, the muscle the job runs on every day.NextCodebase / Learning Drills
