Adam Bender, Principal Software Engineer at Google, stood on stage at Google I/O 2026 and made a claim that should unsettle every engineering leader: by 2030, today's developer ecosystems will feel as distant as 2001 feels now. An era when software shipped on CD-ROMs.
The argument isn't that AI replaces developers. It's that AI applies 10x pressure to every node in the developer ecosystem simultaneously. And ecosystems under pressure don't transform evenly. They break at their weakest points.
Software Ecology: The Lens That Matters
Bender introduces "software ecology" - the study of socio-technical ecosystems that produce software. The term matters because it forces systems-level thinking.
A socio-technical system combines people and technology. Conway's Law states that organisations build technologies mirroring their internal communication structures. Engineering culture and technical choices are interlinked. They cannot be evaluated separately.
An ecosystem is a dynamic network of interdependent actors characterised by emergent behaviour - properties visible only when the whole system is assembled, not in individual components. This means you cannot manage a forest by looking at individual trees. You have to see it as an ecosystem.
Changing technology without changing organisational structure has limited impact. Changing structure without understanding the technical consequences is equally flawed.
Dependency by Randall Munroe, CC BY-NC 2.5, via xkcd.
Google's Case Study: Culture and Infrastructure as One System
Google's developer ecosystem cannot be understood through technical choices alone. The culture is deeply engineering-led: transparency, helpfulness, blameless postmortems, standardisation, continuous improvement, automation over toil.
The technical side is a monorepo with over two billion lines of code, trunk-based development with no branches, a universal build toolchain (Blaze), a global test automation platform running billions of tests daily, uniform compute environments, and a small set of core languages.
The principle of shared fate guides this: all code in one repository means a security patch propagates to every application within a week. This enables large-scale changes (LSCs), where a single developer can modify millions of lines of code - a capability Google has had for over 15 years, predating AI.
The Software Engineering at Google book dedicates its first half to engineering culture because the technical choices cannot be understood without cultural context. Trade-offs reveal what an organisation actually values, not what it claims to value.
A five-person startup would optimise differently - prioritising velocity and agility over extreme scale. Google's choices are not universal recommendations. They are manifestations of Google's specific constraints and values.
The 10x Problem: What Happens When Productivity Jumps
Bender maps a standard developer ecosystem and applies 10x pressure to each node. The results are uncomfortable.
- Source code: 10x more code means 10x more liability. As Jeff Atwood noted, software is a liability, not an asset. Larger binaries may become un-compilable or too large to ship on mobile devices.
- Build systems: More frequent compiles driven by agentic work. Binaries grow. Compile limits approach.
- Code review: Becomes a human bottleneck. Tech leads cannot sustain the velocity. Reviewers cut corners. Quality degrades.
- Testing: The dependency graph grows quadratically with codebase size. A 10x larger codebase may require 100x or 1,000x more tests. Most organisations' testing infrastructure cannot handle this.
- Version control: Optimised for consistency and ordering, not throughput. Becomes a bottleneck under 10x commit velocity.
- Token economics: Tokens are expensive at scale. Accidental budget exhaustion is a real risk that has already occurred in production. Load-bearing token engines create single points of failure.
| Node | 10x Pressure | Likely Breakpoint |
|---|---|---|
| Source code | 10x more liability | Binary size limits, compile times |
| Build systems | More frequent compiles | Queue saturation, artifact storage |
| Code review | Human bottleneck | Review corner-cutting, quality degradation |
| Testing | Quadratic dependency growth | 100-1000x test volume, compute budget crisis |
| Version control | Throughput limits | Performance breaks, merge conflicts |
| Token budgets | Accidental exhaustion | Production dependency on agent capacity |
Agents write code that is easy to produce and hard to maintain. They don't think long-term. The code generation gets faster. Everything downstream gets harder.
Second-Order Challenges Nobody's Talking About
Beyond capacity, several deeper problems emerge:
Integration testing becomes the most critical quality strategy, yet most organisations remain dissatisfied with their integration testing setup.
The "conjunction of booleans" - requiring every test to pass before shipping - becomes infeasible at million-test scale. Organisations will need statistical test selection strategies.
Internal APIs require hardening equivalent to public-facing systems because agents will discover and access whatever data is available. If internal APIs are not treated with public-level security, agentic systems will expose vulnerabilities.
"Everyone is a builder" democratises engineering but fragments the social fabric. Tool sprawl from democratised building creates maintenance overhead. Junior developers lose traditional entry-point work that builds intuition and judgement.
Release cadence must increase to absorb more software, but releasing too fast outpaces defect detection, breaking the rollback safety valve.
AI as an Amplifier, Not a Fixer
DORA research on AI development found that AI amplifies existing fundamentals rather than replacing them.
Teams with strong practices - good decision-making culture, solid technical strategies, effective collaboration, healthy codebases, clean release processes - apply AI amplification productively. Teams with weak fundamentals amplify their dysfunction at equal speed.
AI generates more of everything: more tests, more documentation, more code, and also more confusion. Amplification is a magnitude, not a direction.
This aligns with Jevons Paradox, observed in 1865: as a resource becomes more efficient, total consumption increases rather than decreases. AI makes code generation dramatically cheaper, unlocking demand previously suppressed by cost. The result is more software being built, not less.
The Jevons paradox: efficiency gains push demand up, not down. Chart by JirkaBulrush, CC BY-SA 4.0, via Wikimedia Commons.
Bender's prediction: by 2030, current developer ecosystems will feel like 2001 feels today.
What to Do About It
Bender offers four pillars for preparing:
Infrastructure Capacity
Track compute, token budgets, and resource allocation. AI cannot be deployed without knowing available resources. Implement token spend tracking and compute budget monitoring.
Validation Strategy
Rethink quality assurance for 10x scale. Integration testing becomes paramount. Design statistical test selection strategies to replace the "all green" shipping gate.
Isolation
Separate prototype and experimental code from production systems. Create clear boundaries. Prototype code must not accidentally reach production.
Abstraction
Build good frameworks for agents to operate within. Prevent bad choices at scale the way frameworks prevent developer mistakes. Agent-targeted abstractions prevent systematic bad decisions.
The Real Takeaway
Engineering is programming integrated over time. AI makes programming faster. It does not automatically make engineering faster.
The organisations that win will not be those with the best AI tools. They will be those with the strongest fundamentals that AI can amplify. Culture, technical strategy, collaboration, security posture, code health, release process - these determine whether AI becomes a multiplier or a megaphone for dysfunction.
Focus on fundamentals first. Then deploy AI at scale.
You cannot manage a forest by looking at individual trees. You have to manage a forest by seeing it as an ecosystem.
Adam Bender