Software Ecology and the 10x Moment

Most conversations about AI in software engineering focus on the code machine: how fast can we generate tokens, how many lines per minute, how much can an agent automate. But coding velocity is just one node in a much larger system. The talk "Software Engineering at the Tipping Point" from a Google engineer reframes the discussion around a concept called software ecology: the holistic study of the socio-technical ecosystems that produce software.

An ecosystem is a complex adaptive system. It is built from complex components that are deeply connected. The components have agency: they make decisions, they do things. And critically, the environment is part of the system. You cannot separate the two. Your internal developer environment, with its tools, services, people with opinions, and business constraints, is what Conway's law predicted: a socio-technical system where the way you build mirrors the way you organise. Understanding it as one is the first step to engineering it intentionally.

Shared Fate and the Monorepo

Google's developer ecosystem runs on a principle called shared fate. In a high shared fate ecosystem, one component can affect everything else. Shared fate is as much a technical choice as a social one. You cannot get it by making everyone use the same technology; you also need social contracts for how you manage that technology.

At Google, shared fate starts with the monorepo. Every line of code, with a couple of exceptions, lives in one shared repository. Everything commits to trunk. There are no branches. This means a ten-line security patch in the right place can patch ten billion lines of application and system software within a week. That is the upside of shared fate.

Shared fate is a tradeoff. In production environments, you do not want one service to take down all the others. Google has worked hard to avoid the dangerous kinds of shared fate that cause cascading failures. The point is not that shared fate is good or bad. The point is that it is a choice, and you have to figure out the right place to put it.

The most interesting emergent property of Google's shared fate environment is large scale changes. Long before AI, Google's internal tools made it possible for a single developer to change millions of lines of code they have never seen and will never see again. This capability lets the monorepo evolve over time. Languages and frameworks get updated. The internal environment does not stagnate. It is the practical payoff of a trunk-based development strategy paired with automated tooling. But large scale changes are only possible because of the entire ecosystem: a widespread testing culture, a single test platform, common build tools, standardized code review, and transparency in the monorepo itself. You cannot point at one part of the developer environment and say that is why large scale changes happen. Every part is linked together.

The 10x Moment

Every developer ecosystem on Earth is going through a radical transformation. Some predict productivity gains measured in orders of magnitude: 10x, 100x. The question of 10x growth is not a thought exercise. It is a code red moment. You are going to have to figure this out in the next 12 months.

But generating code 10 times faster is not the same as engineering 10 times faster. Engineering is programming integrated over time. The code machine is speeding up, which means you have to figure out how to engineer around it.

Here is the problem: what we are doing today does not work at 10x. The way you are building software and shipping it does not work at 10x velocity. Something has to change. When you model a standard developer ecosystem as a complex graph and ask what happens when every node has to do 10 times more work, the answer is that almost everything breaks.

Writing source code. If everyone gets faster at writing code, there is going to be more of it. Code is a liability. 10x more code means 10x more liability. Agents are good at writing code but they are not always thinking long term. Code written by agents will not be well-factored. At some point, all that agentic work could make binaries so large you cannot compile them anymore. Google is already bumping into binary size limits.

The build system. More code means more compile time. Bigger systems, more compiles. Agents running autonomously means even more compiles. Compilation is not free in time or compute.

Code review. Everyone is worried about code review for good reason. It is a human process, and people do not like being bottlenecks. With 10x more code, you get 10x larger changes or 10x more of them. Most tech leads cannot sustain the review velocity for five of these 10x developers a day. So they start rearranging their process, cutting corners. AI can help with part of the review process, but if humans are no longer writing code and skimming reviews, who is paying attention to the codebase as it evolves? Nobody. Pretty soon the codebase is a mess nobody can understand.

Token economics. Tokens are expensive. At scale they are a real cost. What happens when everyone in your company starts using 10 times more tokens? What if you accidentally spend your monthly budget in a day? If you had to prioritize where to put that spend, would you even know where the tokens are going right now?

Testing and version control. Every change in version control has to be tested. Agents love running tests because it tells them whether they are doing good work. So with 10x more commits and agents running additional work, test compute explodes. Worse, as the codebase grows, the dependency graph grows quadratically, not linearly. A 10x larger codebase could mean 100x or 1000x more tests running. That is a budget line item.

Version control systems are optimized for consistency and ordering, not performance. They cannot scale to 10x the velocity. Most people never think about the performance of their version control system. That is what systemic change does: it finds every corner of your system and asks if you were paying attention.

Unexpected Challenges

Beyond the capacity problems, there are harder challenges.

Validation beyond unit tests. Integration testing is about to become the most important part of your quality strategy, and nobody is happy with their integration testing setup today. The conjunction of Booleans: shipping software requires every test to pass. What happens when you have a million tests and the reliability of the test infrastructure itself is in question? It might not be possible to ship software where every Boolean has to be true. You need a statistical strategy for what tests to run.

Agentic edit wars. One agent makes a change. Another agent comes in and reverts it. You pay for the tokens on both sides. It is funny until it is your budget.

Release velocity and rollbacks. More code has to land somewhere. You will need to release more frequently, but there are diminishing returns. Releasing every second does not provide much value. And if you can release faster than you can detect a problem in production, every rollback has to contend with multiple conflicting changes landing on top of it. Rollbacks are a safety valve that depends on releasing slower than your detection time.

Internal APIs become public. Agents do not negotiate with you. They find an API and start calling it. If an agent can access a dataset, it is available to them. If you have not hardened your internal APIs and data sets, agents will find things you probably did not want them to.

Everyone is a builder. Democratizing engineering is cool until you have to maintain everything everyone built. And spare a thought for the junior developers who now have fifty agents at their disposal but none of the intuition and judgment that takes a decade to build. How do you teach ten years of experience in six months?

Human attention. There is so much noise. So many agents, so many things demanding attention. We have benefited from the fact that we could not make more trouble than we could pay attention to. That is no longer the case.

AI as Amplifier

The DORA report on AI development found a pattern: AI acts as an amplifier. It gives you more tests, more documentation, more code, but also more confusion. Amplification is a magnitude, not a direction. AI does not care where the output goes; it just gives you more of it.

Teams with good fundamentals could apply that amplification in useful directions. Teams with weak fundamentals got amplified trouble. This echoes the argument in Software Engineering in the Age of AI: AI does not replace skill, it amplifies it. The same principle applies at ecosystem scale. AI does not solve decision making culture, technical strategy, developer productivity, collaboration, security posture, code health, release hygiene, or reliability. It amplifies the practices you have. If those practices are good, you get more good. If they are not, you get more trouble.

Systems Thinking as the Way Forward

In a system, everything is connected. You cannot resolve any of these challenges by looking at a single node. You have to look at the whole system. To adapt to agentic development, we all need to start thinking in systems all the time.

Two questions get you there: why and what if. Why is the drill you use to bore into the heart of your system to figure out how it works. What if challenges what you find. Why do we have so few integration tests? What if we had more integration tests than unit tests? Why do we use these specific languages? What if AI writes all the code?

What you need to invest in: infrastructure capacity (you cannot deploy AI if you do not know your resource limits), validation strategy (you should not ship unvalidated software), isolation (prevent prototypes from finding their way into production), and abstraction (good frameworks keep agents from making bad choices).

Engineering practices are not sacrosanct. Practices change. It is the principles that matter. If you have never thought about why your team tests software the way it does or why your release process works the way it does, you will not be able to evolve it. Understanding the principles gives you the confidence to change things as you move through this 10x moment.

The hardest problem right now is maintaining intellectual control over codebases as they grow. Can humans still reason about the system in front of them? We have been losing this war for fifteen years. Our largest systems are way bigger than any one person can think about. AI might give us tools to understand these large systems as whole systems: a continuously updated, interactive architectural space where you can ask what-if questions.

In 2030, our developer ecosystems today will feel like 2001 does to us now. In 2001 we were shipping software on CD-ROMs. That is how much is about to change.

You Have More Agency Than You Think

Systemic change happens to everything, everywhere, all at once. It can feel impossible to grab anything to steady yourself. But in a system, small actions can have big consequences. AI transformation is not the sole domain of your company's leaders. As front-line engineers, you are at the heart of deciding what software engineering is going to be. From your tools to your workflows, from your engineering practices to your engineering culture: if you can see the systems at work, you can look for leverage. Use it.