Learning is fundamentally full of friction. But what happens when instead of working through the friction, you decide to just let AI handle it? Maybe the work got done, but did you learn anything? Are you more in touch with your craft today than you were yesterday?
These are some of the questions that haunt me these days. I use AI every day and I use it a lot. I regularly describe the ultimate outcome I want and then leave it alone for an hour or so and come back to a perfectly working solution. Sometimes the solution has even handled edge cases and scenarios I didn’t think of but encounter as I put the solution through its paces. It’s impressive and incredible.
And I don’t think there’s anything inherently wrong with working that way. Sometimes I just need something done. Sometimes the implementation isn’t where I want to spend my time or energy. And sometimes letting AI handle the implementation means I can spend more time thinking about the bigger problem.
But what happens when we start working this way by default? When the first instinct, upon encountering something difficult, is to hand it off rather than work through it ourselves?
Some friction is the work
That instinct is easy to follow with code, design, writing, and just about anything else. Writing is where I noticed it first.
For a little while, my writing was being mistaken for AI. It frustrated me so much that I started writing my drafts and then running them through AI with the instruction to rewrite them at a grade 9 or 10 reading level, and then I’d share that. My natural style of writing was being seen as too dense or complicated.
I found the whole experience frustrating, and not just because people were mistaking my writing for something AI had produced. But also because by having AI rewrite it in “plainer” language, so much of the nuance and contextual information was being left out. I was forced to make my writing only about the point at hand, rather than also giving the reader the tools and context to understand the lay of the land, which I felt was pretty vital in the larger picture.
It made me wonder whether our relationship with difficulty is changing. Whether we’ve become so accustomed to things being made easier for us that we’re starting to treat the effort required to understand something as a problem with the work itself.
Sometimes things are unnecessarily complicated. Sometimes writing is dense because the writer hasn’t done the work to make their ideas clear. I have certainly been guilty of that at times. Sometimes software is difficult to use because it’s badly designed. Making things accessible is important, and complexity for its own sake isn’t a virtue.
But just because something is hard to understand or use initially doesn’t mean it’s badly made or not worth engaging with. Not everything can be simplified to a level that everyone can understand on their first attempt. Some things require us to learn new concepts, develop new mental models, or sit with an idea long enough for it to make sense.
So are we getting worse at doing that?
We’ve spent years in tech trying to remove friction. Better developer experiences, better abstractions, better tooling, better documentation, better UX. I’m a huge advocate for all of those things. Much of my own work revolves around making it easier for people to build and do things. That is fundamentally the role of technology in our lives: to make it easier to do the things we want to do, often better and faster too.
But is every kind of friction a defect? Is every kind of friction worth reducing or eliminating?
There’s friction that gets in the way of doing meaningful work. The tedious setup, the repetitive tasks, the confusing interfaces, the unnecessary complexity. Removing that friction gives us more time and energy for the things that matter.
And then there’s the friction that comes from doing the meaningful work itself. The hours spent debugging a problem that forces you to understand a system more deeply. The uncomfortable process of trying to articulate an idea you haven’t quite figured out yet. The effort of reading something complicated and slowly building up enough understanding to have an opinion about it. That’s where learning happens.
And AI is pretty great at removing both kinds of friction.
Thinking happens in the making
Everyone will tell you that you should leave the implementation to AI and spend more of your time thinking about the architecture, the systems, and the bigger questions that you need to grapple with in your work. We can use AI to speed up the writing so we can spend more time thinking and developing the ideas rather than worrying about how to express them.
That advice assumes the message and the medium are decoupled. Often they aren’t. Sometimes we don’t know what we mean until we have exercised the act of typing it or writing it down. That’s what happened when I flattened my drafts. The point survived, but the meaning around it didn’t. Sometimes we don’t know what the system could be until we’ve tried to build it ourselves.
Think about any project you’ve ever worked on. You can spend weeks planning it, breaking down the work, thinking through the architecture, and accounting for every scenario you can imagine. And then you start building, and you discover something that changes your understanding of the problem. Maybe a constraint you hadn’t considered changes the architecture. Maybe an abstraction that seemed perfectly reasonable on paper doesn’t actually work very well in practice. Maybe you realize halfway through that you’ve been solving the wrong problem entirely.
You couldn’t have planned for all of that because you hadn’t encountered it yet. Some understanding only comes from doing the work.
We don’t know what we don’t know. AI can sometimes surface those things for us, like the edge cases I mentioned earlier. But being handed the answer is a different experience from running into it yourself.
The saved hours go back to production
And when AI does free up our time, are we actually using it to think more deeply and develop our ideas more strongly, or are we just moving on to the next thing?
Because those are two very different outcomes.
And there’s another angle to this that I hadn’t really considered until I saw an Instagram reel the other day.
It posed an interesting question about incentives in organizations. Imagine two employees, both working eight-hour days. One figures out how to use AI to get their work done in five hours instead of eight. The other continues working the way they always have.
What happens to the first employee? Do they get three hours back to learn, explore, think, or simply take a break? Or do they get three more hours of work added to their plate?
In many organizations, I’d bet it’s the latter.
And if that’s the case, what incentive does that employee have to share how they’re using AI? They’ve become more productive, but the reward for that productivity is more work, more responsibility, and more pressure. For the same pay.
We keep saying that AI will free us from implementation so we can spend more time on deeper thinking. But that assumes the time we save is ours to spend. It assumes that we, and the organizations we work in, will value the thinking as much as we value the output.
And I’m not sure we’ve figured that part out yet.
If every hour saved becomes another hour of production, we’re not necessarily creating more room for learning. We might actually be creating less.
We’re removing the friction that helped us develop expertise, while simultaneously increasing the expectation that we produce more with the time we’ve gained.
That’s a strange trade to make.
Of course, organizations should benefit when their people become more productive. That’s part of why we invest in better tools in the first place. But there’s a difference between reinvesting that productivity into more valuable work and simply expecting more output.
Choosing the friction
When I hand something off to AI and come back to a working solution, I’ve accomplished what I set out to do. But depending on the task, I might not understand the solution nearly as well as I would have if I’d worked through it myself. I can review it, test it, and verify that it works. I can even ask AI to explain how it works. But that’s not the same experience as having built that understanding along the way.
Not every implementation needs to be an educational experience. There’s plenty of work I am over the moon about never having to do manually ever again.
Still, there is a difference between being able to produce something and being able to understand how to produce it.
And understanding doesn’t necessarily mean having to do every part of the work yourself. Experienced engineers have always relied on other people to implement things, while still being responsible for understanding the systems they’re building and making good decisions about them. AI isn’t entirely different in that regard.
But those experienced engineers developed their judgment somewhere. They had opportunities to make mistakes, discover constraints, wrestle with tradeoffs, and learn from the consequences. If we’re increasingly removing those experiences, what takes their place? And we’re all still developing that judgment. It’s a lifelong venture, after all.
Doing everything manually isn’t the answer. I’m not interested in spending hours on something that could be done in minutes just to prove that I can. And I certainly don’t think we should measure someone’s expertise by how much suffering they’ve endured to develop it.
But I do think we need to be more thoughtful about what we’re giving away.
When we remove friction from our work, what are we making room for? Are we making space to explore, experiment, develop our judgment, and become better at what we do? Or are we simply making room for more work?
And when we encounter something difficult, maybe it’s worth asking ourselves whether the difficulty is getting in the way of the work, or whether working through it is part of the work.
I don’t know the answer to that question. I’m still figuring it out, and I suspect the answer will change as the technology does.
But I know I don’t want to reach a point where I’m producing more than ever before while understanding less and less of what I’m producing.
I want to be better at my craft tomorrow than I am today, and speed alone won’t get me there.
And I think that means sometimes choosing to work through the friction instead of around it.
Leave a Reply