Almost everything written about this is unfalsifiable. "Engineers will become orchestrators." "The role will be more strategic." You cannot be wrong about any of that, which is exactly why people write it.
So here are five claims specific enough to lose. Each one comes with what would have to happen for it to be true, and what evidence would show it was wrong. Two of them I'd bet against my own argument on, and I'll say which.
1. The entry path gets rebuilt, not abandoned
The argument is arithmetic rather than optimism. The BLS projects 15% growth for software developers through 2034, about 129,200 openings a year once you count replacement of people retiring or leaving. Meanwhile SignalFire measures entry-level hiring at the tech majors down 65% since 2019. A lot of what makes the software engineer of 2030 will look different work in practice is process rather than code, which is the territory the XenGrowth practice covers.
Those two cannot both hold for a decade. Experienced engineers are manufactured out of junior ones on roughly a five-year cycle. An industry that stops making them is drawing down a stock it has stopped replacing, and around 2029 or 2030 the mid-level market gets extremely tight.
What the rebuild probably looks like: shorter formal apprenticeships with explicit supervision budgets, more hiring at the two-to-four-year mark from companies that did train, and a return of the co-located first six months — because if Lambert and Schindler at the LSE are right that supervision cost rather than AI is what suppressed junior hiring, then co-location is the cheap lever.
This is the prediction I'd most expect to be wrong, because it requires companies to act on a five-year interest when every individual hiring decision answers to a quarterly one.
Disconfirming evidence: if by 2028 entry-level hiring is still falling and mid-level compensation hasn't moved sharply, the shortage isn't binding and I've mistaken a structural change for a cycle.
2. Verification becomes the centre of the job
This is the safest of the five. Veracode ran 100+ models across 80 real tasks and found 45% of output introducing an OWASP Top 10 vulnerability, with XSS failing 86% of the time — and crucially, larger and newer models were no better. On the operations side of this specifically, The XenGrowth resource library is worth reading.
That last detail is what makes this a prediction rather than a complaint. If the gap were a capability deficit, scale would be closing it and the problem would expire on its own. It isn't closing, because whether code is safe depends on a trust boundary outside the file. That is a property of the information available, not of the model's ability, and information the model was never given does not arrive with more parameters.
So by 2030 the daily work looks less like producing code and more like adjudicating it: reading fast, recognising failure categories on sight, and knowing which parts of a system a change can reach. The engineer's position moves to standing between a fluent generator and a production system.
Disconfirming evidence: a security benchmark showing the flaw rate falling substantially with model scale. That would mean the gap was capability after all.
3. Review capacity becomes the bottleneck everyone complains about
This follows from the second and is already visible. DORA's 2025 data shows throughput rising while delivery stability keeps falling — more shipped, more of it wrong. GitClear measures the codebase-level version: copy-pasted lines up from 8.3% to 12.3% since 2020 while refactored lines fell from 24.1% to 9.5%.
Generation scaled. Reading did not, and cannot with the same tooling, because reading for correctness requires the understanding that reading is supposed to produce. By 2030 I'd expect review to be a staffed, measured, explicitly-resourced function rather than something engineers fit between tickets — closer to how larger organisations treat security review today. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
Disconfirming evidence: verification tooling that genuinely catches semantic defects rather than syntactic ones. That would be a real change and it would invalidate this.
Prediction | Confidence | What would prove it wrong |
|---|---|---|
Entry path gets rebuilt | Low — the weakest of the five | Entry-level hiring still falling in 2028 with flat mid-level pay |
Verification becomes central | High | Security flaw rates falling sharply with model scale |
Review is the bottleneck | High | Tooling that reliably catches semantic, not syntactic, defects |
Domain beats framework knowledge | Medium-high | A generation of successful pure-generalist engineers with no domain depth |
The title fragments | Medium | Job postings converging on a single description rather than diverging |
4. Domain knowledge outcompetes framework knowledge
Framework expertise is precisely what generation commoditised. Knowing the idioms of a particular library was valuable because acquiring them was slow; it stopped being slow. Meanwhile the thing that never got cheaper is knowing what a clearing house actually does, or how a hospital's scheduling constraints really work, or why the logistics customer's exception case is the entire business.
Stanford's substitution-versus-complement distinction supports this from the data side: employment fell where AI substitutes for tasks and held or rose where it complements them, and domain knowledge is the clearest example of something a model complements rather than replaces, because the model has no access to a specific business's accumulated exceptions.
The 2030 version of a strong CV probably reads as five years in healthcare systems, or in payments, rather than five years of a particular stack. That's a significant cultural change for a profession that has organised its identity around tools. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
Disconfirming evidence: continued premium pay for pure generalists with no vertical depth. It's a real possibility — generalists are cheaper to redeploy, and organisations value that.
5. The single title fragments
"Software engineer" already covers several unrelated jobs, and the divergence is accelerating. Someone building evaluation harnesses for model behaviour, someone maintaining a twenty-year-old claims system, and someone doing revenue automation inside a sales organisation share a title and almost nothing else.
What I'd expect by 2030 is that hiring stops pretending these are interchangeable — separate interview processes, separate ladders, separate compensation bands. It's the same fragmentation that split "engineer" into civil, mechanical and electrical over a century, running faster.
This is the second one I hold loosely. Titles are sticky for administrative reasons that have nothing to do with the work, and "software engineer" is convenient for HR in ways that resist accuracy.
What about the predictions I'm deliberately not making?
Three claims are conspicuously absent, and leaving them out is a position rather than an oversight.
I am not predicting a headcount number. Every attempt to put a figure on how many engineers exist in 2030 has to assume something about demand for software, and demand for software is a function of the economy, interest rates and what businesses believe about AI — none of which anyone forecasts well. The BLS projection is the best available and it is a model, not an observation; its 2019 vintage did not anticipate the last five years either.
I am not predicting model capability. It is the variable everyone wants an answer on and the one where nobody outside a handful of labs has information worth having. Notice that every prediction above is constructed to be robust to capability improving substantially: verification stays central because the security gap is informational rather than capability-bound, review stays the bottleneck because reading does not scale with generation, and domain knowledge holds because a model cannot be given a specific business's undocumented exceptions no matter how good it gets.
And I am not predicting that any of this feels like a discontinuity from inside. The last five years contained a collapse in entry-level hiring of 65% at the largest employers, and most working engineers experienced it as a slightly worse job market. Structural change is legible in payroll data long before it is legible in anyone's week, which is the actual lesson of the Stanford paper — its authors called the young-worker cohort a canary precisely because the aggregate statistics show nothing yet.
What doesn't change?
Worth ending here, because the constants are more reliable than any of the above and they get much less attention.
Software is still built by people disagreeing about what to build. Meyer's instrumented study put collaborative activity at 24.4% of the workday — larger than coding — and none of that is a generation problem
Requirements are still wrong at the start. No amount of implementation speed fixes a misunderstanding about what the customer needed, and it makes building the wrong thing faster
Systems still fail through multiple interacting causes. Cook's observation that catastrophe requires multiple failures is not a claim about technology and does not expire
Legacy still dominates. Most software that will run in 2030 already exists, and Stripe's survey put roughly 42% of the developer week on technical debt and bad code before any of this started
Someone still has to be accountable when it breaks at 3am, and that is a person with a phone, not a model
Then and now | 2019 | Plausible 2030 |
|---|---|---|
Primary daily activity | Writing and reading code | Reading, adjudicating and diagnosing code |
Scarcest input | Engineering hours | Calibrated judgment and review capacity |
Career-defining knowledge | A stack and its ecosystem | A business domain and its exceptions |
Entry route | Graduate scheme into supervised work | Rebuilt apprenticeship, or lateral from a domain |
What the title means | One broad job | Several jobs sharing a legacy label |
If you want a single thing to act on, it's the intersection of predictions two and four: get very good at telling whether code is correct, inside an industry whose exceptions you actually understand. Both of those compound, neither depends on a tool staying still, and the evidence for both is stronger than for anything else on this list.
And keep the disconfirming conditions. In 2030 you should be able to check which of these was wrong, which is more than most predictions about this will let you do.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's operator guides writes for the teams who have to run the software engineer of 2030 will look different day to day.
