AI and Software Development: What Changes Next
AI is changing software development, but not simply replacing developers. Explore the evidence on productivity, code review, junior jobs, and what comes next.
AI Won't End Programming. It Will Move the Work.
In 1954, IBM said its new programming language, FORTRAN, should "virtually eliminate coding and debugging." It did take a lot of grind out of the job. Programmers stopped translating formulas into machine instructions by hand. But debugging didn't go away. Software kept spreading. And the work didn't vanish - it shifted.
That history matters because people keep making the same headline claim about AI replacing software developers. Coding agents can already produce working features, run tests, and open pull requests with limited supervision. But writing code is only one piece of shipping software. Someone still has to decide what the product should do, understand what a change could break, and verify the result is safe and actually useful.
The evidence from 2025 and 2026 is mixed. AI adoption is widespread, reported productivity gains vary, and code review is often getting harder. At the same time, employment data raises a real question: where will future senior engineers come from if early career experience shrinks? Here's how I read the numbers - what they suggest, what they don't prove, and what teams can do now.
Programming has been "ending" for decades
The idea that a new tool will make programming obsolete predates modern computing by a long stretch. The 1954 IBM report on FORTRAN promised the language would "virtually eliminate coding and debugging," at less than half the cost of solving problems without it. FORTRAN changed how programmers worked. It didn't remove the need to build software.
The pattern is simple enough: when a tool removes one kind of effort, some tasks get cheaper - and people then find more problems worth solving. Assembly language reduced the need to write machine instructions directly. Compilers let developers work at a higher level. Libraries, package managers, online communities, and code assistants each took another chunk off the programmer's plate.
In 1981, a BASIC program generator called The Last One made the pitch unusually direct: it would generate programs and be the last one you needed to buy. It helped for some business use cases. It wasn't the last program anyone needed.
This history isn't a guarantee that AI will have the same effects. The pace and scope of automation matter. Coding agents can take on bigger chunks than earlier tools, and their capabilities are improving fast. But history does challenge a common assumption: removing one part of a job doesn't automatically eliminate the entire job.
The work moves up a level
When developers don't have to do something manually, that work doesn't always disappear. Sometimes it becomes easier to request, cheaper to produce, or more important to verify.
FORTRAN moved programmers away from hand-translating formulas into machine instructions. Today, AI can generate boilerplate, tests, and sometimes entire changes from a written request. In both cases, the work shifts toward deciding what to build and checking whether what you got is actually right.
That distinction shows up fast in real projects. "Add refunds" sounds straightforward - until you ask what happens when the original payment card has expired. Do refunds go to a replacement card, become store credit, or trigger a support workflow? A coding agent can implement the rule once the business decides what it should be.
A made-up developer's Tuesday in 2031 might look like this: reading agent-generated pull requests, resolving questions that need product or customer context, writing the missing rule as a clear specification, and approving the next batch of work. The prediction is uncertain. Still, the underlying shift is visible: as code becomes cheaper to generate, human attention moves toward decisions, verification, and coordination.
A faster transition, not a guaranteed ending
AI adoption is moving quickly. Stack Overflow's developer survey reported that 84% of respondents were using or planning to use AI tools in 2025. Around half of professional developers said they used them daily. GitHub's 2025 report counted more than 180 million developers on its platform, with more than 36 million joining in the previous year.
Those figures do show AI is becoming part of normal development workflows. They don't show every use is productive, that everyone trusts the output, or that adoption will have the same effect across companies. A tool can spread because teams feel pressure to adopt it - even while they're still figuring out where it helps.
So the practical question isn't "Will AI end programming?" It's: which parts of software work can AI handle reliably in your situation, and what becomes more important once it does?
What the evidence says about AI productivity
Adoption and productivity aren't the same thing. It's possible for developers to use AI every day and still feel that some tasks take longer - especially when they have to inspect and fix output that's "almost right."
The sentiment data points to that tension. In Stack Overflow's survey, favorable views of AI tools fell from 77% in 2023 to 60% in 2025, then rose slightly to 62% in 2026. In 2025, more respondents distrusted AI accuracy than trusted it: 46% versus 33%. The most common frustration, reported by 66%, was output that was "almost right, but not quite."
That kind of output has a particular cost. If something is obviously broken, you can reject it quickly. If it looks plausible, someone has to read carefully to catch the subtle defect. In the same survey, 45% said debugging AI-generated code took longer. That's why "the model wrote it in seconds" doesn't tell you much about delivery speed by itself.
Why one controlled study found a slowdown
A randomized trial by METR offers a useful, if narrow, snapshot. In early 2025, 16 experienced open-source developers worked on 246 issues in repositories they had maintained for years. The issues were randomly assigned to allow or prohibit AI tools.
Before the work, the developers expected AI to cut their completion time by 24%. Afterward, they believed it had reduced time by 20%. The measured result went the other way: with AI, participants took 19% longer.
That's striking, but it doesn't settle the question on its own. The study covered a small group of experienced developers, familiar codebases, and tools available at the time. METR's estimate also came with a wide uncertainty range. The researchers later tried a larger study, but in February 2026 they reported the data was too unreliable for firm conclusions. One reason: developers declined to participate because they didn't want to work without AI.
The takeaway is narrower than "AI makes developers slower" or "AI makes developers faster." A developer's feeling of speed isn't the same as a measurement. If you want to know whether a tool improves delivery, measure the whole chain: time to a reviewed, tested, accepted change, including corrections and production follow-up.
Measure outcomes, not generated lines
A practical evaluation compares similar work with and without AI help. Don't stop at first drafts. Track:
- Time from a clear task brief to an accepted change.
- Review time and how many revisions it took.
- Defects, incidents, and security findings after merge.
- Whether tests cover the intended behavior - not just the implementation.
- Developer experience: cognitive load and confidence in the result.
Be careful with comparisons. A tiny, well-defined task isn't comparable to a cross-service change with unclear requirements. Teams also need to account for differences in experience and familiarity with the code. Otherwise, you might learn more about which tasks you picked than about the tool.
This isn't an argument for avoiding AI until everything can be measured perfectly. It's a case for bounded trials, a clear baseline, and resisting productivity claims based on code volume or a fast demo. A working prototype is progress. It's not the same thing as a reliable software change.
When code gets cheaper, review becomes the constraint
Most production processes have a bottleneck. Speed up one step while the rest stays the same, and work piles up at the next constrained stage. In software teams, AI can reduce the time needed to draft a change. That can leave reviewers with more code to understand and less time to do it well.
Faros AI's 2025 analysis of telemetry from more than 10,000 developers across 1,255 teams found that teams with high AI adoption completed 21% more tasks and merged 98% more pull requests. Their review time increased by 91% as well.
In a larger 2026 analysis, Faros reported task completion per developer up 34%, while median review time grew fivefold. It also reported 31% more pull requests merging without review and a more than threefold increase in the ratio of incidents to pull requests. These are observational results, not proof that AI caused every change. Still, they're a warning: output can grow faster than a team can inspect it.
Review is part of the work, not a tax on it
A pull request isn't good because it's short. And it isn't safe just because an agent says the tests pass. Review is where a team checks whether a change fits the system, handles edge cases, and matches what you actually intended.
Other evidence makes the concern concrete. Veracode's 2025 testing of more than 100 language models across 80 coding tasks found security flaws in 45% of generated results. GitClear reported that copy-pasted lines rose from 8.3% of changed code in 2021 to 12.3% in 2024, while moved code - often associated with refactoring - fell from roughly a quarter to under 10%.
Neither result means AI-generated code is always insecure, or that developers should never use it. It does explain why review can't be replaced by confidence, flashy demos, or a green test suite. Tests can miss requirements that were never written down. A generated change can pass local checks and still create operational or security problems.
Put controls around the risky parts
The right amount of review depends on the change. A small copy edit doesn't need the same process as changes to payments, authentication, personal data, or infrastructure. A risk-based workflow might look like this:
- Low-risk changes: automated tests plus a lightweight human review.
- Moderate-risk changes: a named reviewer, tests tied to the requirement, and a clear summary of the files changed.
- High-risk changes: an accountable human owner, security or domain review where appropriate, staged deployment, and a rollback plan.
Ask agents to explain their assumptions, point out uncertain areas, and tell you which checks they ran. Use that as a starting point for review - not as proof. A screen recording or test report can help a reviewer understand what changed, but it doesn't replace reading the relevant code and validating the behavior.
The operational goal isn't to review every generated line with equal intensity. It's to make review effort match the cost of getting it wrong. If AI increases the number of changes entering the queue, teams need to improve how they prioritize, test, and route that work - not quietly remove review just to keep throughput numbers looking good.
What teams should prepare for next
The capability curve is moving fast, but forecasts aren't schedules. METR's task-duration research estimates how long a human-expert task an AI agent can complete with a 50% success rate. Its measurements grew from seconds for early systems to hours for later models, with overall performance roughly doubling every six months and improving faster after 2023.
It's interesting, but easy to overread. A benchmark task is cleaner than a real codebase. A 50% success threshold isn't reliable autonomy. METR has also cautioned that longer-duration measurements become less reliable with its current task set. A trend line helps you plan for possible improvements; it can't tell you when an agent will safely own a month of your engineering work.
Businesses should plan around observable capability and risk, not extrapolation alone.
The apprenticeship problem is real
Employment data adds a tougher angle. A Stanford Digital Economy Lab analysis using ADP payroll data found that employment for software developers aged 22 to 25 was nearly 20% below its late-2022 peak during the period covered by its 2025 study. An update using data through June 2026 found young workers in AI-exposed jobs were 19% below where they would have been if they'd kept pace with less-exposed peers. The researchers described the results as descriptive, not causal. Other factors - interest rates, post-pandemic hiring corrections, and broader labor-market shifts - also matter.
Even so, the pattern deserves attention. Junior developers often learn by taking small, bounded tasks: making mistakes, and getting feedback from more experienced colleagues. Those are also the kinds of tasks agents can handle first. If companies remove too many entry-level opportunities, they may shrink the pipeline of experienced engineers they'll need later.
A better apprenticeship can include reviewing agent-generated changes alongside a senior engineer, owning a small system end to end, and writing specifications and tests that make the intended behavior explicit. That's not busywork. It builds judgment about trade-offs, maintainability, and user impact. Teams need to create learning opportunities on purpose instead of assuming experience will appear automatically.
Five changes worth planning for
Over the next several years, I'd plan around five shifts without treating any of them as guaranteed:
- Smaller teams may deliver more. AI can let a small group build software that used to require more people. That doesn't automatically mean overall software employment will fall - lower costs can make more projects feasible. But hiring plans should follow actual demand and capability, not an assumption that every team should look the same as before.
- Specifications and tests will matter more. If agents produce implementations quickly, unclear requirements create more rework. Teams should make business rules, edge cases, and acceptance criteria into reviewable artifacts.
- Software for narrow needs will get cheaper. What once needed a dedicated project may become practical for one department or one workflow. That's an opportunity, but it also means more small systems to secure, support, and eventually retire.
- Reading and verification will matter more. Reviewers will need better ways to see what changed, why it changed, what was tested, and where uncertainty remains. "Verification engineer" might become more common, but the responsibility will still sit with the whole team.
- Changes need clearer provenance. Teams should know which work came from a person or an agent, who approved it, and which checks actually ran. Provenance isn't about blame - it helps with debugging, accountability, and compliance.
Taken together, these changes point to a practical stance: automate repetitive implementation where the risk is manageable, but keep humans accountable for requirements, review, and consequences. For your own rollout, compare how the tool performs on your codebase against your current process, not vendor demos or industry averages.
Conclusion: automate carefully, keep learning
FORTRAN eliminated a kind of coding, but it didn't eliminate programmers. It made one part of the job cheaper and moved the field toward larger, more ambitious software. AI may do something similar - only faster, and with new costs around review, reliability, and training the next generation.
The useful question for a team isn't whether AI can write code. It can. The real question is whether your process can turn that output into software you can support, secure, and explain. Start with a bounded workflow, measure the complete delivery cycle, and keep human ownership where decisions carry real consequences.
If your team is already using coding agents, map where work waits today: implementation, review, product decisions, testing, or deployment. That bottleneck is the next thing to tackle. And if your team is seeing a different pattern, share what you measured - not just how quickly the first draft appeared.
Further reading: The original article and its cited research.