필사 모드: English for AI Engineering Meetings: Saying You Do Not Know Without Losing Credibility

Introduction: the thing this field says most

Skim transcripts of AI team meetings and one thing stands out. The more senior the speaker, the fewer sentences of certainty they use. What they use instead are sentences that draw the line between what is known and what is not. Those are two completely different abilities.

Most English-for-meetings material teaches the opposite. Speak with confidence, it says; cut down the vague expressions. In a general office environment that may be sound advice. In AI development, following it literally costs you credibility instead.

The reason is that every number in this field is conditional. Any eval score depends on which harness it was run on, which grader scored it, and which data it was measured against. As How to Read Leaderboards and Benchmarks sets out, self-reported figures, harness differences and grader bias are not exceptions but the baseline conditions. In a field like that, someone who states a number with no conditions attached does not look confident; they look like someone who does not know the conditions.

So this guide has one subject. The English an AI meeting needs most often is not the language of certainty but the language that expresses uncertainty credibly. Being able to say you do not know without sounding incompetent is the core meeting skill in this field.

Why saying you do not know, early, is a credit asset

First, why this is not a loss. If you do not convince yourself of the logic, the sentence will not come out in an actual meeting.

Someone who states uncertainty accurately can be believed when they state certainty. Conversely, someone who is confident every time gets a discount applied to every number they produce from the first time they are wrong. That is the real cost. The next time you carry in a result you are genuinely sure of, the certainty will not land.

The second reason comes from the structure of the field. A hidden regression always surfaces. Someone else runs the same eval, another team wires up the same model, and eventually a user sees it. The later it surfaces, the more expensive it is, because other decisions have already been stacked on top of it.

The third is time. Waiting to report until you have the cause fully identified looks conscientious, but in the meantime the team plans its schedule on a false premise. A decision you could not make for lack of information and a decision already made on wrong information have very different recovery costs.

There are no sentences in this guide for making a result look good. They were left out on purpose. Sentences like that work once or twice and then stop working, and by the time they stop, the career cost has already been incurred.

The three pieces of credible uncertainty

Saying you do not know sounds incompetent not because you do not know. It sounds incompetent because you did not say how far the not-knowing extends. Compare two sentences from the same situation.

[the form that loses trust]
I'm not sure. I'll look into it.

[the form that earns trust]
I don't know yet whether it's the model or the harness.
What I do know is that it started after Tuesday's deploy,
and it only shows up on the long-context slice.
I'm bisecting the commits and I'll have an answer Thursday.

The second one still contains the words for not knowing. Only the amount of information differs. The three pieces that went into it are the spine of this guide.

Drop the boundary and it sounds incompetent. You have reported nothing but a state of not knowing, so there is nothing the listener can do with it.

Drop the basis and it sounds light. The same score of 82 is a completely different sentence depending on whether it is one run or an average of five, and that difference has vanished.

Drop the next step and it sounds evasive. This is the piece most often missing. Go silent after saying you do not know and the other person has to construct the next action, which means they pay the price for your not knowing.

Every situational phrase below is a variation on these three pieces. Training your eye to see which piece is missing lasts longer than memorising the phrases.

Situation 1: presenting eval results with their limits attached

The most frequent situation, and the one most often got wrong. The common mistake is to give the number first and attach the limits afterwards. Then the limits sound like excuses. State the limits first and then give the number, and the same content reads as care.

There are four conditions worth attaching to a number: which data, how many runs, which grader, compared to what. You do not have to say all four, but say none of them and the number circulates in the room as something firmer than it is.

Situation 2: a regression whose cause you do not know yet

The biggest temptation here is to speak only after you have found the cause. That is choosing to save one day and burn three days of the whole team's time.

Heads up is close to standard in engineering conversation, but it is colloquial. In documents that go to executives or in a formal email, I want to flag fits better. That judgement depends on the company culture. On a team that writes documents in a casual tone, there is no need to change it.

No action needed from you yet is short but does a lot of work. The first reaction of someone who has heard bad news is usually to wonder what they have to do, and answering that question first makes the report land far more lightly.

Situation 3: the metric went up but the actual quality did not

This may be the hardest thing to say in this field, because it is the moment you cancel your own good news. But if it goes unsaid, the whole team spends a quarter heading the wrong way.

This situation already has a name: reward hacking. It points at the state where the metric genuinely went up while the task failed, and the key part is that it is not a system breaking but the exact result of optimising the goal we defined.

On English-speaking ML teams, shorthand for Goodhart's law works, as in That might be Goodhart. But this is shorthand that only travels inside an ML team, so in a meeting with other departments in the room it is safer to say it in full. Something like We may be optimizing the measure instead of the thing we care about gets through to anyone.

Situation 4: data quality and disagreements about labelling

Labelling arguments run long mostly because people are arguing about different things. You think you are arguing about whether the model is wrong, and often you are actually arguing about the label definition. The sentence that names what is being argued about saves the most time of anything here.

The sixth sentence carries a judgement about register. Raise a label quality problem and it easily sounds like criticism of the person or team who did the work. Move the target of the criticism from the people to the instructions and the same objection lands far more safely. And usually it is also the truth. What really makes labels wobble is more often ambiguity in the definition than a lack of diligence in the annotators.

The seventh sentence is strong as an argument too. It points out that demanding of a model a criterion two people cannot agree on is an impossible demand, which is hard to rebut.

Situation 5: the cost and latency trade-off

The mistake engineers often make in this conversation is mixing technical judgements with business judgements. Separate the two and the weight of what you say goes up rather than down. The form is definite inside your own domain, information only inside someone else's.

The fourth sentence is the core of this section. that's a product call, not a technical one states your opinion while leaving the decision authority with the other side. It builds a position that is neither withholding an opinion nor making someone else's decision for them.

The last sentence corresponds to the basis, of the three pieces. Speak without distinguishing estimates from measurements and your credibility takes the hit later, when the measured figure comes out different. An estimate given as an estimate costs nothing when it turns out wrong.

Situation 6: when the research schedule collides with the product schedule

Research does not know when a result will arrive and product needs a date. This collision is not resolved, only managed, so turning it into a manageable shape is the whole of this conversation.

The frame that separates a decision date from a delivery date is the most practical thing here. You do not know when the research will finish, but you can usually say when you will be able to judge whether to continue or stop. And that is mostly what the product side actually needs.

One judgement about register to add. A variant that points slightly at the other person circulates, as in I'd rather give you a date I believe than a date you want to hear, and depending on the team it sounds principled or passive-aggressive. Taking the other person out of the sentence and speaking only about yourself is safe on any team. The fifth sentence in the table above is that form.

Situation 7: explaining uncertainty to non-technical stakeholders

There are two ways to fail in this room. Simplify so hard that you say something untrue, or aim for accuracy and communicate nothing at all.

Three rules generally work well. Give one number only, strip the jargon, and always state the failure mode alongside it.

The last sentence matters especially for this audience. What non-technical stakeholders most often miss is the way it goes wrong. They plan on the assumption that failure means stopping, and failure in a language model usually is not that. Say it in advance or the surprise becomes an incident later.

Examples of words to strip out: eval, harness, ablation, in-distribution, held-out, seed. There is nothing wrong with these words; they simply do not travel in this room.

Situation 8: saying you do not know yet, with the next step attached

This is the moment where the three pieces are needed in their most compressed form. A question lands mid-meeting, you do not have the answer, and there are eight people in the room.

The fourth sentence is especially useful. It is the form that hands the condition back without refusing the demand for an immediate answer. If they say a guess will do, give the guess; if they say they need an accurate answer, you have bought time. Either way, the nature of what you said is now explicit.

The last sentence comes up often in this field. English benchmark results frequently cannot be carried across to Korean or Japanese unchanged, and drawing that boundary in advance removes a lot of later surprise.

Situation 9: pushing back on someone else's experiment

The principle here condenses into one line. Do not rebut the conclusion; verify the conditions.

The reason is simple. Condition questions have answers; attacks do not. There is nothing to do with That's wrong except defend, whereas What was the baseline? has an answer. And in the course of answering, the problem usually reveals itself.

One of us has a bug works particularly well in this field. When two people's results differ, it leaves who is wrong undecided while fixing the fact that there is a cause. The other person has no reason to defend, so the conversation moves straight to the technical side.

Before I push back is useful too. It tells the other person an objection is coming, which gives them time to prepare. Whether that much warning is needed depends on the team. On a team where blunt debate is the default it can feel like unnecessary cushioning; on a cautious team this single sentence prevents conflict. If you cannot tell which one you are on, attaching it costs less.

Situation 10: when it will not reproduce

A failure to reproduce is nearly always somebody's mistake, and which somebody is not yet known. Start with a sentence that suspects your own side and the conversation flows into investigation; suspect their side first and it flows into defence.

One judgement about register has to be attached to That's probably on my end. It is a device for raising a problem while protecting the other person's face, and nobody loses anything if it later turns out to be their side. Overuse it as a habit, though, and you can genuinely start to look unconfident. That is especially true on teams that mark self-deprecation down. Use it where the cause really is uncertain, as with a failure to reproduce, and not where the problem is plainly in their code.

The strength scale for hedging

Using uncertainty language well means being able to adjust the strength. Below is a rough scale. It does not map onto exact probabilities; it is closer to a conventional impression.

One rule goes on top of this. One hedge per claim is enough. Stack four, as in I could be wrong, but I think maybe it might be the tokenizer, and the claim itself disappears; what the listener remembers is the speaker's lack of confidence rather than the content.

That judgement shifts with team culture, though. In an organisation where indirectness is the default, two hedges may be the floor of politeness. On a blunt engineering team, even one feels like a lot. Two or three meetings of observation is enough to see a team's default. The fastest method is to take one trusted senior person on that team as your baseline.

Where American and British usage split

A few of these genuinely create misunderstandings in meetings.

The verb table means the exact opposite. In the US, Let's table this means to postpone it; in the UK, to table an item means to put it on the agenda. It is dangerous precisely because it can be understood backwards while a meeting is running. In a meeting with both sides in the room, it is safer to say it in full: Let's come back to this later or Let's add this to the agenda.

The strength of quite differs. In the US quite good is close to a compliment meaning fairly good; in the UK quite good is often read as the lukewarm assessment of not bad. It is an easy word to be misread on when commenting on eval results. If you want to be unambiguous, drop quite and give the number.

momentarily splits too. In the US it tends to mean soon; in the UK it tends to mean for a moment. Swapping in in a moment or briefly removes the ambiguity.

The weight of Sorry differs. In the UK, Sorry is used far more often as conversational padding than as an apology. When a British colleague seems to be apologising constantly, that is not an apology. In the other direction, American company culture often prefers replacing an apology for a delay with Thanks for your patience. That said, company culture varies as much as country here, so I will not generalise it.

Things better left undone

Sentences that inflate the result. There are no examples of that in this guide and there will not be. The reason is not only ethical. In AI development, an inflated number usually gets checked within the same quarter. Another team runs the same eval, it gets wired into a product, and users use it. The shelf life of an inflated sentence is only the time it takes for that number to be reproduced.

Holding a regression until the next report. For the same reason it surfaces in the end, and the later it surfaces the more decisions have been stacked on top of it.

It should work. In engineering English this sentence reads, in effect, as a signal that it was not tested. should is a prediction rather than a report. Say what you tested and what you did not instead: I tested the happy path and the empty input. I haven't tested concurrency.

I'm not sure. used on its own. It reports an internal state and leaves the other person with nothing. Attach just one of the boundary or the next step and it changes completely.

Numbers with no conditions. Say only 82 and the minutes record only 82, and that 82 gets cited as evidence weeks later. Which data it was and how many runs it was, nobody remembers by then.

An uncertainty report that ends with a question. Finish with Let me know if you have any questions. and you have handed the next action to the other person. When reporting uncertainty, it is better to propose the next step yourself and stop there.

Rebutting someone else's experiment with a conclusion. Verifying the conditions comes first. If an objection remains after you have verified them, state the conclusion then, and at that point the objection is far stronger.

A worked example: the weekly model review

Here is how the pieces above attach to each other in a real meeting.

PM:   So the new checkpoint is better, right? Can we ship Friday?

Me:   Two caveats before the number.
      It is a single run, and it is on our internal set,
      so it is not comparable to the vendor numbers.
      With that said, we are up two points.
      Two points is inside the noise for this set,
      so I would not call it a win yet.

PM:   Okay. When will you know?

Me:   What I can give you is a decision date, not a delivery date.
      Three more seeds is about two days of compute.
      By Wednesday I will know whether the gain is real.

PM:   And if it is real?

Me:   Then there is a second question. I read twenty outputs by hand
      and some of them got longer without getting better.
      The metric moved, but I am not sure the task did.
      I would want a human check on a small sample before we ship.

Them: I saw the opposite last week - my run showed a clear gain.

Me:   That is interesting, because it contradicts mine.
      One of us has a bug. Before I push back,
      what was your baseline, and how many seeds?

Them: Baseline was the March checkpoint. One seed.

Me:   Okay, mine is against last month. That could be the whole difference.
      Can we get to the same number before we decide anything on top of it?

PM:   What do I tell leadership on Thursday?

Me:   Short version: it looks promising, we do not know yet if it is real,
      and we will know by Wednesday.
      The failure mode to watch is longer answers that are not better ones.
      No decision needed from them this week.

In that conversation I never once confirmed the good news. And yet the meeting did not stall. Because every time, a boundary was drawn, a basis was stated, and a next step and a date were given alongside it.

Try this today

You do not need to memorise all the phrases. Make three of them automatic.

1. One sentence that puts the limits first: Two caveats before I give you the number. The habit of laying the conditions down before the number is the highest-value thing in this whole guide.
2. One sentence that completes an I-do-not-know: I don't know yet. Here's what would tell us, and here's when. The boundary and the next step are both inside one sentence.
3. One sentence that turns an objection into a check on conditions: I'm not doubting the number. I'm trying to work out what it's comparable to.

And check one thing in your next meeting. Did I attach conditions to the numbers I said? If you did not, that number is right now circulating in the room as something firmer than what you actually know.

Read next

• How to Improve Your English Without the Situation — how to run the situations above alone, before the real meeting.
• How to Read Leaderboards and Benchmarks — which conditions to attach, and the grounds for that list of conditions.
• AI benchmark comparison — check for yourself the source and the conditions of the figures you plan to cite in a meeting.
• Harness Engineering RPG — experience through simulation how grader bottlenecks and reward hacking actually arise.
• Conversation Lab — practise the dialogue above out loud.