Software engineer job postings dropped 20% month-over-month—but rose 11% year-over-year. The gap is where the 'new developer' lives

“AI is going to take our jobs.” Every time I hear this, I can’t help but smile a little.

Five years ago, I had completely walked away from code. My customer success job was fulfilling, and I had no plans to go back to a life of pounding keyboards. Somewhere in my heart I thought “I want to write again,” but that was a sealed-away feeling.

April 8, 2026. CNN Business published an article.

The title: “The demise of software engineering jobs has been greatly exaggerated.”

(Reference: CNN Business)

In that data, I felt I could see myself.

I’m neither on the “engineers will disappear” side nor the “we’re fine” side. As someone who actually left coding and came back through AI, I can say this: there are jobs that will disappear and jobs that will be born. The question is which side you’re on.

Both “down 20%” and “up 11%” are true

First, let’s look at the “decreasing” data.

Zero To Mastery publishes a monthly job market report. According to their March 2026 edition, software developer postings dropped 20% month-over-month. Software engineer postings fell 15.6%. Two consecutive months of decline, with the total job pool shrinking by more than 16,000 listings.

(Reference: Zero To Mastery March Report)

Looking only at these numbers, it feels like “yeah, it’s over.” Combined with the “engineers are obsolete” takes flowing through social media, the anxiety makes total sense.

But look at the annual data, and the scenery changes.

Citadel Securities analyzed Indeed’s data. The result: software engineer postings grew 11% year-over-year. A pace exceeding the all-occupation average.

(Reference: Yahoo Finance)

Down monthly. Up annually. These two datasets that seem contradictory are actually both correct.

The key is what’s inside the “what’s decreasing and what’s increasing.” Break this down, and a map of developer careers in the AI era emerges.

What’s disappearing is “just writing code” jobs

The CNN article introduced an IBM example.

It described how developer jobs have changed dramatically. Once, routine coding work was the center. Now, the work has shifted to talking directly with customers and designing features with AI.

Reading this, I slapped my knee. “That’s literally the CS job.”

In customer success, you listen to customer voices and judge what to build. You organize specs and decide implementation priorities. You also bridge to the tech team. As a CS veteran I can say with confidence: this “what to build” judgment is harder than the skill of writing code. Because there’s never just one correct answer.

In reality, I’ve experienced countless cases where a customer said “I want this feature” but what they truly needed was something different. The ability to see through to the essence beneath surface-level requests. In many situations, that’s worth more than hundreds of lines of code.

Let’s look at Zero To Mastery’s data a bit more closely. What’s decreasing are the generic “Software Developer” and “Software Engineer” positions. While the 16,000+ job pool remains, the shrinking trend continues.

In contrast, “AI/ML Engineer” and “Data Engineer” were flat or slightly up. “Cloud Engineer” showed a similar trend.

In other words, the act of writing code itself is losing value. What’s being demanded instead is the power to design what the code is for.

This overlaps with my own story. The reason I burned out as a new grad was exactly this. The engineers around me had overwhelmingly high code quality, and I couldn’t compete on the same field.

Now we live in an era where AI lifts the floor of code quality. The difference is made outside the code itself—in the realm of “design” and “judgment.” What used to be my weakness has been neutralized by the changing times.

To make it concrete: last month, I built a dashboard visualizing internal inquiry data. Technically, it was a React and Chart.js combo, and Cursor wrote 80% of the code itself. What I did was design “what to visualize” and select “which numbers the CS team actually wants to see.” That judgment is something AI can’t do. It comes from hundreds of conversations sitting next to users.

The BLS prediction of “15% growth” has a trap in its breakdown

Let’s check the U.S. Bureau of Labor Statistics (BLS) data.

Employment of software developers is projected to grow 15% from 2024 to 2034. A number well above the all-occupation average. About 129,200 job openings are projected annually.

(Reference: BLS Occupational Outlook)

But reading this projection as “reassuring material” is dangerous.

Look at the demand breakdown driving that 15% growth: the core is AI, IoT (Internet of Things), robotics, and automation application development. It’s a forecast that developers “who use AI” will increase—not that “people who hand-write code that AI could replace” will increase.

Here’s where my real feeling as Gen kicks in.

Last week I wrote an article trying out all of Cursor 3’s features. I experienced running 8 agents in parallel and generating prototypes in Design Mode.

(Reference: previous article “Still consulting one at a time on Cursor 2? I tried all of Cursor 3’s parallel agents × Design Mode and development became a different game”)

It felt like one developer could output what used to take a five-person team.

What happens when productivity becomes 5x? Simple math says the people you need becomes one-fifth. In reality, though, the range of what you can build expands, so new projects are born and new positions are created.

Since I started using Cursor 3, I’ve added three pieces of work to my “this could be automated” list. The internal inquiry aggregation dashboard, automatic sorting of Slack notifications, automatic weekly report generation. None of these would have been on my radar before Cursor 3.

The evolution of tools generates new demand. BLS’s 15% growth is a number that factors in this “expansion of what can be built.” The question is whether you can be on the side that “outputs 5x productivity.”

Let me share one trap. Cursor 3’s parallel agent feature is convenient, but if instructions are vague, agents compete with each other. I threw “fix the header” and “change the nav layout” at it simultaneously. Two agents rewrote the same file and caused a conflict. You need the skill to properly partition the granularity of instructions. That’s a kind of “design ability” too.

Cursor’s $2B ARR proves how serious tool investment has become

Cursor’s ARR (Annual Recurring Revenue) crossed $2 billion in March 2026.

(Reference: TechCrunch)

A figure that was $100 million in January 2025 ballooned 20x in 14 months. Looking back at SaaS history, Slack took about three years to reach $100M ARR. Zoom took about four years. Cursor got there in about two years, then grew 20x in the next 12 months.

Valuation was $29.3 billion at Series D. There are also reports of negotiations for a further $60 billion-scale fundraise.

(Reference: BusinessWire / Bloomberg)

What do these numbers mean? The clear fact that “developers are paying for AI coding tools.” Both companies and individuals have started investing in AI coding as standard equipment.

When I started using Cursor, I felt like a master-level engineer had taken up residence inside me for $20/month. That untouchable technical level I’d encountered on those hundred-million-yen-scale projects—it’s now in my hands through AI.

Behind that $2B ARR are millions of developers worldwide having the same experience. The view that “AI coding is a temporary boom” no longer holds water. It has become development infrastructure.

What this growth speed tells us is one thing. AI coding has moved from “nice to have” to “you can’t work without it.” A $20/month tool has built a $2B annual market. We need to take that weight head-on.

A 5-question self-diagnostic for getting onto the “growing side”

Are you on the “growing side”? I’ve prepared five questions.

I drew from CNN’s reporting on what an Intuit hiring manager said, combined with Zero To Mastery’s gain/loss data and my own experience.

1. Are you using AI coding tools every day?

According to CNN, Intuit is actively hiring “young developers who grew up with AI.” Cases are emerging where AI-native new grads are evaluated more highly than mid-career developers. The moment you’re not touching the tools, you fall off this current. Cursor, Claude Code, GitHub Copilot. Pick any one—touching it daily is step one.

2. Can you decide “what to build” yourself?

We’re in an era where judging product direction matters more than code quality. As a CS-background person, this was the one skill I could feel confident about. Can you hear what users are struggling with and judge “that’s why we should build this feature”? Reviewing AI-generated code is impossible without this judgment standard.

Let me be honest here. The power to decide “what to build” can be trained even without business experience. Start with the practice of writing down three “inconvenient points” about an app you use and verbalizing “how to improve them.” The muscle of thought grows from being moved many times.

3. Are you bound to a single language?

A characteristic of the growing job types in Zero To Mastery’s data is this: many positions require knowledge of system design and data pipelines rather than a specific language. Being able to write Python isn’t enough. The question is whether you can understand architecture and give AI appropriate instructions.

4. Can you read AI-generated code?

“It works, but I don’t know why it works.” Honestly, this is also one of my weaknesses. That said, you don’t need complete understanding. The point is being able to grasp “what this code is doing” and judge “is this OK security-wise.” 80% judgment beats 100% understanding in practice.

In my case, I always make Cursor explain generated code in comments. Just instructing “add comments in plain language explaining what each line of this code does” lets me learn and verify simultaneously.

5. Can you produce value in “non-coding time”?

As the IBM example shows, developers are spending more time talking directly with customers. The time saved from writing code can be used for design, review, and customer dialogue. Whether you can produce results in this “non-coding time” becomes the dividing line.

If you can answer three or more of these five with confidence, you’re already on the “growing side,” I think. Even if it’s two or fewer, no need to be pessimistic. If you start touching AI coding tools today, you can definitely grow questions 1 and 4 in a month.

That was me. The day I first booted up Cursor, I sat frozen for 30 minutes not knowing what to do. The first thing I made was “a web page that randomly displays today’s tasks.” Just 20 lines of HTML and JavaScript. The emotion of seeing it work I’ll never forget. That was the moment a master engineer took up residence inside me.

The reason I made it to the “growing side” is because I had burned out

Let me be honest. Of the five questions, the only ones I was strong at from the start were 2 and 5.

The judgment of “what to build” and the value of “non-coding time.” These were skills I’d been training for years on the CS front lines. Hear customers’ voices, prioritize, communicate to the tech team. Instead of writing code, define the problems code should solve. I’d spent years living that every day.

Question 1 (daily AI tool use) was a complete zero until I started touching Cursor. Question 3 (breadth of languages) was just having touched front and back broadly and shallowly. As for question 4 (reading AI code), there are still scenes today where I’m genuinely shaky.

Even so, the reason I made it to the “growing side” is because I had burned out.

There was a day I admitted I couldn’t beat pro engineers. From that day on, I thought painfully often about “what am I good at and what am I bad at.” Where I landed was the position of “an engineer who understands users’ feelings.” When the AI era came, the value of this position jumped.

The experience of losing on code quality is now an advantage. If AI writes the code, there’s no need to compete on code quality. Instead, I can compete with the power to judge “why this code is needed.”

I want to say this especially to people who’ve burned out. Your “time when you couldn’t write code” might become an AI-era advantage. The experience you accumulated on the floors of CS, marketing, or sales is itself the judgment of “what should be built.”

When someone with that judgment picks up AI coding tools, they can become a “new developer.” I’m convinced that’s who gets onto the “growing side” of the job data.

When will this current reach developers in Japan?

The CNN article is based on U.S. market data. What about Japan?

Honestly, analysis at the same precision hasn’t come out for Japanese job data yet. But there are plenty of signs.

As Cursor’s growth speed shows, AI coding tools are steadily spreading in Japan too. Around me, I’ve seen about three cases where CS-background non-engineers started building internal tools with Cursor. I’ve also started seeing “AI experience preferred” being added to “no programming experience required” job postings.

I heard a story about a SaaS company’s CS division where the CS staff themselves built an inquiry analysis dashboard with Cursor. Work that previously required a 3-month wait after requesting the dev team was completed in two weeks. The moment when “developer” gets redefined—I’ve started witnessing it in Japan too.

The BLS 15% growth projection is a U.S. number. Given the globalization of software development, there’s no doubt Japan will move the same direction. Even if delayed, it’ll be a 1-2 year gap.

If anything, the fact that there are almost no articles explaining this structural change in Japanese feels like an opportunity. There are still few voices speaking about “the polarization of developer careers” in the Japanese context. If you’re reading this article, you’re already on the high-information-sensitivity side.

What’s happening in America will happen in Japan. The question isn’t “when,” but “which side am I on when it happens.”

You can start preparing today. You don’t need expensive courses or a long learning period. Install Cursor or Claude Code. Try automating one task you feel is “annoying” in your work. That’s the first step.

Summary: What the contradiction in the job data taught us

Down 20% monthly, up 11% annually. The true identity of this contradiction was “the definition of ‘developer’ is changing.”

By the old definition of someone who writes code, postings are decreasing. By the new definition of someone who designs products using AI, postings are increasing. BLS sees 15% growth over the next 10 years. Cursor hit $2B ARR in 14 months.

Let me organize the data introduced in this article.

• Zero To Mastery: Monthly -20%/-15.6% drops. Shrinking of generic positions
• Indeed/Citadel: Annual +11% growth. Exceeding the all-occupation average
• BLS: 15% growth projection through 2034. Annual demand of 129,200 openings
• Cursor ARR: $100M → $2B in 14 months. Fastest-class in SaaS history
• Valuation: $29.3B (Series D) → $60B in negotiation

All these numbers point in one common direction. AI coding tools aren’t “tools to replace engineers.” They’re “tools to rewrite the definition of engineer.”

On the shrinking side are people dependent on manual routine coding. On the growing side are people who wield AI as a tool and produce value through design and judgment. That boundary line is drawn not at “code quality” but at “the judgment of what should be built.”

I once felt I couldn’t beat pro engineers and walked away from code. AI came and I was able to return. The era of competing on code quality is ending, and the era of competing on “what to build” and “for whom to build” is beginning.

I want to tell my five-years-ago self: “I’m glad you didn’t give up. AI came. You can build again.”

I want to give the same words to you reading this. If you haven’t started writing code yet, today is your starting day. Install Cursor and try building one “thing that just works.” Whether you’re on the shrinking side or the growing side—that starts to change with that first one.