AI makes you write code 10 times faster. Then what? More code means longer compilation, heavier testing, more congested code reviews, and a codebase that no one can understand. Software is a liability. The faster you write, the more you owe.
Adam Bender, the chief software engineer at Google, issued a straightforward warning: The way you build software today simply won’t work at 10 times the speed. However, the real winners in the AI era are not the teams with the highest output, but those with the most solid fundamentals. Because AI only amplifies; it doesn’t determine the direction.
During a keynote speech at Google I/O 2026, Adam Bender posed a question that most people haven’t had time to think about: When AI pushes the code output speed to a level that the existing engineering processes can’t handle, what will be the first to collapse in our developer ecosystem? He strung the entire speech together with a concept you might not have heard of: Software Ecology, which is a discipline that conducts a holistic study of the socio – technical ecosystem for software production. In other words, you need to look not only at technology but also at people, culture, and the unwritten rules within the organization. Based on the video of this speech, InfoQ has organized the content.
The core points are as follows:
Your job in 2026 is completely different from what you imagined in 2020. If you tried to explain what’s happening today to me in 2020, I wouldn’t believe it. There have been so many changes that it’s a bit overwhelming. I can’t predict the future, but I believe that if we study the current software ecosystem carefully, some answers are closer than we think.
Today, I want to talk to you about a term: Software Ecology. It might sound like I made it up just for this speech, but it’s a legitimate term. Before giving the definition, I’d like to provide some background and delve a little deeper into systems thinking.
A system is a set of interrelated elements that operate according to a set of rules to form a unified whole. It sounds abstract, but you’re not unfamiliar with systems. For example, an air – conditioning system: a thermostat that knows the target temperature, a heating, ventilation, and air – conditioning (HVAC) unit that heats or cools, and a room. When the temperature is right, the signal stops. That’s a system.
If you’re a software engineer, you deal with systems every day. You design systems, build systems, and operate systems. In the process, you’ve probably learned one thing: everything is interconnected.
Next is the ecosystem, which is a special type of system. The definition is a bit long but important: An ecosystem is a dynamic network of interdependent actors that co – evolve with their environment, characterized by emergent behavior and decentralized autonomy. In plain language, ecosystems are complex, with components deeply connected. Each component has its own autonomy, can make decisions, and take actions. And the most crucial point: the environment is part of the system; you can’t separate the two.
Ecosystems are also complex adaptive systems that can grow, change, and evolve over time. They also have a characteristic called Emergent Property, which is something you can’t see by observing any single component. It only emerges when the system is assembled as a whole. It’s this continuous change, continuous learning, and emergence that make it extremely difficult to figure out what’s really going on in an ecosystem.
When you think of an ecosystem, you probably picture mountains, rivers, birds, and flowers. But the internal developer environment is also an ecosystem: it has various tools and services, people with their own ideas and requirements, and business constraints. And it’s a special type of system: a socio – technical system, which is a system composed of both people and technology. Socio – technical systems are extremely complex because you start with all that technology and then throw people into the mix.
You’ve probably unknowingly encountered the wisdom of socio – technical systems. Do you know Conway’s Law? The technology an organization builds will mirror its internal communication structure. In simple terms, if you have four teams working on the same compiler, you’ll end up with a four – pass compiler. That’s how it is. The core observation of Conway’s Law is that the way we build technology is inseparable from the organizational structure that builds it. The organization shapes what is ultimately built.
But it’s not just the organizational structure that affects the developer ecosystem; values and culture also have a profound impact. Your ecosystem builds what the organization incentivizes, and your engineering culture creates the environment around the developer ecosystem. Once you understand socio – technical systems, you’ll see them everywhere in software development: architecture, post – incident review culture, code reviews, security policies, etc. What we build and the way we choose to build it reflect what we value. If we’re careful enough, we can use this understanding to amplify our values and inject them into what we build.
Now I can give you the correct definition: Software Ecology is a discipline that conducts a holistic study of the socio – technical ecosystem for software production. If the above was a bit abstract, that’s okay. Now let’s look at a real – life case.
I’m talking about Google not because I work there and want to praise it, but because it’s the developer ecosystem I know best. My goal isn’t to tell you to copy Google; that won’t do you any good. You’re different companies at different stages, facing different trade – offs. Many of the choices Google made were tailored to the specific needs when we were building our ecosystem.
A few years ago, we wrote a book, internally called the “Flamingo Book.” Half of the book is about version control and testing, but the entire first half is about engineering culture. Many people asked why we spent so much space on culture. It’s because if you don’t understand Google’s culture, you can’t understand why we made those technical choices. These things are interrelated.
Google has several unique cultural traits. We’re deeply engineering – oriented, and engineers are always involved in making important decisions; we highly value transparency and make as many documents and code as possible accessible to everyone; we encourage helping others. In fact, if you talk to anyone who has left Google, they’ll mention the helpfulness of their colleagues first; we view code reviews as opportunities for guidance, not as grading papers; we highly value standardization; we believe in continuous improvement; we advocate for blame – free incident reviews; we firmly believe that sustainability is better than heroism and automation is better than manual labor. Of course, we don’t always achieve all these ideals, but this is the direction we’re striving for culturally.
In terms of technology? A monolithic code repository, where almost all code is in one repository; trunk – based development, where every change is directly merged into the mainline; when building a binary, almost every line of code is built from source; a unified build toolchain that everyone uses; a global test automation platform that runs all tests in one place, with billions of test cases every day; a global “last green” signal, and I can tell you the status of any build just by using a simple internal website; a unified computing environment, so the problem of “it works on my machine” hardly ever happens; highly standardized developer frameworks and a small set of core programming languages.
This combination of culture and technology has shaped Google as it is today. You can’t understand only half of it and ignore the other.
If I had to choose one principle that has been subtly guiding us, I’d choose “Shared Fate.” It describes the degree of close connection between an ecosystem and its components. In an ecosystem with high shared fate, one component can affect all other components. In the developer ecosystem, shared fate is both a technical choice and a social choice. You can’t achieve shared fate just by making everyone use the same technology; you also need to establish social contracts on how to manage these technologies.
At Google, shared fate starts with the monolithic code repository. Every line of the company’s code, except for a few exceptions like Android and Chrome, is in a shared repository. All code is committed to the trunk, with no branches and no version numbers. Everything is in one place. This shared fate allows us to apply a security patch in one file and know that within a week, every application in the company will be fixed. Patching billions of lines of application and system software with just ten lines of code is like having a superpower.
But shared fate isn’t always a good thing; it’s a choice. There are places where shared fate isn’t appropriate. For example, in a production environment, we never want one service to bring down all other services, or one cluster to infect an entire region. So we’ve put a lot of effort into avoiding dangerous shared fate, the kind that can lead to cascading failures. Shared fate is a trade – off. You have to find the right place for it and make sure it works for you.
One of the most interesting emergent properties in our shared – fate environment is large – scale changes. Note this: Long before the emergence of AI, Google’s internal tools have already made it possible for a developer to modify millions of lines of code, millions of lines they’ll never read, never look at again, and may know nothing about. We’ve built tools that make all this possible automatically, and that’s how it is today, and we’ve been doing it for at least the past fifteen years.
This ability allows us to continuously evolve the monolithic code repository, update languages and frameworks, and prevent the internal environment from becoming rigid. It’s no exaggeration to say that without large – scale changes, Google wouldn’t be what it is today. The colleagues who develop these tools are like unsung heroes, enabling the company to move forward at the required speed.
But the key is, if you don’t understand the cultural and technical components that make large – scale changes possible, you can’t really understand it. What do you need? A widespread testing culture, where everyone writes tests. A unified testing platform so you know where to get the results. A common build tool so that your build results are the same as mine. Standardized libraries so that when replacing components, you don’t have to jump around to find which version works for you and which doesn’t. Standardized code reviews and transparency of the code repository itself so that you know which code needs to be changed. Large – scale changes are the ultimate manifestation of Google’s concept of “automation is better than manual labor,” and it’s only possible when the entire ecosystem collaborates. You can’t point to one part of the developer environment and say that’s the cause. All parts are connected and are the cause.
Every developer ecosystem has such emergent properties. They’re usually the things that make you feel that the place you work is unique, because they’re the products of a series of choices you’ve made.
Google’s developer ecosystem has produced a unique set of trade – offs to serve our technical and business goals. But like every ecosystem, it can’t excel at all tasks. We’ve chosen to optimize for extreme scale, security, and performance, even if it means sometimes sacrificing developer productivity. We’re willing to make this trade – off. The ecosystem of a five – person startup would look completely different, where speed and agility are the most important.
Most of you are in an ecosystem between five and two hundred thousand people. The trade – offs you need to make are very worth paying attention to, because when you examine these trade – offs, you can start to understand the values of the organization: what it really cares about, not what it says it cares about, but what the choices you actually observe reveal. When you understand these values, you can start to shape the ongoing transformation.
It’s time to talk about the elephant in the room that eats tokens: What does an AI – first developer ecosystem really look like?
It would be great to build a brand – new ecosystem from scratch, but none of you have that luxury. You have to continue delivering software while replacing almost every part of it. The company expects you to continue creating value while ensuring that nothing goes wrong.
So ask yourself a question: How well do you know your developer ecosystem today? Can you draw it out completely? Do you know where all the components are, not just the technical ones but also the social ones? Can you list what your ecosystem is composed of? How much do other people in your organization know? What are its strengths and weaknesses? Where are the bottlenecks? Where is it constrained, and where is it free? What choices do you have? What emergent properties have you seen? Maybe the most crucial question: If your ecosystem suddenly has to handle 10 to 15 times the amount of code in the next eighteen months, do you know what will break first?
Every developer ecosystem on the planet is undergoing a complete transformation. Maybe it hasn’t reached every corner of your place yet, but it’s on the way. Every developer ecosystem will have to face this 10x moment. This is an incredible era, but also quite confusing. All the trade – offs we’ve deliberately evolved over the past twenty – five years will be re – balanced.
Generating code 10 times faster and engineering development 10 times faster are two different things. At Google, we often say that engineering is programming integrated over time. But the problem is, we’re significantly accelerating the programming part and making the code machine run faster. So we have to figure out how to do engineering work around this code machine to really deliver results for customers. No one knows how far this productivity growth can go, but one thing is certain: We’re on an upward trajectory from here.
The problem is, the way you and I build and deliver software today won’t work at 10 times or 100 times the speed. Something has to change.
Let’s start with a simplified diagram of the developer ecosystem. In a world where the activity level increases by 10 times, what has to change?
Write source code. If everyone writes code much faster, there will be a lot more code, which isn’t a good thing. Jeff Atwood said that software is a liability. So, 10 times the code means 10 times the liability. And you can’t just give everyone a bunch of tokens and say “good luck.” I hope you’ll invest after training. Do you know where your engineering practice documents are? Do you know how to evolve them? You can think about it later.
Build system. More code and larger systems mean longer compilation times. I’m sure no one in your company has ever complained about slow compilation. But guess what? It will get even slower. And if agents are driving a lot of work, the number of compilations is also skyrocketing. Compilation isn’t free, either in terms of time or computing resources. You may never have noticed how much time you spend on compilation, but at 10 times the scale, you definitely will.
Code design. Do you have the right agent – enabled skills to encourage decoupling? Do you have the right server – side frameworks to ensure the rapid and secure combination of various capabilities? Do you know how many deployment methods there are for web applications in your company? How many different server – side frameworks are running? How do you manage the component reuse of the code written by agents? Maybe you’re gambling that it doesn’t matter. But if agents write code that is easy to write but difficult to maintain, don’t be too surprised. That’s the current baseline. Agents are good at writing code, but they don’t always think from a long – term perspective. I’m sure that code won’t be well refactored. That’s
该文观点仅代表作者本人，36氪平台仅提供信息存储空间服务。
36kr Europe (eu.36kr.com) delivers global business and markets news, data, analysis, and video to the world, dedicated to building value and providing business service for companies’ global expansion.
© 2024 36kr.com. All rights reserved.
Leave a Reply