I asked an AI to run the meetings before I had them.
None of it was real. I gave a model the context of an engagement I hadn't started, had it play the people I'd be sitting across from, and told it to push back on every answer I gave.
It turned out harsher than my father.
Here's the situation. After twenty years as a solo developer — my own code, my own deploys, my own consequences — I'm being brought into a large bank to work out why their software delivery isn't getting faster. Different sport. In my world, being wrong is cheap and I fix it that afternoon. In theirs, a bad change can mean a regulatory finding, and the person who approved it may carry a kind of accountability I've never had to.
So I prepared. Hypotheses, a measurement plan, an interview guide. And one document I'd never written for a project before: a list of my own weak spots.
The trap, in my own handwriting
One section of that document is titled "The trap specific to you." It says:
You are the AI person, hired partly for that, and the most likely honest finding is that AI isn't the top constraint.
Two failure modes, both bad: ... Motivated reasoning toward an AI answer because it's what you were hired for and what you're good at.
I wrote that. Days before any rehearsal. Then I asked an AI to play the people I'd be meeting — a delivery director, a platforms lead, a sceptical tech lead — and to grade every answer I gave. Simulated people, invented names, real questions. I'm still running it as I write this.
Four minutes into the first simulated meeting, the director — call him Burak — asked why eighteen months of AI coding assistants hadn't made his teams faster.
I said: "To answer that I need to see how your teams are currently employing the AI. AI is helpful if you know how to use it — if you're using the handle of a hammer on a nail, you won't see the effectiveness."
He replied:
"You have not spoken to a single one of my engineers, and your first answer is that my people are holding the hammer wrong."
I had walked into my own trap with the note still open in another window.
It happened twice more. Asked which segment of the process I'd examine first, I gave a correct answer and then added "and that's where we can get the most help from AI" — a claim I'd explicitly said, forty minutes earlier, that I couldn't yet make. Then a tech lead described a four-line config change stuck eleven days in a change-approval queue and asked what an AI assistant was going to do about it. I answered with my methodology — and closed with "then look into where we can see where Copilot can help." The obvious truth was: nothing. Nothing at all. The authoring took twenty minutes. No coding assistant moves an approval queue.
Three times. Against a weakness I had identified, written down, and reread that week.
Knowing your reflex is not the same as being able to stop it. Pressure doesn't consult your notes.
The same failure wearing a better suit
The second pattern was harder to see, because both times I said something genuinely good.
Burak asked how long before I could tell him something he didn't already know. I said I didn't know yet — that I needed to observe the process first, and anything else would be guesswork. It landed: he told me the last two consultants in that chair had a diagnosis before they had a badge.
But he had asked for a duration. I never gave one.
Later, near the end: "Six weeks from now I report to a steering committee. Tell me what I'm going to be able to say. And be careful how you answer, because whatever you say now, I will repeat."
I used the moment to pre-commit the awkward finding — that the evidence might show AI tooling isn't among his top constraints — and asked whether he'd want to hear that. He said yes, on record. Best move I made all day.
He asked what he could tell the committee. I never told him.
That's the pattern the simulation named: under pressure I answer the adjacent question — the one I'm prepared for — instead of the one on the table. And because the adjacent answer is often valuable, nobody stops me. A real stakeholder doesn't correct you. They nod, and quietly downgrade what you're worth.
I've graded myself against an AI before, on how I brief agents to write code. This was the same lesson in an unfamiliar room: the gap isn't knowledge, it's what my mouth does when someone applies pressure.
The method, if you want to steal it
- Write your weak spots down first — before any rehearsal, in your own words. This is the step that makes the whole thing work. You can only notice the trap firing if you named it in advance.
- Have the AI play specific people, not roles. Not "a stakeholder." A director whose name is on the investment that hasn't paid off. A tech lead who has watched three consultants come and go. Give each one a reason to distrust you.
- Answer out loud, in one pass. No editing. The failure mode you're hunting only appears under time pressure.
- Grade every answer: missed, partly, landed — and have it write the stronger version underneath. The better version is where the learning is; the grade just tells you where to look.
- Reread the misses before the real thing. Not the wins.
I've spent four hours a day on it for three days so far, and it has already found three habits that twenty years of working alone had made invisible to me. When you work solo, you mostly choose when the hard questions arrive. Nobody sits across a table and picks the moment for you.
I fly out on Sunday. I don't know yet whether any of this holds up in a real room with real stakes — that's the follow-up article, and I'll write it honestly either way.
But I'd rather find my reflexes in a simulation than in front of the person paying me.
If you're weighing up someone to build or fix something for you, this is the part worth asking about: not what they know, but what they do when you ask them something they haven't prepared for. Here's how I work.