During the pandemic tech boom, "learn to code" sounded like universal career advice. Companies competed for developers; in 2021, there were over 1.2 million active job openings in computer-related occupations in the US. In that environment, it was easy to believe that the main ticket into the industry was knowing how to write code.

Today, AI is getting increasingly good at translating a well-defined task into syntax — and the market confirms just how good it's gotten: over two years, the US has lost 27.5% of computer programming jobs. But there's another side to this: jobs for software developers have declined by just 0.3%. The Bureau of Labor Statistics projects 15% growth in software developer roles by 2034 — faster than the average across all occupations.

I've spent more than 20 years in technology education, and I've always believed it should be built around what industry actually needs. Right now, that need is for professionals who know how to work with AI, verify its output, and make engineering decisions. In this column, I'll try to unpack what it takes to become one.

Knowing how to code is no longer enough

The question "will AI tools replace software developers" makes for a great headline, but it oversimplifies what developers actually do. Recently, former Google Distinguished Engineer Kelsey Hightower put it this way: AI won't replace software engineers, but it does make those who only know how to code vulnerable.

Some companies are already restructuring development around AI. In February, Spotify announced that the company's best developers "hadn't written a single line of code since December." Google CEO Sundar Pichai said AI now generates 75% of the company's new code — up from 25% in 2024 — and that engineers increasingly act as reviewers who approve that code rather than write it.

Developer attitudes toward AI remain divided. Some treat it as a near-mandatory work tool. Others see it as a source of "AI slop" — plausible but poorly vetted code that eats into the time of those who have to review and fix it. The most extreme position in this camp belongs to the open-source programming language Zig. The project banned all AI-assisted contributions, with Zig President Andrew Kelley calling them "invariably garbage." Notably, Zig is the language behind Bun — the JavaScript runtime that Anthropic acquired in late 2025 to develop as infrastructure for Claude Code.

However, opinions may differ, the fact remains: producing working code has become easier and cheaper. Producing reliable code has become harder.

How to get there

Here are five things I believe software developers should focus on:

1. You still need to understand code. You can't review AI-generated code if you don't know what a correct solution looks like. Steve Yegge's advice applies here: invest not in the subtleties of syntax or the arcana of a specific language — machines handle that — but in the durable layer: algorithms, data structures, design and software engineering, operating systems, databases, networking. The principle: learn what's beneath the tool, not the tool itself.
2. Learn to verify, not just generate. In the AI era, code review, testing, and debugging are becoming core professional skills. And they're built through specific habits: read unfamiliar code and force yourself to explain what it does and where it might break; write tests yourself, and when AI generates them, evaluate them critically. Decide in advance what "done" means, so that "almost right" doesn't pass for "production-ready."
3. Develop the ability to see the whole system, not just its parts. AI helps you get an impressive draft quickly, but debugging, maintainability, and production pressure demand engineering expertise. Read design docs and postmortems, study architecture decisions, look at how services connect to one another. That's how you build the skill of evaluating not just a local fragment of code but understanding how it will interact with the entire system. Otherwise, you end up with what Addy Osmani called "house of cards code" — code that looks functional but collapses under real-world load.
4. Know how to frame a task for AI. Modern models can parse even a clumsily worded prompt. The value lies in what you actually give the model. In essence, you need to work like the author of a good technical brief — designing the informational environment for the model. You learn this by sharpening an old engineering skill: writing a task clearly enough that someone other than you could execute it.
5. Understand people, not just code. AI won't attend a meeting for you or take responsibility for how a product performs. That falls to two skills developers often underestimate — requirements gathering and communication: drawing out what a stakeholder actually wants and explaining a technical decision to non-technical people. Beyond that, you need to talk to the people who will use the product and practice explaining complex things simply.

What could go wrong

It's a straightforward point, but if companies don't create environments where these skills can be developed, eventually there will be no one left to develop them.

There's a useful analogy between software development and medicine — an intern doesn't become a doctor just by having access to information. They need extended practice alongside an experienced professional, and only years later do they earn the right to make independent decisions. But what's left for people just entering the profession if companies hand entry-level tasks to AI?

In this context, the idea of mentorship becomes especially relevant. Microsoft Azure CTO Mark Russinovich and VP of Developer Community Scott Hanselman have proposed exactly the medical model — preceptorship.

In this model, an early-in-career developer and a senior work with AI together: the junior participates in prompting, debugging, and reviewing, while the senior helps them see where AI output only looks functional but doesn't hold up across the system. The goal of this kind of mentorship is to gradually develop judgment in the newcomer.

Adopting this model means companies will have to treat growing junior developers as a direct objective — and accept that for a time, it may reduce their productivity.

Is it realistic to hope this will happen? There are no guarantees. But as long as companies measure AI's effectiveness by the volume of code generated and replace juniors with AI, they risk hitting a ceiling: code will be produced faster than it can be verified. At some point, it will become clear that there aren't enough people capable of turning AI output into reliable systems. When that happens, mentorship will stop looking like an overhead cost and start looking like a way to preserve the profession.