I remember reading about the 10,000-hour rule and finding it compelling. It gave expertise a shape. Put in the time, do the reps, stay with it long enough, and eventually you become excellent. There is something true in that. Time matters. Repetition matters. Sticking with something long enough to get past the awkward early stage matters.
But after more than 10,000 professional hours in software engineering (and probably closer to 20,000 by now), I do not think the rule is a very good rule.
Part of why I feel comfortable saying that is because software engineering was not the first thing I got deeply proficient at. Before I was a software engineer, I was a senior video editor. I am not going to say the paths were identical. They were not. But they were similar in one important way: you could absolutely spend thousands of hours getting faster at the familiar while staying narrow in what you actually knew.
That is the problem with using hours as the headline metric. You can spend 10,000 hours doing the same thing over and over again and remain a beginner in every way that matters. You can spend 10,000 hours in a low-feedback environment. You can spend 10,000 hours never taking on higher stakes, never stretching your judgment, never owning outcomes. Time is necessary, but it is not sufficient.
I think the real engine of expertise is repeated exposure to new constraints, real feedback, rising stakes, and ownership of outcomes. The hours help, but only if they are carrying those things. AI is making that distinction impossible to ignore.
Hours do not create expertise by themselves
What actually grows a person is not the passage of time. It is the friction of reality.
If you edit the same kind of video in the same way for years, you can become fast without becoming broad. If you write the same kind of software ticket in the same corner of the system for years, the same thing can happen. You get efficient. You become reliable inside the groove. But expertise is not the same as comfort.
Expertise comes from having to reorient yourself. A new kind of problem. A new system boundary. A production issue you did not expect. A cross-functional conflict that cannot be solved with code alone. A moment where your usual move stops working and you have to build a better one.
That is why I have a hard time with the 10,000-hour framing. It hides the quality of the reps. It makes time sound like the cause, when time is really just the container. The contents of the container are what matter.
This also explains why some people compound quickly while others stay flat. One person spends their years collecting new constraints and updating their mental models. Another spends those same years repeating a narrow loop. Both did the hours. Only one built the deeper form of expertise.
What software engineering used to teach you for free
For a long time, software engineering hid this distinction because the work itself forced a lot of learning.
You had to fight the language. You had to fight the framework. You had to wire up the boilerplate. You had to debug syntax problems, dependency issues, bad tooling, vague error messages, confusing build failures, and all the small cuts that came with implementing something from scratch. A lot of junior growth came from wrestling directly with that terrain.
That friction was not the same thing as expertise, but it often acted like training. It forced repetition with feedback. It forced you to understand how systems actually fit together. It forced you to build patience, debugging instincts, and the habit of tracing cause and effect through a messy stack.
More importantly, software engineering did not just teach through code. It taught through consequences.
You learned when your change broke production. You learned when your design did not survive real traffic. You learned when a handoff failed because the context was vague. You learned when another team could not use what you built because the interface made sense only inside your own head. Those were the experiences that actually shaped judgment.
So when I look back, I do not think the real learning came from "typing code for a long time." It came from ambiguity, feedback loops, accountability, and having to absorb the results of my decisions.
AI removes some of the old apprenticeship terrain
This is where the conversation gets interesting.
Agents are taking over more of the ramp-up terrain that used to be part of becoming an engineer. Boilerplate is cheaper. Syntax recall is less important. Spinning up a first draft is easier. The blank page is not what it used to be. A lot of the old friction is being compressed away.
That is great for productivity, but it raises a serious question: if AI reduces the amount of time spent on low-level implementation, where does learning come from now?
I do not think the answer is "learning goes away." I think the answer is that the learning moves.
The scarce skills become things like:
- defining the actual problem
- setting the right context
- choosing boundaries
- evaluating trade-offs
- verifying that the output is correct
- deciding what deserves human attention
- owning the result when the agent was wrong
In other words, the center of gravity moves away from raw implementation and toward judgment.
Coding still matters. Technical depth still matters. I do not think this becomes a world where you can float above the system and simply issue prompts. Someone still has to understand what good looks like. Someone still has to recognize when an answer is brittle, overfit, insecure, or just misaligned with the actual goal.
But I do think the shape of engineering work is changing. The future engineer is not simply the person who can type the most code the fastest. It is the person who can create clarity, direct agents well, integrate context, and make good decisions under ambiguity.
Software Engineering 3.0 is closer to alignment work
This is why I keep thinking of this shift as a kind of Software Engineering 3.0.
A lot of people are treating AI as just another tool in the toolbox. I do not think that is right. I think it is a transformation in the way the work is done, and transformations change which skills rise to the top.
In my mind, software engineering has always sat near two neighboring functions: technical program management and strategy. There is a kind of Venn diagram here. One circle is deep technical execution. Another is alignment and coordination. Another is strategic framing and prioritization. The interesting thing now is that the overlap between them is getting more important, not less.
That does not mean software engineers and TPMs are now the same role. It does not mean strategy replaces engineering. It means the valuable engineer is increasingly operating in the overlap: technical enough to judge the system, aligned enough to coordinate humans and agents, and strategic enough to frame the work correctly in the first place.
That is also why the skill shift can feel surprising. Some abilities that used to be secondary now matter much more. Clear writing matters more because agents consume context. Alignment matters more because the cost of generating code has dropped, so the cost of generating the wrong code at scale has also dropped. Taste matters more because there are more plausible answers to choose from. Verification matters more because fluent output can still be wrong.
So no, I do not think this is a story about coding no longer mattering. It is a story about coding no longer being the sole center of professional gravity.
If the old story was "become an expert by doing the hours," the new story is more demanding: become an expert by owning outcomes in a world where implementation is cheap.
That is the part I think the 10,000-hour rule missed. Hours were always incomplete. AI just makes the missing part impossible to ignore.
This post connects to a few ideas I have been writing about lately: Context as Code on why alignment artifacts matter more in an agent-driven world, Craftsmanship, Judgment, and Taste on the human side of agent collaboration, and the growing overlap between engineering, coordination, and strategy that more people are starting to notice across the industry.