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 you wings, a cure-all for whatever ails you.
I installed Claude Code, and the friction is gone. An idea now costs an evening to test, not a month.
Then it turned out the friction mattered to me, and once it was gone, I felt that in full.
I am not a junior who just discovered autocomplete. I have been writing code for twenty-five years.
Ideas drop like flies
For twenty-five years I had one quiet comfort: "if I ever really went for it, oh boy."
Somewhere in my head sat a drawer of ideas I would get to someday. Not because I couldn't build them. I just never got around to them. And an untested idea is pure hope. Maybe this one is the one. Maybe I am actually worth something.
Testing an idea was expensive: evenings, energy I do not have after work. So the drawer stayed full. Expensive means later.
Claude Code dropped the cost of testing to zero. Want it? Working prototype by tonight.
So I started pulling ideas out of the drawer, one by one. And they started dying. Quietly, fast, like flies. The one that was going to be huge turns out mediocre by the third evening. The next one is worse.
A month in, an ugly thing dawned on me. The idea was never the valuable part. The hope before testing was. The friction worked as anesthesia: it kept me from feeling that the drawer is mostly junk. I had an endless supply of brilliant ideas precisely because I never tested them.
The endless self-improvement loop
The second half is funnier, because it looks like something useful.
You sit down to do the thing. Say, post to Telegram. The built-in tools can't do it. Fine, let's write our own sender. And let's have the model run through the subscription I already pay for, not the API. And let's make the sender add its own workflows. And let's have those workflows write workflows.
# what I sat down to do: post one message to Telegram
# what I had by 2 a.m.:
~/projects/telegram-sender/
└─ plugins/ # it can add its own workflows now
└─ plugins/ # and the workflows write workflows
# users: 1 (me)
By 2 a.m. I do not have a Telegram post. I have a tiny AI newsroom full of agents, with exactly one user.
Research is the same story. The built-in one is mediocre, so let's write our own. Properly. With blackjack and programmatic quality gates. Memory is its own saga: let's try a hundred implementations, bolt on codegraph, then something else. By morning it is a monster nobody understands. I look at it with a clear head, see that half of it has to go, delete it, and start a fresh lap the next day.
The thing I sat down to do never got done. But it's all perfect.
What used to save me was the price. Writing my own sender was a few days of work, so I grabbed something off the shelf and went and did the job. Claude Code made "let's just write our own" free. So now I pick "our own" every time. Every single time. Forever.
The friction was a brake
I put the two problems together and saw it is one problem.
The friction I grumbled about for twenty-five years was a brake. Expensive to test an idea, and the weak ones quietly stayed in the drawer with the hope. Expensive to roll my own, and I grabbed something ready and went to do the work. The barrier filtered junk on the way in and kept me out of the rabbit holes on the way out. The whole time I called it the enemy.
Claude Code removed the friction. And the brakes with it. Now nothing slows me down. Ideas die under instant testing. Self-improvement runs for the sake of self-improvement. AI did not remove the busywork. It removed the excuse. And behind the excuse, it turns out, no great version of me was waiting.
So now what
The funny part: by every metric I am more productive. Agents spinning everywhere, prototypes by evening, tools built to fit my hand, tests, gates. A perfect homemade sender that, for some reason, I never use. I have never gotten so much done.
There is just not much left to get done. The ideas are tested and buried, the dream right behind them, and all my energy pours into late-night platforms with one user.
I used to have an excuse: "once I clear the decks, then." Good excuse. Kept me warm for years. Claude Code took it. And it seems the only thing left for me to figure out, with its help, is how to put some friction back. Life used to install the brakes for me.
Seniors with a couple of decades in: was your friction load-bearing too? Or did losing it actually set you free?
Juniors: you started without the friction. Does any of this land, or does it read like a guy mad at his own productivity?
Top comments (11)
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.