The Move From Execution To Origination
This article is a reprint of the article I wrote last week on The Software Conductor substack.
Let me give you the numbers straight, because I think the industry has done a lot of hand-waving around them and that isn’t helping anyone.
Programmer employment in the U.S. fell more than 27% over the past two years. Entry-level technology hiring at the largest firms is down 25% year over year. These aren’t rounding errors or statistical noise. They represent hundreds of thousands of people who were working in software and aren’t anymore, and a significant reduction in the new-graduate hiring pipeline that has historically replenished the field.
At the same time, the Bureau of Labor Statistics projects growth of 18% over the next decade for the role they classify as “software developer,” which skews heavily toward design-oriented, architectural, systems-level work.
The industry isn’t shrinking. It’s being redrawn. And the line being drawn right now is one you need to understand, because your career is going to end up on one side of it or the other.
What’s actually being separated
The line isn’t between AI and humans. That framing is too simple and it leads to the wrong conclusions.
The line is between execution and origination.
Execution is the work of producing a known output from a known specification. Write this function. Implement this interface. Generate this boilerplate. Translate this requirement into running code. AI handles execution with great competence, increasing speed and dramatically decreasing cost.
Origination is the work of deciding what to build, why to build it this way instead of that way, what the implications are over a three-year horizon, and how all of these systems are going to fit together into something that serves actual people in actual organizations. AI does not do this. Not today, and not for the foreseeable future.
Execution is the majority of what a typical developer’s day looks like. That’s not a criticism. It’s an accurate description of where software development effort actually goes.
Origination is what architects do.
The mistake I see people making
When I talk to senior developers who are anxious about the AI shift, I notice a pattern. They’re watching what AI can do to individual tasks, and comparing it to their own ability to do those same tasks. “Can AI write this code as fast as I can?” And then they’re either reassured (no, not quite, I’m still faster) or anxious (yes, and it’s getting faster).
That’s the wrong comparison.
The right comparison is: “What kind of work is my organization still going to need humans to do in five years?” And the answer to that question is almost entirely in the origination category. Synthesis, judgment, systems thinking, trade-off evaluation, cross-team coordination, long-term architectural direction. The work where the value comes from experience, context, and judgment rather than the speed of execution.
If your career is built primarily on execution speed, the trend line is uncomfortable. If your career is built on origination depth, the future looks very bright.
AI makes origination work more valuable, not less.
AI does this by raising the floor of what execution can produce and therefore raises the stakes for whether the architectural decisions behind the execution are any good.
What this means practically
The developers who navigate this well aren’t the ones who get better at competing with AI. They’re the ones who move decisively to the work AI can’t do.
That’s the architect track. Now, this isn’t necessarily the formal “senior architect” title, though that matters too. Rather, more fundamentally, it’s shifting the center of gravity of your work from implementation to design, from execution to origination, and from building things to shaping the conditions under which the right things get built.
Most developers I know are ready for this shift earlier than they think. The technical foundation is usually there. What’s missing is the mental model for what the work actually looks like, and the confidence to step into a role that doesn’t reward the same behaviors that made you successful as a developer.
That’s the problem this Substack and the book behind it are trying to solve.
The honest caveat
I want to be careful not to make this sound simpler than it is.
Not every developer wants to be an architect. The architect track is genuinely different from the deep technical individual contributor track, and both are legitimate paths. If your joy is in the craft of building things with your own hands, there’s still a version of that career that works in an AI-augmented world. It just looks different than it did five years ago.
And the transition to architecture isn’t automatic. Wanting to do architectural work doesn’t mean you’re automatically good at it. There’s a real skill set to develop, and it starts with understanding what the job actually is.
That’s what I want to spend the next several weeks unpacking here.
The numbers are what they are. The question isn’t whether the industry is changing. It’s whether you’re going to get ahead of it.
If you’d like to read more articles about the changing roles of software developers and software architects, may I suggest subscribing to The Software Conductor substack? This substack follows the teachings of my latest book, The Software Conductor, and expands on the ideas contained in that book.
Lee Atchison is a software architect, author, and cloud computing thought leader. He writes at Software Architecture Insights and is the author of The Software Conductor and Architecting for Scale (O’Reilly).