Yes, but not for the reason most people learned it a decade ago. The value has moved from producing code to deciding what should be built and verifying that what got built is correct. The employment data separates those two things sharply. Federal projections put software developers, quality assurance analysts and testers at 10 percent growth from 2025 to 2035, much faster than average, at median pay of $134,040. Over the same decade computer programmers are forecast to decline 7 percent at $100,390.
Two occupations, same industry, same skills at the entry point, opposite trajectories. Understanding what separates them answers the question better than any general claim about AI.
Key points
- The growing category is developers, at 10 percent to 2035; the declining one is programmers, at minus 7 percent.
- The difference is deciding versus implementing. One category designs and owns outcomes; the other writes to a specification.
- Writing code got cheap. Reading it, judging it and knowing what to build did not.
- Learning to code is now learning to evaluate code, which requires writing enough of it to develop judgement.
- The entry route got harder, because the simple tasks juniors learned on are the ones models handle best.
Why two coding occupations diverge
The Bureau’s distinction is not arbitrary and it predates generative 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. In practice many jobs blend the two, but the statistical split tracks something real about where value sits.
Automation has widened the gap rather than created it. A model given a clear specification produces working code quickly, which compresses exactly the activity the programmer classification describes. It does not decide what the specification should be, notice that the requirement is wrong, or take responsibility when the system fails in production.
The same pattern appears across the technology sector. Information security analysts grow 21 percent at $129,180 median. Computer support specialists decline 3 percent and network and systems administrators 4 percent. Roles defined by executing known procedures contract. Roles defined by design, judgement and accountability grow.
What learning to code is actually for now
The honest case for learning has changed, and stating it plainly is more useful than reassurance.
To read code you did not write. This is the largest single change. A great deal of professional work now involves reviewing generated code, and reviewing requires knowing what correct looks like. Someone who cannot read code cannot supervise a system that writes it, and the review is where the remaining risk lives.
To know what is possible. Deciding what to build requires understanding what is cheap, what is expensive and what is genuinely hard. That intuition comes from having built things, and there is no shortcut to it.
To specify precisely. The skill of describing a requirement without ambiguity is the same skill whether the recipient is a compiler, a colleague or a model. People who have written code specify far better than people who have not.
To debug. When something behaves unexpectedly, someone has to form a hypothesis, test it, and narrow down the cause by elimination. This remains the least automated part of software work and the most reliably valuable, because the interesting failures are the ones nobody anticipated well enough to write a check for.
To understand systems, not just syntax. How data flows, where state lives, what happens under load, why this design will not scale. None of that is typing.
Notice that none of these is producing lines of code, and all of them require having produced lines of code at some point. That is the awkward shape of the current situation. The output is worth less, and the practice that develops the judgement is still necessary.
There is a useful comparison here with other fields that automated a core task. Pilots still learn to fly manually even though autopilot handles most of a flight, because the value of the human appears precisely when the automation stops coping, and you cannot supervise a system you have never operated. Software is arriving at the same arrangement, and the training implication is the same: you learn the manual skill in order to be competent at the supervisory one.
The junior problem, stated honestly
This deserves its own treatment because it is the strongest argument against learning to code, and most coverage either ignores it or waves it away.
Historically, someone entered software by doing the work nobody senior wanted: writing a well-defined function, fixing a small bug with a clear reproduction, adding a test for existing behaviour, updating a configuration. None of that was glamorous, and all of it was how judgement got built. You saw a hundred small pieces of a system and gradually understood how it fitted together.
That tier of work is precisely what models handle well. A senior developer who once delegated it to a junior can now produce it directly in less time than briefing someone would take. The economic argument for hiring at that level weakened, and hiring data across the sector reflects it.
Two things follow. The first is that anyone entering now needs a different route in, most commonly through a domain, through support or operations roles that touch the software, or through building something visible themselves. The second is that this is a genuine structural problem the industry has not solved, because the people who will be senior in a decade are supposed to be learning right now.
Nobody should decide to learn without knowing this. But it argues for a different approach rather than against learning at all. A qualification opens the first conversations and gives the learning a structure that self-teaching rarely matches; pairing it with domain knowledge or with something you have actually built is what carries the rest of the way. The two together are a much stronger position than either on its own.
What to know before deciding
Several things about the current market matter more than the general question.
The entry route genuinely narrowed. Junior work was historically the well-specified, self-contained tasks that senior people did not want. Those are exactly what models handle well, which has compressed the traditional first rung. This is real and articles that gloss over it are not helping anyone.
Domain knowledge now counts for more. A developer who understands healthcare billing, logistics or financial compliance is far harder to replace than one who only knows the language, because the scarce input is knowing what the software should do.
Verification is a discipline. Being the person who catches the plausible-looking bug in generated code is a defensible position, and it is undervalued relative to how difficult it is.
Learning is faster than it was. The same tools compressing junior work also make learning quicker. A beginner today can get an explanation of any error message instantly, which removes one of the largest historic causes of people giving up. Being stuck for three days on a missing semicolon used to end more programming careers than aptitude ever did.
Passing the test is not the same as understanding. Code that works, produced by a model, teaches nothing unless you read it and can say why it works. This is the main trap for people learning now.
How to learn it so it is worth learning
- Read more than you write. Take generated code and explain what each part does before accepting it.
- Break things deliberately. Change something and predict the failure, then check whether you were right.
- Build one thing end to end. A complete small system teaches more than twenty exercises, because the difficulties are in the joins.
- Learn debugging explicitly. Most courses skip it, and it is the most durable skill in the field.
- Pick a domain alongside the language. The combination is what makes someone hard to replace, and it is the thing employers find hardest to hire for.
- Finish what you start. A completed small project you can talk through is worth more in an interview than three abandoned larger ones.
- Resist accepting code you cannot explain. This single rule is the difference between learning and generating.
Legitimacy and trust: which claims about this are worth believing
Few topics attract as much confident nonsense as this one, in both directions, and knowing how to filter it is worth as much as any answer here.
Claims that coding is finished usually rest on a demonstration: a model produced a working application from a paragraph of description. Those demonstrations are real and they prove less than they appear to. Producing something that runs is the part that got cheap. Producing something that is correct, maintainable, secure and does what the business actually needed was always the expensive part, and no demonstration addresses it.
Claims that nothing has changed are equally unreliable. The junior hiring data is not ambiguous, and anyone telling beginners the market is as it was in 2020 is not looking at it.
The filter worth applying is whether a claim is grounded in something checkable. Federal employment projections are published, methodologically documented and updated on a schedule, which is why this page leans on them rather than on anecdote. They are not perfect, and the Bureau itself notes that its AI exposure categories do not imply job loss, but they are a considerably better basis than a viral demonstration or a recruiter’s impression.
Apply the same test to advice about what to learn. Someone recommending a path should be able to say what evidence supports it, and if the answer is that it worked for them five years ago, that is a data point rather than a plan.
Decision framework
Five questions if you are considering learning to code.
- What do you want it for? Building your own things, moving into the field, or being able to supervise technical work all point to different depths.
- Do you have or want a domain? Coding plus a subject area is a far stronger position than coding alone.
- Can you tolerate a harder entry? The junior market is genuinely tighter than it was, and that should inform the plan rather than be discovered later.
- Will you read what you produce? Learning with these tools works well for people who interrogate the output and badly for people who accept it.
- Is the goal employment or capability? Many people want to build things rather than to be hired, and that is a shorter path with different requirements.
Learning to direct these systems, judge their output and know where they fail is itself a skill, and it transfers across whatever tooling arrives next. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
Your next step
Take some code a model wrote for you and, before running it, write down what you expect each section to do. Then run it and see where you were wrong.
That exercise is the whole of learning to code now compressed into ten minutes. The gap between what you predicted and what happened is exactly the knowledge that makes someone useful, and it is the part no tool produces on your behalf.