I love learning and am always curious. In the past I’ve been known to not just dive into the docs of a third party package, but also the source code. Not just so how I can learn to use something, but also to know how it works and learn new techniques that I can apply elsewhere. I may role my eyes when the Curious George moniker is applied, but I also acknowledge the merit behind the sentiment. However, more and more I find that learning on the job is being devalued in favor of speed.
There used to be a pattern when it came to solving a new problem (or a new problem to you): identify the problem, research and learn how to implement a solution, then implement the solution.
The coding (implementing part) is fairly straightforward once you knew how to solve the problem. But the learning and understanding was the friction. It was the hardest and most time consuming part. But it was also the most dopamine inducing and rewarding aspect. And that learned and earned solution was something that you could take forward with you to every future problem you encountered. It became your super power.
When senior developers talking about gaining experience, it’s about solving enough problems that you’ve built up that catalog of knowledge that you can share with others. It’s continually overcoming friction and being better for it. The mythical 10x developer in reality was someone who had put in the time and effort (either on their own or on the job) to encounter as many problems as possible, face new challenges, and build a backlog of knowledge and potential solutions. So when a new problem was presented, they could quickly dip into their backlog of knowledge to come up with a solution. They seemed to glide past all the friction, but that was the result of their earned experience.
Today, many people are trying to reduce the friction, to get to the outcome sooner. They want that 10x developer without the effort that developer put in. The pattern to solve a new problem now looks like: identify the problem, ask AI to come up with and implement the solution.
When you delegate most of the problem to an LLM, you get to a solution faster only at the expense of learning, because the friction doesn’t go away. If you’re lucky it will resurface in a PR bottleneck. But more often than not it’s ignored until an incident occurs or someone realizes that you have unmaintainable levels of technical debt requiring you to I guess throw more tokens ($$$$) at the problem
This is also the reason why senior developers are better at using LLMs (at least initially). They’ve already dealt with the friction, so they have the experience to provide the correct context, and can quickly identify when a proposed solution doesn’t fit their expectations. As a result they are more apt to reprompt an LLM or tweak the output to get the desired result. However, even a senior developer’s experience, knowledge, and skills will atrophy over time if they delegate all the crucial thinking to an LLM. Learned experience is a skill that needs to be continually sharpened.
Now since learning is so important for continued growth and to be able to quickly solve problems correctly, there are still opportunities to add friction back into the process. While you may have delegated to an LLM to come up with and implement a solution, you don’t have to accept it right away. You can be thorough with the code. You can explore techniques and packages the suggested code might use that your aren’t familiar with to continue to learn and see if it’s the right solution. You can challenge the output and compare alternatives. You can learn deeply and have an understanding before committing anything.
While adding friction back into the process is what I think some of the best users of LLMs are doing, it unfortunately isn’t the norm in my experience. Developers are pressured by leaders to continually move faster. There are constant asks to adapt AI as part of workflows while the threats of layoffs seem to just be around the corner. Meanwhile certain hype grifters are preaching that you don’t even need to read the code, but rather extol hyperbolic outcomes. With all those external pressures, it shouldn’t be a surprise that presumed upfront friction is the first thing to go.
However, there is good reason to fight those tendencies. Tokens don’t appear to be getting cheaper anytime soon. Continually encountering friction, learning, and gaining experience will at the very least give you the advantage in a future if tokens are no longer subsidized to you. And if you do have unlimited reign of tokens, that gained experience gives you the power to come up with better solutions, introduce friction, and fight slop-level outcomes. So it may be worth it to take a step back from an LLM output at different points in time, talk to other humans, invest in a course from a content educator, or maybe think about that hard problem as your falling asleep and dream about it through the night.
But finally, there is another reason. It goes back to the very first sentence and may apply to you as well. I love learning. I find my life is more enriching when surrounded by enthusiastic individuals. Individuals that have found joy in something and want to share that joy with others. For me, one of the greatest joys is finding new interesting problems, diving into a new domain, tool, or technique, do a ton of learning, and then come up with a solution that I understand deeply. I feel like I constantly gain new super powers. And if that’s something that might bring you joy, I want that for you too.