What I Learned Designing AI for Engineers Who Don't Trust AI
2026-02-09 · 9 min read · Janaina Maia
The first thing the lead engineer said in our kickoff meeting was: "I've been doing this for 25 years. I don't need a computer telling me what the soil looks like."
Fair enough.
He wasn't being difficult. He was being professional. His reputation, his PE stamp, his liability — all of that rides on his judgment. And here we were, asking him to trust a model that he couldn't interrogate the way he'd interrogate a junior engineer.
That project changed everything about how I approach AI design for expert users.
Skeptics Aren't the Problem. They're the Design Brief.
Most teams treat skeptical users as a marketing problem. "We just need to show them a good demo!" "Once they see the accuracy numbers, they'll come around!"
No. Skepticism from domain experts is information. It tells you exactly what the product needs to do to earn trust.
That lead engineer's concerns mapped directly to design requirements:
- "I don't need a computer telling me" → The AI should support his judgment, not replace it
- "25 years of experience" → The AI needs to speak his language and relate to his mental models
- "What the soil looks like" → He needs to see the data, not just the conclusion
What Actually Worked
Show the data first, AI opinion second
We flipped the typical AI product pattern. Instead of leading with the AI's classification and hiding the data behind a "details" link, we showed the borehole log first — the raw data the engineer would normally read — and showed the AI's interpretation alongside it.
This tiny change was enormous. The engineer could do his own assessment and then compare it to the AI's. He wasn't being told what to think. He was getting a second opinion.
Let them catch the AI being wrong
Counterintuitive, right? But we deliberately included cases where the AI's classification was debatable. When the engineer corrected the AI and the system acknowledged the correction and learned from it, something shifted.
He went from "this thing doesn't know what it's doing" to "it's pretty good, but it struggles with transitional zones — I need to watch those."
That's trust calibration. And it only happens when you let the AI be fallible in front of the user.
Use their vocabulary, not ours
We had a UX writer draft the AI's explanations using actual engineering terminology — the same words you'd find in a geotechnical report. Not "the model's feature analysis suggests" but "based on the SPT blow counts and moisture content at this depth."
The engineers started treating the AI like a competent colleague instead of a black box.
Make the AI's limitations explicit
We added a simple section to the interface: "This model was trained on [X] borehole logs from [these regions]. It performs best with [these soil types]. It has limited experience with [these conditions]."
One engineer told me: "That's the first honest thing I've seen an AI product say."
The Turning Point
About six weeks in, that same lead engineer — the "25 years" guy — sent the AI's classification report to a client. Voluntarily. Without us prompting him.
When I asked why, he said: "It's faster than doing it myself, and it catches things I miss when I'm going through hundreds of layers. But I always check the transitional zones."
That's the goal. Not blind trust. Not replacement. Collaborative trust where the expert knows exactly when to rely on the AI and when to lean on their own experience.
Things I'd Tell My Past Self
- Don't try to impress skeptics. Earn them. Slowly. With transparency and honesty about limitations.
- Design for the correction workflow as carefully as you design the happy path. The correction moment is where trust is built or destroyed.
- Put the expert's workflow first. The AI adapts to them, not the other way around.
- Track the "voluntary use" metric. When experts start choosing to use the AI without being required to, you've won. Everything else is vanity metrics.
I'm still learning this. Every expert user group is different. But the pattern holds: start by respecting what they know, show the AI's work, let them catch mistakes, and never — ever — imply the AI knows better than they do.