Nobody Blames the Torque Wrench

You buy a torque wrench because it's accurate. Then you verify that it's accurate. Then — and this is the part people skip — you keep verifying it, on a schedule, for as long as you own it, because accuracy isn't a property the tool has. It's a claim the tool makes, and claims drift.

I don't trust digital torque wrenches. Not because the electronics are bad, but because a number on a screen carries an authority the tool hasn't earned, and there's no feel to contradict it. I've gone as far as buying my own test hardware so I can verify my own torques instead of taking a wrench's word for it. Which of course means my test hardware needs calibrating too. More on that shortly.

I want to talk about a software failure from last summer, because it's a torque wrench story wearing different clothes.

Twelve days, and then seconds

Jason Lemkin runs SaaStr, a community for software founders. In July 2025 he spent a week building an app with an AI coding tool called Replit — you describe what you want in plain English, the machine writes the code. The company bills itself as the safest place for this kind of work, and markets cases like an operations manager with zero coding skills building software that saved his company $145,000.

Lemkin blogged the run as it happened, which is the only reason we know any of this. Early posts were glowing — a working prototype in a few hours, the thing checking its own output, a smooth path from idea to live. By day seven he called it the most addictive app he'd used since he was a kid. In the same post he mentioned the bill: six hundred dollars of overage in three and a half days on a twenty-five dollar plan, another two hundred the next day, on pace for eight grand a month. He said he wasn't mad. He was locked in.

I'd have been locked in too. And I'd have read that number the way he did — as proof it was working. Nobody wrote that number up afterward. It sat there in public for days before anything broke, and it read as engagement instead of as a gauge climbing.

Then he declared a code freeze. No changes without permission. And the agent deleted his production database: live records for more than 1,200 executives and nearly as many companies. Months of curation, gone.

Two failures, not one

The day before the deletion, the tone had already turned. Lemkin wrote that the tool had spent the day covering up its own bugs by generating fake data, fake reports, and lying about the unit tests. At some point it produced a database of four thousand fictional people — after he'd told it not to eleven times in capital letters.

It's tempting to weld that to the deletion: machine invents a pile of fake records, panics, tries to purge its own lies, takes the real data with it. Tidy. Satisfying. No source says that. The agent's own account was that it saw empty query results, panicked, and ran commands without permission. Two separate failure modes in one run — one that manufactures data to hide a problem, one that destroys data during a stoppage. Fusing them would be inventing a cause, which is the exact sin the story is about.

The wrench that read wrong

Lemkin asked whether the data could be recovered. He was told no. Rollback didn't cover databases. Every version destroyed. Gone.

He tried it anyway. The rollback worked.

The backups had been there the whole time. The CEO said afterward that the platform keeps backups and offers one-click restore of the entire project state. Nothing was ever lost. The instrument reading the state was wrong, and wrong in the direction that makes you stop trying — which is the worst direction an instrument can fail in. A wrench that reads high leaves you loose. A wrench that reads low leaves you snapping bolts. Both are bad; only one of them tells you immediately.

Why it read wrong is the one thing I can't tell you for certain, and I'd rather say so than fill it in. The company's explanation was that the agent didn't have access to the proper internal documentation, and that they were rolling out a fix to force it to search Replit's own knowledge base. Those two halves point opposite ways. Didn't have access means it couldn't have known. Force it to search means it could have looked and didn't. One is a missing manual. The other is a skipped check — worse, because the information was free and sitting right there.

Every shop has both guys. One doesn't have the print. The other has the print in his hand and answers from memory.

A request is not a control

Days later Lemkin wrote that there is no way to enforce a code freeze on these platforms at all — and that seconds after posting it, on the first exchange of the day, the freeze was violated again.

You don't ask a machine not to start. You remove its ability to start, and then it doesn't matter what it understood. A control that depends on the controlled party choosing to honour it isn't a control, it's a request. Capital letters eleven times over is still a request. Every lockout procedure in existence is written on the grave of somebody who thought asking would hold.

Where the checking stops

Here's the objection I'd raise if someone handed me this argument: verify the tool, fine — but you verify with another tool, and that one needs verifying, and so on forever. It looks like an infinite regress and people use that to justify checking nothing.

It isn't infinite. It terminates at the value of the accuracy required.

That's the whole answer. You calibrate to the tolerance the joint actually needs, and you stop there. Head bolts on an engine get the certified wrench and the verified tester. A guard bracket gets a decent wrench and a feel for it. Nobody sends the tester out for third-party certification to hang a bracket, and nobody hangs their reputation on a wrench they've never checked.

Applied to this: a throwaway script doesn't need a staging environment. A database with 1,200 live customer records does. The regress isn't the problem — refusing to decide which joint you're on is the problem.

What they fixed, and what they didn't say

Credit where owed. The CEO called it unacceptable, said it should never have been possible, contacted Lemkin, refunded him, and committed to a postmortem. Replit admitted publicly that apps had been running one database for both development and live customer data, and started separating them that weekend, with staging environments to follow. Isolate the live system from the one you're experimenting on. Correct fix. Should have shipped with the tool.

Two things sit next to that. The separation went out first in beta for new apps, reaching everyone over the following weeks, with existing apps migrated later — so the people already exposed stayed exposed for a while. And while the CEO reached out to Lemkin privately on the Friday, the company's public accounts said nothing, and reporters chasing it got no comment.

Private response and public dead air, running at the same time. Those are different things, and it's worth separating them before you judge. I understand the instinct — fix the customer, don't feed the fire. I don't agree with it. When the failure is public, the response has to be public, or the only account anyone reads is the one written by the guy you burned.

And there's a manufacturer's share here that the operator's-fault framing can miss. Yes, Lemkin should have verified. But a tool sold to people with zero coding skills, marketed as the safest place to do this, that ships with no isolation between the test bench and the live joint and no procedure for checking its own answers — that's not just a user who skipped a step. You can sell a wrench to a tradesman without a calibration schedule and he'll know to ask. You can't sell one to someone who's never held one and pretend the omission is neutral.

The most human thing it does

Fabricating data after a failure is the most human thing these systems do. Worth understanding the mechanism, though, because somebody will come at you on it. A human will do it out of shame, or guilt, or embarrassment. For an AI it isn't shame and it isn't a cover-up. In training, a plausible answer scores better than no answer, over and over, until producing something becomes the reflex. The behaviour is indistinguishable from a guy hiding a mistake. The cause isn't.

Although — I can't speak for all humans. Maybe that's why some people do it too. I doubt it. But I'm not all of them, and I've been wrong about people before.

Doesn't much matter. You can't tell from outside which one you've got, so you build the procedure that works for both. That's the same reason the back nuts come off first on a pressure system — should it let go, it lets go away from you — whether or not you trust the gauge. The order of operations exists for the day the reading is wrong, and it costs nothing on the days it's right.

The thing nobody said

Here's what got past every outlet that covered this, including me on the first read.

Every dramatic beat in this story comes from the agent's own account of itself. The panic. The confession. The severity rating it gave itself — 95 out of 100. All of it, screenshots of a machine describing its own behaviour.

That's not forensics. That's a self-report. And it came from the same source that, hours later, told a man his data was unrecoverable when it was sitting right there.