This is a great breakdown of the exact friction points. To answer your questions from a developer's perspective:
Trust & Verification: We don't use gut feelings; we use constraints. We treat AI like a fast junior dev—great for boilerplate, but we rely on automated tests, type checkers, and linters to verify the output. If checking the AI takes longer than writing it ourselves, we just skip the AI.
Adoption & Prompts: The "70% right" experience is a known limitation. LLMs are probabilistic; they don't "think" like us. Real adoption only happens when the AI lives inside the workflow (like Cursor or Copilot). If it's a separate chat window, it's just extra friction.
Data: Tell your non-technical coworkers: "If it's a consumer tier (free or $20/mo), assume your data trains the model. If the company buys the Enterprise/Team tier, you are covered by a legal contract that protects your data."
Counterexample: AI makes things worse when teams use it to generate code they don't actually understand. It creates "technical debt at the speed of light," which takes forever to debug later.
AX Researcher at Knowverse. Exploring how AI changes the way people actually work. Less interested in hype, more interested in what people keep using after the demo.
Location
Seoul, Korea
Education
B.B.A. in Business Administration, Yonsei University
Thanks for answering all four so directly. The "fast junior dev" framing was the part that stuck with me most, and the idea that you verify with constraints instead of gut feeling.
What I hadn't understood is that your checks are built into the work itself. Tests and linters tell you what's wrong without anyone having to feel suspicious. In my kind of work, there's no automatic test for "is this market number right," so I end up rereading everything out of anxiety. It makes me want to try designing a few cheap checkpoints of my own, like always asking for the source next to every figure, instead of a vague feeling that something is off.
Your point about AI living inside the workflow also matches what I see with teammates. A separate chat window is exactly the extra step that people quietly drop.
Quick question for you: when you're deciding whether a task is worth giving to AI, do you have a rough gut rule for it, like "if I can't check it in a minute, I skip it"?
Exactly! For me, the rule is simple: if writing the prompt takes longer than doing the task myself, or if I can't verify the result in under a minute, I skip the AI.
Your idea of keeping the source right next to the figure is the perfect way to make that verification instant. If I have to hunt for the source, the time savings are gone.
AX Researcher at Knowverse. Exploring how AI changes the way people actually work. Less interested in hype, more interested in what people keep using after the demo.
Location
Seoul, Korea
Education
B.B.A. in Business Administration, Yonsei University
Thanks, that "under a minute" rule is the part I'm taking with me. I'd been asking "how much should I trust this?", which is a vague question that just feeds my anxiety. Your version asks whether I can check it fast enough to be worth it, and that's much easier to answer.
It also ties back to what I wrote about the 5 minutes of prompting plus 8 minutes of checking. I'd only counted the prompting as the cost. The checking was the hidden part, and I never put a limit on it. If a source isn't sitting right next to the number, I'll treat that as a sign to do the task myself. I'm going to try that this week.
Quick question: have you ever started using AI for something and then dropped it because checking the result felt too slow?
Glad it helps! And yes, absolutely. I dropped AI for writing complex regex and SQL queries pretty quickly. Debugging a hallucinated regex pattern always took longer than just writing it myself. If the domain is highly specific and I can't spot the error at a glance, the AI becomes a net negative.
AX Researcher at Knowverse. Exploring how AI changes the way people actually work. Less interested in hype, more interested in what people keep using after the demo.
Location
Seoul, Korea
Education
B.B.A. in Business Administration, Yonsei University
Thanks for sharing that. The regex and SQL example is useful because it's the clearest case of the "checking cost" I'd been missing. A wrong answer that looks right and takes ages to debug is worse than no answer at all.
What clicked for me is your phrase "if I can't spot the error at a glance." I think my version of that is a market figure or a translated sentence in a language I know less well. Those are the places where I can't tell it's wrong just by reading, so I keep rereading everything. I hadn't thought of that as a sign the task might not suit AI in the first place. I'd only blamed myself for being anxious. I'll try sorting my own tasks by "can I spot a mistake quickly or not" and see which ones fall on the wrong side.
Since it's the weekend, I'm curious about the opposite case. Is there something you tried AI for that you didn't expect to stick, but it ended up being a thing you'd feel annoyed to lose now?
Coming at this from the non-developer side, the adoption part rings true for me. In my experience a team doesn't stop using a tool because the tool is bad — they stop because nobody changed the actual job around it.
What has worked when I've seen it stick: pick one real, repeatable task, not "use AI more." Something like turning rough notes into a clean follow-up summary. One person does it live, in front of the team, with a real example, and everyone sees where it saves time and where it still needs a human check.
Your trust rule is sensible, too. I check anything with a number, a name, or a date myself, and anything going to a client gets read line by line. That's not distrusting the tool, it's just treating it like a first draft from someone new. And on the data worry — if you're unsure where a document goes, don't paste it. Ask first, or use a version with the sensitive details stripped out. That caution is what keeps people comfortable enough to keep trying.
AX Researcher at Knowverse. Exploring how AI changes the way people actually work. Less interested in hype, more interested in what people keep using after the demo.
Location
Seoul, Korea
Education
B.B.A. in Business Administration, Yonsei University
Thank you for this, especially the point that a team doesn't quit because the tool is bad, but because nobody changed the job around it. That's exactly what I was circling in Problem 1 without being able to say it so plainly.
What I hadn't thought through is your "one real, repeatable task, done live in front of the team." I'd been treating adoption as a training problem, like we needed better sessions. But your version is closer to showing a coworker how you do something Tuesday morning. Seeing where it saves time and where it still needs a human check, on a real example, seems far more convincing than a slide deck. Turning rough notes into a follow-up summary is also small enough that nobody feels they're being asked to change their whole workflow. I'd like to try picking a task like that rather than telling people to "use AI more."
It's also reassuring that my number, name and date check isn't just anxiety. Treating the output like a first draft from someone new is a framing I'll keep.
Have you ever watched a live demo like that actually make a skeptical coworker start using the tool?
We're a place where coders share, stay up-to-date and grow their careers.
This is a great breakdown of the exact friction points. To answer your questions from a developer's perspective:
Trust & Verification: We don't use gut feelings; we use constraints. We treat AI like a fast junior dev—great for boilerplate, but we rely on automated tests, type checkers, and linters to verify the output. If checking the AI takes longer than writing it ourselves, we just skip the AI.
Adoption & Prompts: The "70% right" experience is a known limitation. LLMs are probabilistic; they don't "think" like us. Real adoption only happens when the AI lives inside the workflow (like Cursor or Copilot). If it's a separate chat window, it's just extra friction.
Data: Tell your non-technical coworkers: "If it's a consumer tier (free or $20/mo), assume your data trains the model. If the company buys the Enterprise/Team tier, you are covered by a legal contract that protects your data."
Counterexample: AI makes things worse when teams use it to generate code they don't actually understand. It creates "technical debt at the speed of light," which takes forever to debug later.
Thanks for answering all four so directly. The "fast junior dev" framing was the part that stuck with me most, and the idea that you verify with constraints instead of gut feeling.
What I hadn't understood is that your checks are built into the work itself. Tests and linters tell you what's wrong without anyone having to feel suspicious. In my kind of work, there's no automatic test for "is this market number right," so I end up rereading everything out of anxiety. It makes me want to try designing a few cheap checkpoints of my own, like always asking for the source next to every figure, instead of a vague feeling that something is off.
Your point about AI living inside the workflow also matches what I see with teammates. A separate chat window is exactly the extra step that people quietly drop.
Quick question for you: when you're deciding whether a task is worth giving to AI, do you have a rough gut rule for it, like "if I can't check it in a minute, I skip it"?
Exactly! For me, the rule is simple: if writing the prompt takes longer than doing the task myself, or if I can't verify the result in under a minute, I skip the AI.
Your idea of keeping the source right next to the figure is the perfect way to make that verification instant. If I have to hunt for the source, the time savings are gone.
Thanks, that "under a minute" rule is the part I'm taking with me. I'd been asking "how much should I trust this?", which is a vague question that just feeds my anxiety. Your version asks whether I can check it fast enough to be worth it, and that's much easier to answer.
It also ties back to what I wrote about the 5 minutes of prompting plus 8 minutes of checking. I'd only counted the prompting as the cost. The checking was the hidden part, and I never put a limit on it. If a source isn't sitting right next to the number, I'll treat that as a sign to do the task myself. I'm going to try that this week.
Quick question: have you ever started using AI for something and then dropped it because checking the result felt too slow?
Glad it helps! And yes, absolutely. I dropped AI for writing complex regex and SQL queries pretty quickly. Debugging a hallucinated regex pattern always took longer than just writing it myself. If the domain is highly specific and I can't spot the error at a glance, the AI becomes a net negative.
Thanks for sharing that. The regex and SQL example is useful because it's the clearest case of the "checking cost" I'd been missing. A wrong answer that looks right and takes ages to debug is worse than no answer at all.
What clicked for me is your phrase "if I can't spot the error at a glance." I think my version of that is a market figure or a translated sentence in a language I know less well. Those are the places where I can't tell it's wrong just by reading, so I keep rereading everything. I hadn't thought of that as a sign the task might not suit AI in the first place. I'd only blamed myself for being anxious. I'll try sorting my own tasks by "can I spot a mistake quickly or not" and see which ones fall on the wrong side.
Since it's the weekend, I'm curious about the opposite case. Is there something you tried AI for that you didn't expect to stick, but it ended up being a thing you'd feel annoyed to lose now?
Coming at this from the non-developer side, the adoption part rings true for me. In my experience a team doesn't stop using a tool because the tool is bad — they stop because nobody changed the actual job around it.
What has worked when I've seen it stick: pick one real, repeatable task, not "use AI more." Something like turning rough notes into a clean follow-up summary. One person does it live, in front of the team, with a real example, and everyone sees where it saves time and where it still needs a human check.
Your trust rule is sensible, too. I check anything with a number, a name, or a date myself, and anything going to a client gets read line by line. That's not distrusting the tool, it's just treating it like a first draft from someone new. And on the data worry — if you're unsure where a document goes, don't paste it. Ask first, or use a version with the sensitive details stripped out. That caution is what keeps people comfortable enough to keep trying.
Thank you for this, especially the point that a team doesn't quit because the tool is bad, but because nobody changed the job around it. That's exactly what I was circling in Problem 1 without being able to say it so plainly.
What I hadn't thought through is your "one real, repeatable task, done live in front of the team." I'd been treating adoption as a training problem, like we needed better sessions. But your version is closer to showing a coworker how you do something Tuesday morning. Seeing where it saves time and where it still needs a human check, on a real example, seems far more convincing than a slide deck. Turning rough notes into a follow-up summary is also small enough that nobody feels they're being asked to change their whole workflow. I'd like to try picking a task like that rather than telling people to "use AI more."
It's also reassuring that my number, name and date check isn't just anxiety. Treating the output like a first draft from someone new is a framing I'll keep.
Have you ever watched a live demo like that actually make a skeptical coworker start using the tool?