AI is an amplifier, not a direction.

Article author and source: InfoQ

AI makes you write code 10 times faster—so what? More code means longer compile times, heavier testing, clogged code reviews, and a codebase nobody understands. Software is a liability; the faster you write, the more you owe.

Google’s chief software engineer, Adam Bender, issued a straightforward warning: the way you build software today simply won’t work at ten times the speed. But the true winners of the AI era aren’t the most productive teams—they’re the ones with the strongest fundamentals, because AI amplifies, but doesn’t direct.

During a keynote at Google I/O 2026, Adam Bender posed a question most people haven’t had time to consider: When AI pushes code production speed beyond what current engineering processes can handle, what will break first in our developer ecosystem? He tied together the entire talk with a concept you may not have heard before: software ecology—the discipline of studying the sociotechnical ecosystem of software production as a whole. In other words, you must look not only at technology, but also at people, culture, and the unwritten rules within organizations. Based on the video of this talk, InfoQ has organized the content.

The key points are as follows:

• AI won't solve any problems for you by default. If your practices are good, it can amplify them. But if they're not, it will only create more trouble.
• It's cool that everyone is a builder, until you have to maintain everything everyone has built.
• Engineering practices are not sacred or inviolable. Practices change; principles are what matter.
• As a frontline software engineer, at this pivotal moment, you are at the heart of determining where software engineering is headed. From tools to workflows, from engineering practices to engineering culture, if you can see the systems in motion, you can find your leverage.

What is a "system"?

Your job in 2026 is completely different from what you imagined in 2020. If I tried to explain to my 2020 self what’s happening today, I wouldn’t believe it. The changes have been so numerous and rapid that they’re almost overwhelming. I can’t predict the future, but I believe that if we carefully examine today’s software ecosystem, some answers are closer than we think.

Today, I want to talk to you about a term: software ecology. It might sound like something I made up for the stage, but it’s not—it’s a legitimate term. Before defining it, I’d like to provide some context and briefly delve into systems thinking.

A system is a set of interconnected elements that operate according to a set of rules to form a unified whole. It may sound abstract, but you’re already familiar with systems. For example, an air conditioner: a thermostat that knows the target temperature, an HVAC unit that heats or cools, a room, and when the temperature is right, the signal stops—that’s a system.

If you're a software engineer, you interact with systems every day—you design them, build them, and operate them—and along the way, you likely learned one thing: everything is connected.

Next is the ecosystem, 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 simple terms, ecosystems are complex, with deeply interconnected components, each possessing its own autonomy to make decisions and take action. And most crucially: the environment is part of the system—you cannot separate the two.

An ecosystem is also a complex adaptive system that can grow, change, and evolve over time. It also possesses a characteristic known as emergence—properties that cannot be observed by examining any single component alone, but only arise when the entire system is assembled. It is precisely this ongoing change, continuous learning, and emergence that make it extremely difficult to understand what is truly happening within an ecosystem.

When you think of an ecosystem, you probably imagine mountains, rivers, birdsong, and blooming flowers. But an internal developer environment is also an ecosystem: it consists of various tools and services, people with their own ideas and needs, and business constraints. And it’s a special kind of system—a sociotechnical system, one made up of both people and technology. Sociotechnical systems are extremely complex because you start with all those technologies and then introduce people into the mix.

You’ve likely already encountered the wisdom of sociotechnical systems without realizing it. Do you know Conway’s Law? It states that the technology an organization builds will mirror its internal communication structures. In simple terms, if you have four teams working on the same compiler, you’ll end up with a four-pass compiler—that’s just how it works. The core insight of Conway’s Law is that the way we build technology is inseparable from the organizational structure behind it; the organization shapes what ultimately gets built.

But it’s not just organizational structure that shapes the developer ecosystem—values and culture have an equally profound impact. The ecosystem you build reflects what your organization incentivizes, and your engineering culture creates the environment surrounding your developer ecosystem. Once you understand sociotechnical systems, you’ll see them everywhere in software development: in architecture, incident postmortem culture, code reviews, security policies—they’re everywhere. What we build, and how we choose to build it, reflects what we value. If we’re intentional enough, we can leverage this awareness to amplify our values and embed them into everything we create.

I can now give you a proper definition: Software ecology is the discipline that studies the sociotechnical ecosystem of software production holistically. If that was a bit abstract earlier, that’s okay—let’s look at a real-world example now.

Google's developer ecosystem

I’m talking about Google not because I work there and am trying to promote it, but because it’s the developer ecosystem I understand best. My goal isn’t to tell you that you should copy Google—that wouldn’t benefit you. You’re a different company, at a different stage, facing different trade-offs. Many of the choices Google made were driven by the specific needs we had when building our ecosystem at the time.

Several years ago, we wrote a book internally called the "Flamingo Book." Half of it covers version control and testing, but the entire first half is devoted to engineering culture. Many people asked why we spent so much time on culture—because without understanding Google’s culture, you can’t understand why we made the technical decisions we did; these things are interconnected.

Google has several distinctive cultural traits. We are deeply engineering-driven, with engineers always present when making important decisions; we place extreme emphasis on transparency, making all documents and code accessible to everyone whenever possible; we encourage helpfulness—in fact, anyone who has left Google will typically cite the helpfulness of their colleagues as the first thing they remember; we view code reviews as opportunities for guidance, not as grading exercises; we place extreme importance on standardization; we believe in continuous improvement; we champion blameless postmortems; and we firmly believe that sustainability trumps heroism, and automation trumps manual labor. Of course, we don’t always live up to all these ideals, but they represent the cultural direction we strive toward.

On the technical side: a monorepo where nearly all code resides in a single repository; trunk-based development where every change is merged directly into the main branch; when building a binary, nearly every line of code is compiled from source; a unified build toolchain used by everyone; a global automated testing platform where all tests run from one location, executing billions of test cases daily; a global "last green" signal that allows me to tell you the status of any build via a simple internal website; a standardized compute environment that makes "it works on my machine" virtually impossible; and highly standardized developer frameworks with a small set of core programming languages.

This blend of culture and technology has shaped Google into what it is today—you can't understand half of it while ignoring the other half.

Shared destiny

If I had to choose one principle that has quietly guided us all, it would be “Shared Fate.” It describes the degree of interconnectedness between an ecosystem and its components—in a high-shared-fate ecosystem, one component can influence all others. In the developer ecosystem, shared fate is both a technical and a social choice. You cannot achieve shared fate merely by having everyone use the same technology; you must also establish a social contract around how these technologies are managed.

At Google, shared fate begins with a monorepo. Every line of code in the company, with few exceptions like Android and Chrome, resides in a single shared repository. All code is committed to the main branch—no branches, no version numbers—everything is in one place. This shared fate allows us to apply a security patch in a single file and know that within a week, every application across the company will be fixed. Patching ten lines of code to fix ten billion lines of application and system software feels like a superpower.

But sharing fate isn't always a good thing—it's a choice. There are situations where sharing fate is inappropriate, such as in production environments, where we never want one service to bring down all others, or one cluster to infect an entire region. Therefore, we've put significant effort into avoiding dangerous shared fate—those types that lead to cascading failures. Shared fate is a trade-off; you must find the right placement and ensure it works in your favor.

Large-scale changes

One of the most fascinating emergent properties in our shared fate environment is large-scale change. Notice this: long before AI existed, Google’s internal tools enabled a single developer to modify millions of lines of code—millions they would never read, never look at again, and might know nothing about. We built the tools that made this automatic, and that’s how it is today—and we’ve been doing this for at least the past fifteen years.

This capability allows us to continuously evolve our monolithic codebase, update languages and frameworks, and prevent our internal environment from becoming rigid. Without large-scale changes, we would not be the Google we are today. The colleagues who build these tools perform behind-the-scenes hero work that enables the company to move at the speed it needs.

But the key point is that you can’t truly understand it unless you understand the cultural and technical components that make large-scale changes possible. What do you need? A widespread testing culture where everyone writes tests. A unified testing platform so you know where to find results. Common build tools so your build produces the same result as mine. Standardized libraries so that when you swap components, you don’t have to jump around figuring out which version works for you but not for me. Standardized code reviews and transparency within the code repository so you know exactly which code needs to be changed. Large-scale changes are the ultimate expression of Google’s principle that “automation beats manual labor,” and they’re only possible when the entire ecosystem collaborates. You can’t point to one part of the developer environment and say, “That’s what caused it”—it’s the connection of all the parts together that makes it happen.

Your ecosystem, your trade-offs

Every developer ecosystem has such emergent properties. They are typically what makes you feel that your workplace has a unique character, because they are the result of a series of choices you’ve made.

Google’s developer ecosystem has evolved a unique set of trade-offs to serve our technical and business goals. But like every ecosystem, it cannot excel at every task. We choose to optimize for extreme scale, security, and performance, even if that sometimes comes at the cost of developer productivity—we are willing to make this trade-off. A startup ecosystem with five people would look very different, where speed and agility are paramount.

Most of you are operating in an ecosystem between five people and 200,000 people. The trade-offs you need to make are highly significant, because when you examine these trade-offs, you begin to understand the organization’s true values—what it actually cares about, not just what it claims to care about, but what its actual choices reveal. Once you understand these values, you can begin to shape the transformation unfolding before you.

10x moment: Every node is under pressure

It’s time to talk about the elephant in the room eating tokens: what does an AI-first developer ecosystem actually look like?

Building an entirely new ecosystem from scratch is certainly ideal, but none of you have that luxury. You must continue delivering software while replacing nearly every component within it. The company expects you to keep creating value while ensuring nothing breaks.

So ask yourself this question: How well do you understand your developer ecosystem today? Can you draw it out in full? Do you know where all the components are—not just technical ones, but social ones too? Can you list what your ecosystem is made of? How much do others in your organization understand? What are its strengths and weaknesses? Where are the bottlenecks? Where are constraints, and where is there freedom? What options do you have? What emergent properties have you observed? Perhaps most critically: If your ecosystem suddenly had to handle 10 to 15 times the code volume over the next eighteen months, do you know what would fail first?

Every developer ecosystem on Earth is undergoing a radical transformation—perhaps it hasn’t reached every corner where you are yet, but it’s on its way. Every developer ecosystem will soon have to confront this 10x moment. It’s an incredible time, but also a deeply confusing one. The careful trade-offs we’ve deliberately cultivated over the past twenty-five years will all be rebalanced.

Generating code 10 times faster and accelerating engineering development 10 times are two different things. At Google, we often say that engineering is programming integrated over time. But the issue is that we are dramatically accelerating the coding portion, speeding up the code machine. Therefore, we must find ways to build solid engineering practices around this code machine to truly deliver value to customers. No one knows how far this productivity surge will take us, but one thing is certain: we are moving upward from here.

The problem is that the way we build and deliver software today won't work at 10 or 100 times the speed—something must change.

Let’s begin by looking at a simplified version of the developer ecosystem map. In a world where activity increases tenfold, what must change?

Code committed

Write the source code. If everyone writes code much faster, the volume of code will increase dramatically—and that’s not a good thing. Jeff Atwood said that software is a liability. So, ten times the code means ten times the liability. And you can’t just hand everyone a pile of tokens and say, “Good luck.” I hope you invest only after training: Do you know where your engineering practices documentation is? Do you know how to evolve it? Consider that first.

Building systems. More code and larger systems mean longer compile times. I’m sure no one at your company is currently complaining about slow compiles. But guess what? They’re going to get even slower. And if agents are driving a massive amount of work, the number of compiles is skyrocketing. Compiling isn’t free—it costs time and computational resources. You may never have noticed how much time you spend compiling, but at ten times the scale, you definitely will.

Code design. Do you have appropriate agent-based skills to encourage decoupling? Do you have suitable server-side frameworks to ensure rapid and secure composition of various capabilities? Do you know how many different deployment methods your company uses for web applications? How many distinct server-side frameworks are currently in use? How do you manage component reuse for code written by agents? Perhaps you’re betting it doesn’t matter. But if agents produce code that’s easy to write but hard to maintain, don’t be surprised—that’s the current baseline. Agents are skilled at writing code, but they don’t always think long-term. That code, I’m certain, won’t be easily refactored. That’s fine; we’ll address this part later. But the reality is that agents are doing a tremendous amount of work for us, and we must find ways every day to apply these capabilities as efficiently as possible.

At some point, these agent-based workflows may cause your binaries to become so large that they can no longer be compiled—or even pushed to a mobile device. Have you ever asked yourself: What’s the largest binary you can compile? I don’t know the answer, but I know that at Google, we’re already hitting limits, with some binaries having grown too large to compile. I believe we’ll find solutions. But the reality is that scale has far-reaching consequences—its impact is everywhere.

Maybe you're using a microservices architecture and thinking: My services are all small, why should I care? But here's a question: Are you ready for 10x network traffic, 10x the number of services, and 10x the communication volume? No one can escape unscathed—the impact of scale is everywhere.

Code review. If you can't reliably compile all this code, how does your code review process change? Everyone is anxious about code review, and with good reason. We're placing immense pressure on this inherently human process, and in many cases, it's becoming a bottleneck—and people don't like being bottlenecks. When you pressure them, their behavior becomes erratic. With ten times the code volume, you either get ten times larger changes or ten times more changes. Can your tech lead maintain the necessary review speed? Most tech leads can't even keep up with the daily code output of five 10x developers.

So, to avoid becoming a bottleneck, they start rearranging processes and taking shortcuts to ensure no one gets blocked, because no one wants to be the blocker. You might solve part of this with AI—deploying AI to improve code reviews. But this only addresses part of the problem, because if your team members aren’t writing code anymore, the only time they encounter code is during reviews, and if their attention during reviews is insufficient, who’s tracking the evolution of the codebase? No one. Soon, your codebase will become a mess that no one understands.

Token economics. Tokens are expensive—you some of you already know this. At scale, tokens are a real cost you must account for. What happens if everyone in the company starts using 10x or 100x more tokens? What if you accidentally spend your entire monthly budget in a single day? If you must prioritize where to allocate tokens, do you know where to focus your spending? And do you even have visibility into where your tokens are actually going?

Even within the first few nodes of this simple system, we have already identified issues. And it is clear that there will be some challenging second-order effects.

Testing and Version Control

Have you ever considered how much computational resources your testing infrastructure consumes? At Google, I’ve never been satisfied with the speed of my tests.

Every change entered into version control must be tested. But beyond that, agents also enjoy running tests because tests tell them how well they’re doing. As a result, agents generate additional workload, which means I have more to do. So, with ten times the number of commits plus all the work the agents are doing, how much test computing resource is now being consumed?

The situation may actually be worse. What we’ve observed on Google is that as the codebase grows, the dependency graph scales quadratically, not linearly. So if your codebase becomes 10 times larger, you might need to run not 10 times as many tests, but 100 or even 1,000 times as many. This will become a very significant challenge—and at some point, it will show up as a line item on your budget. If you’re not currently concerned about the cost of test computation resources, that’s even more worrying, because it likely means you don’t have enough tests at all, and your agents are YOLOing through your codebase without a safety net.

Assuming compilation and testing are resolved, let’s look at the version control system. Most popular version control systems are not optimized for performance—they’re optimized for consistency and ordering. That’s their job: maintaining a complete record, not running at lightning speed. How many commits per minute can your version control system handle? I guarantee it’s far fewer than you think. It cannot scale to the 10x speed you need. When was the last time you thought about the performance of your version control system? If you’re not developing Git, you’ve probably never thought about it. Honestly, if you’re reduced to discussing version control performance, something has gone seriously off track. We’re at the very bottom of the developer experience—but this is the consequence of systemic change: it finds every corner of your system and says, “Hey, are you paying attention?” Because something you didn’t anticipate is coming.

To those considering solving version control issues with many small repositories, ask anyone who has managed hundreds or thousands of small repositories—I can guarantee it’s an entirely new set of challenges, and AI won’t necessarily make these problems easier.

Unexpected Items List

So far, we’ve only looked at relatively easy-to-identify capacity nodes—taking a number and multiplying it by ten to ask whether it would be better or worse—yet there are many unexpected challenges ahead.

Verification strategy. Today, your verification likely consists of many unit tests plus some integration tests. But in a world with ten times the code and ten times the services, integration testing becomes the most critical part of your quality strategy. How many of you are satisfied with your current integration testing approach? I’m not either. Integration testing is truly difficult—I currently don’t have the tools to perform integration testing the way I’d like to.

Boolean conjunction problem. Today, you’re releasing software and require every test to pass—all boolean values to turn green—before you proceed, which makes sense. But what happens when you have a million tests, and the underlying test infrastructure itself cannot reliably run a million tests? It may become impossible to require every boolean value to be true before releasing the software. You need a new strategy—likely based on statistics—to determine which tests are correct to run, since you can’t run them all.

Massive changes. It’s exciting to be able to refactor everywhere and switch languages and frameworks. But do you have the workflows and social contracts in place to help people manage merge conflicts involving tens of thousands, hundreds of thousands, or even millions of lines of code? Probably not. If everyone in the company could make massive changes, we’d need entirely new workflow strategies.

Agent editing war. One agent makes a change, another agent comes over saying, "No, I don't like that—I'm making a different change." It seems funny until you realize you're paying token fees for both sides.

Release cadence. How often do you release to customers today? Daily? That’s pretty good. If not, here’s the issue: you’ll end up with ten times more software, and all of it needs to go somewhere. If you’re not releasing daily, each change becomes much larger—and my SRE friends will tell you that very large changes are terrifying. Don’t do that. But code must be deployed to create value, so you might try releasing more frequently, which is great—DORA folks will be pleased. But at some point, returns diminish; releasing once per second likely won’t add much value. Code will still grow, and you’ll need to figure out where to put it without introducing more risk.

Internal API. I’ve been telling my colleagues that suddenly, all your APIs become public. Agents won’t consult with you—they’ll find the APIs and call them directly. They’ll use whatever they can access; I guarantee it. If you’ve never secured your internal interfaces and datasets as rigorously as you would public APIs, agents will find things you never intended them to access.

Jevons Paradox. Jevons said that the cheaper and more efficient a resource becomes, the more we use it. The explosion of tokens is a living example. We’re placing them everywhere, changing how we work and how we think about work. We’re putting a price on previously invisible productive labor—what impact will this have on our behavior? I don’t know yet.

Rollback. Do you know why rollback is basically feasible today? Because you release software slightly slower than the time it takes you to detect issues in your production environment. What if you could release so incredibly fast that you couldn’t detect any problems before they were deployed? Your rollback posture would then be compromised—each rollback would have to contend with multiple conflicting changes piled on top of one another. So releasing faster alone isn’t enough; you must consider the entire system, including rollback as a critical safety valve. By the way, you need to be careful about where you place your token engine. If your rollback process depends on an agent having sufficient capacity, and someone previously exhausted that agent’s token budget—leaving you unable to rollback now—that would probably not be ideal.

Everyone is a builder. You’ve probably thought of building an alternative to that tool at work you dislike. Now multiply that by every person and every tool in the company. What happens to the company’s social fabric when everyone is using completely different tools? If you’re lucky, you have a unified data layer where all data flows into one place—that’s manageable. But what if you don’t? It’s cool that everyone is a builder—until you have to maintain everything everyone has built.

Crash course in technical leadership. It takes so long to become a technical lead because you must develop intuition, judgment, and expertise to make decisions—when you lead a team, your mistakes have far greater consequences than when you work alone. What goes wrong when a recent graduate steps into an environment where they can invoke fifty agents, yet has no intuition or judgment? How can I teach ten years of experience in six months? I don’t know.

Human attention is our most valuable resource. Today, there is so much noise, with so many agents and so many things competing for our attention, that we must find ways to manage it. Previously, we benefited from the fact that our ability to cause trouble never exceeded our capacity to pay attention—but that is no longer the case.

These may sound like a lot, but that’s because everything in a system is interconnected. None of the challenges I just mentioned can be addressed by looking at just one node—you must examine the entire system.

To adapt to agent-based development, we must all begin learning to think systematically and consistently. When thinking about systems, these are the things you should focus on: how things grow over time, the effects that unfold over time, the direction of causality, which nodes are communicating with all their neighbors, what emergence looks like, and what those seemingly out-of-nowhere elements are. What about incentives—both social and technological? Capacity, feedback loops, and bottlenecks: these are the tools of systems analysis.

It may seem complicated, but you really only need two questions: Why? and What if? Why do we have so few integration tests? What if we had more integration tests than unit tests? Why are we using these specific languages? What if AI wrote all the code?

"Why" is the drill bit you use to dig deep into the system’s core and understand how it works. You’re all great at asking "why," but "what if" is the harder part. "What if" can be intimidating—it might require you to let go of practices you once thought were brilliantly designed. What if you didn’t test it? What if you didn’t write tests at all? Don’t go too far. But if you allow it to happen, "what if" can also be incredibly exciting.

AI is an amplifier, not a direction.

AI is an amplifier. This idea comes from my friends at DORA, whose 2023 AI development report found a common thread among teams that truly figured things out: they learned how to make AI an amplifier.

AI can give you more: more tests, more documentation, more code—but also more chaos. Amplification is about magnitude, not direction. AI doesn’t care where those things go; it simply gives you more. What DORA truly discovered is that teams with strong fundamentals are able to direct this amplification toward useful outcomes.

This raises the question: How do you feel about your foundational skills? What is your company’s decision-making culture? What can you do to improve it? What about your technology strategy? Is anyone paying attention to developer productivity? How well are people collaborating in your organization today? What is your security posture? How are your code health, release hygiene, and reliability? AI won’t solve any problems for you by default. If your practices are strong, it can amplify them. But if they’re weak, it will only create more trouble.

But even with a solid foundation, we are about to embark on a true journey. I suspect that by 2030, our current developer ecosystem will seem as distant to us as 2001 does today. In 2001, we were still distributing software via CD-ROM; by 2030, we may be just as far removed.

As you continue to strengthen your fundamentals, let me give you four things to reflect on along the way.

First, infrastructure capacity. If you don’t know how many resources you have available, you can’t deploy AI or allocate computing resources—you need a reliable way to track them.

Second, verification strategy. You cannot and should not release software that hasn’t been verified. But verification strategies evolve—it’s time to figure this out clearly. Integration testing will become your most important weapon, and you may not yet have the right tools at hand.

Third, isolation. You’ll end up with a lot of code written for different purposes, some of which were never intended for production use. That’s fine—but you don’t want cool prototype code to accidentally make it into production. Keep the experimental stuff from affecting the money-making systems.

Fourth, abstraction. We build abstractions to prevent developers from making poor choices—that’s why we have libraries and frameworks. No one writes a web server from scratch. Allowing agents to make too many decisions leads to the same outcome, so you need good abstractions for agents to follow. Don’t give them bad options.

You must also accept one thing: engineering practices are not sacred. Practices change; principles are what matter. This is easier said than done—if you’ve never truly thought about why your team tests software in a certain way, or why your release process works the way it does, you won’t be able to evolve it. Understanding the principles will give you the strength and confidence to navigate this 10x moment.

It’s an exciting time to be a software engineer. Every dimension of our work is being redefined; we need creativity more than ever; we require skills to address challenges like context management, token economics, and model drift; we need creativity; and we must resist the temptation to optimize everything, instead encouraging exploration.

There’s a problem that has kept me up at night, and it can’t be solved by optimization alone: as our codebase grows, how do we maintain intellectual control over it? Intellectual control means whether humans can reason about what’s in front of them. We’ve already lost this battle for at least fifteen years—our largest systems have long surpassed the scale any single person can comprehend. If you don’t believe me, try an experiment: ask everyone on your team to draw a system architecture diagram and see how many different versions you get.

Many of our software systems are extremely fragile—a single line of bad code or an incorrect configuration flag can bring down a system with hundreds of thousands of lines. This fragility forces you to think carefully before making any changes. But I have a very exciting idea about AI: a continuously updated, nearly interactive architectural space where I could ask questions. What if we moved this capacity to the East Coast? What if user growth suddenly spiked by 40%? For even a moderately sized system today, answering these questions functionally is nearly impossible—there are simply too many variables. But AI can understand massive datasets, so I believe there’s something here worth exploring.

I like this question because we’re not just focused on making the code machine run faster—we’re asking: How can we deepen our understanding of what we’ve already built?

Changes are happening incredibly fast—faster than most of you have ever experienced. One of the most important things you can do right now is to help those who are struggling and reach out to those who haven’t yet figured things out. We’re all moving at different paces and responding to this change in different ways. It’s easy to feel like you’re falling behind.

Senior engineers, become mentors. Find those who are stuck and help them. If you’ve figured out the AI development workflow, share it with others—it’s not a precious secret. Technical leads, you must get involved and help guide the direction of software engineering in your company. If you care about software quality or software design, you must speak up for it. The people in this room are the ones who need to make this happen—your bosses probably won’t.

If we imagine the developer ecosystem as a living ecosystem, we’ve become accustomed to closely monitoring every leaf on every branch, tending to each tree as if it were a rare form of life. But soon, we won’t be managing just one tree—we’ll be managing an entire forest. And you can’t manage a forest by focusing on individual trees; you must view the forest as an ecosystem to manage it effectively.

Systemic change has a quality: it occurs simultaneously everywhere and in everything, so vast that it feels like nothing can be grasped. Right now, you may feel that nothing can help you stand firm against the waves of change that seem to surge every week. But as we just discovered, in a system, everything is connected—small actions can produce large consequences.

Regardless of how it may appear on the surface, AI transformation is not solely the domain of company leaders. As a frontline software engineer, you are at the heart of determining where software engineering is headed at this pivotal moment. From tools to workflows, from engineering practices to engineering culture, if you can see the systems in motion, you can find leverage. You have more autonomy than you realize—use it to create the future for your organization, your team, and yourself.