The Future of Software Engineering: What Changes for Engineering Teams?

Key Points

• Bottleneck shift: Your delivery constraints now sit upstream in specification and downstream in review and security, with writing code no longer the limiting step.
• Role reallocation: Your engineers are shifting toward specification and production ownership as AI absorbs routine implementation work.
• Review capacity: High-adoption teams merged 98% more pull requests while review time rose 91%. Your Staff+ engineers absorb that gap.
• Measurement: Delivery outcomes that reflect value to the business are a stronger indicator of productivity than code volume when AI is handling implementation.
• Governance: Your review process should treat all AI-generated code as untrusted until it clears automated security scanning and risk-tiered human review.

What is the future of software engineering? Generating code is becoming easier and less expensive, so the harder parts of software creation will increasingly be deciding what to deliver, validating what AI provides, and running it consistently. Engineering judgment will become the scarce resource that engineering leaders need to allocate.

The future of software engineering, from cloud-native to AI-first: a 10-minute recap of our panel with Google, Credit One Bank and Precession Partners. The full 48-minute session is at the end of this page.

In this recap:

0:00 Roles repackaged: full-stack PMs and engineers
1:08 AI-first in regulated industries: audit-first, policy as code
2:02 Cloud-native vs AI-native: humans as adjudicators
3:12 Automate the whole workflow, not one task
4:26 Leaders vs laggards: TDD reborn with agents
5:40 Risks and blockers: regulation, IP, the four EBITDA levers
7:57 One piece of advice for 2026

Most of what the industry has written about the future of software engineering reads as an inventory of tools. The better question for engineering leaders is what the operating model looks like once generating code is cheap. This article focuses on the research that indicates pressure on the work around the code.

We also put that question to people living it. Chris Haire (Chief Technology Officer, VSCO) hosted a panel with Jason Davenport (Technical Lead for Developer Experience, Google), Saurabh Gupta (Chief Technology Officer, Credit One Bank) and Ravi Bellur (Chief Technology Officer, Precession Partners), and their answers appear alongside the research below. For the tool-level view of the year, see our software development trends for 2026.

Where Does the Bottleneck Move in the Software Development Lifecycle?

There are now two bottlenecks around the code: specification before it, and review, security, and operations after it. AI accelerates the most easily measured part of the work, mainly implementation code and test scaffolding, and does little to help with the rest.

The lab tests show substantial benefits for bounded problems. In a controlled experiment, GitHub tested 95 professional developers on a bounded JavaScript task. The developers using GitHub Copilot completed it 55% faster than those without it.

A McKinsey lab study of 40-plus developers compared documentation and new code development times. Documentation took about half the time and new code nearly half, but the time saved fell below 10% on work the developers considered highly complex.

Under normal working conditions, METR monitored 16 experienced developers across 246 real tasks in familiar repositories, with each participant working against the background of their own codebase rather than a controlled lab problem. In this randomized controlled trial, the developers took 19% longer when using AI tools. They had expected a 24% speedup.

One likely explanation for the gap is that lab tasks come completely defined, while real-world development work includes the specification and integration effort that lab tasks exclude. METR cautions that its finding should not be generalized, but it is a useful check on vendor-claimed improvements when we set expectations.

DORA’s 2025 report examines the organizational perspective. AI adoption shows a positive relationship with software delivery throughput and a negative relationship with delivery stability. The capabilities around AI, including a quality internal developer platform, test automation, fast feedback loops, and continuous learning practices, influence whether companies see improvement or decline.

DORA calls this the “amplifier” effect, where AI magnifies whatever operating model is already in place. Taken together, the research points to constraints moving toward the activities that govern code quality and stability. That conclusion is an inference from converging data; no single study measures it directly.

How Is the Software Engineer’s Role Changing?

AI-assisted software development changes where an engineer’s time is spent. Companies that do not dedicate resources toward specification, review, and operational ownership will accumulate risk faster than they ship features.

84% of developers use or plan to use AI tools, and DORA’s 2025 data indicates professional adoption at 90%, a 14-point increase from last year.

Trust has not increased proportionally. Only 33% of developers trust the accuracy of AI tools, while 46% actively distrust them, and 30% of DORA respondents report little or no trust in AI-generated code. 66% identify AI answers that are “almost right, but not quite” as their top frustration.

With AI embedded in most developers’ work, yet only one-third trusting the results, we cannot rely on the developer who accepted the generated code to have validated it. The current review processes designed for code authored by humans have yet to evolve.

METR’s trial quantifies what this validation costs. 75% of participants reported reading each line of AI output. Screen recordings showed approximately 9% of AI-assisted time was used to review and clean up that output.

The center of gravity in the software development lifecycle is moving away from “write the code” to “determine what the code should do and validate that it does it.”

AI can generate initial implementation code, test scaffolding, and first-pass documentation. Bridging business goals and technical execution still falls to engineers: deciding what to build, assessing the risk of a proposed change, negotiating constraints with stakeholders, and owning results in production. Team structures will need to evolve around this split, with the role moving toward technical architect and product partner.

Jason Davenport’s image for this is a box of crayons: it’s as if all the responsibilities of every role were thrown on the floor. The package of roles is changing, with teams moving toward full-stack PMs and full-stack software engineers who span back end, front end and databases. Ravi Bellur points to where that could lead. In an AI-native operating model, the claim is that roles reverse: AI makes many of the decisions, and people become adjudicators of those decisions. How organizations navigate that change at scale, he says, is the key challenge of the next three to five years.

This shift also creates a hiring issue. Historically, junior engineers developed their professional judgment by writing implementation code, and that code is now drafted by AI. Leaders will need intentional ways for future senior reviewers to develop that expertise, for example, review rotations and software design ownership.

What Does Faster Code Generation Mean for Quality and Governance?

AI-assisted software development raises code output faster than most companies can increase review and testing capacity. The gap is greatest in security review.

Faros AI’s 2025 study of more than 10,000 developers across 1,255 teams found that high-adoption teams completed 21% more tasks and merged 98% more pull requests (PRs). Review time increased by 91%, and bugs per developer rose 9%.

Faros draws on its own customer telemetry. This is best read as an operational pattern across many teams rather than a causal finding.

LinearB’s 2026 benchmark of 8.1 million PRs across 4,800 teams indicates the same trend. Agentic PRs waited 5.3 times longer for initial reviewer pickup than unassisted PRs. AI PRs were merged within 30 days 32.7% of the time vs. 84.4% for manual PRs.

As PR volume exceeds qualified reviewer capacity, the queue falls on Staff+ engineers, reducing the value they can add to architecture and design work. Asking even the most capable senior engineers to review more carefully is not scalable. Tiering review by risk is scalable: automating deterministic checks and keeping PRs small lets senior reviewers focus on changes that cross architecture, security, or data boundaries.

Security carries a separate risk. In a 2023 Stanford University study using OpenAI Codex, Perry et al. found that AI-assisted participants wrote SQL-injection-vulnerable code 36% of the time, versus 7% for controls. Those participants also rated their code as more secure than the control group rated theirs.

Regulated industries show where this is heading. Saurabh Gupta describes banks adopting an audit-first posture: AI that is explainable, fully auditable, more deterministic and compliant with regulatory guidelines. Policy as code has become a major pivot, with banks codifying their policies so AI can ingest and apply them in real time, and every action stays observable and loggable by design. The same principle holds for autonomous agents, as our panel on AI agents in production found.

What Should Engineering Leaders Act On Now?

Whether AI initiatives improve your delivery process or compound existing constraints comes down to four operating decisions. Specification is the most critical of them, since it serves as the foundation for all downstream work.

AI coding tools make clear communication a critical skill: a poorly specified feature handed to an AI-enabled team gets built rapidly before the specification error surfaces. When the specification is wrong, the rework can take longer than the time the build saved. Regular requirements reviews protect specification rigor under deadline pressure.

Tests can carry part of that specification. Jason Davenport uses test-driven development for most of his agent work: once he and the agent agree on the tests, the tests represent the business logic, and the code behind them can be rewritten hundreds of times as long as it still passes. Asked what separates leaders from laggards, he points to a willingness to throw implementations away as models improve. The durable part is the learning.

As the quantity of code grows faster than validation, lines of code and story points become unreliable as measures. The SPACE framework suggests using multiple metrics to measure different aspects of productivity. DORA’s five delivery metrics (deployment frequency, lead time for changes, change fail rate, failed deployment recovery time and deployment rework rate) work best together as a system.

Measurement also decides what gets funded. Ravi Bellur, who often acts as a translator between technology teams and the C-suite, notes that CEOs and CFOs judge AI initiatives on four EBITDA levers: revenue growth, gross margin, cost reduction, and capital preservation and expansion. Initiatives that can’t draw a direct line to one of them risk coming to a budgetary close. Saurabh Gupta adds two risks that are easy to miss: regulatory exposure for companies relying on open-weight models such as Qwen and GLM, and IP infringement. Teams worry about their own data leaking, he says, but often overlook what the model learned from.

Governance is where companies turn AI policy into engineering practice. Review checklists, security scans and architectural sign-offs need to evolve for code written without organizational context. For teams using AI-assisted development, that means writing the merge requirements for AI-generated code into the definition of done. Our panel on agentic AI governance covers who owns that work.

If a company scales its AI initiatives but does not upgrade its specification and governance, it will get more output built on the same weaknesses that limited delivery before, without adding value to customers.

Watch the Full Session

The full 52-minute session includes the live audience poll, the semantic-layer question, and the closing advice from each panelist.