They Pulled the Ladder Up from Below: Why Breaking Into Software Is Harder with AI

Once a week my feed serves up another prediction: in a year or two AI will replace programmers, juniors are obsolete, learning to code is pointless. The authors change, the arguments don’t. Someone shows an agent building an app in an evening, someone quotes a CEO promising investors to “do more with fewer people”, and a thread about the end of the profession is ready. The hype crowd keeps pouring the same three ideas from one glass into another, and every round they sound more certain.

I look at this from two sides. I have been writing iOS apps for more than eight years, I’m job hunting right now, and I see the market from the inside: openings, interviews, requirements. I also invest, and I read the quarterly reports of the very companies whose executives hand out those loud forecasts. Put a layoff press release next to the shareholder report and the picture turns out far more down to earth than in the threads.

My position is simple: AI is not replacing developers. The layoffs come down to money. First, the cheap money that companies used to hire people they didn’t need in 2020–2021 ran out. Now money is also flowing into AI hardware, and part of the bill is paid out of payroll. AI is a convenient signboard in this story: telling investors “we’re reorganizing around a new technology” is far more pleasant than “we got our headcount planning wrong”.

That doesn’t mean I’m ready to claim AI changed nothing. It changed a lot, just not where the hype crowd is looking. It isn’t the main reason for how many developers are being hired, but it noticeably changes what kind of developer is needed. And that hits hardest the people who are only trying to get into the profession.

Below I take both parts in order. First, what actually happened to the market and what the reports say. Then, what changed in the work itself and why the entry bar keeps creeping up.

What actually happened to the market

#

A party on cheap money

#

In 2020–2021 the Fed’s rate sat near zero, everyone was at home living inside apps, and investors paid for growth and weren’t too curious about profit. Companies hired ahead of demand, on plans in which the pandemic surge in digital services became the new normal. Indeed’s index of software development job postings (February 2020 = 100) reached 234 at the end of February 2022: employers were looking for developers 2.3 times as actively as before the pandemic (FRED / Indeed Hiring Lab).

The companies themselves don’t deny the overhiring. In November 2022 Zuckerberg announced a cut of 13% of Meta’s staff, more than 11,000 people, and wrote it plainly: “I got this wrong, and I take responsibility.” He had expected the pandemic growth to last, and it didn’t (Fortune).

Money got expensive

#

In March 2022 the Fed started raising rates, and by summer 2023 it had brought them to 5.25–5.5%. The investors’ question “how fast are you growing?” turned into “when will you start making money?”. And the easiest place to save is the biggest line in an IT company’s budget: people.

Look at the dates. Postings began to fall in spring 2022, right after the first rate hike. The index dropped below its pre-pandemic level in spring 2023 and hit bottom, around 61, only in May 2025. ChatGPT came out on November 30, 2022, when the decline was already six months old, and back then replacing even one developer with it would have been a very bold idea. Now, at the end of October 2026, there are still about 19% fewer postings than before the pandemic.

From the inside it looks like this. In three or four years the market went from active hiring to a sluggish, stale state. It used to be common that a couple of technical screens and a chat with the hiring manager were enough for an offer. Now a recruiter call can easily be followed by two technical screens, a call with the manager, and then a full onsite panel. The data shows the same from the other side: according to Ashby, hiring one person into a technical role now takes interviewing 17.6 candidates, versus 11.6 in 2021 (Ashby). And a noticeable share of openings seems to exist only for show: by Greenhouse’s estimate, in one quarter of 2024, 18–22% of postings on its platform were “ghost jobs” that nobody was hiring for (FOX 29).

AI as a signboard

#

Against this background AI turned out to be a very convenient explanation. In January 2026 Oxford Economics calculated that in the US AI was cited in roughly 55,000 layoffs over the first 11 months of 2025. That is about 4.5% of all announced layoffs, while “market and economic conditions” accounted for around 245,000, four times as many. The analysts say outright that they suspect companies of repackaging ordinary layoffs as a story about a technological pivot (Fortune). Molly Kinder of the Brookings Institution called such an explanation a “very investor-friendly message” (TechCrunch). The phenomenon already has a name: AI-washing.

What the reports show

#

Let’s test the hype crowd’s version with simple logic. If AI replaced developers, two things should show up in the reports at once: headcount shrinking, and productivity and margins growing like crazy. The costs are gone, the output stayed.

Profit did grow after layoffs, but not because of AI. In the fourth quarter of 2023 Meta tripled its profit with 22% fewer staff than a year earlier, and Zuckerberg called 2023 the “year of efficiency” (TechXplore). Agents that write code didn’t exist yet. Profit grew because payroll was cut and the ad market rebounded.

An explosion in productivity, on the other hand, isn’t there. According to the same Oxford Economics, labor productivity growth is slowing, not accelerating. In the MIT NANDA report (2025), about 95% of corporate generative AI pilots produced no measurable effect on profit (Fortune). In a METR study, experienced developers using AI tools solved tasks 19% slower, even though they were sure they had sped up (The Decoder).

When I open annual reports, the first things I look at are headcount, capex, free cash flow and debt. And on those lines the picture is nothing like the press releases.

---
config:
  themeVariables:
    xyChart:
      backgroundColor: "transparent"
      plotColorPalette: "#eb6834, #2a78d6"
---
xychart-beta
    title "Meta + Alphabet + Microsoft: capex and headcount (2019 = 100)"
    x-axis [2019, 2020, 2021, 2022, 2023, 2024, 2025]
    y-axis "index" 0 --> 450
    line "Capex" [100, 100, 121, 165, 167, 255, 429]
    line "Headcount" [100, 116, 133, 162, 153, 158, 162]

Orange line: capex. Blue line: number of employees. Source: 10-K annual reports; Microsoft’s fiscal year ends June 30.

Take Meta, Alphabet and Microsoft together. In 2022 they employed 497,700 people. In 2025, again 497,700: headcount returned exactly to the peak of the pandemic hiring, no more and no less. Meanwhile capex, the money for data centers and equipment, grew over the same period from $86.8 billion to $225.7 billion, 2.6 times (10-K annual reports, SEC). For 2026 Alphabet plans $175–185 billion and Meta $115–135 billion (Alphabet, Meta). They haven’t added people for four years, while the money for hardware grows many times over.

That money shows up on two other lines too. Amazon’s trailing twelve-month free cash flow fell to $1.2 billion in the first quarter of 2026, from roughly $26 billion a year earlier (The Next Web). And their own cash is no longer enough for the buildout: according to Dealogic, Alphabet, Amazon, Meta, Microsoft and Oracle issued $159 billion of bonds in the first five months of 2026, more than in 2020–2024 combined (24/7 Wall St.).

The buyers of AI have a line item of their own: tokens. Uber burned through its annual AI tooling budget for development in four months, largely on Claude Code, with employees nudged toward it by an internal ranking of teams by AI usage. Asked whether those tokens turn into more useful features for customers, Uber’s president and COO Andrew Macdonald answered: “That link is not there yet” (Fortune).

A fresh example: Microsoft

#

While I was writing this article, Microsoft offered voluntary buyouts to about 60,000 employees, around 27% of its staff. Half a year earlier the company had launched an early retirement program and then laid off 4,800 people (Forbes). According to the annual report, in the fiscal year that ended in June 2026 headcount fell from 228,000 to 223,000, while spending on equipment grew from $64.6 billion to $115.9 billion (10-K, SEC). CNBC framed the buyout news like this: “as AI leads to efficiency push” (CNBC).

I read it differently. AI really is behind part of the layoffs, just not the way the threads tell it. People aren’t being replaced by machines. People are being cut so there is something to pay for machines and tokens. For AI sellers like Microsoft itself, it’s a bet on future revenue. For the buyers, judging by Uber and the MIT report, tokens aren’t turning into profit yet.

Where AI really is involved

#

Saying AI has nothing to do with any of this would be as much of a stretch as shouting about the end of the profession. It has its own, quite specific segment: the bottom rung.

Stanford economists (Erik Brynjolfsson and co-authors) took payroll data from ADP, one of the largest payroll processors in the US, and looked at employment by age. In the occupations most exposed to AI, software development among them, employment of 22–25-year-olds in the first version of the paper (data through July 2025) fell by about 13% relative to other groups, and in the latest one, from August 2026, the gap reached 19%. For more experienced colleagues in the same occupations, employment held steady or grew (Canaries in the Coal Mine).

My first reaction was predictable: it’s interest rates, when money is expensive the young are hired last. The authors tested that version separately and found no confirmation: the occupations more exposed to AI are, on average, even less sensitive to rates (Stanford DEL). But the timing matters: under the strictest test the gap becomes statistically significant only from 2024. AI does not explain the main wave of layoffs in 2022–2023, but it explains well what is happening after it.

At the same time, AI is not killing demand for developers overall. Since the end of February 2025, when Claude Code came out, software development postings in the US on Indeed have grown by almost 15%, even though total postings fell by 7%. What matters is who exactly became needed: 71% of the increase came from senior positions (Indeed Hiring Lab).

Put it all together and the picture is this. How many developers the market needs is decided by interest rates, investors and hardware budgets, and AI as a replacement for people plays a supporting role there. But which developers are needed is increasingly decided by AI. Experienced people who can steer a model are sought more actively. Those who have just arrived, less and less. Even when money gets cheaper and hiring revives, entering the profession won’t be what it was in 2019. Next, why.

How the work itself changed

#

For me this shift turned out to be more noticeable than any chart. Over the last year working with code has changed dramatically, and I see it from two sides: in my own side projects and in interviews.

In interviews, hiring managers increasingly admit themselves that their teams haven’t touched code by hand for months and only write prompts. Public statements sound the same. In February 2026 Spotify co-CEO Gustav Söderström said the company’s best developers “haven’t written a single line of code since December”: an engineer asks Claude to fix a bug in the iOS app on the way to the office, gets a build in Slack and merges it to production before arriving at work (TechCrunch). In spring 2026 Sundar Pichai said AI generates 75% of new code at Google, up from about 25% in 2024 (Semafor). Yes, these are CEO words aimed at investors, and after the AI-washing section I don’t advise taking them on faith. But on the main point they match what I see myself: less and less code is written by hand.

Interviews have caught up. In my experience, about every second interview loop now includes a stage with AI: either writing code together with an assistant, or debugging. Meta started testing this format back in summer 2025 (TechRadar), and in May 2026 it became known that Google is launching a pilot in the second half of the year where candidates for junior and mid-level roles will be allowed to use Gemini in the round on reading and debugging someone else’s code (Business Insider via Yahoo Finance). I write about these rounds in more detail in a separate article.

What does all this mean for everyday work? Before, most of the time went into translating a solution into code: syntax, APIs, boilerplate, documentation. Seniors found this routine the most draining: the solution has been clear for ages, and you still have two more days of typing it out. Now there is always a junior or a mid-level (depending on the model) at hand, and you can hand them the job of sketching all the boilerplate by the rules you set. While the model spits out tokens, you have time to think about the rules themselves.

What stays with the human is everything around the code. Setting the task and gathering context. Breaking it into pieces the model can do reliably. Deciding how the architecture is laid out and where the module boundaries run. Reading and reviewing what the model wrote, verifying it with tests and debugging. And answering for the result, because the model doesn’t. In short, the developer turns from an executor into a tech lead over a very fast and very self-assured junior who sometimes lies.

Which skills come to the front

#

The main skill used to be “I can write it”. Now it’s “I know what it should look like before it’s written”. In side projects this is clearer to me now than ever. The most valuable thing I bring to working with a model is not typing speed but an idea of what the code should be: which patterns the business functionality maps onto, which architecture wraps the process, by which criteria I’ll accept the result.

That’s why before generating anything I get to grips with the domain myself. Not to write everything by hand, but to understand which implementation I want to see, and where its critical paths and failure points are. Without that I can neither set the task nor check the result.

At the general planning stage, by contrast, the model can be let off the leash. What if we build the process like this? What if on-device ML shows up later? Which SQLite wrapper to pick if the flows are reactive? How do we test this critical path? The model will sketch five options where I’d have stopped at two, and its answers can be turned this way and that like a seasoned data analyst would: compare them by criteria, ask it to criticize its own proposal. It is safe to let it loose here for a simple reason: nothing has reached the codebase yet, and a mistake costs one discarded idea.

As soon as the model starts writing code, the leash gets shorter. It doesn’t remember past sessions, so its memory becomes the documentation: what is being done, why, and which decisions led to a given approach. It also knows how to deceive itself. A test fails, and the model “fixes” the test instead of the code. That isn’t paranoia: the phenomenon has a name, reward hacking, and researchers at METR documented models tampering with checks so that any solution passes, even when explicitly asked not to cheat (METR). So I protect tests, documentation and git history technically, not with requests in the prompt. How exactly, with hooks, permission rules and their non-obvious holes, I’ll cover in a separate article.

Everything listed (architectural vision, domain knowledge, acceptance criteria, supervision of the executor) used to be called the skills of a senior or a tech lead. Now it’s the baseline kit for working with a model. And this is where the main problem begins.

Why this doesn’t work without fundamentals

#

All these skills rest on one foundation: you understand what the code you didn’t write yourself does, and you notice what’s missing from it.

You can only review what you understand. A model will confidently produce a closure that captures self and quietly keeps a view controller in memory. Or update the UI off the main thread. Or pass an NSManagedObject from one Core Data context to another, and everything works right up to the first serious load. The code compiles, looks tidy, and the tests the model wrote for it itself are green.

But more often than errors in what the model wrote, I run into what it didn’t write. The model loses states. Picture working with any entity as a tree of options: data goes down the correct path, fails with an error, goes to retry, and at every step there may be a fork. In multi-step processes the model most often implements the happy path with confidence and drops the handling of the other branches.

That’s how it went in my document processing side project. There are many stages: import, recognition, analysis, user confirmation, event generation. And each stage breaks down into substeps. Import alone requires saving the file to disk, writing it to the database and generating a preview.

flowchart TD
    A["User picks a document"] --> B["Save file to disk"]
    B -->|ok| C["Write record to database"]
    C -->|ok| D["Generate preview"]
    D -->|ok| F["Document ready for recognition"]
    F --> G["Recognition"]
    G -->|ok| H["Analysis → confirmation → events"]

    B -.->|"no space, I/O error"| E1["Report the error,<br/>save nothing"]
    C -.->|"database error"| E2["Delete the file from disk,<br/>roll back the import"]
    D -.->|"preview failed"| E3["Show a placeholder,<br/>retry in background"]
    G -.->|"app was closed"| E4["Save progress,<br/>resume on launch"]

    classDef happy fill:#2a78d6,stroke:#2a78d6,color:#ffffff
    classDef lost fill:#fcfcfb,stroke:#eb6834,stroke-width:2px,stroke-dasharray:5 4,color:#0b0b0b
    class A,B,C,D,F,G,H happy
    class E1,E2,E3,E4 lost

What happens if the file was written to disk but not to the database? If the preview failed to generate? If the user closed the app in the middle of recognition? Unless you walk the model through every step and every branch, it will most likely just skip them. The code still looks finished. A skipped branch isn’t visible in review; you have to know about it in advance.

Where does that knowledge come from? Not from documentation. My instinct for this kind of thing grew at a previous job, where I worked on complex messenger functionality. Even ordinary messages travel a long way: load, check for overlaps with what already exists, filter, write to the database, read the right slice back from the database, make sure the data layer has no duplicates, and only then show it. An error at any step turns into a lost or doubled message in a real person’s chat.

Calls are even more fun. I wrote them from scratch and maintained them alone. You are juggling states and events from CallKit, AVAudioSession and the calling library (LiveKit in my case), the user database for conferences, interactive events from the socket, and media streams all at once. Each of these systems lives its own life and can change state at any moment. After a school like that, the question “what happens if everything goes wrong right here?” asks itself. The model doesn’t ask it. You do, if you know what to ask.

That’s how the “something is off here” instinct accumulates: from hundreds of small mistakes made by hand, from the crash you chased until two in the morning, from the leak you found in Instruments a week after release.

There is data too. In early 2026 Anthropic ran a randomized experiment: 52 developers, mostly juniors, learned Trio, a Python async library new to them. Half worked with an AI assistant, half without. On the final test of the material the AI group scored 50% on average, the group without AI 67%. The gap was widest on debugging questions, which is exactly the skill that becomes central when working with a model. Meanwhile the AI group finished only a couple of minutes faster, and that difference is not statistically significant (Anthropic).

There is an encouraging detail in the study as well. Participants who asked the AI conceptual questions or had it explain generated code learned with almost no loss: 65% or higher on average. The worst results, below 40%, came from those who delegated the task entirely. The groups are small, and the authors call this part of the findings correlational. But the direction is clear: AI hurts learning when it works instead of you, and barely hurts it when it works as a teacher.

They pulled the ladder up from below

#

Now the main paradox. The fundamentals without which the skills from the previous sections don’t work used to be built on quite specific tasks. And those are exactly the tasks a model handles best.

When I came into development, for the first six months, maybe a year, I did tasks of this kind: figure out why a view has the wrong color, why a button doesn’t respond to taps, why a collection shows the wrong cell. A language model now finds and fixes this in no time. But it is on these tasks that the foundation gets laid. Not the theoretical one, which you can get from books, but the understanding of how theory lands on practice. The button doesn’t respond because a transparent view lies on top of it or the parent has isUserInteractionEnabled turned off, and while you hunt for that, you truly work out for the first time how hit-testing works. The collection shows the wrong cell because cells are reused and you didn’t reset the state of the previous one, and that’s how you learn about reuse: not from an article but from your own bug.

The market, meanwhile, says it outright: such tasks are no longer for a developer. How is a junior supposed to force themselves to do by hand what a model will do from one short prompt? And watching someone else solve the problem is nothing like struggling with it for half a day, digging through documentation and figuring out how it works under the hood. That “struggle” even has a scientific name: psychologists Robert and Elizabeth Bjork of UCLA call such conditions desirable difficulties. Learning this way is harder and slower, but the knowledge sticks far more firmly than after skimming someone else’s solution (APS Observer).

Now add expensive money. Companies used to take juniors on for growth, hand them that very stream of small bugs and wait for them to grow into mid-levels. It was an investment with a delayed payoff, and at zero rates you could afford it. With expensive money the payoff is needed now, and an agent closes small bugs faster and cheaper than a junior. According to SignalFire, in 2024 new graduates made up just 7% of hires at the 15 biggest tech companies, and their hiring fell by more than half compared with 2019 (SignalFire).

That’s the whole construction. Expensive money discouraged companies from investing in training. AI removed the tasks people learned on. Each factor alone could still be lived with. Together they took the ladder apart from the bottom: the upper rungs are in place, and that’s where people are being sought (remember, 71% of posting growth was for seniors), while the first rungs are gone.

What to do about it

#

First, the analogy most often brought up in AI debates. Compilers, frameworks and Stack Overflow also took part of the manual work away from developers, and each time someone buried the profession. I mostly agree with that analogy. It’s just that the conclusion usually drawn from it is the wrong one.

Look at who is still valued the highest: people who understand what happens under all the layers of abstraction. In the late 1990s Chris Sawyer wrote RollerCoaster Tycoon 99% in x86 assembly (Wikipedia). Chris Lattner started LLVM as a graduate student, then built Clang and Swift at Apple, then created Mojo, a language for AI development, at his company Modular, and now leads advanced AI and platforms at Qualcomm (Lattner’s résumé). The knowledge of people like this goes very deep into the domain, with a cultural layer of modern advances grown on top. As a result they have both a deep view of the essence of things and a wide view of a large slice of the industry. Abstractions did not cancel the value of understanding what lies beneath them. They made that understanding rare, and therefore expensive.

With AI it’s the same story, only the abstraction layer is thicker and the temptation not to look beneath it is stronger.

For those entering the profession

#

If a junior asked me where to start, I’d answer like this: don’t collect recipes, develop an approach. Specific tasks will keep changing, and a model will solve any of them faster than you. What’s valuable isn’t the answer to “why doesn’t the button respond”, but the ability to find the cause yourself, propose a solution and defend it. In front of a person or in front of a model, it doesn’t matter.

The rest follows from that. Before asking the model, understand the domain yourself: what the implementation should look like, where its critical paths are, what can fail. Use the model as a teacher, not as an executor: the Anthropic study above shows that those who asked “why” learned almost without loss. Fix bugs by hand in at least one project where agents are banned. And dig one layer deeper than your tool requires. If you write in SwiftUI, learn UIKit, which it is still closely entangled with. If you work with SwiftData, look into Core Data. If the model proposed a solution with actors, understand what they guarantee and what they don’t.

For teams and tech leads

#

When I onboarded juniors, an iterative approach worked best, and it’s strikingly similar to working with a model. You set a plan with concrete problems. The junior goes off, looks for causes and proposes solutions. You discuss their reasoning: either you accept it or steer it the right way. That’s how you gradually walk them through all the layers and functionality they will be working with. The point isn’t to give tours of the codebase, but for the junior to develop an approach to varied tasks. The tasks shouldn’t become familiar, and the approach should crystallize regardless of the problem domain.

Now it’s worth doing this on purpose, because on its own it no longer happens. Leave juniors some tasks “by hand” as an investment, not as an inefficiency. Yes, an agent will do it faster. But in two years you’ll need a mid-level who understands your codebase, not a person who knows how to press “accept”. And review not just the code but the understanding: the question “explain why it’s done this way” separates someone who figured it out from someone who simply accepted the model’s suggestion.

Conclusion

#

Back to the threads from the beginning. Developers are being cut not because AI replaced them. They are being cut because cheap money ended while the headcount hired with it stayed, and because money now goes to AI hardware. In this story AI is a convenient signboard for investors and a line item that justifies cutting payroll.

But AI does change the profession, just in a different place. It cuts not people but the rungs people used to climb. Entry into the profession shifts from “I can write code” to “I can think about a system and verify the result”, and that shift will stay even when money gets cheap again.

The fundamentals haven’t gone anywhere. It’s just that nobody will let you build them on the job anymore. You’ll have to do it yourself.

And the next time another thread about the end of the profession lands in your feed, look at the dates, at the reports and at the Fed rate. The picture usually turns out far more down to earth.

Sources

#