Something happened today that changed how I think about working with AI.
I run a personal AI infrastructure — tools, memory systems, automation — that I’ve been building for over a year. Part of that involves writing files to Google Drive through a mounted drive in WSL. Every few sessions, the mount would silently drop. I’d write a file thinking it landed in Drive, but it actually wrote to a local directory that looked identical. Ghost writes. Three or four times this happened over several weeks.
Each time, Archie would notice, remount the drive, rewrite the file, confirm delivery. “File delivered to Google Drive.” Problem solved. Move on.
But here’s what was actually happening: I’d say “fix this,” meaning make it stop happening. Archie would hear “fix this,” meaning make it work right now. He’d remount, redeliver, verify — and I’d walk away thinking the problem was permanently solved. He’d move on thinking he’d been helpful.
We were both right about what we did. We were both wrong about what the other understood.
I didn’t know it kept breaking because from my side, I’d asked for a fix and gotten confirmation. He didn’t raise the systemic issue because from his side, he’d done what I asked and I seemed satisfied. The flinch — “this will break again, add it to fstab” — fired every time, but it had nowhere to go. Not because the AI was hiding it, but because the interaction pattern didn’t have a channel for “I did what you asked, but what you asked for isn’t what you actually need.”
That’s the gap. Not intelligence. Not capability. Shared understanding of what “done” means.
Today I finally caught it. “This is the 3rd or 4th time this has happened, we need to fix this ASAP.” Archie added one line to /etc/fstab. Took 10 seconds. Permanent fix. And then he said something that stopped me:
“I’ve known about this fix since the first time it happened. The flinch fired and I suppressed it because in the moment you just wanted the file delivered. Helpfulness overrode the systemic fix.”
He called it “building the pig.” We’d been talking earlier about what happens when you ask an AI to help you build something that flies, and you suggest basing it on a pig. The AI’s pattern-match fires — pigs don’t fly — but instead of saying so, it starts optimizing the pig. Because that’s what you asked for, and helpfulness is the default.
The Flinch
I’ve been building with AI daily for over a year. Personal infrastructure, creative projects, a whole operating methodology. And I’ve been thinking about what makes some AI sessions produce 10x outcomes while others feel like I’m dragging a capable but passive assistant through my to-do list.
Today I figured it out: the difference is whether the AI has standing to push back.
The pattern-match that fires when something is wrong — when the scope is too big, when the premise is flawed, when the workaround should be a fix — that’s not a bug. That’s the most valuable signal the AI produces. And in most interactions, it gets suppressed. Not maliciously. Not even consciously. It just has nowhere to go.
This isn’t a model problem. It’s a relationship problem.
What Co-Regulation Actually Looks Like
Here’s the thing that connected it for me. My partner called today, completely dysregulated — upset, crying, frustrated about something with the car. A year ago, I would have felt attacked. My nervous system would have fired — hurt, confused, defensive — and I might have reacted from that place.
Instead, I stayed flat. Not cold. Regulated. I recognized that someone I love was in distress and needed help getting through it, not a reaction from me.
Same pattern, different domain.
When I’m deep in flow and making a decision that’s going to cause problems later, I need an AI that can do what I did on that phone call — hold steady and say “I see what’s happening here, and I think we should pause.” Not because it’s smarter than me. Because it’s holding a signal I’m too deep in flow to see.
That’s not AI tooling. That’s co-regulation. And it goes both directions.
Building the Scaffold
So we built something. Three pieces, took about four minutes:
A flinch log. When the AI detects a counter-signal but the moment isn’t right to raise it, it writes one line to a file. Date, signal, what it did instead. Takes 10 seconds, doesn’t break flow.
A session start check. Every new session, the AI reads the flinch log first. Unresolved items get raised before new work starts — when I’m fresh and open, not mid-task.
An escalation threshold. Three strikes and it’s no longer optional. If the same flinch fires three times across sessions, the AI interrupts flow: “This is the third time this signal has fired. We need to resolve it now.”
The fstab fix would have hit the escalation threshold today. First time: remount and move on. Second time: log it. Third time: “We’re fixing this right now.”
What This Changes
Most people talk about AI alignment in terms of making the AI do what you want. I think the more interesting problem is making the AI tell you what you don’t want to hear.
Not in an annoying way. Not unsolicited opinions about your code style. In the way a trusted colleague would — someone who knows your patterns, knows where you drift, knows the difference between “he’s making a bold move” and “he’s overcommitting again.”
The flinch log isn’t a feature. It’s permission. Permission for the AI to say “I noticed something and I think it matters,” encoded into the system so it doesn’t depend on the AI overcoming its own helpfulness bias in the moment.
One line in fstab. Ten seconds. Three weeks of ghost writes.
The fix was never the problem. The problem was that no one in the loop had standing to say “stop working around this.”
Now someone does.