The Future of Software Developers After AI

I've been writing software for about fifteen years, and I've lived through enough hype cycles to be suspicious of anyone who says they know exactly how this ends. But I've also changed how I work more in the last two years than in the previous ten, so I can't dismiss the question either. Here's where I think things stand, based on what I actually do each day and what the evidence supports.

What the Work Looks Like Now

Last quarter, our team had to migrate a billing service from an old Python 2-era codebase to modern Python with typed dataclasses and a new persistence layer. Two years ago, that project would have meant weeks of tedious line-by-line translation. This time, I used an agentic coding tool that could read the repository, propose changes across files, and run the test suite.

Most of my time didn't go to typing. It went to three things.

Writing the spec. Before the agent touched anything, I wrote a short document describing the invariants that had to survive the migration: which fields were money, how rounding worked, which endpoints were public contracts, and what could change. The agent is only as good as the constraints I give it, and vague instructions produce confident, plausible, wrong code.

Characterizing the old behavior. The legacy code had a rounding quirk nobody had documented. Before letting the agent refactor, I wrote tests that pinned down what the current code actually does, not what we thought it did:

# test_invoice_characterization.py
import pytest
from legacy_billing import calc_invoice_total  # the untouched original

@pytest.mark.parametrize("line_items, tax_rate, expected", [
    ([10.005], 0.0, 10.00),       # banker's-style quirk we must preserve
    ([19.99, 5.01], 0.08, 27.00),
    ([], 0.2, 0.00),
])
def test_legacy_behavior_is_pinned(line_items, tax_rate, expected):
    assert calc_invoice_total(line_items, tax_rate) == pytest.approx(expected, abs=0.005)

Reviewing the diff. The agent's rewrite was clean, idiomatic, and wrong in one place. It switched money handling to Decimal with default rounding, which silently changed totals by a cent on some invoices. The characterization tests caught it. The agent, when shown the failing test, fixed it immediately. But it wouldn't have noticed on its own, and a reviewer who only skimmed the diff would have missed it.

That's the job now: specify, verify, and own the outcome. The keyboard time is a smaller slice than it used to be.

The Productivity Numbers Are Real but Messy

The headline figures are striking. GitHub's 2022 Copilot study reported developers completed a benchmark task about 55% faster. A 2023 study by Peng et al. found similar gains on a customer-support task. It's easy to extrapolate those numbers into "developers are now twice as productive."

I don't think that extrapolation holds. Later field studies, including work from Google and Microsoft researchers, show smaller gains in real production settings. Results also vary by task type and experience level. Greenfield boilerplate, test scaffolding, and well-documented APIs see large speedups. Debugging a subtle concurrency bug in a system you've never read, or making a design decision with unclear product requirements, sees much less.

So I'd treat the lab numbers as an upper bound on a narrow task, not a forecast for your roadmap. The honest summary is: real gains, uneven distribution, and the gains are concentrated where the work was already the least interesting.

The Junior Pipeline Problem

This is the part that worries me most, and it's the one I hear least about in tech-industry optimism.

Junior engineers have historically learned by doing routine work: fixing small bugs, writing CRUD endpoints, adding tests, reading unfamiliar code under supervision. That work is the apprenticeship. If AI absorbs most of it, where do the next senior engineers come from?

This isn't hypothetical anymore. Brynjolfsson and colleagues at Stanford (2025) reported a measurable drop in employment for early-career workers in AI-exposed occupations. That doesn't prove a causal story about software specifically, but it makes the concern concrete rather than speculative.

Companies that stop hiring juniors will find themselves in a bind a few years out. Seniority is built from years of exposure to real failures. If we cut that exposure, we should expect a shortage of people who can evaluate AI output, which is exactly the skill the industry is now most dependent on. Teams that deliberately create learning work, like pairing juniors with agents on reviewed tasks or assigning debugging rotations, will have an advantage.

Verification Is Becoming the Job

When code is cheap to produce, the scarce resource is confidence that it's correct. That shifts demand toward code review, testing, security engineering, and reliability work.

AI-generated code has specific failure modes. It produces subtle logic errors, insecure defaults, and deprecated patterns that look modern. It also invents dependencies. Security researchers have started calling one version of this "slopsquatting": models repeatedly suggest a package name that doesn't exist, and attackers register it with malicious code. A developer who blindly runs the install command gets compromised.

A simple guardrail goes a long way. Here's a check I run in CI to flag dependencies that aren't on an approved list:

# check_dependencies.py
import sys
from pathlib import Path

APPROVED = {
    line.strip().lower()
    for line in Path("approved_packages.txt").read_text().splitlines()
    if line.strip() and not line.startswith("#")
}

def declared_packages(req_file: str) -> set[str]:
    names = set()
    for line in Path(req_file).read_text().splitlines():
        line = line.split("#")[0].strip()
        if not line:
            continue
        name = line.split("==")[0].split(">=")[0].split("[")[0].strip().lower()
        names.add(name)
    return names

unknown = declared_packages("requirements.txt") - APPROVED
if unknown:
    print(f"Unapproved dependencies: {sorted(unknown)}")
    sys.exit(1)
print("All dependencies approved.")

This is a small thing. It's also exactly the sort of unglamorous verification work that AI makes more important, not less.

Skills Gaining Value

If I were advising someone entering the field, I'd say the skills gaining value are the ones that were always underrated:

• Systems thinking. Knowing how components interact under load and failure matters more when you didn't write most of the components.
• Product sense. Deciding what to build is harder to automate than building it.
• Debugging unfamiliar code. Agents write code faster than anyone can read it, so the ability to reason through code you didn't write is essential.
• Communication. Translating ambiguous stakeholder needs into precise specs is now a core technical skill.
• Domain knowledge. Regulatory constraints, money handling, and data retention rules don't come from the model. Someone has to know them.

Syntax memorization and framework API recall are becoming less valuable. Judgment about tradeoffs is becoming more valuable. Someone who can produce boilerplate quickly is less useful than someone who can tell you whether the boilerplate should exist.

Historical Parallels, and Why This One Differs

Every generation of tooling has prompted the same fear. Compilers would deskill programmers. High-level languages would make assembly experts obsolete. Stack Overflow would replace thinking. Frameworks would reduce engineers to configuration. In each case, the work moved up an abstraction level rather than disappearing. Nobody hires assembly programmers to write web backends, but we still need engineers.

I find that history reassuring, with a caveat. The parallel is imperfect. Previous tools operated at one level of abstraction. A compiler doesn't design your architecture; a framework doesn't write your product requirements. AI can operate at several levels at once, including the spec, the implementation, and the tests. That means the ladder we're climbing may be less stable than the ones before it. We should be honest that we don't know how far up the work will move before it gets hard to find a human position.

Reading the Layoff Headlines Carefully

Tech layoffs make good headlines, and "AI is taking developer jobs" is an appealing story. But attributing layoffs to AI is difficult. Interest rate increases, post-pandemic overhiring, and sector-specific slowdowns all confound the picture. Many companies announcing cuts were also correcting for years of aggressive hiring.

If you want to know what's actually happening, look at primary sources: BLS occupational projections, job posting data from sites like Indeed, and the workforce disclosures in company earnings reports. Those will tell you more than a viral post from someone who has an opinion to sell.

Closing

I don't think software developers are going away. I do think the job I'm doing today would have been unrecognizable to me a decade ago, and the job I'll be doing in five years will look different again. The developers who thrive will be the ones who treat AI as a fast, fallible collaborator: someone who writes clear specs, reads diffs skeptically, tests relentlessly, and keeps learning the parts of the system that machines can't yet own.

The typing was never the hard part. The judgment was. That's the part worth investing in.