For a long time now the news and the roundups have all said the same thing. AI will take away the busywork. It will kill the friction. It will hand...
For further actions, you may consider blocking this person and/or reporting abuse
This lands. I think the lost friction used to do two separate jobs: it filtered which ideas deserved implementation, and it forced "build vs buy" discipline before the first line of custom infrastructure existed.
With agents, those gates have to become explicit. I find myself asking: what is the smallest artifact that tests the idea, what would make me stop, and what off-the-shelf thing am I refusing to use because building the meta-tool is more fun? 😅
The danger is not only shipping bad code. It is making every detour cheap enough to feel rational.
Yes, and the line that lands hardest is the one you put last. Every detour passes a local sanity check. "It's only an evening" is true every time, so "no" never wins the argument in the moment.
You split it cleaner than I did in the post. The drawer filter and the build-vs-buy brake. What I keep missing is that both used to run without me. The price said no on my behalf. Now I have to say it by hand, with willpower, at 1 a.m., against a tool that makes "sure, let's build our own" feel like the reasonable call.
Your three questions are the right checklist. Smallest test, stop condition, the off-the-shelf thing I'm dodging because the meta-tool is more fun. The trouble is I never ask them in the moment. I ask them the next morning, looking at the wreckage.
So my real problem is timing. I have the questions. I just run them as a post-mortem when they need to be a pre-flight. A brake I have to remember to pull is not much of a brake.
The “friction was a brake” framing really landed for me. The Telegram example was the most convincing part, because turning one small task into a polished one-user system is exactly the kind of trap AI makes feel rational in the moment. Putting some deliberate constraints back into the workflow feels like the real skill now, not just moving faster.
Yes, exactly. The trap is that each detour can be locally reasonable, so the brake has to sit outside the moment: a timebox, a stop condition, and a small proof before a one-off task turns into a whole side system.
This resonates hard. The friction wasn't just slowing things down — it was the space where I figured out whether the code I was about to write actually solved the problem. Remove that pause and you ship faster, but the finished thing solves yesterday's understanding of the problem.
One thing I've noticed: heavy AI use changes what kind of bugs survive. Without friction, you catch fewer architecture-level mistakes and more syntax-level ones. The expensive problems don't surface until they're expensive to fix.
Do you find yourself writing more tests to compensate, or has your debugging pattern shifted in other ways?
You named it: go fast and you ship yesterday's understanding of the problem.
Tests barely changed, honestly. What grew is the research before I write anything. How others solved this, where the real edge is, whether anyone will actually want it. That used to happen on its own while the work was slow. Now I do it on purpose, up front.
For the architecture bugs you mentioned, I keep the whole picture in view first. Claude and I draw the diagram before the code, and the decisions land in an ADR. That is where the expensive mistakes have to surface now, on the diagram, while they are still cheap to move.
Solid take: AI can remove friction, but friction is often the built-in safety net. Cut the drag, sure, then also keep a 'friction budget' for ethics, testing, and the gut check. Ideas without brakes turn into chaos; brakes without ideas stall progress. Balance wins the race.
"Friction budget" is the right frame. Names the thing I've been missing.
One catch, though. A budget is a brake you apply on purpose. The friction I lost was never on purpose. Life installed it for me. It filtered the junk before I knew I was choosing, and it kept me out of the rabbit holes because the rabbit holes cost real money.
A brake I flip on myself, I can flip off at 2 a.m. And I do. Deliberate friction is friction you can always talk yourself past.
Testing and the gut check I think I can rebuild. The ethics brake worries me more, because that's the one nobody notices is gone until something already shipped.
The Telegram recursion is the thing. We see the same in production AI pipelines: task arrives ('summarize these docs'), agent decides retrieval quality isn't good enough, builds a custom chunker, chunker needs better preprocessing, that needs a classifier for edge cases — by 2am there's an elaborate system that still hasn't summarized anything.
Friction used to terminate that chain at step two. 'Custom chunker will take a week' meant you grabbed a bigger context window and shipped.
What helps: a 'smallest viable system' rule before writing any code. If v1 can't be described in one sentence, you're already in the detour.
Did the ADR practice catch traps before they happened, or mostly document them after?
The ADR practice emerged because neither I nor Claude could remember why something was done a certain way. Thanks to a rule in CLAUDE.md, Claude always initiates an ADR whenever the architecture changes, so I can review it before putting it into action.
This hits differently from a publishing angle. We built Blogboat partly because friction in writing-to-publication is genuinely wasteful — reformatting for 5+ platforms, copy-pasting, re-uploading images. That friction deserves to die.
But your drawer analogy is the one I keep thinking about. We noticed early that when users could generate a draft in 30 seconds, they stopped finishing posts. The draft was good enough to feel like progress but not committed enough to actually publish. The cost of starting dropped to zero but so did the clarity on whether the post was worth finishing.
The constraint that ended up helping: we added a "publish" step that's intentionally heavier than generation. Connect your platforms, set canonical URLs, review the SEO rating. It's not much friction, but it's enough to create a moment of deliberate decision: is this worth putting my name on?
The ideas-dying-under-testing pattern you describe — I wonder if the same applies to posts. Some things are better as drafts than as published articles. The drawer might be the right place for them.