How would you detect that users are working around your AI feature rather than with it?

How to answer this, stage by stage

Nobody is grading whether you can name "engagement" as a metric. They are grading whether you can find a signal that survives a person who never stops opening the app. Eight moves get you there.

Let's learn

Here is a strange kind of success. A person opens your tool every single day, uses it for exactly the task it was built for, and still walks away with almost none of what it actually offers. That is what a working around looks like from the inside, and it is nearly invisible from a dashboard.

Say we build a tool that reads a job posting and someone's raw work history, and turns them into a tailored resume and cover letter. Wordbridge does this for Northstem Careers' users. Before a tool like this, someone hunting for a job spent about fifty minutes hand-writing and tailoring a resume and cover letter for each posting, which meant six or seven applications a week was close to the ceiling for a person doing it alone, on top of everything else in their week.

With Wordbridge running, that same person gets a full tailored draft, bullets rewritten to match the posting, an opening paragraph, a closing line, in about ninety seconds, then spends a few minutes checking it before sending. That is enough to push someone from six or seven applications a week to twenty.

Here is the turn. Twenty applications a week is not the problem. The real problem is what a person does with one specific part of what Wordbridge writes. Her bullets keep matching the model's draft closely, week after week. But her opening paragraph, the two or three lines meant to hook a recruiter before they read anything else, gets rewritten a little more each week, in a document Wordbridge never sees, then pasted back in right before she hits submit.

That week-three snapshot only tells half of it. The drop didn't happen overnight, and it started well before anyone would have thought to look.

At its worst, this costs more than one person's evening. If this pattern holds across most of Wordbridge's users, the product that gets sold as a resume and cover letter assistant quietly becomes just a bullet-rewrite tool, with a summary generator nobody actually uses as intended, while the numbers leadership sees, applications sent, drafts generated, keep climbing and hiding the whole thing. A per-section check adds real cost: three similarity checks per submission instead of one. But a single whole-document check would have buried the exact section that broke inside an average that still looked healthy, which makes the extra cost worth paying.

The choice I would take back is not the opening paragraph's wording. It is that Wordbridge generates a whole application, bullets, opening, closing, as one model call with one "regenerate everything" button, and no way to keep four fifths of a draft while redoing the rest. That was a fine choice when Wordbridge's first users applied to two or three jobs a week and just wanted one clean draft, fast. It stopped being fine the moment someone started sending twenty a week and noticed the same paragraph shape every time.

What I would leave alone: a small dip in bullet-level overlap, when someone swaps the model's estimate for their own real number. Odessa's bullets moved from 91 percent overlap to 88 percent the week she corrected her actual wait-time savings into one line. That is the resume getting more honest, not less trusted, and chasing it back up to 100 would be chasing the wrong thing.

The lesson: a person who keeps opening your tool every morning has not told you it's working. She's only told you she's still looking for a job. Ask what she keeps, not how often she shows up.

Now here is the same thing as a story

The short version is above. Read on if you want to feel how ordinary the week was that this almost slipped past on.

Odessa Fairweather can tell you, in under thirty seconds, exactly how she trimmed four minutes off the average prescription wait at the pharmacy counter she ran for eight years at Corrivale Drug. The reorder trigger she changed, the pickup line she rearranged, the exact week it started working. When her district closed in the spring, she carried that same habit into her job search: she doesn't guess about her own work, she can name it precisely.

She found Wordbridge in her second week of looking. For about a month, 8am was the best part of her day. She'd paste in a posting for an operations coordinator role, and by 8:04 she had bullets rewritten to match it, an opening paragraph, a closing line. In week one she read every word of that opening carefully, changing one or two things. By week two she was skimming it, sending it mostly as written, because it kept being fine.

Then, on a Wednesday evening at a job-search meetup in a library conference room, a woman two seats over glanced at Odessa's laptop screen and said one line: "You're still letting it write your first paragraph? Mine used to sound exactly like that. Recruiters don't read past it."

Odessa didn't argue. She went home, opened her next application, and instead of editing Wordbridge's opening paragraph in place, she deleted it entirely, opened a blank document, and wrote her own three lines by hand. Then she pasted them back into Wordbridge before she submitted. She did that again the next morning. And the one after that. Every single time, from that Wednesday on.

The similarity score barely moved from week to week. The habit did not drift. It snapped once, on a Wednesday, and never went back.

She never had a number in her head for any of this. She had a feeling with exactly two settings: use what Wordbridge wrote, or step around it and write her own somewhere else. There was no version where she edited the paragraph a little more carefully. Once the switch flipped, it stayed flipped.

Wordbridge's team designed for a dial. What every job seeker actually got, the day the opening paragraph stopped landing, was a switch.

Months before any of this, when Serafina Vos's team scoped the first version of Wordbridge, the design meeting was short. The whole application, bullets, opening, closing, would come back from one model call, with one button to regenerate the entire thing if it wasn't right. Separate controls for each section were on the list. They got pushed to "v2, if anyone asks," because the earliest users, applying to two or three jobs a week, said having one clean draft fast mattered more than fiddly controls. Nobody in that room was picturing someone sending twenty applications a week and noticing the same paragraph shape on the fifteenth one.

What Serafina actually did, once the per-section similarity check flagged the pattern across dozens of accounts like Odessa's, not from a support ticket, since nobody ever filed one: she shipped a "regenerate just this" control on each section, and had every flagged opening routed to the model team as a labeled example instead of vanishing into someone's personal document. Three weeks later, the share of submitted applications with a near-empty opening-line overlap dropped from 61 percent to 18 percent. Odessa stopped leaving the app entirely. Her opening line still cost her about a minute of edits, not twelve, and for the first time since her search began, the paragraph she actually sent lived somewhere Wordbridge's own team could see it.

What I would tell myself, back in that first design meeting: one generate button feels like the simple choice. It stays simple right up until the moment someone needs to keep four fifths of what you made and rebuild the rest somewhere you can't see.

The five letters, if you want to carry them into the room

This is a detection question wearing a diagnosis question's clothes, which is exactly what makes FLIPS fit: find the person, find what they quietly stopped doing, and the flip itself is the signal you're actually being asked to catch.

The five moves in order. The middle one, the flip itself, is the only hard step. Everything else is setup and payoff.

And if you want to be sure it really works, try it somewhere else

Same method, a different flip family, a product nowhere near job hunting, so the method proves itself instead of repeating a story you happened to prepare.

Grenshaw Veterinary Network runs Scanlight, an AI tool that flags likely fractures and soft-tissue abnormalities on x-rays for rural vet clinics, so a vet tech can triage which images need a vet's eyes first.

F, find the person. Junia Marchant, a vet tech at a two-doctor clinic, uploads about thirty x-rays a week.
L, locate the habit. She used to review every full image Scanlight flagged, edges included, before deciding what to escalate.
I, identify the flip. A different family this time, pre-editing, not workaround. She learned Scanlight kept flagging harmless shadows near the image edges as false positives, so she started cropping every x-ray tight around the joint before uploading it, every single time, rather than uploading the full image.
P, pinpoint the old decision. Scanlight was built to score the whole image at once, with no way to tell it "ignore the edges, I already checked those," so cropping the input was the only lever Junia actually had.
S, show the replay. Scanlight adds a "mark this region as reviewed" tool instead of forcing a crop. Junia stops trimming images, Scanlight keeps seeing the full x-ray, and the edge cases she used to crop away, the ones a full image would have caught, stop disappearing before the model ever sees them.

Swap the trigger and it still runs.
Speed: an interviewer caps you at ninety seconds. Skip straight to the method: score each section against what's actually submitted, not the whole document at once, and say why usage numbers alone would miss it.
Cost: engineering says a per-section check triples the similarity calls versus one whole-document check. Don't cave and ship the cheaper coarse version. Say plainly what it would have hidden, the exact averaging that let Odessa's pattern hide for three weeks.
The model got better, for real: say Wordbridge's opening-line writing improves and overlap climbs back to 70 percent for most users. That's still not proof nobody's routing around anything. A better model can still get bypassed out of habit, which is exactly why the check stays on after the fix ships, not just during the incident.

Where people run it wrong.
They treat "usage is up" as proof the feature is working, instead of asking what fraction of the output actually survives to what gets shipped.
They build one score for the whole document, which averages away the one section that's actually broken.
They flag any edit at all as suspicious, which punishes honest personalizing and trains people to stop trusting the flag.

How to use it live. Say the reframe before naming a signal: "I wouldn't watch whether people open the feature. I'd watch what fraction of its output survives, section by section." That buys you room to give the real answer instead of reciting "track engagement" on reflex.

Flashcards (click a card to flip it)

Check yourself Score: 0 / 0