When good cameras got cheap, everyone predicted the death of professional photography. The prediction landed wrong. The low end died outright: stock libraries, cheap portraits, mass-event coverage went to anyone with a phone and a free editing app. The high end did better than ever — editorial work, photojournalism with access nobody else had, an aesthetic you could not reproduce by buying the same gear. The damage landed in the middle. Small weddings, corporate headshots, real estate listings, the steady unglamorous bulk of the market: not extinction, compression. Prices fell, volume moved to cheaper substitutes, and the survivors climbed up or specialized out.
That compression is the cleanest map I know for what AI-assisted coding is doing to software work. And this half I know from inside: two decades leading dev teams, and now building AI tooling for them.
The comfortable half of the argument
The reassuring version of this is everywhere right now: you were never paid to type, you were paid to think, so AI just frees you to do the valuable part. It's not wrong. It's just the half that's easy to hear. The other half is about the market, not about you.
Judgment, architecture, knowing what breaks in maintenance, deciding what not to build — a model that writes plausible code on command doesn't commoditize any of that. I have watched weeks of confusion land on people who could not read what a capable model generated; the gap was never the tool, and better AI autocomplete does not close that gap.
But "judgment beats typing" answers only a question about skill and dodges the question about market structure. AI doesn't replace developers as a class; it commoditizes a segment. The segment it hits first is the same one the camera hit: the middle. The junior-to-mid tier that lived on CRUD apps, simple integrations, brochure sites, the standard internal tool with a form and a table behind it. That work was always implementation against a known spec, and implementation against a known spec is exactly what a model does cheaply now.
I felt this directly on a side project. I spent many months of evenings building a content pipeline on a visual no-code platform; when AI-assisted coding changed the math, I rebuilt it as proper code in a few weeks. The months were not wasted — they are why I knew exactly what to build. But the same work now costs weeks, not months.
"So the middle just learns to think better?"
This is the obvious objection, and it's worth taking seriously because the answer is where the whole thing turns.
First problem: "learn to think better and survive" doesn't refute the thesis, it confirms it. The claim was never about the people, it's about the work. When someone in the middle develops real architectural judgment, they haven't saved the middle, they've left it. They climbed to the high end. The middle still empties out, by promotion or by exit. A wedding photographer who became a sought-after editorial shooter didn't prove the wedding market survived.
Second problem: "thinking better" isn't a soft upgrade you bolt onto the same job. Going from implementing a spec to deciding what to build, judging tradeoffs, holding the whole system in your head, anticipating the failure that surfaces in production eight months later — that's a change in the muscle being used. Some people build it. Some won't, and some genuinely don't want to; they liked implementation and were good at it. The skill axis is real, but it doesn't pull everyone up by default.
Third problem, and this is the one the reassuring posts never reach: capacity. Suppose everyone in the middle became a strong systems thinker overnight. The market still doesn't need that many architects, security specialists, performance engineers, and trusted advisors. The high end is narrow by definition, which is what makes it the high end. Premium editorial photography never had room to absorb every wedding shooter it displaced.
So when people ask whether "think better" just means "become a consultant," the honest answer is partly. The trusted technical advisor is one exit from the middle, and a good one, but not the only one. Architecture is an exit. Deep security and performance work is an exit. Complex-domain expertise — the kind where you understand the business so well the AI becomes a lever instead of a crutch — is an exit. When a prototype that should take weeks comes together in an afternoon, the speed never comes from the model. It comes from twenty years of knowing the exact problem before the first prompt. The tool doesn't create that position; it amplifies what was already there.
The honest limit of the analogy
I'd be selling you something if I claimed software follows photography like a law. It doesn't. Photography had roughly fixed demand; the number of weddings didn't triple because cameras got cheap. Software might. Total demand for software has grown for forty years, and cheaper production could grow it further, which means some of the displaced middle gets reabsorbed into work that didn't exist before. The wedding market never had that escape valve.
So I won't tell you eighty percent of developers will be unemployed. I don't believe it, and the people who say it are guessing. The defensible claim is narrower and still uncomfortable: middle-tier work commoditizes, value migrates toward the extremes, and you should plan around that rather than hope the middle holds.
For the individual, the move is to climb toward judgment, architecture, and advisory work, not to defend the commoditizing tier by getting slightly faster at it. Speed inside a shrinking band is a losing race against a tool that's cheaper than you and getting better weekly.
For anyone running a technical team or a practice, this is the argument for senior-led work getting stronger. The middle is precisely the layer being liquified. Value concentrates in the people who were never doing middle work to begin with: the ones whose contribution was the system, the tradeoff, the domain, the call about what not to build. That's why this practice is senior-led and founder-run. It is not a positioning choice; it is what the map says to do.
The question to sit with isn't whether you can out-think the AI. You probably can, on a good day. The question is which segment that thinking lives in, and whether that segment will still be there to stand in. Go look at the last five things you shipped. Count how many were implementation against a spec someone else wrote. That number is your exposure.