A working CTO's five year forecast for AI agents in software development: what erodes, what appreciates, and why judgment and code review beat prompting.
Every few weeks someone tells me my job is over. The same week, someone else tells me nothing has really changed and the models are a party trick. Both of these people are wrong, and they're wrong in the same way: they're selling a clean story, and clean stories are how you know someone hasn't shipped anything recently.
I've spent the last two years wiring agents into a real production Flutter codebase, watching my three-person team's daily loop bend around them, and paying the bills out of a Dubai startup budget that does not tolerate magic. So here's my actual forecast for the future of software development over the next five years — not what I hope happens, not what a keynote promised, but what I'd bet a quarter's runway on. It's more boring than the doom crowd says and more disruptive than the skeptics will admit.
If you only remember one thing: the change is real, but it lands unevenly. It hollows out the mechanical parts of the job and makes the human parts — the ones you can't fit in a prompt — worth dramatically more.
The first lie is "nothing changes." It's usually told by senior engineers who tried Copilot in 2022, watched it hallucinate a function, and closed the tab. That version of the tooling is three generations dead. If your mental model of AI coding is autocomplete-that-sometimes-lies, you are calibrating on a product that no longer exists. The distance between "smart autocomplete" and "an agent that reads your repo, drafts a change across six files, runs the tests, and hands you a diff to review" is not incremental. It's a category change, and pretending otherwise is how you get left behind quietly.
The second lie is "everything changes tomorrow." This one's louder and comes with a pitch deck. It says by next year you'll describe an app in a sentence and ship it. I've watched enough of these demos to know the shape of the trick: the demo builds a to-do list, and a to-do list has no legacy code, no compliance constraint, no third-party API that returns null on Tuesdays, no angry customer from 2021 whose data model you can't break. Real software is 5% greenfield and 95% constraints, and constraints are exactly what a two-minute demo is designed to hide.
The truth is that software development changes the way a river changes a canyon. Slowly, then all at once in the parts that were already cracked. The boring parts of your job erode fast. The parts that were actually load-bearing — judgment, context, responsibility — get more valuable, not less. Anyone selling you a single-sentence version of the next five years is selling you something.
Let me be concrete about the loop, because that's where you feel the change, not in the think-pieces.
In 2024 my loop was: read a ticket, open the files, write the code, write the tests, run them, fix them, open a PR. In 2026 it's already: read a ticket, write a tight brief for an agent, review a diff it produced, reject about half of it, keep the rest, and spend my real energy on the two decisions that mattered. The typing went away. The thinking did not.
By 2030 I expect the steady state to look like this:
That last point is worth sitting with, because it's where most teams will fumble. The codebases that thrive under agents are the ones that already invested in the unglamorous stuff: clear module boundaries, a written architecture doc, naming that means something, tests that describe behavior instead of implementation. Agents amplify whatever is already there. A clean, well-documented repo gets a force multiplier. A tangle of implicit knowledge in three people's heads gets a confident intern who breaks things faster than you can review them.
Here's the unglamorous version in practice. A task brief I'd hand an agent today looks like this, and I don't expect that to fundamentally change — it'll just get better at reading between the lines:
## Task: Cache the pricing feedContext:- Pricing comes from `PricingRepository.fetch()`, called on 4 screens.- Feed changes at most hourly. We currently refetch on every screen mount.- Firebase reads cost real money; we're on Blaze but the budget is $0.Constraints:- No new dependencies. Use the existing `HiveStore` wrapper.- Must survive app restart (cold cache from disk).- TTL 1h, but expose a `forceRefresh` for the pull-to-refresh gesture.Done when:- Reads to the pricing collection drop to at most 1/hour/device.- Existing pricing tests still pass; add a test for the TTL boundary.
Notice what that is. It's not code. It's judgment written down. That skill — turning a fuzzy business need into an exact, testable contract — is the job that survives. And notice that the brief encodes constraints an agent could never infer: the $0 budget, the specific wrapper to reuse, the exact definition of "done." Strip those out and the same agent will happily reach for a new dependency, ignore the cost math, and declare victory when the happy path compiles.
The strongest near-term shift is that natural language becomes a real interface to the codebase, not a novelty. You'll talk to your system. That part is genuine and it's here.
But I'll make an unpopular prediction: the natural-language layer plateaus well before it eats the code. Here's why. Natural language is ambiguous by design — that's its feature and its ceiling. "Make the checkout faster" has a thousand meanings. At some point in every serious task you have to collapse the ambiguity into something exact, and the exact thing is called code. We didn't invent programming languages because we hated English. We invented them because English can't say WHERE status = 'pending' AND created_at < NOW() - INTERVAL '30 days' without a fight.
So the mature shape isn't "English replaces code." It's a layered thing:
The people who think prompts replace programming have it backwards. Prompts are a higher-level language with worse determinism. That's fantastic for a first draft and dangerous for a financial transaction. The layer rises. It does not swallow the stack. Think of it the way high-level languages didn't kill assembly — they moved most of us up a rung while a smaller group kept working closer to the metal. Natural-language coding does the same thing one rung higher: it moves the median task up to intent, and pushes the precision work into fewer, higher-stakes moments.
This is the part nobody demos, and it's the part that decides whether any of this ships.
When a human writes code slowly, the writing is a review — you catch things because your hands are moving through the logic. When a machine emits 400 lines in nine seconds, that review is gone. You didn't earn the understanding. So the discipline that used to be optional becomes the whole game:
That last failure mode deserves a name, because you'll meet it constantly: plausible-but-wrong. It's code that reads cleanly, uses the right idioms, passes the tests you thought to write, and is subtly, expensively incorrect at a boundary you didn't test. Human bugs tend to look like mistakes. Agent bugs tend to look like confident, well-formatted decisions. The review muscle that catches them is different — you're not scanning for sloppiness, you're interrogating assumptions.
My rule for the team now, and I think it becomes industry-standard by 2030: you may not merge code you cannot defend. Doesn't matter who or what wrote it. If you can't explain why it's correct and where it breaks, it's not ready, and "the AI wrote it" is not a defense — it's a confession.
The org chart changes, and this is where the "everything changes" crowd is accidentally right for the wrong reasons.
Small teams get disproportionately stronger. A three-person team with good agent leverage now does what a team of eight did in 2022 — I'm living this. That compresses the middle. The uncomfortable truth: the traditional path where juniors learn by doing the grunt work is getting hollowed out, because the grunt work is exactly what agents do best.
That's a real problem and I won't pretend it isn't. My honest read on team shapes by 2030:
| Role | 2022 | 2030 |
| --- | --- | --- |
| Senior engineer | Writes hard code, reviews | Sets direction, reviews, owns correctness at scale |
| Mid-level | Writes most features | Runs a fleet of agent tasks, curates output |
| Junior | Grunt work, learns by volume | Endangered as a role; survives as apprentice-to-judgment |
| "Full-stack" | Two languages | One person owning a whole vertical slice, agents filling the width |
The stranger part: I think we get more generalists who go deep on demand. The cost of touching an unfamiliar part of the stack drops, because the agent bridges the gap. The engineer who "only does frontend" becomes rarer. Not because everyone learns everything, but because the machine lets one person credibly own more width than before — as long as they own the judgment.
There's a hiring implication buried in that table, and it's the one I worry about most. If nobody hires juniors, nobody grows seniors, and in five years the supply of people who can actually defend a diff runs dry. The teams that think a step ahead will treat junior roles not as cheap labor for grunt work — the agent took that — but as deliberate apprenticeships in judgment: pairing a new engineer with agent output and teaching them to interrogate it. That's harder to justify on a spreadsheet and it's the thing that keeps the pipeline alive.
If typing code is depreciating, what's appreciating? Boring, durable, deeply human stuff. I'd invest my next five years here:
Notice none of these are "prompt engineering." Prompting is a skill with a two-year shelf life — the models keep getting better at reading sloppy intent, which means the craft of phrasing keeps getting cheaper. Judgment is a skill with a forty-year shelf life. If you're deciding where to spend your learning hours, spend them on the layer the models can't absorb: knowing what's worth building, what's safe to ship, and what will hurt in a year.
A word on how to actually build these, because "get better at judgment" is useless advice on its own. Read more code than you write — specifically, review agent output as if you'll be the one paged when it fails, because increasingly you will be. Design a system on paper before you let an agent touch it. And practice writing the brief in the pricing-cache example above: the discipline of specifying "done when" in testable terms is problem decomposition, review, and taste all at once.
Let me put my actual chips down, because forecasts without stakes are just vibes.
In 2030 I'm still a CTO shipping Flutter and Firebase products. I write dramatically less code by hand — maybe 20% of what I do today — and I'm more productive, not less. My day is: framing problems precisely, reviewing agent output for the things that matter, making the handful of architecture and product calls that compound, and being the person whose name is on it when it's wrong.
My team is smaller than a naive 2022 forecast would've guessed and each person is more senior. We ship faster and we're more paranoid about correctness, not less, because speed without judgment is just a faster way to production incidents. The infra bill is still near zero, because agents don't change the math of a startup — they just change how much one careful person can do inside it.
What I'm not betting on: that any of this replaces the engineer who understands the system and takes responsibility for it. That person doesn't get automated. That person gets amplified — and also gets a lot more to answer for.