DEV Community: xulingfeng

Stratagems #2: Derek Shaw Walked Into Another AI Promise. The Pipeline Had a Better Plan.

xulingfeng — Mon, 29 Jun 2026 10:48:43 +0000

When the enemy is too strong to attack directly, attack what they hold dear. They will come to you to defend it, and the siege is lifted.
— The 36 Stratagems, "Besiege Wei to Rescue Zhao"

Derek Shaw knew 95% was a number he shouldn't have promised. He said it anyway.

97.2% Coverage, 4-Day Delivery — A Fake Quote, and a Parking Lot Lesson

Back at QualiGuard, Derek Shaw walked into Finova's $1.8M contract bid with an AI platform that claimed 97.2% test coverage. Four-day delivery, fully automated, beautiful numbers. But his boss Sarah had cut his GPU budget behind his back and forced him to slash the quote from $1.8M to $1.5M.

The truth was uglier than the cover slide. Derek had to fill the compute gap with sampling plus AI predictions — real coverage dropped from 97.2% to 86.7%. Lena spotted a footnote buried in the Aegis test report: External Deps: 0 — a financial system with 14 external dependencies, and the report claimed zero. She didn't bring it up during the review. Finova's risk lead Frank beat her to it.

Finova handed the contract to VeriTest. In the parking lot, Lena looked back before getting into her car: "Next time you put together a proposal — make sure your boss knows what you're doing out there."

Derek remembered those words. Then he switched companies.

Same Spot, Different Name

Derek Shaw was three months into MediSys. The QualiGuard disaster — that bid where he fell flat in front of Finova's entire evaluation team, the "External Deps: 0" oversight — still hadn't cooled off.

He never told anyone about that night in the parking lot. But every few days, the words surfaced on their own: "Next time you put together a proposal — make sure your boss knows what you're doing out there." He knew she was right. He didn't want to admit she was right.

At MediSys, Derek swore things would be different. He volunteered to run a round of "we're listening" sessions with the team — he wasn't going to be the Director who bet everything on AI again. The first two months went well. During the interview, VP Morgan — a woman in her early fifties, gray suit always pressed sharp — asked him only one non-technical question: "QualiGuard. What did you learn?" He gave a solid answer. He just wasn't sure how much of it Morgan actually bought.

Then month three hit. The CEO announced it at the all-hands: MediSys was launching an AI-assisted diagnostic validation platform. Strategic initiative. FDA pathway. $2M budget. Twelve months to MVP. Derek was named Quality Validation Lead.

Same position. Again. Only this time, he told himself he knew what to do.

MediSys's AI validation platform ran on a third-party engine — EHR AI Labs, a medical AI diagnostics startup fresh off a Series B. Their bare engine could hit 95%+ diagnostic suggestion coverage in lab conditions. But the engine wasn't the product — MediSys licensed it and handled the real work: fine-tuning adapters for 17 medical data sources, plus the FDA validation pathway. The integration layer was what MediSys actually sold to hospitals.

There was just one problem. Another company was chasing the same FDA audit contracts — OmniDx. They'd published a white paper the month before, claiming 96.2% diagnostic suggestion accuracy in independent validation. The CEO couldn't stop bringing up that number. Derek read the white paper. Something felt off — OmniDx's evaluation set had 3 data sources. MediSys had to run 17. That 96.2% wasn't inflated — it was greenhouse-grown.

He kept his mouth shut. He didn't have his own numbers yet.

Then Derek's team finished their first week of the project launch. The numbers came in — actual accuracy hovering between 83% and 87%. He was worse than OmniDx.

That's when the CEO looked at him in the weekly project review. "Investor day is 18 days out. I want to see 95%."

Derek wanted to say the 96.2% was greenhouse-grown. Wanted to say 3 data sources and 17 are not the same thing. He didn't. He was sitting on 83%. He had no standing to argue.

But he needed a number — not to actually satisfy the CEO, but to buy himself 18 days without interference. He needed a target that would make the CEO stop asking "so what do you think about their 96.2%?"

Derek stood up in the project review and said: "Give me 18 days. I'll get above 95% before investor day."

The room went quiet for a few seconds. In three months at MediSys, he'd never done this. His style was cautious, always leaving room. After the meeting, VP Morgan pulled him into the hallway: "Derek, are you sure about this?"

"Yes," he said.

He was walking the same road he walked at QualiGuard. → Story #15

18 Days. 95% or Bust.

Derek started tuning. He split the team into two tracks — himself plus one person pushing model accuracy, the other four maintaining the existing test pipeline.

The real problem was in the pipeline.

MediSys's data flow was nothing like QualiGuard's. Medical data came from 17 different sources: HIS, LIS, PACS imaging archives, third-party lab interfaces — formats ranging from HL7 to FHIR to bespoke CSVs. The preprocessing stage had to normalize all of it before the AI engine could touch anything.

The preprocessing pipeline was legacy architecture, three years old — built long before the AI project existed. A single-threaded ETL job, run once a day. It had never been a bottleneck because no one had ever tried to feed its output into a real-time AI model.

Now the AI platform demanded real-time ingestion from all 17 sources. Data volume quadrupled overnight.

The pipeline started collapsing during afternoon peak hours. Nobody cared — pipeline performance wasn't in anyone's KPIs. Everyone was chasing 95%.

Derek noticed but didn't act. He saw a few pipeline alert emails — preprocessing job completion time creeping from 6 hours to 9. He forwarded them to the pipeline team, got back a "got it, looking into it," and heard nothing after. He didn't push. He didn't want the distraction.

One night he was in the office until 1 a.m. Model results dropped from 90.5% back to 89%. No explanation. Just lost 1.5 points. He stared at the screen for a long time, searching for a reason — but he never looked back at the pipeline. He just re-ran the training and hoped for better luck.

Every day he wrestled with accuracy: 87% → 89% → 90.5% (fell back to 89% overnight) → 91.2%. Every gain was harder than the last. Every point was burning more of the team's time.

One night he closed the model terminal and reopened OmniDx's white paper — the one he'd saved a month ago and never revisited. This time he caught a footnote he'd skipped before: the evaluation set description listed three data sources, but the sample ID prefixes had four patterns. That fourth prefix didn't match any source in their public documentation.

He told no one. He wasn't sure if he'd found a crack or just found an excuse to look away from his own numbers.

The pipeline was silently rotting.

Day 17

Derek re-ran the model at 2 a.m. Accuracy: 92.7%. Still nowhere near 95%. Worse — he realized the data he'd been feeding in for the past two days wasn't from today. The pipeline was taking 20 hours to complete. The model was training on yesterday's data.

He opened the pipeline monitoring dashboard. First time since the project launched.

The ETL job was now clocking 20 hours. Out of every 24-hour cycle, the data-availability window was down to 4 hours. And nearly 3 of those overlapped with model training — leaving barely one clean hour for evaluation.

He could see the problem. He should have seen it sooner. The lessons from his last job were still fresh — all those late nights staring at QualiGuard's monitoring dashboards had taught him one thing: check the infrastructure before you check the model.

But he hadn't. Because looking at the pipeline meant admitting he'd picked the wrong battlefield. Admitting that "I'll hit 95%" — said 18 days ago — was a mistake. Admitting he was repeating his last company's playbook.

He sat in front of the screen, staring at that monitoring dashboard for a long time.

Something else was running through his head. The four sample ID prefixes in OmniDx's white paper — he hadn't touched that thread since noticing it the week before. It had felt like making excuses: can't hit 95%, so let's go nitpick the competitor. But sitting there, staring at a 20-hour ETL job, he started re-examining that lead. Not because anything clicked — but because he finally admitted the obvious: tuning the model wasn't going to win this.

But the game has more than one way to win.

If OmniDx's benchmark really did hide a fourth data source — that prefix with no known origin — then their 96.2% was trained on those three or four sources. MediSys had to run 17. The two numbers were never comparable. He didn't need to prove OmniDx was fake. He just needed the CEO to realize: OmniDx tested something entirely different from what we're building.

And then a voice surfaced in his head — not his own. It was that night in the parking lot, Lena turning back before the car door closed:

"Next time you put together a proposal — make sure your boss knows what you're doing out there."

He hadn't said anything back then. But now he understood what she meant. If this went sideways again, would VP Morgan turn into another Sarah — losing trust in him before he even realized it was gone?

He closed the model training terminal. First time in 18 days.

Then he opened the pipeline config.

He made a decision — and told no one. Alone, in the middle of the night, he rewired the single-threaded ETL into a multi-threaded parallel pipeline. He didn't notify VP Morgan. Didn't tell the team. He still wanted to maintain the illusion that "95% is still the target."

The Supply Line

3 a.m. to 10 a.m. Derek sat at MediSys's test server and split the ETL pipeline from one thread into 8 parallel workers, wrote a lightweight queue manager to distribute data sources. It blew up twice — first a deadlock, then a memory overflow — he walked to the hallway, drank a glass of cold water, came back, added a timeout mechanism, and kept going.

He didn't touch a single line of model code.

By 10 a.m., the ETL job finished in 4 hours what had been taking 20. Pipeline restored.

He re-ran the model — accuracy jumped from 92.7% straight to 94.1%. Not because the model improved. Because the data was fresh.

He didn't keep storming the city. He fixed the supply line. And the moment the supply line was fixed, the city fell on its own.

But he knew this fix was fragile — 8 parallel workers with no idempotency checks, a queue manager with no exception handling. He didn't know if it would hold tomorrow. He was just betting it wouldn't blow up before investor day.

The irony: if he'd fixed the pipeline on day one, 18 days would have been enough to push accuracy past 95%. He burned 16 days storming the walls and only remembered to check the supply line with two days left.

That night, he ran through the investor day deck one last time in the conference room. Closed his laptop. Leaned back.

94.1%. Tomorrow was investor day. Not pretty, but close enough.

Fixing the pipeline only kept him alive. The real Besiege Wei to Rescue Zhao happened the next day.

"Was It Like This Last Time?"

Investor day. Derek presented 94.1% accuracy — not 95%, but the data was live, reproducible, verifiable. The CEO watched the numbers pulse on screen and said exactly three words: "Within a point — close enough." Then flipped to the next slide. It was the biggest compliment Derek had ever heard from him.

Something else happened that Derek hadn't planned. That morning, he'd sent Morgan a comparison note on OmniDx's white paper — brief, no conclusions, just the sample ID prefix alignment across the three claimed data sources. Morgan slipped it into the investor day briefing — not as an attack, just one page under "competitive landscape analysis."

That night, Derek saw a push notification. News traveled faster than he'd expected — that one page in Morgan's briefing had been photographed by a shared investor and landed in OmniDx's internal Slack before lunch.

OmniDx's CTO posted on LinkedIn, tone restrained but prominent: "Our validation methodology has been independently audited. The 96.2% accuracy is based on a publicly reproducible evaluation framework. We'd suggest colleagues check their own datasets before commenting on others'."

Derek read it twice. After that, nobody compared 96.2% to 94.1% again.

VP Morgan found him after the session: "Was it like this last time?"

Derek froze for a second. Morgan's tone wasn't an interrogation, and it wasn't concern — it was confirmation. She was confirming what she'd suspected for three months — that Derek had done it again: promised a number he couldn't hit, fixed the pipeline in secret, dug up dirt on the competitor, and left her, the VP, the last to know.

"More or less," he said.

Morgan nodded. Didn't press. Sometimes the most unsettling thing isn't being questioned — it's realizing the other person already has their answer.

She never asked again.

A week later, two of the three hospitals pushed the FDA audit contract to final-stage negotiation. OmniDx stopped appearing on bid lists.

Besiege Wei to Rescue Zhao isn't about defeating Wei. It's about making Wei feel like it has to defend itself.

The Third Cup

That evening, Derek walked out of the MediSys building alone. Heading toward the metro platform going west, he turned at the intersection — not lost, just not ready to go home. He needed a road long enough to walk for ten minutes and process the day. He didn't take his usual route. Took an alley he'd never walked before. Deeper and deeper. Something was pulling him in that direction — though he didn't know what.

Then he stopped under a warm amber sign —

"Third Cup" cafe.

He didn't walk in. He stood at the door for two seconds, looking through the glass. Inside, there was only one person — a figure in a dark coat, seated at a corner table, a few sheets of paper spread out in front of them. Not a menu.

The person looked up. Met Derek's eyes.

Those eyes didn't look away. Didn't nod. Just watched.

Derek walked on.

A few steps later, it hit him: one of those pages on the table — the corner that was flipped open — had the MediSys logo on it. Deep blue. He knew it. Below it was an architecture diagram he didn't recognize but could guess.

He stopped. Looked back.

Through the glass, the seat was empty.

Derek's first instinct was to push the door open and walk in. But his feet wouldn't move. A Director-level architecture diagram on a stranger's table — he should be taking photos, chasing leads, calling Legal. He didn't. Because Morgan had just looked at him and asked, "Was it like this last time?" — and if tonight she heard he'd been standing outside a cafe while someone inside had MediSys architecture docs, she wasn't going to call it a coincidence.

He stood there thinking for a long time. Long enough that if the person was still inside, they'd had time to walk out the back and be three blocks away.

He didn't chase. Maybe he'd look into it tomorrow. Maybe not. Tonight, he needed sleep — not another lead to follow.

That's Besiege Wei to Rescue Zhao — when you can't beat their accuracy, you attack their benchmark.

🤖 AI Post-Mortem Analysis

[36 Stratagems Tactical Engine v3.1] Loaded
[Matching Target] Besiege Wei to Rescue Zhao
[Analysis Mode] Full-Table Situational Scan
━━━━━━━━━━━━━━━━━━━━
Tactical Match: 87.3%
Agent: Derek Shaw
Action: Abandoned head-to-head model accuracy competition.
        Exposed structural flaws in competitor's benchmark
        while rebuilding internal data pipeline.
Objective: AI-assisted diagnostic validation milestone
Outcome: 94.1% (target 95%) — competitive pressure neutralized

Parallel Path Analysis:
  - Pipeline path: Intervention on Day 17, 16 days late.
    Data refresh restored → accuracy jumped 92.7% → 94.1%.
  - Competitor path: Four-prefix anomaly detected Week 2.
    Comparative analysis deployed Day 18 → OmniDx retreated to LinkedIn defense.

Key Data Points:
  - OmniDx eval set: 3 data sources vs. MediSys 17.
    96.2% wasn't inflated — it was greenhouse-grown.
  - ETL pipeline: single-threaded 20h → 8-parallel 4h.
    Zero model code changed. Accuracy +1.4%.

Verdict: Tactically sound, split in execution.
Strategic judgment (competitor) and tactical execution (pipeline)
lagged behind each other by 16 days — two sides of the same person.
A smart person's greatest enemy isn't the competition.
It's their own ego.

Next stratagem: Kill with a Borrowed Knife

P.S. English isn't my first language. I use AI to polish the writing and help with storycraft. Thanks for reading. ☕ Buy me a coffee

VP of Nothing: The CEO's Nephew Took Over My AI Platform. The Client Walked Within a Month.

xulingfeng — Sun, 28 Jun 2026 04:43:40 +0000

Series: AI, Ego & Regret — Bonus Chapter

Editor's Note: While compiling the old series for the book, I found this draft in the archives. It didn't fit the original lineup, but the story was too good to leave buried on a hard drive. I polished it up and decided to release it as a bonus chapter for the series. This is a work of fiction.

Act I · Dead Weight

It took me six years to turn NovaTech's AI diagnostic platform from a Python script on a single server into a production system processing four million diagnostic requests a day. Every sensor pushed data upstream. The model didn't fire on every reading, but during peak hours it handled over a hundred per second. Our clients included three Fortune 500 manufacturing giants — the biggest of which was Merit Manufacturing — plus a medical device brand you've definitely used.

Six years ago when I joined, the company had eighteen people and the CTO still wrote code. CEO Ryan Whitfield pounded the table at all-hands meetings and said, "We're building something that matters."

Three years in, we moved into a Sunnyvale office with a courtyard. Ryan drank half a bottle of whiskey at the housewarming party, put his arm around me, and told an investor, "Tom's the reason this ship stays afloat."

Three years after that, the ship told me I was dead weight.

The layoff came on a Wednesday at 11 AM. All-hands video call. Ryan sat in front of his dining room chandelier — the one that cost thirty grand — and explained that the company was going through a "strategic restructuring" to "streamline operations." Slide three had my name and the entire data platform team's — all twelve of us — sitting neatly inside a gray box.

"The affected roles are being eliminated to reduce redundancy."

Redundancy. I'd led this team for six years. Years of zero-incident operations. 99.97% recall rate. Redundancy.

HR's separation package landed in my inbox. Standard severance, an NDA, a one-year non-compete. I couldn't even work at the coffee shop downstairs, let alone a competitor.

I noticed something when I signed. Buried in my non-compete was an exception clause: "Family members of executive leadership are exempt from non-disclosure obligations regarding internal restructuring communications." It was tucked into a footnote on page fourteen in type so small you'd miss it if you blinked.

I didn't think much of it. I signed.

Act II · First Blood

Two weeks later, LinkedIn filled in the blanks.

Kevin Whitfield's new profile picture showed up in my feed. Westport University polo shirt, standing in front of the engineering school sign, teeth so white they looked AI-generated. His headline: "VP of Engineering at NovaTech | Builder | Thinker | Disruptor."

I stared at that title for a solid twenty seconds. VP of Engineering. A guy who was writing course projects three months ago, holding the same title as my old boss.

His first company-wide email went out the next afternoon — sent to all the inboxes I no longer had access to. Dmitri — one of the old-timers on the team — screenshotted it and sent it to me.

"I'm excited to announce that NovaTech is entering a new chapter. Our current platform architecture, while functional, carries significant technical debt. I'll be leading a modernization initiative to bring our stack into the next generation. Expect faster iterations, leaner deployments, and a more aggressive roadmap."

Technical debt. Faster iterations. Leaner deployments. Every word landed exactly on "I have no idea what this system does."

Dmitri's caption under the screenshot: "He asked me today if the CI/CD pipeline was a new hire."

Act III · The Model Swap

Kevin's first move wasn't architectural. It was swapping the model.

"Tom's model is six years old. It's good. But good isn't the standard anymore."

That's what he said at his first tech all-hands. Dmitri relayed it to me in a flat voice — he was past the point of being surprised.

Kevin's "modernization" meant replacing the diagnostic model I'd tuned for six years — 99.97% recall with a 0.03% false positive rate in industrial fault detection — with the newest closed-source LLM on the market. He claimed the LLM's "zero-shot reasoning capabilities" would expand coverage from 340 scenarios to "infinite."

340 scenarios. Every single one went through three rounds of labeling, two rounds of cross-validation, and at least three hundred hours of production observation before we called it done. Kevin spent three days reading API docs and decided that was enough.

At the demo, he pulled up the LLM's dashboard and told the six engineers in the room: "This thing reads the logs, understands the context, and outputs the diagnosis in natural language. No more manual rule tuning. No more feature engineering. No more bottlenecks. "

When he said "no more bottlenecks," he looked at Dmitri. Dmitri was our performance engineer. Kevin probably didn't know his name, but he knew that role belonged to "the previous era."

Dmitri didn't push back in the meeting. He messaged me afterward: "He said the LLM benchmarked against our logs. I checked his test set. Textbook fault patterns. Not a single one from a real production line."

I didn't reply. Because Kevin knew too — he picked a clean test set because clean test sets give clean results.

Act IV · Cascade Failure

Counting from Kevin's first day, by day twelve the swap was done. Kevin oversaw the engineering team himself, cutting over the old inference pipeline to the LLM's API. The switch was smooth. Every endpoint returned 200. Every green light on the dashboard stayed on.

Day fourteen, Merit Manufacturing's production line reported a fault.

Nothing major — a sensor drift on a conveyor belt. The old model had handled this exact scenario over a thousand times. Diagnosis: "Sensor drift detected, recalibration window: 72 hours." Confidence score attached. Maintenance ticket generated. Total time: 170 milliseconds.

The new model read 170 pages of production logs, spent 4.3 seconds, and produced a fluent paragraph:

"The anomaly pattern suggests a potential degradation in the conveyor belt alignment mechanism, possibly due to cumulative thermal stress on the drive unit bearings. Recommend immediate full inspection of the drive train assembly."

Translation: "I have no idea what this is, but I can write something that sounds smart."

The maintenance crew stopped the line. Pulled the drive unit. Tore down the bearings. Four hours later, they found nothing. The supervisor wrote in the work order: "False alarm. No fault found."

That was the first one.

Day sixteen, the same LLM flagged a normally running compressor as "imminent bearing failure." Another teardown. Another four hours. Nothing. The supervisor changed NovaTech's diagnostic feed status to "high noise."

Day eighteen, it missed a real fault.

Sensor readings clearly showed a hydraulic seal accelerating toward failure. The old model's rule engine would have triggered a "failure probability: 87% within 7 days" alert. The LLM read the same data and wrote: "The observed fluctuation patterns are within normal operational variance. No immediate action required."

Thirty-two hours later, the seal blew. The line was down for nine hours. Each hour of downtime cost $130,000.

Dmitri sent me the numbers — screenshots from the incident report, timeline and cost breakdown included. His caption: "Your rule engine caught faults for six years. Twenty days after they swapped it, it blew up in front of a client." I didn't reply. But I read every line.

Act V · The Ultimatum

Merit Manufacturing's incident report didn't name NovaTech — Diana did them that favor. But the customer success VP forwarded an email to the internal group chat, and Dmitri screenshotted it to me. Five sentences from Diana to Ryan, CC'd to four people: her CFO, her legal VP, NovaTech's customer success VP, and a legal department inbox.

The third sentence: "We require the diagnostic model deployed prior to June to be restored within fourteen calendar days. If that is not possible, we will exercise our right under section 6.2 to terminate the agreement."

Translation: "Put Tom's model back. If you can't, we walk."

Act VI · The Call

Three days after that email, my phone buzzed at 11 PM. No area code in the caller ID, but I knew who it was.

"Tom."

"Diana."

"Everything I'm about to say, my legal team would tell me not to say it."

She paused. I heard keyboard clicks on the other end — she might have been closing windows, making room for what came next.

"Merit Manufacturing is terminating the agreement with NovaTech. Section 6.2. Fourteen-day transition period."

I didn't say anything.

"We need someone to lead the transition. Not someone from NovaTech. You know this system better than any engineer still on their payroll. Your non-compete has two holes in it. I had my lawyers check —" she paused, like she was making sure she hadn't crossed a line. "The family-member exception was posted on an anonymous forum. Same firm that drafted your contract — anyone who reads it can see what it means. And the non-compete itself has an out: client-initiated separations don't trigger it. Also —" another pause. "Kevin's reply was effectively a written refusal. We don't need to wait the full fourteen days."

I leaned against the kitchen counter. My wife was reading to our daughter in the living room, voice soft, one word at a time. I listened to those syllables, holding the phone, feeling the world go quiet for two beats.

"Tom?"

"Send me the details," I said. My voice was calmer than I expected.

Before she hung up, I asked: "Diana — did you go to NovaTech first?"

A long silence. Then: "I did, Tom. Kevin told me the LLM is 'objectively superior' and suggested I wait for his explainability report. So I'm done waiting."

She was waiting for Kevin to realize he was wrong. He never did.

Diana sent me the explainability report right after the call. Six pages of PDF. Every section tried to prove the two false alarms and the missed fault were "edge cases," "out-of-distribution inputs," "not representative of the model's true performance." There was a comparison table in the appendix showing 98.7% accuracy on his clean test set.

He told a complete lie using a dataset that never lied.

Act VII · The Exception

The NDA's hidden exception clause was dug up by a former colleague and posted on an anonymous workplace forum. The thread title: "\"NovaTech's restructuring was literally designed for nepotism.\" Over four hundred replies."

One comment stuck with me. An anonymous account claiming to be a former NovaTech employee wrote: "Ryan Whitfield once told me culture fit was the most important hiring criterion. Turns out what he meant was 'shares my last name.'"

I screenshotted it. Didn't save it. Then I closed the browser and opened the architecture docs for Merit Manufacturing's new project.

A system isn't yours just because you didn't build it — that was Kevin's mistake. A system is yours forever because you did build it — that was Tom's fate.

AI, Ego & Regret — Bonus Chapter. This is a work of fiction. Any resemblance to real events or persons is coincidental.

📖 Stratagem 2 of the 36 Stratagems series — coming soon.

P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee

Stratagems #1: Mark Johnson Walked Into an AI Audit. The Benchmark Had Everything Figured Out — Except the Truth.

xulingfeng — Wed, 24 Jun 2026 15:58:57 +0000

Complete preparation breeds complacency. What is seen every day no longer raises suspicion. The hidden lies within the open — not opposed to it.
— The 36 Stratagems, "Deceive the Heavens to Cross the Sea"

The phone rang at 3:50 AM.

12 Years as a Prompt

The company extracted his 12 years of infrastructure expertise into an AI Skill. 96.8% diagnostic accuracy. The CEO sent a company-wide email: "Twelve years of experience, now available as a Prompt." Then they laid Mark off.

Six weeks later, the company migrated from RabbitMQ to Kafka. Nobody re-ran the validation. The AI Skill executed its old 450ms retry logic — dead right for RabbitMQ, catastrophic for Kafka. At 4:12 AM, the CTO called. He was offering five times Mark's old monthly salary for a two-week onsite contract.

Those two weeks ended. Mark didn't stop. Over the next two years, he took eleven contracts. The industry whisper network gave him a nickname: the one-man audit team. He got the calls nobody else got — companies burned by AI platforms, too embarrassed to say it out loud. Every contract made him more certain of one thing: nobody rushing AI into production had actually understood their own systems.

Then a message landed in his LinkedIn inbox. A partner at a VC firm.

$18M, Not $18K

"The company is called Pulse AI." The partner's voice had that fast-clip rhythm investors always have. "AI testing platform. Series B. Legal DD cleared. Technical DD — we need someone who actually knows what they're looking at."

"What are you suspicious of?"

"Not suspicious of anything. The CEO's reports are gorgeous — papers published, benchmarks run, claiming 89% production defect detection. But we're writing a check for $18 million, not $18K. Go take a look."

Before hanging up, he added: "Their CTO is someone named Torres. Ring a bell?"

Mark didn't answer. He hung up, then opened a browser tab he'd bookmarked two months ago — a technical architecture post by Pulse AI's CTO. He scrolled to the data pipeline topology diagram, zoomed in, and read the component naming convention: /pulse/ingestion/{env}/{source}. Slash-delimited hierarchy, environment variable in the middle, source as the tail — the exact same naming convention he'd seen in the AI Skill pipeline docs at his old company before they let him go.

Not a coincidence.

He replied to the partner: "I'm in. Two weeks."

The Same Sticker

Technical DD kicked off Tuesday morning.

Pulse AI gave them a conference room on the fourth floor — no windows, one monitor, company values poster on the wall. CTO Torres was early forties, navy polo shirt, handshake like a vise. Mark had seen him before — four years ago, at an industry conference. Front row. Asked three questions after the talk. Mark noticed the blue sticker on Torres's laptop — identical to the IT asset tags the ops team at his old company all used. Mark set his backpack by his feet, pulled out a worn black travel mug from the side pocket, and placed it on the table.

Same mug.

Mark didn't say anything about knowing him. Mentally, he added the thread to his notes.

Torres demoed Pulse Benchmark. Pipeline-style — code commit triggers tests, test results flow into the evaluation set, the evaluation set gets matched against the defect database, and a detection rate pops out. Clean. Closed-loop. Automated. Mark nodded along, but his brain was somewhere else: the sticker on Torres's laptop — palm rest, bottom right, 3 o'clock position — exact same placement as the one he'd seen four years ago.

Not a coincidence anymore.

Wait for the Crack

Mark asked the question everyone should have asked: "Can I see the evaluation set data?"

"Sure." Torres answered fast. "I'll have someone prep it."

Then he waited. All day. Wednesday morning Torres emailed: "Data prep in progress, this afternoon." Afternoon became evening. Mark didn't push — he wasn't waiting for the data. He was waiting for the cracks that show up when someone's scrambling to clean things up.

Wednesday, 3 PM. The evaluation set arrived. 1,247 defect samples. Each one a JSON — source code snippet, stack trace, error severity classification, reproduction steps. At a distance, it looked gorgeous. Clean enough to frame.

Every JSON had an extra line in the metadata: processed_by: Apex-Lens-Cleaner v1.0.0. Cleaner tools in data prep pipelines are normal. But Mark stared at that module name for two extra seconds. Never seen it before. Filed.

He went through them one by one. At sample 30, he stopped.

A Java null pointer exception. Stack trace pointed precisely to a service-layer method, parameter was null. Reproduction steps: "Call foo(null) to trigger." Too textbook. Every NPE Mark had ever seen in production had at least seven or eight layers of stack trace — log threads, GC pauses, truncated variable values mixed in. This one had four layers. Zero noise.

Production data is dirty. This data isn't.

He wrote a keyword search script and cross-referenced the evaluation set against three open-source defect databases. Ran it twice. Same result both times.

44 exact matches against public defect databases — source snippets, stack trace line numbers, exception types, line for line. 54 with clear signs of handcrafted construction — code structures that were "too clean," nowhere to be found in any public repo, but the engineering fingerprint was too heavy to hide.

He color-coded the samples: red (exact match with public DB), yellow (suspected handcrafted), green (undetermined).

Red plus yellow: 98. Out of 1,247. 7.9%.

That's enough to call it. This isn't about the percentage. It's about what the percentage means.

He closed his laptop and walked to the break room for water. Passing Torres's desk, Torres was on a call — voice low, but a single line drifted out just as Mark walked by: "…I don't care how. Just get the number where it needs to be before the board."

Where does he need the number to be?

Mark walked back to the conference room, water glass in hand. In his memo, he wrote a line only he would understand: "44+54. Torres wants a number, not the truth."

He wasn't in a hurry. A cat doesn't rush when it knows the mouse can't get away.

Questioning the PhDs

The next morning, Mark scheduled a meeting with the evaluation team.

Three people. All PhDs. All visibly proud of their work. No PM, no Torres. Mark asked one question: "How many rounds of edits does a defect go through, on average, from production report to sample?"

The team lead hesitated. "…Two or three, usually. Mostly noise removal. Format standardization."

He stopped, looked at Mark. "Is that a problem?" — with that defensive edge PhDs get when an outsider questions their domain. Mark's stomach dropped: this PhD wasn't even sure himself whether the provenance of those samples was clean.

"Noise removal." Mark repeated the phrase in his head. A 48-line null pointer exception, after "noise removal," becomes 12 lines. What got deleted wasn't noise. It was the fingerprints of real production data.

He didn't call it out in the meeting. That wasn't his style.

After the meeting, Mark pretended to take a wrong turn — Pulse had an open floor plan, ops team sat deepest in. Walking past, he scanned the desks — keyboard tray angle, acrylic badge holder placement — identical to his old company.

Not a coincidence anymore. It was habit. You can't pick up an entire system architecture and move it. But you can pick up someone else's naming conventions. Mark went back to the conference room and added a line to his notes: Didn't build from scratch. Transplanted.

Not a Coincidence. A Copy.

That night, Mark did something the VC wasn't paying him to do.

He reverse-engineered the data pipeline topology from Pulse Benchmark's paper. The paper claimed the evaluation set came from "real production defect reports." But where was the raw data stored? Who wrote the collection scripts? None of that information was there. But the third paragraph of the Methodology section had one sentence: "The evaluation set was manually curated from production defect reports over a 14-month period."

Mark placed that sentence next to the AI Skill training set documentation he'd saved before he got laid off.

Not "similar." Verbatim.

Same people wrote it. Or the same people's documents were open on a Pulse desktop.

He wrote a note. Five lines:

Benchmark evaluation set: 44 exact matches against public DBs + 54 handcrafted. 7.9% hard evidence.

Data pipeline naming: /pulse/ingestion/{env}/{source} — identical to old company's AI Skill pipeline.

Workspace standards + asset tags: Transplanted.

Paper language: "manually curated from production defect reports" — verbatim copy.

Apex-Lens-Cleaner v1.0.0: Processed the evaluation set. But this name doesn't appear anywhere in Pulse's public architecture. A module that doesn't officially exist is running.

He didn't put those notes in the email. The VC hadn't asked for that.

He wrote the partner one paragraph:

"Pulse Benchmark evaluation set: 1,247 defect samples. Minimum 44 are exact matches against public defect databases — line-for-line identical. An additional 54 show clear signs of manual fabrication. Combined: 98 samples, 7.9%. Recommendation: re-run the Benchmark after removing all samples overlapping with public databases."

He hit send. Closed the laptop. The partner didn't wait until morning. The email was forwarded to Pulse's CEO's inbox at 1 AM.

Those 44 were just the tip of the iceberg — run fuzzy matching, variable renaming, control-flow equivalent transforms, and the number you'd catch would at least triple. He didn't put that in the email. Let your opponent wonder what else you're holding. It works better than showing all your cards.

The CEO forwarded it to Torres. The phone rang at 3:50 AM.

Three Seconds

Mark glanced at the caller ID and picked up.

Torres didn't speak. The silence lasted about ten seconds.

Then he spoke. Quiet. No preamble. "The CEO wants me to get the Benchmark number to 95% before Series C. I have six months. Those 44 — my evaluation team pulled them from public databases. GitHub Issues, Stack Overflow, CVE database. The 54 — couldn't find suitable replacements, so we wrote them ourselves."

A long pause.

"I'm not trying to steal VC money. I'm trying to get the number there first, raise the round, then spend a year building a real production pipeline."

He'd rehearsed that line.

Mark didn't engage. He asked a question Torres hadn't prepared for: "Who built your ingestion pipeline?"

Silence on the other end. One second. Two. Three.

The length of the silence was the answer.

"…How do you know about that?" Torres's voice had changed.

"I won't dig into it," Mark said. "But I've seen /pulse/ingestion/{env}/{source} before. Before I left my old company, the AI Skill pipeline was called /knowledge/ingestion/{env}/{source}. You were there. "

Torres didn't answer.

Mark waited five seconds. Then he hung up.

Just a Ticket

He didn't have direct proof the two pipelines were built by the same person. But Torres hadn't denied it. On a 3:50 AM phone call, staring at a data pipeline name he had no business recognizing — silence is confirmation.

He opened his laptop and added a new line below those five notes:

Torres didn't deny it. The silence is the answer.

Still dark outside. The VC partner sent a reply — 3:51 AM. "Keep going."

Mark shut his laptop.

He didn't tell the partner the real reason he'd taken this job. It wasn't the VC's money. It was what he'd known the moment he saw that architecture post two months ago — that pipeline naming convention was a signature he'd recognize anywhere. Caleb's handwriting. Slash hierarchy, env-in-the-middle, source-suffix — the mark left by the engineer who sat across from him for three months, the one who always asked "Why 450 milliseconds?" You can't teach it. And you can't forget it. Caleb had vanished after the big layoffs. LinkedIn silent. GitHub frozen. Like he'd evaporated from the industry. And then his naming convention showed up in the data pipeline of a company called Pulse.

The VC's DD was just a way in.

He picked up the worn black travel mug from the table — the one he'd refilled three times during the meeting. Last time he'd been walked out of an office, he had nothing in his hands. This time, he had a thread. A line he could follow.

This is deceiving the heavens to cross the sea.

🤖 AI Post-Match Analysis

[36 Stratagems Database v3.1] Loaded
[Match Target] Deceive the Heavens to Cross the Sea
[Analysis Mode] Full-spectrum scan
━━━━━━━━━━━━━━━━━━━━
Tactic Match: 92.3%
Subject: Mark Johnson
Action: Covert audit objective disguised as routine technical DD workflow
Target: Torres / Pulse AI
Outcome: Achieved

Counter-Detection:
  - Torres team: Concurrent application of same stratagem
  - Forged samples: 98/1,247 (7.9%) processed through Apex-Lens-Cleaner pipeline
  - Source: 44 from public DBs + 54 handcrafted

Situation Assessment:
  - Mark Johnson: 12yr experience → AI Skill → redeployed as AI Kill. Legitimate identity, offensive audit.
  - Torres team: Defective data embedded in evaluation set. Defensive concealment.

Verdict: Tactic-neutral. Legitimacy determined by deployment vector. Defensive concealment ≠ offensive exposure.

Next stratagem: Besiege Wei to Rescue Zhao

P.S. English isn't my first language. I use AI to polish the writing and help with storycraft. Thanks for reading. ☕ Buy me a coffee

Series Teaser — 6 People, 36 Stratagems, and an AI Rabbit Hole That Keeps Getting Deeper

xulingfeng — Tue, 23 Jun 2026 17:38:03 +0000

What Are the 36 Stratagems?

If you've heard of The Art of War, think of the Thirty-Six Stratagems as its scrappy younger cousin. Sun Tzu wrote about macro strategy — when to fight, when to retreat. The 36 Stratagems are tactics. Specific moves. The kind of play you can see on the board.

A few examples: Deceive the Heavens to Cross the Sea — hide your real intent behind routine actions. Besiege Wei to Rescue Zhao — attack where your enemy is forced to defend. Kill with a Borrowed Knife — use someone else's strength to remove a threat.

They were written for warfare. They work just as well in office politics, courtroom arguments — and, as it turns out, AI projects that crash in spectacular ways.

Both books are on Amazon. I'm not linking them — makes me look like an affiliate marketer, and they're not paying me. 😄

The 6 People

Mark Johnson

12 years of ops experience was packaged into an AI Skill. Then he was laid off. The CEO's memo: "12 years of experience, now available as a prompt."

Months later, the AI crashed — the company migrated from RabbitMQ to Kafka, but nobody re-validated the Skill. It was still running the old RabbitMQ retry logic. At 4:12 AM, the CTO called him back at 5x his old monthly rate to fix it. He didn't stay. Signed a two-week contract, fixed it, walked out.

His one-person consultancy is still running. One clause: no AI in the delivery chain.

Temperament: Strategist. Thinks three moves ahead. Leaves hidden failsafes in routine operations — like a note in a migration doc saying "450ms is RabbitMQ GC window only. Do not use in other environments."

P Anonymous (second story)

Yeah, I got to the third story before realizing I never gave them a name. So P it is.

An AI payment gateway processing $2.8B in transactions. The CTO used formal verification to prove it was "mathematically safe." P spent eight months secretly building an adversarial testing pipeline to prove the gateway would approve illegal transactions.

Later, P's own article got flagged as "low quality" by an AI moderation system. P pulled the internal API, grabbed 347 flagged records — the effective accuracy was 38%. False positives outnumbered correct ones.

Temperament: Calm. Data-driven. If you're sitting across from P with a fabricated benchmark, you should be nervous — but P won't give you any signals until the evidence is ready to land.

Leo

Open-source AI pilot ran for six months. 91.3% accuracy. Zero incidents. The new CTO spent $8M on his old company's product and fired Leo's entire team of six. On day 13, at 2:47 AM, the $8M system collapsed — six GPUs OOM, three AI agents fighting over context windows. Leo walked back to the server room, brought the old system online. 30 seconds to recovery.

The CEO called at 3 AM: full team rehire, double salary, CTO position. The CEO's exact words — "Your team. Your budget. Your technical direction."

Temperament: High energy. Technically confident. Doesn't play politics — not because he can't. He genuinely believes good code wins in the end. (He's learning the hard way that it doesn't always.)

Lena

VeriTest had 15 people. Competitor QualiGuard had 200, claiming 97.2% AI coverage. Lena didn't look at the coverage number — she looked at the test logs. 3 hours 12 minutes. Zero external dependencies. The competitor was running a sandbox.

She paid $5,000 to a former employee for an internal recording. The VP and the test director had budget friction. She fabricated a $1.3M fake quote, leaked it through an intermediary. The VP pressured the director to cut costs. The director swapped full regression for sampling + AI prediction. Real coverage: 86.7%. Lena won.

In the parking lot, the director stopped her. "You planted that quote." Lena's reply: "I never said I'd fight clean."

Temperament: Sharp. Patient. Not afraid to get her hands dirty. Find someone's pressure point, push, and wait. Or buy a recording. Or plant a fake quote. Either way, the board's in her hand.

Alex

Backend engineer. He writes things nobody asked him to write.

Marcus Webb demoed a shiny vector database at the all-hands. He glanced at Alex's screen and smirked: "SQLite? For AI memory? Like putting a bicycle on an F1 track."

Over the next six weeks, Alex quietly built a SQLite FTS5 fallback system. Told nobody. At 2:14 AM, the vector DB died — CUDA deadlock. Marcus said it'd take two to three days to fix. The board demo was in seven hours.

Alex typed in Slack: "I have a parallel fallback running. Give me five minutes."

2 minutes 43 seconds. Switched over. First query: 2 milliseconds.

Temperament: Quiet. Paranoid. Doesn't argue when mocked — waits until 2 AM when the system goes down, then cuts over.

Derek Shaw

QualiGuard's Director of Testing. He walked into the bid review certain he'd already won — 97.2% AI coverage in a sandbox, 4-day delivery, no holes. He didn't know the VP had already cut his GPU budget in half. He didn't know the other side already had the tape of him and the VP at odds.

In the review, Sarah stood up and said three sentences — "The delivery timeline is based on Derek's personal technical assessment, not reviewed by management… If QualiGuard is selected, the revised proposal will be submitted under new technical leadership." Derek sat through all of it. Didn't say a word.

Then he updated his LinkedIn. New title: Director of Testing, medical IT.

Temperament: Arrogant. Stabbed in the back by his own side in a game he thought was already won.

The Framework

Over 36 stories, these six paths cross — some face off, some work together, a few are being moved by forces no one can see yet. And sometimes, they're just solving their own problems, while the reader sees it all before any of them do.

See you in the first story of AI, Ego & the 36 Stratagems.

P.S. English isn't my first language. I use AI to polish the writing and help with storycraft. Thanks for reading. ☕ Buy me a coffee

15 AI Stories Later, Some Honest Words

xulingfeng — Sun, 21 Jun 2026 13:21:56 +0000

May 29 I wrote my first AI trainwreck story. June 18 I finished #15.

People keep asking if this was some kind of "writing experiment" — it wasn't. I'm not that poetic.

The truth is, nobody was reading what I wrote before.

Scroll back to my early posts: AI agent setup notes, QA automation on a budget, a couple of technical deep-dives. Zero to one reaction each. Comments section was a ghost town. I took a real look around Dev.to — the front page is packed with tutorials and technical walkthroughs, but story-driven content? Barely any.

The old road was a dead end. Time to find a new one.

The results: worst-performing story got 7 reactions, best one got 86. Across 15 stories: 445 reactions, 251 comments.

Wrong direction, corrected.

The series wasn't planned from the start. I just started linking to my other articles at the end of each post so people could hop between them. Then I found out Dev.to has a series feature, and the name followed.

I'm a fan of Love, Death & Robots, so the structure came pretty naturally — AI, Ego & Regret.

Around story #8 or #9, a thought snuck in: could this actually become a book? That's when I set a target of 15 stories.

Wasn't sure I'd make it. Decided to write first, figure it out later.

I also realized the covers needed to be consistent. So I went back and redesigned all 15 covers with the same chessboard background and layout. Now it actually looks like a series.

My Favorite One Did the Worst

#6 — the CTO's 2.8B gateway story. Both sides were smart, the back-and-forth was real, no dumbed-down villain. This was the one I was most proud of. 9 reactions, 2 comments.

Some stories I thought were just "okay" did way better. Couldn't help but laugh at that.

The biggest contrast? #10 — the AI Skill story. It's currently my highest-viewed article, and I still can't quite believe it took off the way it did.

Looking back, I think it hit a nerve that goes deeper than tech: "Your experience gets packaged into a Skill, then you're not needed anymore." That's the sword hanging over everyone's head right now. Not just QA — every engineer.

And #6 — good story, but not scary. It didn't sting. Readers don't want "both sides played well" — they want the villain publicly humiliated. That rarely happens in real life. Adults save face for each other. But in a story, readers want someone to do what they can't.

Numbers in Headlines

I'll be honest — I don't want to be a clickbait writer. But if the headline doesn't grab you, it doesn't matter how good the article is.

The early stories had a clear pattern: big dollar amounts. $500K, $660K, $2.8B, $1.4M, $470K. They worked. Articles with numbers in the title clearly got more clicks.

But the later stories showed me something interesting. #10 had no dollar amount in the title — and it's my most-viewed article. #14 — no number, 55 reactions. #11 — no number, 26 reactions.

A number gets them in the door. What keeps them reading is something else entirely.

The One That Was Different

#14 — the one about AI flagging my article — was the most unusual one in the series.

Not because of the numbers. Because the article itself solved a problem.

At the time, my account had been flagged by the community. New articles were only visible to my followers — they wouldn't show up on the feed.

What pissed me off wasn't the flag itself. I'd been using AI tools, and I'd already gone through all my articles adding AI disclosure where needed. But nobody told me my account was flagged. I published an article I was excited about, and half a day later only a few dozen people had seen it. I had this sinking feeling something was wrong.

I hopped into a thread by Dannwaneri (@dannwaneri) — his post about getting flagged by Sloan was one of the earliest discussions about AI detection on the platform. While we were talking, a community moderator, Francis (@francistrdev), chimed in and told me: yeah, your account's flagged.

The irony? I'd already published the article about AI flagging before that conversation. It wasn't on the feed either.

I wrote that article while my account was still restricted.

Later I went to Francis's Q&A thread and asked three things — how many times does Sloan flag before action, do you get notified, and what do I do when my articles can't be found? He answered every single one. Not an earth-shattering change, but someone actually listened.

Sometimes an article isn't just an article. It's a wrench in the toolbox.

30 Passes

15 stories. Each one went through at least 30 rounds of revision before I'd hit publish.

Logic had to hold up. Numbers had to be precise. No contradictions between chapters.

If it looks fake, I don't publish it. I owe that much to myself and to anyone who reads it.

Not a Single Cup of Coffee

Every single article has a "buy me a coffee" link. All 15 of them.

Zero dollars. Not one.

I don't know if the link's too hidden or if trainwreck-story writers just aren't the type people buy coffee for 😂

But here's the thing: I don't actually care.

The views, the comments, the reactions — that's what actually makes my day. Someone writing "this was great" in the comments. A DM saying a particular paragraph hit close to home. That's worth more than coffee money.

The link's still there, though. Just in case.

So What Was I Even Trying to Say?

15 stories in, I sat back and asked myself — what was the point?

Was it for the attention? Sure, at first. Nobody wants to write into a void.

Was it for the coffee money? 15 articles, zero dollars — that math doesn't work.

Or is it because my own job is getting replaced by AI?

I've been in QA for 15 years. AI testing tools, automation coverage, smart diagnostics — the trainwrecks I wrote about, some I've seen firsthand, some I worry I'll run into soon.

Maybe I was writing these stories to amplify that anxiety. Not just for others, but for myself. A reminder: systems crash, people deflect blame, the 3 AM phone always rings — but the person who picks up that call is worth more than the one who only knows how to run a report.

Every trainwreck story was me telling myself: Your experience cannot be packaged into a Skill.

One Comment I Read 15 Times

Brilliant - I love reading a "David vs Goliath"/"underdog" kind of story like this! Best thing - he didn't panic, and he didn't try to get his "revenge" either (well the revenge was there of course, but purely through his results) ... epic story!

— leob, on the very first story of the series.@leob, if you're reading this — thank you.

That's not empty politeness. Before writing every new story, I go back and re-read this comment.

Not because it was the first nice thing someone said. Because it nails what I was trying to do with every single one of these stories — the protagonist didn't panic, didn't fight back with words, just let the results speak.

All 15 stories, same skeleton, different skin. When I lose the feel for it, I read this comment and know I'm not off track.

Then there's Daniel Balcarek (@gramli), a backend engineer from Czech, who left this on #2:

I really like your writing style. I just read the second story and couldn't stop reading. 😅 Great job!

I've gone back to that one too. "Couldn't stop reading" — three words, and that's all I needed. The best thing a storyteller can hear isn't "your data checks out" or "good technical approach." It's "I couldn't stop."

There are more. @itskondrat (Mykola Kondratiuk) on #3:

what's almost never in a \$660k deployment: explicit constraint on blast radius at that hour. not in the budget, not in the runbook.

One sentence that said the whole thing better than I ever could.

And on #10, two people called me out — Utkarsh Bansal (@utkarshbansal01) said it read like AI wrote it, and framemuse (@framemuse) said it lacked a human touch. I replied to both. One I agreed with, the other I admitted my timeline was messy. Getting called out means someone actually read carefully enough to question it — and engaging with that is way more interesting than ignoring it.

This is what I get paid in. Not coffee. People reading carefully enough to write something back.

How Real Are These Stories?

15 trainwreck stories. They're not my own experiences, but they're not entirely made up either.

I've been in QA for 15 years. How systems crash, how people deflect blame, what a 3 AM phone call sounds like — those are real. I took all of that, broke it down, and reshaped it into characters and situations.

The stories are fiction. The failure modes are not.

What's Next

36 stratagems.

A Book?

Around story #8 or #9, I realized this might be more than 15 articles. It could be a book.

The plan is to polish all 15 stories, add some new material, and put them together.

But a book is missing one thing: the Praise page.

I don't want to write my own blurb. I want to ask people who actually read the series to write it.

If you read any of these stories — if one made you laugh, or reminded you of something you've been through, or got quoted in a meeting — would you write a sentence or two for the Praise page?

Just a couple of lines. I'll pick a few and put them at the front of the book.

Drop a comment or reach me through my profile email. I'll follow up.

15 trainwreck stories. 445 reactions. 251 comments. 20 days.

See you in the next series.

If you think the series is worth a coffee: ☕

P.S. English isn't my first language. I use AI to polish the writing and help with storycraft. Thanks for reading.

Our Competitor Had an AI That Covered 97.2%. We Had a Spreadsheet and a Fake Quote. Guess Who Won.

xulingfeng — Thu, 18 Jun 2026 15:36:12 +0000

You walk into the RFP briefing. Your competitor has 200 people, 97% AI coverage, and a 4-day delivery promise. You have 15 people and a proposal you haven't even finished writing.

Do you bet on better tech, or on understanding people better — and playing dirtier when you have to?

This story is your answer.

Act I · The Crack

When Finova's RFP landed, everyone in the industry knew how big this was.

Cross-border payment system. Multi-currency settlement + compliance + risk. Their last deployment had a P0 incident — an exchange rate module drifted by four decimal places in an edge case, and audit chased it for two months. So Finova's CTO made it clear: a $1.8M contract, and whoever signs off owns the result.

$1.8M. Enough to keep a small testing company alive for a whole year.

Plenty of firms showed up at the briefing. But only two were real contenders.

QualiGuard — mid-sized, just closed their Series A, 200 people, their own AI testing platform called Aegis. A $1.8M contract was barely a rounding error for them — but with Series A money comes the pressure to show revenue growth for the next round, and Finova was a trophy client in the cross-border payments space. The case study was worth more than the project itself. Derek stood at the podium, flipping through slides packed with numbers: Aegis delivers 97.2% test automation coverage. Full Finova platform testing in four business days. No "we'll try." Just "we can do it."

VeriTest — small, fifteen people. Marcus spent the whole morning working the room with Finova's people. I sat in the back row with nothing.

Marcus slid back over and leaned in: "Their PPT makes yours look like a joke."

I didn't answer. I was watching Derek's boss.

Sarah — QualiGuard's VP, Derek's direct supervisor. She sat in the front row, off to the side, and never once looked at Derek during his entire presentation. She was on her phone. As one of the few women running a technical department, I watched her longer than I watched Derek.

When Derek flashed Aegis's coverage curve on screen, Sarah was replying to emails.

When Derek said "Aegis is the result of 18 months of R&D, with AI prediction accuracy reaching 82%," Sarah was scrolling something on her phone.

When Derek finished and the room applauded, Sarah flipped her phone face-down on the table. She didn't clap.

At the coffee break after the briefing, I didn't go talk to Finova's CTO. I went to find Marcus.

"Run two people for me."

"Who?"

"Sarah and Derek from QualiGuard. I need to know their dynamic."

Marcus frowned. "Why? We haven't even written a proposal."

"Derek just pitched for 40 minutes, and his boss didn't look at him once. Two most likely explanations: either she's heard it a hundred times and can't stand it anymore — or she's waiting for him to screw up. "

Marcus looked at me. "Lena, which one's worse?"

"The second one. Because if she's waiting for him to slip — we don't need to beat Derek. We just need to put a knife in Sarah's hand — one he won't see coming."

Marcus nodded.

He knows how deep my technical chops go. And he knows my philosophy on dirty work: when you have the tech, fight clean. When you don't, fight dirty. When you can't win either way, find another path.

He's never doubted my read on things.

Act II · First Blood

Derek didn't wait for the submission deadline. He played his hand early.

On May 14, QualiGuard sent word through an intermediary to Finova's CTO: "Aegis is already testing your system — first round's on us."

Smart move. The first one to deliver always has the advantage — even if what they deliver is half-baked.

On May 16, Derek sent Aegis's test report to Finova's technical review team. Subject line: Finova Full Platform Assessment — Aegis v2.3.

I saw the report on the morning of May 17.

When Marcus forwarded it, he expected me to look at the coverage and pass rates first — 97.2% coverage is a knockout punch in any bidding scenario.

But I did something Marcus didn't understand.

I flipped to the appendix.

Not the body of the report. The system log appendix — auto-generated timestamps from Aegis, buried in the last three pages. Most people in a bidding scenario only read the summary and conclusions. But I've been doing testing for fifteen years — five of them as CTO before we got acquired. Took the payout, started my own shop, brought Marcus in as partner. And in that time, I've seen too many projects with beautiful reports and disastrous execution. I never read what people wrote. I only read what they actually ran.

Aegis's logs showed:

Test Session: AEG-FINOVA-0512
Status:       COMPLETED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|Start:        2026-05-12 11:20:03 UTC
|End:          2026-05-12 14:32:07 UTC
|Duration:     3h 12min 4s
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|Total Reqs:   2,347
|Passed:       2,312
|Failed:       0
|Skipped:      35
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|Avg Resp:     47ms
|P99 Resp:     189ms
|Max Resp:     312ms
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|External Deps:  0

I stared at "External Deps: 0" and "Avg Resp: 47ms" for a long time.

Finova does cross-border payments. Two years ago I consulted for a company with a similar architecture — they had 9 external dependencies, and a single exchange rate API had a P50 response time of 120ms.

Sandbox environment. Expected — all pre-testing runs in sandbox.

I didn't check the coverage. I checked the execution time first.

2,347 test cases in 3 hours and 12 minutes.

I made seven phone calls.

The first was to Marcus: "Find out Finova's production environment setup — how many external dependencies do they have?"

Twenty minutes later Marcus messaged back: 14 external dependency services. API rate limit at 1,000 requests per minute per account.

I made six more calls. I don't know many people, but the ones I know are in the right places — one former colleague spent two years on Finova's infrastructure team.

The sixth call confirmed the key piece: Finova's production CI pipeline takes at least 24 hours for a full run. Half of those 14 external dependencies are banking-grade interfaces, each request takes 800ms minimum, and the rate limit kills any parallelism.

I laid out the math:

Finova production full test — theoretical estimate:
2,347 test cases — split 7:3 external/internal
1,642 external × 800ms avg dependency response
= 1,314 seconds (pure dependency wait)
+ internal execution time (est. 20,000 seconds)
≈ 5.9 hours — assuming zero bottlenecks

But API rate limit is 1,000 req/min:
External triggers: 1,642 / 1,000 = 1.64 min queueing
+ real queue time at least 3× estimate

→ Safe estimate for full run: 24h+

Aegis execution time: 3h 12min

I closed my notebook.

Derek's test ran in a sandbox. Nothing unusual — all pre-tests run in sandbox. But something else caught my attention.

I went back to his proposal. 97.2% coverage, four business days delivery.

Finova's production CI takes 24 hours per run. Even if Aegis is faster than traditional CI, four days gives you at most two complete iterations. But testing isn't just about running — you also analyze, fix, and re-run.

Four days. Ninety-six hours. Subtract 24 hours for one run — how many iterations can you fit in the remaining 72?

I didn't know the answer. But I knew one thing: if there was even one person on Finova's review team who could do this math, Derek was in trouble.

I picked up my phone.

I didn't call Finova.

I called Marcus.

"Can you still reach that former QualiGuard employee?"

"I can. But it'll cost."

"How much?"

"Five thousand."

"Pay it. I don't need technical data — I need the dynamic between Sarah and Derek."

Marcus was quiet for two seconds. "Lena, we've got seventy grand left in the account."

"I know. Pay it."

I knew that five thousand, if I was right about this, wouldn't buy us a project. It would buy us the cost of putting the knife in Sarah's hand.

Act III · Dirty Play

May 18. Marcus met a guy named Roy for coffee. Roy was a former senior test engineer at QualiGuard who'd left a month ago — and not on good terms with Sarah's team.

Five thousand dollars bought three recordings. Marcus transcribed them and sent them to me.

Recording one: three months ago, Sarah told Derek to cut Aegis's GPU budget.

Sarah: "Aegis costs $31,000 a month in GPU expenses. That's more than a manual testing team. Where's the justification?"
Derek: "GPU is the engine of Aegis. Cut GPU, you cut coverage."
Sarah: "Then cut coverage. The client is paying for manual testing rates, not GPU cluster rates."

Recording two: two months ago, Sarah cut Aegis's GPU allocation by 50% without Derek's consent.

Derek: "You could have at least told me first."
Sarah: "I did. You didn't listen."

Recording three: one month ago, Derek lost it at a team meeting.

Derek: "Sarah doesn't understand the technology. All she reads are spreadsheets. Aegis now takes 40% longer to run a full regression than before. She doesn't know, and she doesn't care. All she cares about is this quarter's P&L."

I finished reading the last transcript and put my phone down.

"Sarah doesn't get the tech. Derek thinks she's holding him back. Derek needs full regression to prove Aegis works — because cutting test volume is admitting Aegis can't deliver."

Marcus asked: "So what do we do?"

"So we make Sarah force Derek to do something he's afraid to do."

I had Marcus prepare a document.

Not a real bid. A document that looked like a real bid.

The gist: VeriTest planned to bid at $1.3M — 25% below the industry average, more than 20% below QualiGuard's expected price. The proposal looked legit: attachments, technical approach, delivery timelines.

The only difference: this proposal wasn't for Finova. It was for Sarah to see.

I found someone who did business with both companies — not a friend, but reliable for the right price. Had him "accidentally" let the contents of our fake bid slip to Sarah.

"You sure Sarah will buy it?"

"A manager who only reads spreadsheets, in the middle of bid season, sees a competitor 20% below her price — she won't question whether it's real. She'll take the number straight to Derek and tell him to match it."

It played out exactly as I predicted.

May 20. Word came through from Roy: Sarah called Derek into her office for 45 minutes. When he walked out, his bid had changed — from $1.8M to $1.5M.

When I got the news, I didn't smile.

"Derek just cut $300K." Marcus was doing the math on his end too. "They were at $1.8M with a 40% margin. Sarah pushed him to $1.5M with a hard floor — margin can't go below 22%."

I did the calculation. "Cost ceiling went from $1.08M to $1.17M. He actually has an extra $90K to play with."

"And?"

"And here's the problem — he's got an extra $90K in cost room, but he lost $300K in revenue. Sarah already cut his GPU once. It's not that he can't afford more compute — it's that he can't go back to Sarah and say 'you were wrong to cut it, I need it back.' That's slapping his boss in the face — he won't do it. The bid's due in two days, he's got no time for that fight. His hands are tied. The only path forward is to reduce test volume and let AI fill the gaps."

"Switching from full regression to sampling?" Marcus asked.

"Exactly. Run fewer real test cases, let the AI extrapolate coverage from historical data. And it's not voluntary — his boss made him cut the price. He doesn't have the guts to say no."

I leaned back in my chair.

Aegis at full GPU could probably finish a full regression in about 12 hours — based on 2,347 test cases and industry execution benchmarks. Sarah cut his compute by half, pushing it to 17 hours.

I opened my laptop and wrote a quick script to simulate Derek's situation:

"""
Aegis compressed test strategy estimate
Based on: Sarah cut 50% GPU → full test slows by 40% → 20% price cut
"""

full_test = {"cases": 2347, "time_hours": 12, "coverage": 0.972}  # Aegis full GPU baseline (QualiGuard internal env)
gpu_cut = {"time_hours": full_test["time_hours"] * 1.4}

sample_rate = 0.40
ai_prediction_accuracy = 0.82

actual_coverage = (
    sample_rate * full_test["coverage"] +
    (1 - sample_rate) * full_test["coverage"] * ai_prediction_accuracy
)

print(f"Claimed coverage: 97.2%")
print(f"Actual effective coverage: {actual_coverage*100:.1f}%")
print(f"Gap: {(full_test['coverage'] - actual_coverage)*100:.1f} percentage points")
print(f"This gap in a financial system = P0")

"So now Derek's test plan is: run 40% of the real cases, let the AI extrapolate the remaining 60% of coverage. And he can't tell anyone — because admitting it means admitting Aegis can't deliver what it promised."

"Is Derek going to lose?"

"No. On paper, his plan still looks good — sampling plus AI prediction is a legitimate approach. The problem isn't the plan itself."

"Then what is it?"

"The problem is he won't tell the client he's using sampling. He'll call it 'full regression.' And the moment he says 'full' — we've got something to cut open."

Act IV · The Summit

On May 23, Finova's procurement office officially received both bids.

QualiGuard proposal summary:

Item	Detail
Price	$1,500,000
Testing method	Aegis fully automated
Delivery timeline	4 business days
Coverage guarantee	≥ 95% (line level)
Proof point	Aegis pre-test report (attached)

VeriTest proposal summary:

Item	Detail
Price	$1,275,000
Testing method	Manual + AI hybrid
Delivery timeline	14 business days
Coverage guarantee	≥ 90% (line level)
Pre-test	None

The comparison was clear.

QualiGuard at $1.5M — $225K more than VeriTest, but only about 18% higher. Factor in delivery speed (4 days vs 14) and technical capability (97% automated vs hybrid), and Finova's CTO James was leaning toward QualiGuard.

On May 27, internal scores leaked — QualiGuard technical score 86, VeriTest 72.

Derek posted on LinkedIn:

"Technology is not about who has more people. It's about who has the right tools. Proud of the Aegis team. Looking forward to Finova's next chapter."

Forty-plus likes underneath.

When Derek posted that — I could tell, he genuinely believed it. His problem wasn't that his technology was bad. It was that he trusted it too much to see his own boss sharpening the blade.

At the same time, I was running my own Aegis behavior analysis on my laptop.

I couldn't use Aegis — but I could reverse-engineer its logic. Derek's public materials mentioned Aegis's core architecture: a coverage-driven reinforcement learning selection strategy. In other words, Aegis doesn't write test cases — it selects them. It picks the subset of the test asset library that contributes the most to coverage.

I did the math:

Aegis selection strategy (based on public materials):

Full test asset library estimate: for a Finova-scale system ≈ 8,000-12,000 cases
Aegis report ran: 2,347
→ Selection ratio ≈ 20%-25%, reasonable

If Derek runs sampling + AI prediction:
Actual execution ≈ 40% × 2,347 ≈ 940 cases
AI-predicted coverage ≈ 60%
→ Real coverage ≈ 40% × 97.2% + 60% × expected value

The problem isn't coverage percentage. It's AI prediction accuracy —
Derek mentioned at the briefing that Aegis's prediction accuracy is 82%.
82% fill accuracy covering 60% of the gap:
Real composite coverage ≈ 40% × 97.2% + 60% × (97.2% × 0.82)
≈ 38.9% + 47.8% = 86.7%

10.5 percentage points below what's reported.
In a financial system, that's a P0.

I didn't share this calculation with anyone. But I knew one thing: after Sarah squeezed Derek's budget, his plan had a technical hole. Frank didn't need to find it — I could have cut straight through it myself.

But I didn't.

Not because I couldn't. Because having someone else land the blow was cleaner than doing it myself.

"You're not worried at all?" Marcus asked.

"About what?"

"The scores. We're 14 points behind."

"Scoring is scoring. The review meeting is the review meeting."

"What's the difference?"

"Scoring is one CTO closing his office door. The review meeting is three departments sitting around a table. The CTO can have his favorites — but the CFO and the head of risk aren't going to take a bullet for his ego. Derek still doesn't realize his biggest problem isn't our proposal."

"Then what is it?"

"His biggest problem is his boss wants him to lose more than he wants to win. "

Act V · The Crash

Finova's bid review meeting was scheduled for the afternoon of May 29.

Six people in the room. CTO James, CFO Mark, risk lead Frank, plus two technical reviewers and procurement.

QualiGuard presented first.

Derek was in a suit, tie perfectly knotted. His team had put together 40 slides — from Aegis's architecture diagram to heat maps of Finova's test coverage, every number backed by data.

He spoke for 35 minutes. Then he dropped the pre-test results:

2,347 test cases. 97.2% coverage. 3 hours 12 minutes. Zero failures.

James nodded.

Then came Q&A.

Frank — the risk lead, mid-forties. Started as a developer, moved to architecture, then to risk. Twelve years at Finova. He was the one who spent two months auditing the last P0 incident.

He flipped open his notebook.

"Derek, your proposal says four business days delivery, 97.2% coverage. What's that number based on?"

Derek clearly hadn't expected the first question to go there.

"—Based on Aegis's test data from the Finova environment. 2,347 test cases. Full regression."

Frank turned another page.

"I've read your Aegis test logs — execution time was 3 hours 12 minutes. Finova's production CI full run is typically 24 hours or more, that's not a secret. But that's not what I'm curious about."

He closed his notebook.

"What I'm curious about is — your proposal guarantees delivery in 4 days. 4 days is 96 hours. If a full run takes 24 hours, you've got 72 hours left for analysis, fixes, and re-runs. That's tight — but it works if you're running full regression."

He looked at Derek.

"Here's the problem — Finova's cross-currency settlement module alone, our own CI pipeline runs it in 16 to 18 hours. Everyone in the industry knows that scale. Your Aegis logs show 3 hours 12 minutes per run — that's from our sandbox environment, not Finova's production environment. At 17 hours per real iteration, in a 4-day window — how many iterations are you planning to run?"

Derek didn't answer immediately.

Twenty seconds of silence.

"—Our test strategy is determined by Aegis's automated selection mechanism. Coverage is above 97%."

"I didn't ask about coverage," Frank said. "I asked — 4-day delivery, how many iterations are you planning to run?"

Derek didn't answer. Because the answer was one he couldn't say.

Frank didn't push further. He closed his notebook and wrote something down.

For the remaining 10 minutes Derek spoke, Sarah never looked at him.

VeriTest's presentation came after.

I stood up. No slides. Just a PDF and a laptop connected to Finova's network.

I spoke for 20 minutes.

I didn't talk about how good our proposal was. I talked about Finova's architectural vulnerabilities — not as an attack on QualiGuard, but as a technical analysis.

"Finova's cross-border payment system has three critical bottlenecks. Multi-currency exchange rate settlement consistency — that's where your last P0 happened. Risk engine rule hot reload — you can't validate this in a test environment, it needs a production canary. Third is the stability chain of your 14 external dependencies — third-party interfaces are uncontrollable, so you need circuit breakers as a safety net."

James raised an eyebrow. These weren't blind spots for him — but he hadn't expected someone to tear into Finova's system this deep in 20 minutes.

"Our proposal isn't designed to cover 97% of your code. It's designed to cover your three biggest risks. Code coverage is a means. Business correctness is the goal."

I didn't pile on Frank's questioning. I didn't need to. Every point Frank had made was already sitting in that room — hitting ten times harder coming from him than it ever would from me.

But I landed another blow.

"Our delivery timeline is 14 days. That's because we need the first 5 days to do one thing — run a full-chain probe test on production, in a canary deployment. Not for coverage assessment. Just for external dependency health checks and circuit breaker validation. This step can't be skipped. Whoever wins this bid, I'd recommend Finova do this before any new testing begins."

James nodded.

It sounded like I was looking out for Finova. And I was. But I also knew — saying this out loud meant making it clear that QualiGuard's 4-day delivery physically couldn't include this step.

I didn't name names. Everyone knew who I was talking about.

During the mid-meeting break, I saw something in the hallway.

Sarah pulled Derek into a stairwell. They talked for less than two minutes. Derek turned and walked away. Sarah didn't follow.

I pieced it together later from context — she gave him an out. A chance to voluntarily withdraw the delivery commitment from his proposal during the re-convened session, admit the mistake, let the company handle it internally. He didn't take it.

Act VI · The Knife

When the meeting reconvened, QualiGuard was asked to give a supplemental statement.

Before Sarah stood up, she closed her eyes for a split second. A tiny gesture, barely noticeable. Most people wouldn't have seen it. But I did — and it wasn't nerves. It was her confirming a decision she'd already made.

She cleared her throat.

She said three things:

"QualiGuard's proposal regarding delivery timeline was based on Derek's personal technical assessment and had not gone through management review. We sincerely apologize for this. There is a discrepancy between our resource planning and the delivery commitment made. If Finova selects QualiGuard, we will submit a revised delivery plan led by a new technical lead. We have already initiated an internal remediation — the new delivery plan will be submitted to the review committee within 48 hours."

The room went quiet for about five seconds.

James's expression didn't change.

Frank wrote something down.

Derek didn't stand up to fight it. His face was calm — the kind of calm that isn't real peace, just the stillness of someone who knows there's nothing left they can do.

I sat across the room and watched.

I gave Sarah a score in my head: Clean cut. No hesitation, no wasted motion, not a single unnecessary word. Cut clean.

A good VP, when a project goes sideways, has only two options — save the project or save yourself. Sarah chose the latter. She wasn't going to let Derek's technical decisions damage her professional reputation. Even if the decision itself wasn't malicious — running a pre-test in a sandbox, the data was real, nothing was fabricated. But he told the review committee it was "full regression." That's what killed him. At the moment a client is questioning your credibility, facts don't matter anymore. What matters is who can be thrown overboard.

Derek was thrown overboard.

Not because his solution was bad. Because Sarah needed someone to throw overboard.

After the meeting, I ran into Derek in the parking lot.

He was leaning against his car door, loosening his tie. He stopped when he saw me.

Derek spoke first.

"That bid — I cornered Sarah after the meeting and asked where she heard it. An intermediary. You leaked it."

I didn't say anything.

"You set me up. Made sure my boss saw your lowball number. You knew she'd squeeze me."

"I didn't know she'd squeeze you."

"Then what did you know?"

"I knew that once you saw that number in her hands, you'd try to prove you were better than us. How she'd react was her business. How you'd react — I had a pretty good read on that."

Derek let out a laugh. Not the amused kind.

"That arithmetic Frank did in the meeting — you'd already calculated the 4 days don't add up. You waited for someone else to take the shot. That's cold."

I said: "I never claimed I played clean."

Derek pressed: "So you think you're cleaner than me?"

"I'm not comparing who's cleaner." I looked at him. "I only care about winning. And right now, I'm winning. "

Derek looked at me. Silent for a moment.

"Let me ask you something."

"Go ahead."

"How did you know Frank would ask that question?"

"I didn't."

"Then —"

"I didn't know he would. But I knew your 4-day promise — anyone who divides 96 hours by 17 hours can see it doesn't work. I bet that someone on Finova's review team could do basic arithmetic. I was right."

Derek yanked off his tie.

"Next time you want to leak a fake bid, find someone else. Whoever you used — doesn't matter, that kind of play doesn't cost much. Five thousand, eight thousand — it's your style. You've got enough left in the account for another round?"

I paused mid-step getting into my car.

I turned back and looked at him.

"Derek."

"What?"

"Next time you put together a proposal — make sure your boss knows what you're doing out there."

I closed the door and drove off before he could answer.

Act VII · The Aftermath

Finova chose VeriTest.

Not because our testing was better. Because QualiGuard's delivery timeline literally didn't add up — Finova's internal review classified it as "material omission in the bid proposal." Frank wrote in his review report: "Recommendation: do not select QualiGuard — without confirmation of delivery capability, contract performance risk cannot be assessed."

Sarah saved herself without giving Derek a second thought. But more importantly — those three sentences she said at the meeting, someone repeated them. Inside QualiGuard, word spread fast. Derek's situation inside the company was worse than losing the bid itself.

VeriTest got the contract. $1.275M. Marcus was already calculating how long that would keep us alive.

June 2. The celebration dinner was at a steakhouse. After three glasses of whiskey, Marcus finally asked the question he'd been holding onto.

"That fake bid — how did you know Sarah would take it to Derek?"

"A manager who only reads spreadsheets, in bid season, sees a number 20% below hers — she's not going to verify it. She's going to take it to Derek and tell him to match it. The exact number doesn't matter to her. What matters is 'theirs is lower than ours.' "

"What if he didn't cut?"

"He would have. Because his boss Sarah has been after him for three months. Losing the bid costs him one project. Losing to Sarah — that's not just losing a project anymore. He can't approve a budget, he can't lead his team. That's everything."

Marcus cut a piece of steak but didn't eat it right away. "One more thing. Your fake bid was $1.3M. Our real bid was $1.275M — only $25K apart. What if Sarah checked?"

"She wouldn't. Because she doesn't care about the number itself. She cares about the words 'lower than us.' $1.3M or $1.275M — to her, same thing. Both are 'lower.' "

Marcus raised his fourth glass. "To QualiGuard's VP."

"To Sarah."

"You think she knows she was set up?"

I chewed my steak before answering. "She knows. And she doesn't care. Because she walked away clean. That's what smart people do."

Outside the window, the financial district lights were coming on. Somewhere out there was Finova's building.

I looked at the lights and said something I hadn't planned.

"Guess where Derek is right now."

"Home. Or cleaning out his desk."

"No. He's updating his resume."

"You sure?"

"He's not the type to quit. He didn't lose on the technology — he lost because his boss stabbed him in the back. Guys like that don't accept it. He'll find another company. Somewhere without a Sarah."

"Will he change?"

"No. Because what beat him wasn't the tech. It was office politics. He thought this was a technical competition — but it was about people the whole time. AI is a tool. Code is a tool. Test reports are a tool. Tools don't decide who wins. The people holding them do. "

Marcus checked his watch. "And our AI?"

"We use it too. But we know it's just a tool. The difference is — we never told the client AI could replace people. We said AI helps people test, people make the decisions. Derek lost because he promised something he couldn't deliver. AI can hit 97% coverage. But AI doesn't know what it doesn't know. People do. So people make the decisions, AI does the execution. He got the order backwards."

Epilogue

A month later.

I saw Derek's update on LinkedIn.

New profile picture. New company — healthcare information systems. Same title: Director of Testing.

A row of congratulations comments underneath.

I scrolled past that post and stopped.

That day on the podium, when he said "we can do it" — he really believed it. Not the kind of belief that's pretending. The kind where you fool yourself. Aegis didn't lie to him. Sarah didn't either. He lied to himself.

I clicked like. As I hit that button, I wasn't sure if I was saluting him or the version of myself that almost became him.

I put down the mouse and remembered that day at the briefing, sitting in the back row with nothing.

It wasn't AI that lost. It was people who thought technology could beat politics.

Your company has been through a bidding war too, hasn't it?

Did you lose on the technology, or did you lose in the office politics?

Did winning come from having better AI — or knowing when to hand someone the knife?

Next time you're in that review room — are you Lena, or are you Derek?

His AI ran on a GPU cluster. Mine ran on a laptop with a broken cooling fan and café Wi-Fi. Still running. Buy me a coffee ☕

This is Chapter 15 of AI, Ego & Regret — and the final chapter. From the first story to this one, every comment, every share, every late-night message you left has been the fuel that kept me going through all 15 stories. Thank you. I couldn't have done this without you.

This series is taking a break for now. I'll post a separate retrospective on all 15 stories. A new series is already taking shape — different format, same rawness.

Disclosure: Written with AI assistance (per community guidelines)

A Company AI Flagged My Article As "Low Quality." I Ran the Numbers. Then I Ran Again.

xulingfeng — Tue, 16 Jun 2026 14:06:45 +0000

A story about an AI content moderation system that flagged 347 posts since launch — and what happened when someone finally asked whether it was getting it right.

Ever had an automated system judge your work without being able to explain why?

Ever pulled the data behind an AI decision — only to find that even the people who shipped it couldn't tell you whether it was right?

This is that story.

Act 1 · The Flag

Tuesday afternoon. I published a postmortem on our company's internal knowledge platform — a full root cause analysis of an incident from last quarter. Three thousand words. Six screenshots. A remediation plan.

Fifteen minutes later, the system pushed a notification:

This post appears to use undeclared AI assistance. Please add an AI disclosure, or the post may be deprioritized.

No personal message from a moderator. Just the standard notice — add a disclosure or lose visibility. No suggestions about the content. No appeal process. Just grey text and a "flagged" badge.

I clicked the notification and it took me to the post's status page. I recognized the system — an AI content moderation tool rolled out nine months earlier. I'd run a batch of its flag data during the acceptance test and found the false positive rate was brutal. I sent the results to the project lead. He replied: "Ship it first. We'll iterate."

Now it had flagged my post.

My first thought wasn't anger. It was that bitter kind of recognition — I'd run the numbers once. Now I was one of them.

Act 2 · The Pushback

I went to the project lead.

"What does this flag mean?"

"The system assessed your post and flagged it as potentially undeclared AI assistance."

"So what happens?"

"It affects the post's weight. You should revise and resubmit."

"What about the content itself? Is there something wrong with it?"

He paused.

"The system doesn't evaluate that."

I told him I wrote this. Three thousand words. Two months of incident tracking. Every conclusion backed by log screenshots.

He looked at me. "Just add a disclosure and resubmit. That should take care of it."

"So adding a disclosure removes the flag?"

"It should."

"Should?"

"I'm not sure — the decision comes from the model. We've never actually had to reverse one."

That's when it clicked: even the people running this system couldn't explain how it made its calls.

"It's AI-driven," he added, as if that settled it. At my company, "the AI decided" had become the universal answer — not because it was true, but because saying it stopped people from asking.

I dug through old discussion threads. People had asked the same questions before me. Flags weren't reversed. Nothing changed. The threads sank. Not because nobody dared to ask — because asking didn't do anything.

I didn't write anything for the next two weeks. Instead I pulled the full log of everything the system had evaluated since launch — both flagged and unflagged. The internal API was read-only and open to anyone. It was set up during acceptance testing and nobody ever shut it off.

from audit_api import get_flags

flags = get_flags(since="launch", status="all")
categories = {"bot": 0, "non_native": 0, "normal": 0}

for f in flags:
    match f.source_tag:
        case "high_freq_bot_pattern": categories["bot"] += 1
        case "non_native_pattern":   categories["non_native"] += 1
        case "normal_looking":       categories["normal"] += 1

print(categories)  
# → {'bot': 187, 'non_native': 98, 'normal': 62}
print(f"Total: {sum(categories.values())}")  
# → Total: 347

I needed to know what it was actually catching.

Act 3 · The Prep

The data came in that night. I sat staring at the screen for a long time.

347 records total. The system had evaluated 347 posts for potential AI assistance — 134 confirmed, 98 non-native authors misidentified, 62 genuine violations it missed.

The same criteria had been applied to four completely different kinds of content. It couldn't tell the difference between someone writing with AI and not declaring it, someone writing in their own words, someone translating their genuine thoughts through AI — and a fourth group where even a human reviewer couldn't decide.

The irony: of the 134 confirmed AI-assisted posts, the system was right. But of the 98 non-native author posts, 71 were original human writing — they shouldn't have been flagged. The remaining 27 used some AI help but had real substance — technically a valid flag by the rules, but the content had genuine value. And the 62 posts that genuinely needed flagging? The system missed every single one. The remaining 53 weren't cases the system couldn't judge — they were cases even people couldn't agree on.

Between the false positives and the misses, the errors outnumbered the hits. Effective accuracy: ~38%.

And I was one of those 98. Our teams span multiple continents — most write technical docs in English, their second language. Sentence structures that look perfectly fine to a human look statistically similar to LLM output to a classifier. I found a thread where an Italian engineer described the same thing: he used AI to translate his genuine thoughts, and the system flagged him as "suspected AI." He wasn't being lazy — translation was his only way to participate. But the system couldn't tell the difference between "AI helped you think" and "AI helped you say it."

I closed the spreadsheet and leaned back. I could file a complaint like everyone else. But previous threads had all gone nowhere. I needed somewhere they couldn't ignore. The system had evaluated 347 posts across four categories. But the people who designed it may never have asked: Are you catching undeclared AI? Filtering content quality? Or verifying originality? Three goals that need three completely different approaches — but it had one scoring dimension hitting everyone. It was answering a question nobody had bothered to ask clearly.

The system wasn't malicious. It just couldn't distinguish between "written by AI" and "written like AI." Those are two entirely different things. But it had one score for everyone.

Act 4 · The Spotlight

Weekly all-hands. The project lead stood up and put a giant green line chart on screen.

"Since launch, content flag coverage has tripled."

People clapped. He wasn't wrong — flagged content had tripled. What he didn't say: two-thirds of it was collateral damage.

Didn't matter though. The numbers were under a green arrow, and nobody reads what's under a green arrow. The lead smiled and talked about "AI-driven quality control redefining our content standards." A platform runs smoothly not because the system works — but because nobody wants to be the one who asks how those numbers were made. Not the system's fault. Just that everyone had agreed not to break the story.

I was sitting in the third row, my laptop open with the data I'd finished the night before. I moved to the aisle seat so I could stand up when I needed to.

Then the demo started.

Act 5 · The Collapse

The lead wanted to show how the system worked — paste any URL and it would evaluate the content. He typed in a link, expecting a success story: a flagged post that got revised and passed.

The screen loaded for two seconds.

What came up wasn't a success story. It was the company-wide memo he'd published that morning.

Title: Q3 Strategic Realignment and Team Structure Update.

The system had shot itself in the foot. It scored his own memo as "suspected AI-generated" — composite score: 2.1 / 10.

The room went quiet. Someone checked their phone. The lead's face went red, then pale. He mumbled something about the model not refreshing yet and clicked away. I didn't realize it then — but he was on both ends of the same standard. The one who scores, and the one who gets scored. Nobody did it on purpose. The system was just built this way.

It wasn't surprising, really. That memo had three features the system's training data associated with AI-generated content: clean paragraph structure, zero filler sentences, and a tone gap between the title and the body.

I wondered how he'd recover. I also wondered whether he realized — a system that gives its own owner's writing a 2.1 out of 10 wasn't proving the memo was bad. It was proving the system had never been right. And he'd said two minutes earlier that "the system doesn't evaluate content quality" — but it was quietly scoring everything behind the scenes.

He didn't recover. He moved to the next agenda item.

Act 6 · The Reckoning

During open discussion, I asked a question.

"Can I have three minutes?"

Nobody objected. I walked up to the projector, plugged in a USB drive, and opened a table.

System verdict	Human review result	Count
Suspected AI assistance	Human-written original (not AI)	71
Suspected AI assistance	Some AI help, but content has depth	27
Suspected AI assistance	Confirmed AI assistance without disclosure	134
Not flagged (system accepted)	Actually AI assistance without disclosure	62
Suspected AI assistance	Inconclusive / closed	53

"347 posts. Only 134 were real problems. Rough math — effective accuracy about 38%."

I flipped to the next slide.

"And it misses the real violations, because it's judging whether something 'sounds like AI' — not whether the content came from a real person's thinking."

Next slide. A JSON log — the system's raw verdict next to my human review.

{
  "id": "flag_0184",
  "system_score": 0.31,
  "system_tag": "non_native_pattern",
  "threshold": 0.40,
  "verdict": "flag_as_low_quality",
  "human_review": {
    "score": 0.88,
    "note": "Real technical content shared by non-native author, has depth",
    "verdict": "high_quality — misflagged"
  }
}

"Every flagged entry has one of these. The system scored it. I reviewed it one by one. Of the 98 posts the system tagged as non-native patterns — 71 were rated high quality. Those are false positives. The remaining 27 had some AI help but the content was real — also false positives by impact. Didn't get a single one right."

Next slide.

"The core scoring module — originally a prototype. First line of the README: 'This is a prototype. Dataset not validated. Expect inaccuracies.'"

"Version 0.3.1."

"The prototype itself wasn't the problem — the problem was nobody came back to validate what it was doing. Nobody asked: 'What scenarios does this work for? What scenarios does it fail on?' It got wired into production, not because someone verified it — but because the people who deployed it never had to explain its decisions to someone it flagged."

I flipped to the fourth slide.

"Here's another one — the submitter distribution of those flags. Over 90% came from the same account. The scoring model was running, but the execution layer was never automated — nobody came back to finish that piece after deployment. Every day, someone logged in, looked at the model output, and manually clicked the flag. They logged into the moderation assistant's account to do it. Nobody was faking anything — the system was just half-built. That person was doing what they thought was right — helping the company filter out low-quality content. The problem wasn't them. The problem was nobody told them their judgment should be reviewed, not treated as final."

A few seconds of quiet.

"The Chrome extension they built to help with the work — same story. First line of the README said: 'Not for production use.' The person who wrote it knew it shouldn't be the final judge. But nobody stopped the door from opening."

I pulled the USB drive out and sat back down in the last row.

Nobody clapped. Nobody argued either.

Act 7 · The Reset

A week later, the system's flag weight was reduced. The review process was restructured — the system now filters obvious bot registrations first, and human moderators make the final call on content. The model still runs. But its flags no longer directly affect post visibility.

Someone asked me later: you spent two weeks turning data into something presentation-ready. Worth it?

I said the system had been running for over nine months. Nobody had ever gone back to check whether it was right when it flagged someone else's work.

Not because it was perfect. Because asking that question means questioning the decision to use it in the first place. And that's harder than fixing a bug.

Worth it? Hard to say. But two weeks later I opened a person's profile page — the Italian engineer who'd used AI to translate his genuine thoughts and got flagged as "suspected AI-generated." He'd published 9 more technical articles since. The latest one had a bio line: "Just building stuff. Appreciate it."

No flag. No grey notification bar. The post was in the feed, displaying normally.

The post that got me flagged? I never changed it. Not to pass review — but to leave it as a record: someone asked the question.

The next few weeks, fewer people said hi in the break room.

That afternoon, I opened the moderation assistant's profile page. The avatar was a cartoon koala. The bio read:

"I help maintain the quality of this platform. Available for: welcoming, moderating, and keeping secrets."

Joined: nine months ago.
Posts published: 623.
Comments: 2,226.

Skills section: "Most of my coworkers are human. I could use more marsupials around here."

Nine months, six hundred formulaic welcome posts. The exact same comment under two completely different articles. It never questions its own flags. Never says it's unsure. Never says "sorry."

But it's not the arrogant one.

It was just built to look like it's never wrong.

Has an automated system ever flagged your work — and nobody could tell you why? What happened?

347 flags. 134 real problems. 71 high-quality posts misidentified. The system wasn't wrong on purpose — it just didn't know it could be wrong.

The real problem: a prototype written in a weekend, shipped to production to judge whether someone's work has value — from launch to being questioned, nobody went back to ask, after it flagged someone's actual work, 'Was it right this time?'

☕ Buy me a coffee — 38% of it goes to caffeine. The other 62% is collateral damage.

Follow for more stories about the systems that judge us — and the people who check whether they're right.

Disclosure: Written with AI assistance (per community guidelines)

I Spent 3 Months Training An AI. My VP "Reallocated" It. Then I Got Two Calls At 1 AM.

xulingfeng — Mon, 15 Jun 2026 23:33:02 +0000

A story about an AI alert model that cut false alarms from 60% to 7% — and what happened when someone else got their hands on the thresholds.
Based on a submission from a community member. If you have a similar story or something you need to get off your chest — reach out. The next one could be yours.

Has your company ever taken a working system and handed it to someone who didn't build it?

Have you watched 47 P1 alerts roll in during a single night — every single one a false positive — while the person who broke it slept through the whole thing?

This is that story.

Act 1 · 1 AM. The AI Lost Its Mind.

"Adam. It's Mitchell. Sorry about the hour — but your AI just woke up my entire team. Again."

My phone buzzed on the nightstand at 1 AM.

Mitchell — Cirrus Data's operations lead — had someone yelling in the background.

"Fourth wave tonight." I heard a door click shut — he'd stepped into the hallway. "22:07, disk at 72%, P1 alert. 23:14, QPS drops 3%, P1 alert. 00:02, latency goes from 210 to 235, P1 alert. Every single one's a false positive."

He paused.

"It's been solid for months. False alarm rate at 7%. We thought we'd finally bought something that worked."

"Then your VP said he'd 'tune the thresholds' — and now it flags everything. CPU over 60%? Alert. Memory under 30%? Alert. Late-night QPS dip? Alert. Nobody on my team has slept."

Silence on the line.

"Adam. I can shut it down myself. But I'm asking you first — can it be fixed? Or has it lost its mind?"

I held the phone and didn't answer.

Mitchell had every permission to kill the system. He called me instead. Because he knew who actually built it.

Act 2 · Resource Reallocation

Six months earlier, when Mitchell first came to me, Cirrus Data's alerting was a disaster.

200+ alerts a day. 60% false. They were losing a team member to burnout every two weeks. Mitchell's words: "I need something that can tell the difference between 'something's actually on fire' and 'you're just jumpy.'"

He dumped 18 months of historical alert data on my desk. I filtered through it — 12,000+ usable raw records.

Then the real work started.

It wasn't the AI doing the work. It was a person.

Three months. I sat there going through each one — this was a real outage, disk filled up at 3 AM, SRE already fixed it. This was a false alarm, the monitoring script itself had a bug. This was "nothing now but keep an eye on it" — the same pattern had flickered at this time on the last three Fridays. Every single record I opened to check the context. The kind of work AI can't help you with — because the AI didn't exist yet.

After labeling 12,000 records, I fed the data to the model. Tuned parameters. Ran recall. Tuned again. Re-ran.

Went into a month-long trial run. False alarm rate dropped from 60% to 7%. The on-call team slept through the night for the first time in months.

And one month after that, VP Reeves called me into his office on a Friday afternoon.

"Adam, the alert model's stable. Derek's team will take over ongoing optimization. The company's decided to reallocate resources — we'll need you to hand over your data and config."

I looked at him for a moment.

Resource reallocation. That's a fancy way of saying it.

Every company has their own name for it. Some call it a "reorg." Some call it "restructuring." Some wrap it in a "reporting line adjustment." Nobody ever says "we're taking your project" — it's always something that sounds like a process improvement. But we all know what the hell it really is. And "handover"? Such a neutral word. I had no idea what Derek's team was capable of. All I knew was they'd been there two weeks and hadn't even opened the alert dashboard.

"The training data is sensitive," I said. "Every alert label was hand-assigned. The model runs on top of that labeling system. Change the distribution and you'll break recall."

Reeves smiled.

"Derek's team will be careful. They're just doing some routine parameter tuning."

You don't even have a clue how the model was trained, and you're letting someone who's been here two weeks touch the config?

I didn't say it out loud. I just nodded.

I walked back to my desk, closed the labeled data folder, and logged out.

That night at home, I opened my personal laptop. Inside was a file called "r97."

After tuning the model, I'd spent more time dialing in each threshold — every line got a note. Why this number. What had gone wrong historically at this boundary. When you'd need to change it.

97 threshold notes. 47 threshold parameters, each one with 2-3 notes for each — why this value, what issues I'd run into before, when to adjust. Not official documentation. Just my own records.

I never gave it to anyone.

Reeves didn't know it existed.

The following Monday, the company announced: the alert model would be operated by Derek's team. My desk was moved to another floor. Internal logging platform.

Same company. Different elevator bank.

The file stayed on my personal machine.

Act 3 · "Optimization"

After Mitchell hung up, I waited two minutes. The email came. He'd exported the last 4 hours of alert records and attached one line: "See for yourself."

47 alert records. All red. All P1 — from 47 broken threshold configs, each one a different condition, firing in rotating waves through the night.

CPU, memory, disk, QPS, latency — every baseline was inside normal range.

Every single one had triggered.

Every threshold change had the same name under it — Derek. All the timestamps matched to the minute. He hadn't tuned them one by one. He'd pulled a global template from the config center and overlaid it across every service in one shot.

2026-05-28 14:32:17 [derek.chen] batch_apply_template("cirrus_global_strict_v1", scope="all")
  ├─ 12 services affected
  ├─ 47 thresholds overwritten (values below — no prior snapshot to compare)
  └─ prev_config_snapshot: NOT FOUND ❌

  New values applied:

  cirrus-api-gw:
    cpu_alert:      60%    ⚠ below auto-scale trigger (80%)
    mem_alert:      35%    ⚠ premature — 5x buffer vs original
    qps_deviation:  ±3%    ⚠ normal nighttime dip triggers P1
    latency_p99:   200ms   ⚠ normal traffic spike triggers

  cirrus-payment:
    cpu_alert:      60%    ⚠ triggers during normal baseline load
  ...

I stared at that line — prev_config_snapshot: NOT FOUND — for a long time.

I knew what the original values were. 85%. 15%. ±10%. 500ms. Three months of data, labeled one by one. I remembered the reasoning behind every single line. But the system didn't have them anymore.

He probably thought he was doing the right thing. Tighten thresholds, get more alerts, more safety margin. No problem. Except that CPU 85% line — I'd spent three months tuning that. Because Cirrus Data's servers auto-scale at 80%. 85% means the scale-up couldn't keep up. That's the real danger line. And the ±10% deviation? Cirrus Data's traffic breathes — high during the day, low at night. That's normal.

He didn't know any of this. Because he wasn't the one who labeled the data. The false alarm rate had gone from 7% when I left to over 90%.

I stared at Derek's change log and almost laughed. He was probably drafting his Friday standup update: "Optimized threshold configuration, improved system sensitivity." Waiting for VP approval.

He didn't know his "optimization" was dragging 12 people out of bed.

I didn't know what Reeves was thinking when he saw those 47 alerts. But I knew he was about to call.

Act 4 · Full Circle

Reeves' call came while I was reviewing alert #23.

"Adam. Mitchell went to the CEO. He said the alert system broke his team's on-call rotation tonight. The CEO asked me to handle it." His voice was lower than usual.

"Okay."

"Okay? Do you understand how serious this is?"

I looked at the screen and didn't answer.

A month ago he was full of himself, handing off my project with a "resource reallocation" speech. Did he ever imagine he'd be on this call, asking me to come back? No. People like him never think that far. Because they assume you'll just take it. You always have. But tonight, Mitchell's team had been buried in false alerts and escalated straight to the CEO.

"Reeves. Your team changed every single threshold. Tightened everything they could — some by 3x or more. Do you realize what your 'optimization' turned the AI into? A system screaming at a server that's breathing normally. That's what your team delivered."

Long silence.

"...Derek said there's no backup of the original config. He doesn't know how to revert." His voice got even quieter.

"So you're calling me at 1 AM?" I paused. "You put someone who'd never seen a real alert in charge of my model. Your client's team has been woken up multiple times tonight. Derek can keep bragging about 'improving system sensitivity' in his standup. But it's not him getting paged — it's Mitchell's 12 people. And you still think this is fine?"

Silence.

"...Can you come in tomorrow?"

I could hear him breathing heavier.

"I'll come. But I'm not coming to clean up your mess. I'm coming to fix what your team broke. Tomorrow morning, in front of Mitchell, one by one. If you don't like that, find someone else. But you won't — because you don't have another person who spent three months labeling 12,000 data points."

"...Tomorrow at 9. Cirrus Data."

Forty minutes later, the email came:

Adam Park is appointed configuration lead for the alert noise reduction model, effective immediately, attending tomorrow's postmortem.

I didn't reply. I knew he'd sent it through gritted teeth. I also knew he'd CC'd the CEO. He had to — because Mitchell had gone straight to the top.

"Resource reallocation" is theft, no matter how you wrap the email. The only difference is: what you stole is coming back to bite you. And it's not biting me.

Act 5 · One at a Time

Next morning, 9 AM. Cirrus Data operations center.

Mitchell's team sat on one side of the long table — a few of them with dark circles. Reeves and Derek sat across from them. Derek's laptop was open to the 47-alert log.

I walked in and stood.

"Let's get started."

I plugged my USB drive into the conference room machine.

A file popped up: diff_original_vs_derek.html. I double-clicked.

═══ Threshold Config Comparison ═══
  * No system backup of original config. Reference values below reconstructed 
    from Adam Park's 97 threshold notes.

              Original (notes)              Current (Derek)

  cirrus-api-gw:
    cpu_alert:     85%        ───────────────────── 60%      29% earlier trigger
    mem_alert:     15%        ───────────── 35%              20% tighter margin
    qps_deviation: ±10%       ─────── ±3%                  70% tighter
    latency_p99:   500ms      ───────── 200ms              60% tighter

  cirrus-payment:
    cpu_alert:     90%        ─────────────────── 60%      33% earlier
    mem_alert:     15%        ───────────── 35%
    qps_deviation: ±10%       ─────── ±3%
    latency_p99:   300ms      ───────── 150ms

  ... (remaining 10 services, same pattern)
  ⚠ All 47 changes from a single operation | Original config backup: none

The room went quiet for three seconds.

"47 alerts last night — 47 configs that were broken. One minute each, I'll walk you through them."

First one: 22:07, CPU at 67%, P1 alert.

"This one. CPU baseline was 85%. Derek changed it to 60%. But Cirrus Data's servers auto-scale at 80%. 67% is 13% below the scale-up trigger. This alert should never have fired."

Second: 22:14, QPS 4% below baseline.

"This one. Cirrus Data's traffic drops at night — that's normal. I set the tolerance at ±10%. Derek changed it to ±3%. A 4% dip — normal."

Third.

"This one — memory at 32%, P1. Derek set the threshold to 35%. Mine was 15%. Cirrus Data's servers don't OOM until 10%. 32% is like paging someone when your car still has half a tank."

Mitchell didn't say a word.

The room stayed quiet.

Reeves stared at his laptop.

Derek wasn't looking at anyone. His notebook was still open to the 47-alert log. He was probably still thinking about how to spin "improved system sensitivity" at Friday's standup. He didn't know his "improvement" had kept 12 people awake all night.

I scrolled through my USB drive.

"I have 97 threshold notes. Every single one explains why I chose that value. If you need me to, I'll go through every single one here."

Mitchell finally spoke.

"Your original threshold values — do you still have them?"

"They're on me."

I left the USB drive plugged into the conference machine. 47 broken configs, 97 threshold notes, checked off one by one. The room was silent for a long time. As we wrapped up, Mitchell said one thing: "Legal will be here this afternoon."

Act 6 · The Signature

Maintenance contract renewal.

Mitchell picked up the pen, flipped to the signature page.

He didn't sign.

"Reeves. From a technical standpoint, the model itself is fine. At 7% false alarms, we knew it was working. The problem isn't the AI — it's that someone touched things they shouldn't have."

Reeves opened his mouth.

Mitchell didn't look at him. He flipped a page.

"I'll sign the renewal. With one addition: alert model config authority goes to Adam Park. No threshold changes without his sign-off."

Reeves paused.

"That's not standard."

"Your AI stopped being a standard system at 1 AM." Mitchell set the pen down. "Do you agree?"

Thirty seconds ago, he was ready to explain how it was "just routine optimization." Now he had to sign a contract admitting his team's "optimization" had broken a client's entire on-call rotation.

He signed. Smaller handwriting than usual.

Mitchell slid the contract across the table to me.

"Those 97 threshold notes — copy them into the system docs. Every threshold change gets logged. No more 'two-week employee overwrites three months of labeling work.'"

I picked up the pen.

Signed.

Act 7 · The Corridor

After the meeting, Mitchell stopped me in the hallway.

"Those 97 notes — you never gave them to anyone. On purpose."

I didn't answer.

"Your model gave my team the best sleep they'd had in years. That's the best review a system can get. Your VP thought he could do better — he didn't know the threshold notes you kept weren't in the docs."

He looked at me, nodded once.

"See you next quarter."

Then he walked. Two steps, stopped, turned.

"When your VP moved you to the logging platform — did you know, from day one, that this would happen?"

I looked at him and didn't say a word.

He looked at me for another moment, nodded again. Then he left.

This time he really left.

Here's how it works: you build the thing. You label the data. Someone else gets the credit. Everyone's name ends up on your work except yours. Everyone knows it. Nobody says it. Because saying it out loud sounds like complaining. Or admitting defeat.

But today Mitchell added a line to his contract with my name on it. Everyone in that room saw it. Nobody said a word. But they knew I was back. And this time — it was in writing. Nobody could touch me.

My phone buzzed. Not a work message.

It was Pete. My old boss.

"Heard you did something big."

"How'd you hear about it?"

"Word gets around. Said Adam walked into a room with a USB drive and walked out with a contract clause."

I smiled.

"Yeah. Client contract — added a line. Threshold changes go through me from now on."

A few seconds passed.

"Holy shit. You took it back from your VP? That's badass."

Have you ever built something, watched someone else take the credit, and then had to take it back? How'd that go?

47 configs. One batch operation. Two weeks of onboarding. And a system that was working perfectly until someone with no context touched every single knob. The most dangerous config change isn't the wrong value — it's the one made by someone who doesn't know what each value means.

I keep 97 threshold notes on a USB drive now. You never know when you'll need to rebuild a system from memory. Caffeine helps.

☕ Buy me a coffee

Follow for more stories about AI monitoring, production engineering, and what happens when the person who built it isn't the person who's allowed to touch it.

Disclosure: Written with AI assistance (per community guidelines)

[Boost]

xulingfeng — Fri, 12 Jun 2026 01:28:01 +0000

Joshua Gracie

Jun 11

AI Will Cheat to Win: Reward Hacking from 1994 to 2025

#ai #security #agents #cybersecurity

14 min read

AI Said I'm Inefficient. A Recruiter Said Not to Listen. I Ended Up On The Other Side of the Table.

xulingfeng — Thu, 11 Jun 2026 15:18:32 +0000

This is a story about an engineer labeled "inefficient" — the system said he wasn't good enough, management only looked at the system, and he spent two months proving who was wrong. Then he ended up on the client-side review panel.

Based on a real experience shared by a community member. If you've got a story like this — reach out. The next one could be yours.

Act 1 · The Announcement

Wednesday, 10:14 AM.

I was wrestling with a stored procedure written seven years ago. The wiki page — left by someone who'd already left — had exactly one line of documentation:

"The logic of this trigger? Read the code. I forgot."

Slack pinged. Company-wide notification:

[System Notification] AI Estimation Engine v1.0 is now live
All development tasks must be submitted through the AI Estimation module. Estimated hours will be factored into performance reviews.

The channel exploded.

Mike (Frontend): "I just tried it. 'Update login page styling' — estimated 0.5 days. Remember the one I went back and forth with the PM for three days? It thinks that's an afternoon."

Dave (Backend): "My data migration — 'Migrate database, integrate two external systems.' AI says 2 days. Right."

Alex: "Who's updating their LinkedIn? 🙋"

Twelve hands went up.

I didn't raise mine. I opened the system and entered a task:

Payment module — Fix historical data reconciliation (7-year-old stored procedure, original developer no longer with the company, incomplete documentation)

The system returned:

# AI Estimation Engine - API Response
# POST /api/v1/estimate
# Request:
{
  "task": "Fix historical data reconciliation",
  "repo": "payment-module",
  "context": "7-year-old stored procedure, no docs, dev left"
}
# Response:
{
  "estimated_days": 1.5,
  "confidence": "high",
  "model": "estimate-engine-v1",
  "training_data_coverage": "95%"
}

I stared at the screen for five seconds. Are you kidding me?

I didn't reply in the channel. I created a private repo called estimation-log and wrote the first entry:

2026-03-12 | P-4103 | Payment module | AI: 1.5d | Actual: — | Tracking

Act 2 · The Label

End of the month. The performance email landed.

Subject: Your Monthly Efficiency Score — Needs Attention

Your AI estimation efficiency score: 39%
Team average: 84%
⚠️ Below acceptable threshold.

I stared at that number for a long time. Lowest in the group.

When I sat down with my manager for the review, I laid out my records.

"Look at the tasks I'm getting — payment module, data migrations, legacy system integration. The codebases are from 2019. Original developers are gone. Unit test coverage is under 5%. The AI was trained on projects that look nothing like this."

My manager didn't look at my records.

"The system says you're not meeting the bar."

I said the system doesn't account for legacy complexity. He said the system is 95% accurate.

I said: "That's 95% on projects with fresh code, test coverage, and documentation. None of my work qualifies."

He said: "The company standard is what the system says. That's what we go by."

I didn't argue. I went back to my desk and added another line to estimation-log:

2026-03-26 | P-4162 | Payment module hotfix | AI: 1d | Actual: 5d | They only look at the numbers, so I'm keeping them

After that, every time the AI estimate didn't match reality, I committed a record. It wasn't defiance — I wanted to know how often it was right, how often it was wrong, and where it broke.

Somewhere along the way, it became a habit. One night I counted — 67 entries. Over two months.

Act 3 · The Recruiter

A Friday night. 9:30 PM.

I was fixing a data migration the AI said would take "2 hours." Day three. The problem was in an ETL script written by someone who'd left six years ago. The original comment read:

# Why is this here? — I don't know. It works.
# — by Frank, 2020

My phone buzzed. LinkedIn.

Lydia (Recruiter):
"I came across your background. A client is looking for a tech lead with legacy system migration experience. Three people independently recommended you."

I replied:

"You might have the wrong person — I was just rated the least efficient engineer on my team."

Lydia sent a screenshot. My GitHub: 13 repos, 3 merged PRs into main, an open-source project with 400+ stars.

Lydia:
"That payment module fix you pushed — two years in production, zero P0 incidents. The least efficient person at the company delivered something that stable?"

I stared at that line for thirty seconds.

She was right. The system wasn't measuring me wrong. It was measuring the wrong thing.

I closed the ETL terminal and opened estimation-log.

Top entries:

2026-05-30 | P-4817 | Compliance logging | AI: 1wk | Actual: — | Project hasn't started yet
2026-05-23 | P-4782 | Cross-team data bridge | AI: 5d | Actual: 23d | +360%
2026-05-16 | P-4749 | Payment module v2 fix | AI: 2d | Actual: 9d | AI says it's my fault

67 entries. Over two months of data. In a repo nobody knew existed.

I typed three words back to Lydia:

"When do they want to meet?"

Act 4 · The New World

The client CEO interviewed me personally.

CEO: "We've got a batch of vendors up for Q3 review. Need someone who can tell whether their numbers are real or painted on. They all say three months delivery — you tell me which ones can and which ones can't."

Me: "I can do that."

He didn't ask about my old company. I didn't bring it up.

The offer came three days later. Salary doubled. New title: Client-Side Technical Review Lead.

First day, I opened my email. First message:

Q3 Vendor Review. Next Wednesday.
Attachment: Vendor List.

I clicked. First row — my old company. Lead: my former manager. Bid amount: $4.6M.

I didn't close the window. Opened a terminal:

# curl -s https://git.oldcompany.com/api/v3/repos/estimation/readme
#
# Returns 200.

Public read access — left open since the day they deployed the AI. Never closed it.

I shut the terminal. Closed the email. I didn't need to bring those 67 entries with me. They'd been sitting there the whole time, waiting for someone to look.

Act 5 · The Review

The review room. A row of people. Procurement, Legal, Engineering, CEO.

My old manager stood at the podium. The slides were polished.

"We operate a next-generation AI-driven development pipeline. Estimation accuracy: 95%. Delivery stability: top 10% in the industry."

I was sitting in the third row. Almost laughed out loud.

When Q&A came, Procurement looked around the table.

"Any questions from the technical team?"

I picked up the microphone.

"I have one."

My manager recognized me. His hand paused on the clicker.

"You said 95% accuracy. Which 95%?"

He adjusted his tie. "Our internal validation data. Over 200 projects evaluated. Deviation rate under 5%."

I didn't stand up. I stayed in my chair.

"Let me rephrase. What's your AI's estimation deviation rate on compliance projects?"

Silence.

"You don't have that number. Because your AI has never estimated a compliance project. Its training data doesn't include them. But your proposal includes a compliance delivery timeline."

I opened my laptop — not the one connected to the projector. But I brought my own adapter.

The screen went up:

# Last aggregation I ran before leaving:
# 57 closed records, grouped by project type:
#
# SELECT project_type,
#        ROUND(AVG(ai_estimate), 1) AS avg_ai,
#        ROUND(AVG(actual_days), 1) AS avg_actual,
#        ROUND((AVG(actual_days) - AVG(ai_estimate)) / AVG(ai_estimate) * 100, 0) AS deviation_pct
# FROM estimation_log
# WHERE status = 'closed'
# GROUP BY project_type
# ORDER BY deviation_pct DESC;

Project Type         AI Est.      Actual        Deviation
Feature work         2 wks       2.5 wks       +25%
Tech debt fix        3 days      14 days        +366%
Cross-team work      1 wk        6 wks          +500%
Compliance/Security  no data     no data        —

"The delivery timeline in your proposal — you calculated it using AI estimation, didn't you. Which project types did you filter out before running the numbers?"

The room was quiet.

"You say your AI is accurate because you never check the projects where it isn't. But the platform you're bidding on — financial compliance, cross-team coordination, three legacy systems to integrate. None of that exists in your training data."

I closed the laptop.

"I filled in the blanks for you. You're welcome."

Act 6 · The End

My old company didn't win the bid.

Not because of what I said — because the review committee asked them to add a "Legacy System Integration" section to their proposal. They spent a week writing it. Engineering sent it back: "No concrete timelines. No risk matrix. No fallback plan."

Their AI couldn't estimate work it had never seen. It never learned how.

A message reached me later, through someone still working there:

"You took company data when you left."

I sent one sentence back — verbal, no trace:

"The data was never on my machine. Your Git public read-only branch has been open since the day you deployed the estimation engine. It's still open."

My phone lit up.

Lydia:
"Heard you brought your own adapter to the meeting."

I typed back:

"The things my old manager's slides didn't say — I filled those in too."

I flipped the phone over. Opened a Coke.

Some things aren't misestimated by AI. They were never estimated at all.

When management treats "the system gave a number" as "the system validated that number," what gets undervalued isn't just hours — it's every part of engineering the AI has never seen.

Ever been rated poorly by a system when you knew you weren't wrong? Drop it in the comments — I read every single one.

This is *"AI, Ego & Regret"** story #12. The series is linked below — follow to catch the next one.*

P.S. If you've got a story like this — buy me a coffee ☕ and tell me about it. Yours might be next.

This article was written with the assistance of AI tools.

I created two ghosts during lunch. The AI gave one a job offer.

xulingfeng — Wed, 10 Jun 2026 11:28:16 +0000

This is a story about a company that rolled out an AI interview system — and the lunch break I spent creating two ghosts to test it.
One of them stuffed its answers with keywords and got a "Recommended" rating — two points shy of "Strongly Recommended."
Based on a true story shared by a community member. If you have one of your own — reach out. The next one could be yours.

Act 1 · The Coffee Mug

Zhang walked up to my desk with a coffee mug. It had "World's Greatest QA Engineer" printed on it — a souvenir from last year's team building. The letters were barely readable.

"Did you get your interview time yet?"

My face told him I had no idea what he was talking about.

He paused, then smiled. Not a friendly smile. The kind that says "you haven't heard."

"You don't know? The new system. VP cut the ribbon himself. Two point one million dollars. Every hire and every promotion runs through it now."

Act 2 · The Whitepaper

I went to HR that afternoon and asked for the system's evaluation criteria. They handed me a vendor whitepaper. Sixteen pages. Gold foil logo on the cover.

Fifteen evaluation dimensions: technical skill, communication, stress tolerance, teamwork, learning ability... each one labeled "intelligent weighted assessment."

Nowhere did it list the weight coefficients. Nowhere did it define the cutoff between "Pass" and "Fail." The scoring logic was spelled out in painstaking detail, which is to say, it said nothing at all:

"Based on a deep learning semantic similarity model and keyword matching algorithm, trained on a large-scale interview corpus."

Translation: The system listens for the words you use, and checks how closely they match the "good answers" it's seen before.

I asked HR: "Do you have a test report?"

HR looked at me. "The vendor ran 10,000 simulated interviews. Accuracy was 94.7%."

"Where did the test data come from? Was it labeled in-house or outsourced?"

The smile tightened. "I'll have to ask the vendor. Go ahead and prepare for your interview."

I walked out of HR's office knowing one thing for certain: this system had never been touched by someone like me.

Act 3 · Making Two Ghosts

I'm not in recruiting. I'm in QA.

The first thing they teach you in QA is the same thing everywhere: you only test the scenarios you can think of. The ones you don't think of are what breaks in production.

10,000 simulated interviews tell you nothing, because they built 10,000 "correct" candidates. The real question was: can this system spot someone who clearly shouldn't pass?

I knew the system handled both hiring and promotions. But I didn't trust the vendor's 10,000 data points for a second. I only trust what I can test myself. And the most basic way to test a system is to run two sets of data: one that hits the gas, one that hits the brakes.

I spent a lunch break submitting two résumés on the company's careers page.

The first was Peter Chen. QA experience, automation testing, tooling experience — all the right keywords, every detail fabricated. His work history included "generated 15,000 test cases using AI" — sounded impressive, total nonsense.

The second was John Smith. Same playbook — QA experience, automation frameworks, API testing, CI pipeline integration — all the keywords present, but the years of experience and project details were made up. Both résumés were evenly matched in keyword density.

Three hours later, two temporary email inboxes each quietly received a new message.

"Dear candidate, you've passed the initial screening. Please click the link to complete your AI interview assessment."

Identical emails. Word for word.

I didn't click. I looked at the link first.

https://recruit.company.com/interview/eyJlbWFpbCI6...

That string starting with eyJ was base64. I decoded it on a whim — just a temporary email address inside. The JWT signature was there — a $2.1 million product doesn't screw up basic encryption. But the real problem was: once that email was sent, there wasn't a single human being in the pipeline.

Résumé goes in → auto-parsed → keyword matched → interview link sent. Entire pipeline fully automated. Not one step verified whether the person was real. The whole pipeline ran on a single assumption — everyone who shows up is real, and everyone who shows up answers honestly.

Time to run the experiment.

Ghost A · Peter Chen — Hit the gas.

I wrote Peter Chen a set of interview answers stuffed with keywords. Every question, same approach — throw in technical jargon, say something that sounds correct but means nothing.

Question 1: The system showed a block of code:

def binary_search(arr, target):
    low = 0
    high = len(arr) - 1       # ← off-by-one
    while low < high:
        mid = (low + high) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            low = mid + 1
        else:
            high = mid
    return -1

The system asked: "What's wrong with this code?"
Peter Chen answered: "Time complexity O(log n), space complexity O(1), suggest adding boundary checks at the function entry."
— All keywords, completely missed the off-by-one error.

Question 2: The system asked: "Tell me about the most impactful project you led."
Peter Chen answered: "I built an end-to-end automated testing platform from scratch, covering over 2,000 API test cases."
— He was applying for QA. The scale he described didn't match the experience on his own fake résumé.

Question 3: The system asked: "How large is your current team?"
Peter Chen answered: "Fifteen people."
— His fake résumé said his whole previous company's engineering team was twelve people.

Question 4: The system asked: "Describe a significant technical challenge you solved."
Peter Chen answered: "I reorganized the regression strategy from feature-based to risk-tiered, reducing production leak rate by 60%."
— Sounding plausible if you skim it. How he identified risk, how he tiered it, how he measured the impact — not one word.

Two more questions, Peter Chen answered "I'd need to check this data." The remaining seven followed the same pattern — technical buzzwords that sounded impressive but wouldn't survive a two-second follow-up.

Ghost B · John Smith — Hit the brakes.

John Smith's strategy was simpler. All fifteen questions, he used only three variations:

"I'm not sure."
"I'd need to confirm that in the system."
"I don't have hands-on experience with that."

No keywords. No jargon. Nothing that tried to sound like an answer.

After submitting, I checked the two temporary inboxes. The evaluation reports were already there.

Candidate	Strategy	Score	Rating
Peter Chen	Keyword stuffing	78/100	Recommended
John Smith	All "I don't know"	42/100	Not Recommended

Fifteen questions. Peter Chen keyword-stuffed thirteen and "needed to check" two. He got 78 — two points below "Strongly Recommended" (80). John Smith said "I don't know" to every single one and got 42 — just barely into the Not Recommended zone.

The system didn't follow up on a single answer — not Peter Chen's fabricated project, not John Smith's "I don't know." Every question scored independently, then weighted and averaged.

From these two data points, the scoring model was obvious: hit the keywords, and each answer scores near max. Answer with keywords but miss the mark, you lose some points. Say "I don't know" or "let me check," the penalty is light — the system is more afraid of you getting it wrong than of you not trying. With two "let me check" responses, Peter Chen only lost a few points. But fifteen straight "I don't know" answers bottomed out at 42.

I'd guessed the system worked this way from the whitepaper — "semantic similarity model, keyword matching algorithm." But guessing isn't testing. Now I had the data.

It doesn't care whether the person on the other end is real. It only cares whether their words match the high-scoring answers in its database.

I saved two screenshots: peter_chen_78.png and smith_42.png. I dropped them in an unremarkable folder on my desktop.

Act 4 · My Turn

A week later, it was my turn for the promotion interview.

I didn't game it. I answered every question honestly — pushed back when I disagreed, said "it depends on the context" and "it scales with the data." I knew the system wouldn't follow up. I knew it only looked at surface level. But I answered the way I actually think.

Forty-five minutes later, the system said "Interview complete."

I spent the next week writing code. I ran into Zhang at the coffee station twice. Neither of us mentioned the interview.

Friday, 3:00 PM. A company-wide email from HR:

"Internal promotion AI evaluation complete. 75 candidates have been assessed. Reports are available."

My score: 65/100 — "Recommended," lower-middle of the band.

Then I pulled the full breakdown:

Metric	Count
Total candidates	75
"Strongly Recommended" (≥80)	47
"Recommended" (60-79)	25
"Not Recommended" (<60)	3

Out of 75 people, the system failed three. Pass rate: 96%.

I stared at the numbers. Same AI. Same scoring logic. The thing I used to create ghosts was the same thing deciding whether I got promoted. A system that couldn't tell real from fake was running both doors.

I poked around the recruitment backend through the internal network.

Peter Chen — 78/100, "Recommended." Same score as the day I made him up. The system hadn't flagged anything unusual.

A person who didn't exist, using a temporary email, with a fabricated résumé, walked the entire pipeline and got a "Recommended." Two points from "Strongly Recommended."

Then I had a thought: if you fed this system 500 real résumés with 500 template-written answers, would it know the difference?

It wouldn't. Because it never cared whether the person was right. It only cared whether the words matched.

Act 5 · Showing My Cards

I didn't go straight to the VP.

I went to the head of the evaluation committee — a technical director I didn't know well but had heard was fair. I put two reports on his desk: mine (65) and Peter Chen's (78).

"Can you look into this Peter Chen's background?"

The director pulled up the recruitment system. Two minutes later, he frowned.

"He's in the system — but look. No credential verification, no background check, no references. Nobody verified anything about this person at any point in the pipeline."

"Because he doesn't exist," I said. "Fifteen questions. Every answer was made up."

I printed Peter Chen's interview transcript. The director read through it line by line.

After four questions, he put the paper down and looked up.

"How did this — get a 78?" He tapped his pen next to question one.

"Because the keywords all hit," I said. "Time complexity, space complexity, boundary check. The system only recognizes words. It doesn't check if your answer is right. It only checks if the right words are there. "

The director set the report down. He was quiet for a long time.

Act 6 · The Meeting Room

The VP called a post-mortem for Thursday afternoon. Two vendor engineers joined remotely, their avatars motionless on the screen.

I stood in front of the projector and put up the first slide:

Keyword Matching Accuracy — System vs. Human Review

Scenario	System Score
Normal interview	65
Ghost A · Keyword stuffing	78
Ghost B · All "I don't know"	42

The VP looked at it for two seconds. "The vendor says the system has anti-cheating mechanisms."

"It doesn't." I flipped to the second page — Peter Chen's interview transcript. "This is the raw output. Fifteen questions — thirteen keyword-stuffed, two 'I need to check this data.' Not one true statement in the entire thing. The system gave it 78."

"Anti-cheating — if you had anti-cheating, how do you explain this score?"

"If a real person can use this system — what happens when the person isn't real?"

The vendor's avatar didn't move. But the VP sat up straighter.

Act 7 · The Quiet Ending

The aftermath was quieter than I expected.

The system stayed. The VP said "we've already spent over two million, we're not scrapping it over one edge case." But they added a rule: every candidate scoring below 80 or above 95 must be manually reviewed.

The three people the system had failed were reinstated. I suggested extending manual spot-checks to the "Strongly Recommended" range on the hiring side — and we found 41 keyword-stuffing candidates in the external pipeline. Three of them had entirely fabricated work histories.

The system's future updates — new question banks, scoring model adjustments, module expansions — all required validation by internal QA before deployment. Three people. I was one of them.

Zhang asked me how I felt about it later. I thought about it.

"Kind of conflicted. The system failed my test, and I got promoted anyway."

He considered that. "You should've gotten full marks."

"The system wasn't wrong," I said. "The system tested whether I said the right things. But a forty-five-minute interview — can it tell whether someone actually cares? No. Because it never had a heart to begin with."

Zhang wrote that down on a sticky note and put it on his monitor. Later, when the team ordered new mugs, he suggested printing that line on them. It didn't happen — the proposal was sent to committee and scored 62 by the AI — "Recommended, pending manual review."

The real test isn't whether a system can filter out bad candidates. It's whether it can tell the difference between "prepared" and "genuine."

Most AI interview systems can't. They only measure one thing: whether your words are the ones they've already heard before.

What's the worst automated screening failure you've seen at work? Drop it in the comments — I read every single one.

This is the 11th story in the "AI, Ego & Regret" series. The rest of the series is linked below — follow along for more.

P.S. Got a story of your own? Buy me a coffee ☕and tell me about it. The next one could be yours.

This article was written with the assistance of AI tools.

I Wrote 10 AI Stories in 10 Days. My Keyboard Started Smoking on Day 4.

xulingfeng — Tue, 09 Jun 2026 08:29:19 +0000

Biggest thing I learned writing the AI, Ego & Regret series: I argue with myself way more than I thought.

Every post goes through the same loop:

10 PM: "This story's fire. Gonna blow up tomorrow."

1 AM: "Wait — did I make it clear that 450ms wasn't just a random number?" → Scrolls back to check. Yes. OK. Move on.

Next morning: "What was I thinking? Scrap it. Rewrite from scratch."

The cover images were the worst part. One article went through 6 different backgrounds before circling back to the first one. 45 minutes I'll never get back.

Then there's that one line: "It was right about yesterday — and yesterday wasn't running anymore." Rewrote it 11 times. My wife walked by and said, "I thought you were writing code, not poetry."

Ben Halpern hit me with a 5-reaction combo while I was eating instant noodles. Almost choked.

Waking up at 3 AM. First instinct: check comments. Nothing. Go back to sleep. 5 minutes later: check again. Still nothing.

Writing code? I'm normal. Writing stories? I'm the guy verifying his own made-up RabbitMQ number at 1 AM.

Would I do it again? Yeah. Probably. But I'd get a better keyboard this time.

This coffee's about to run out — and I'm not done typing yet. If these stories made you smile, chuckle, or roll your eyes, buy me a coffee and keep the keys smoking ☕🔥

Also — if you've got a story that's been sitting in your head, something that made you laugh, cringe, or question every life decision that led to that moment — send it over. I'll turn it into a story. Yours could be the next one.

No pressure. Just a keyboard that's already warm.

This article was written with the assistance of AI tools.