I’ve been using an AI coding assistant for about a year now. Long enough to move past the initial excitement, through a phase of mild overconfidence, and into something closer to a working theory about what’s actually happening to the people building software.
I’ve heard “AI will replace developers” in at least three different registers during that time. CEOs say it to justify tightening headcount. Founders say it to signal capital efficiency. Junior developers say it out loud with a look that makes me want to change the subject. The phrase carries very different weight depending on where you’re standing.
The problem is that almost no one stops to ask: replace what, specifically? At what pace? And what happens to the pipeline behind those roles?
Replacement isn’t an event — it’s a slow dismantling #
What’s actually happening is quieter and more structural. A typical mid-level developer’s job isn’t one thing — it’s closer to 40 to 60 different types of tasks: writing endpoints, debugging, reviewing pull requests, estimating effort, choosing libraries, designing schemas, writing tests, deploying, being on-call at 3 a.m., and a dozen invisible ones like “knowing when to ask whom and how.” Current AI handles roughly 30–50% of those tasks reasonably well, performs passably on another 20%, and is genuinely bad at the rest.
So “replacement” in practice looks like this: the expected output volume stays constant, the headcount drops, and the remaining team absorbs the difference with AI acting as a buffer. A 10-person team becomes a 6-person team, each person running at 1.5x their former load. No one gets a memo titled “You have been replaced by AI.” Instead, the junior hiring quota quietly disappears. Recent industry reports and public commentary from engineering leaders at mid-size companies corroborate this pattern — entry-level roles have contracted noticeably while mid-level and senior positions have held relatively flat.
What’s being replaced first isn’t the human. It’s the ladder.
What’s already gone, what’s shifting, what’s holding #
The first layer is largely gone: repetitive, structurally clear work. CRUD endpoints, unit tests for existing functions, documentation for existing code, simple ETL scripts. In companies that have seriously adopted AI tooling, humans still press the button, but they no longer do the work. This shift happened faster than I expected.
The second layer is actively shifting: exploratory work with clear boundaries. Building prototypes, integrating third-party APIs, spinning up internal dashboards. This is the layer I worked in most directly when building an internal data platform. What made it hard was not that the tasks were conceptually complex — it was that each one sat on top of constraints that weren’t written down anywhere. The AI would generate a schema that was clean in isolation but ignored a decade of decisions baked into the legacy system it had to coexist with. I’d accept the output, wire it in, and only discover the problem when something broke two layers up. That pattern — plausible output, hidden constraint violation — probably cost me three or four days across that project that I hadn’t budgeted. A task that previously required a junior developer two weeks can now be done by a mid-level developer plus AI in roughly two days. The junior hiring quota for that type of work has effectively disappeared, not because juniors were fired, but because the opening for them to learn by doing it no longer gets posted.
The third layer is slowly shifting: maintaining production code. This is where the dynamic gets counterintuitive. A study by researchers at NBER (Brynjolfsson, Li, and Raymond, 2023, though focused on customer support rather than code) and related observational work on developer productivity suggests that AI tooling can slow down experienced developers working in familiar, complex codebases — the opposite of what most people expect. The reason is that production code carries hundreds of implicit constraints around style, testing, security, and backward compatibility that models haven’t internalized. I can’t give you a precise slowdown figure with a clean citation, but the mechanism is real and I’ve felt it personally. The parts of my codebase I know best are the parts where AI suggestions require the most correction.
The fourth layer is barely touched: work that is fundamentally social and contextual. Understanding what a stakeholder actually means when their request is vague. Knowing when to push back and when to absorb. Deciding between two architectures that are both technically defensible. Being accountable when the system fails. Mentoring someone who’s demoralized. These aren’t technical problems — they’re problems of judgment, positioning, and consequence. AI doesn’t bear consequences, which is a more significant limitation than it sounds.
The short version: AI is eating from the bottom up. Juniors are hit hardest and first, mid-levels are being squeezed upward, and seniors are temporarily safe but are absorbing the work that formerly belonged to the layers below them.
The illusion I fell into — and it’s more common than the obvious one #
AI makes you more productive at work you already understand. It does not make you competent at work you don’t. I was able to build that data platform because I had a solid software engineering foundation — AI filled in the data engineering gaps I lacked. If someone without that foundation had tried the same approach, the result would have been a codebase that worked until it didn’t, and that no one could maintain afterward, including themselves six months later.
This is where I think executives are miscalculating when they cut junior roles. AI doesn’t manufacture seniors. Seniors are the product of years of painful coding, painful debugging, mentorship, and having their code torn apart in review. Cut the juniors, and in five to seven years there are no new seniors. At that point, AI will still not be able to own a production system independently. The problem has no clean solution, and it gets very little attention because its consequences fall well outside the planning horizon of the companies making the decision today.
Where I’ve seen people land — and where the pressure is #
Junior developers facing this market have a real structural problem that has nothing to do with their individual capability. The entry-level positions that used to exist as learning environments — write the CRUD, fix the small bugs, review the basic PRs — are the exact positions AI has made easiest to eliminate. The practical response I’ve seen work is domain specificity over breadth. Domains with genuine barriers — compliance-heavy industries, hardware-adjacent work, legacy systems that require deep context to navigate — are where AI is weakest and where someone willing to put in the time can still build something other people can’t easily replicate. What I’ve noticed, counterintuitively, is that deliberately doing some work without AI is also useful. Recoding something you previously delegated to the assistant. Reading a large open-source codebase with your own eyes without asking it to explain. The understanding you build that way is the only long-term asset that’s genuinely hard to compress.
Mid-level engineers I speak with are in the most uncomfortable position. Experienced enough that AI amplifies their output significantly, but young enough to be absorbing the overflow from reduced junior headcount below them. The shift I’ve watched happen is from execution toward decision-making: architecture choices, API design, data model trade-offs, judgment calls about what’s worth building at all. That kind of work is much harder to automate because it requires business context, aesthetic judgment, and — crucially — someone who will own the consequences if it’s wrong. The developers I’ve seen navigate this well are the ones who moved from “code writer” toward “decider of what’s worth writing.”
Senior engineers are, for now, in the safest structural position, but the work looks different. The skill that seems most relevant is something closer to system management than people management: how to have AI and a smaller team produce the output a larger team used to. That’s a meaningful shift, and I don’t think everyone at the senior level has fully reckoned with what it requires.
The two questions I still don’t have answers for #
I’ve worked through most of my earlier confusion about this, but two things still sit with me and I haven’t resolved them.
The first is about what “human oversight” actually means at scale. If a developer is approving 200 AI-generated decisions per day and rejecting three of them, are they genuinely deciding — or are they a liability buffer so the organization has someone to hold responsible? I don’t think that’s a cynical question. I think it’s the question, and the answer will probably come from case law and regulatory pressure before it comes from any internal engineering process.
The second is the pipeline problem I mentioned earlier. The market’s implicit assumption seems to be that AI will be capable enough by the time today’s missing juniors would have become seniors that human seniors won’t be needed in the same way. I’m skeptical. But I don’t have a clean alternative answer either.
Those two questions will probably shape the next decade of software development more than whatever benchmark the next model hits. And the answers aren’t going to come from AI companies — they’ll come from the accumulated weight of ordinary decisions made by individuals, teams, and organizations over the next few years.
Including the one about whether to post that junior opening or quietly let the headcount shrink.