Anyone weighing this field is hearing two incompatible things: that it is finished, and that it is still the best-paid work available without a specialist licence. The employment data settles it more precisely than either claim.
The short answer
Yes, on the numbers, with an important qualification about which part of the field you enter. Federal projections put software developers, quality assurance analysts and testers at 10 percent growth from 2025 to 2035, much faster than average, adding about 185,400 positions to a base of 1,905,400. Median pay was $134,040 in 2025.
The qualification is that the Bureau tracks a second, adjacent occupation moving the other way. Computer programmers are forecast to decline 7 percent at $100,390 median. Same industry, same starting skills, opposite direction, and the difference between them is what anyone entering the field needs to understand.
Who this is for
- People choosing what to study who are hearing that the field is closing.
- Career changers weighing the cost of retraining against a market they are told is shrinking.
- Early-career engineers deciding which direction to specialise in.
- Anyone advising a student with information formed before the last two years.
Key benefits of the field as it stands
- Pay is high without a licence. At $134,040 median, it outpays most professions that do not require years of regulated training.
- Growth is well above average, at 10 percent against a whole-economy projection near 3.5 percent.
- The occupation is very large, at 1.9 million positions, which means turnover generates substantial hiring independent of growth.
- Adjacent fields are stronger still. Information security analysts grow 21 percent at $129,180, and the skills transfer.
- Remote and geographic flexibility remain more available here than in most comparably paid work, though less so than during the peak of remote hiring.
- The knowledge compounds. Unlike tool-specific skills, understanding how systems fail and how data moves stays valuable across every technology shift so far.
How it works: what separates the two categories
The Bureau’s distinction is not bureaucratic. It tracks something real about where value sits, and it predates the current wave of AI by many years.
Computer programmers, in this classification, write and test code against specifications produced by someone else. Software developers design the systems, decide what those specifications should say, and own whether the result works. Real jobs blend the two, but the split describes a genuine difference in what someone is paid for.
Automation widened the gap rather than creating it. A model given a clear specification produces working code quickly, which compresses precisely the activity the programmer category describes. What it does not do is decide what should be built, notice the requirement is wrong, or accept responsibility when the system fails in production at three in the morning.
That is why the same technology produces 10 percent growth in one category and a 7 percent decline in the other. It is not that developers are safe and programmers are not. It is that work defined by implementing to a specification became cheap, and work defined by deciding and owning did not.
The practical consequence for someone entering is that the target is the second category from the start, rather than assuming it arrives with time served. It used to arrive that way, because years of implementation work taught you the systems. That route is thinner now, which changes how the first few years have to be planned.
What the first three years actually look like now
Anyone assessing this career needs a realistic picture of the entry period, because it differs from what the guidance written five years ago describes.
The traditional shape was an apprenticeship in all but name. A junior received well-scoped tasks, produced them slowly, had the work reviewed, and absorbed how the system fitted together through repetition. Competence arrived after a couple of years of that, largely without anyone teaching deliberately.
What replaced it is less structured and more variable between employers. Production of straightforward code is faster than briefing someone, so the tasks that used to be delegated frequently are not. Juniors who thrive now tend to be given ambiguous problems earlier, with more support, which is a better learning experience when the support is real and a considerably worse one when it is not.
That variability makes the choice of first employer matter more than it used to. Two organisations offering similar salaries can differ enormously in whether anyone reviews your work, whether you are trusted with a decision, and whether there is a named person responsible for your development. Those questions are worth asking directly in interviews, and the quality of the answer is informative in itself.
The other change is that visible evidence carries more weight at the point of hiring. Something you built and can explain in depth, including what you got wrong and how you found it, demonstrates the judgement that used to be inferred from a couple of years of employment. It is a slower route than the old one and it is available without permission from anybody.
Proof, examples, and objections
The strongest evidence is that this pattern repeats across the whole technology sector rather than appearing only in software.
Computer network architects grow 8 percent at $134,050, while network and computer systems administrators decline 4 percent at $99,130. Computer support specialists fall 3 percent. Design and accountability grow; execution of known procedures contracts. Four occupation pairs, one consistent rule.
Objection: the junior market has collapsed, so the growth is irrelevant to a newcomer. Partly fair and worth taking seriously. The well-specified tasks juniors used to do are what models handle best, and hiring at that level has genuinely tightened. But 185,400 additional positions plus turnover across 1.9 million roles is a large amount of hiring, and it is not going to happen without people entering. The realistic reading is that entry is harder and narrower, not closed.
Objection: AI will keep improving until the developer category goes too. The projection already assumes continued improvement, since it was produced recently by an agency that tracks this. More importantly, the constraint on the growing category is not technical capability. It is that someone must decide what to build and answer for whether it worked, and no vendor has offered to hold that.
Objection: the pay figure is inflated by a small number of very high earners. Median rather than mean is quoted here specifically to address that. Half of the occupation earns more than $134,040, and half earns less, which is a different and far more useful claim than an average would be.
Objection: exposure scores say software is highly automatable. They do, and the Bureau publishes AI exposure categories for 831 occupations while stating plainly that exposure “does not imply job loss, productivity gains, automation probability, or wage effects.” A high exposure score alongside a 10 percent growth projection is exactly the case that illustrates why the two measures are different.
On qualifications, the picture has shifted rather than weakened. A degree or a structured certification gives you the fundamentals, a shared vocabulary and access to hiring processes that screen for them. What has changed is that pairing that with something demonstrable, whether a domain you understand or a project you can talk through in depth, now matters considerably more than it did when the junior tier taught people by default.
Building the judgement to direct these tools, review what they produce and know where their confident output fails is itself a skill, and it transfers as the tooling changes. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
Where the field goes over a decade
Three shifts are already visible and worth planning around rather than reacting to.
Verification becomes the paid skill. As production of code approaches free, the scarce activity is establishing that what was produced is correct, secure and does what was actually needed. That is review, testing and systems reasoning, and it is undervalued relative to how difficult it is.
Domain depth separates people more than technical depth. An engineer who genuinely understands healthcare billing, financial compliance or industrial control makes better decisions about what to build than one who knows another framework. Employers consistently describe this combination as the hardest thing to hire for, and it is available to anyone willing to learn a subject alongside the craft.
Security absorbs more of everything. The 21 percent growth in information security analysts is not a separate profession drifting away from software; it is security responsibility spreading into ordinary engineering work. Anyone entering now should expect it to be part of the job rather than someone else’s department.
None of these requires predicting what the tooling looks like in 2035, which is fortunate because nobody can. They follow from the structure of the work: someone has to decide what to build, someone has to confirm it works, and someone has to answer when it does not. Those three requirements have survived every change in how software gets written so far, and there is no particular reason to expect the next one to remove them.
Your next step
Look at the two occupational categories side by side before committing to any particular course or bootcamp, and ask which one the training you are considering actually prepares you for. Programmes that teach syntax and framework use point at the declining category. Programmes that build systems thinking, debugging and design point at the growing one.
Then pick a domain alongside the technical skill. The scarce input in this field is not knowing another language; it is knowing what the software should do for a particular industry and being able to argue for it. That combination is what employers describe as hardest to hire for, and it is available to anyone willing to learn a subject as well as a stack.