>> Hey everybody, how you doing?

Hey, that's pretty good.

That's pretty good.

3:00 p.m.

On a Wednesday, right? It's a Wednesday.

Not so bad.

Welcome to software engineering at the tipping point.

My name is Adam Bender and today I'm going to talk to you about something called software ecology,.

A term you might not have heard before.

I want to talk about it will tell us something about the impact of AI on our developer ecosystems, the developer ecosystems.

You work in every day.

Now, I don't know if you guys have noticed this, but things are getting pretty weird out there, right?

Your job in 2026.

Does not look like what you thought it would in 2020.

I assure you that. If you tried to explain to 2020 me what this was going to be, I would not have.

Believed you.

It can be a bit overwhelming to try and figure out where all of this change is taking us, right?

And while I can't predict the future,.

I think that if we study our software ecosystems.

As they are today, some of the answers we're looking for are a lot closer than we think.

I think that software ecology, this idea, it gives us the perfect lens for framing this particular moment in our industry.

Now, I can hear you asking,.

"What is software ecology and did he just make this up to get on stage?"

I did not. It is a real term.

But before I define it, I want to set some context for you.

So, we're going to go a little deep dive on systems thinking.

I hope you're okay with that.

Hang with me. I promise you it will all make sense when we get there.

So, let's start with the concept of a system,.

Right? A system.

It's a group of interrelated elements that act according to a set of rules to form a unified whole.

That sounds pretty fancy, but you know systems.

They look like this. This is a system you're probably pretty grateful for today.

This is what air conditioning is, right?

So, you have a thermostat that knows what temperature to be, you have an HVAC that's going to jack the temperature up.

Or down, and you have a room.

And when the temperature's right, the signal stops.

That's a system.

If you're a software engineer, you're probably used to thinking about systems all the time.

You design them, you build them, you operate them.

But one thing you've probably learned when working with systems is that everything is connected.

Everything.

That's a theme you're going to hear from me a couple times today.

Now, let's move on to an ecosystem, which is a particular kind of system.

This is a long one, so bear with me.

An ecosystem is a dynamic network of interdependent actors that co-evolve with their environment, characterized by emergent behavior and decentralized agency.

Ecosystems.

Are complex. They're built from complex components.

The components themselves are deeply connected.

They have agency, they can make decisions, they can do things.

And critically for us, the environment is a part of that system.

Right? The environment is a part of the system.

You can't separate the two.

So, ecosystems are also a kind of complex adaptive system.

A complex adaptive system, or CAS, they're characterized by their ability to grow and change and evolve over time.

All the cool systems are complex adaptive systems, right?

Now, complex adaptive systems, they possess this emergence quality as well.

An emergent property.

Is something that you can't see by looking at any individual piece of the system.

You can only see it when the system is all put together, and then you see behavior emerge out of it.

And it's that constant change, that learning, plus the emergence that make it really hard to figure out what's going on in.

An ecosystem.

Now, when you think of ecosystems, or at least when you thought of them before you walked in here, this is probably.

What you had in mind. And frankly, I'd like to be here right now, right?

Looks kind of idyllic.

But your internal developer environment, it is also a kind of ecosystem.

You have all your tools and services, you have complex actors, you have people with opinions and things they want to get.

Done, you have business constraints.

This is a system, too.

And in fact, it's a particular kind of system.

It's a socio-technical.

System.

A socio-technical system is just kind of a fancy way to say a system made of people and technology.

Now, socio-technical.

Systems are incredibly complicated.

They're complicated because you start with all that technology.

And then you mix in the people,.

Right?

There's a pretty good chance though that you've encountered some wisdom about socio-technical systems without even realizing it.

Have any of you ever heard of Conway's law?

Yes, of course everyone heard it has heard of Conway's law, but briefly, Conway's law goes like this.

Organizations build technologies that mirror their internal communication structures.

Or informally,.

If you have a four-team.

Group working on a compiler, you're going to get a four-pass compiler.

That's just how it works. Now, at its core, Conway's law is an observation that the way we build technology.

Is inseparable.

From the structure of the organizations that build it.

The organizations shape what gets built.

Now, of course, it's not just the organizational structure.

That impacts our developer ecosystems,.

Right? The values and culture of an organization can have just as profound an impact.

Your ecosystem builds what your organization incentivizes.

Your engineering culture creates the environment around your developer ecosystem.

See, the thing is, once you learn about socio-technical systems, you see them everywhere in software development.

From your architectures.

To your postmortem culture to code review to security policy, they're everywhere.

The things we build and the way we choose to build them are a reflection of what we value.

If we're thoughtful, we can use that knowledge to amplify our values and put them into the things we build, boosting the.

Kinds of outcomes that we want.

So, now I think I can properly define for you software ecology.

Software ecology is the holistic study of the socio-technical.

Ecosystems that produce software.

All right, now we're all caught up.

It's okay if all that felt a little abstract by the way, because now we're going to look at a real example.

We're going to talk about Google's developer ecosystem.

Google has a very large, and I would argue, somewhat complicated developer ecosystem,.

Because over the last 25 years, we have evolved.

Truly remarkable capabilities and, yes, a little complexity.

Now, as an upfront disclaimer, I'm talking about Google, partly because I work there, but it is the developer ecosystem I understand.

The best. My intent here is not to tell you you got to go do what Google did.

That's not going to be good for you, right?

You're a different company, you're a different you're in a different place,.

You didn't have a different set of trade-offs you're worried about.

Now, like any engineering organization, Google has made a lot of choices.

They were very specific to the needs we had at the time we were building our our ecosystem.

Your situation? Different. Different.

So, a few years ago, we wrote a book.

Maybe some of you have seen this book before.

Um internally, we call it the flamingo book.

Uh we wrote this book to give people an understanding of how Google actually worked inside.

And we spent half this book talking about things like version control and testing, but the entire first half of this book.

Was spent on engineering culture.

And we used to get a lot of questions about that.

Why so much on engineering culture?

Well, the reality is, if you don't understand the culture that Google has, you can't appreciate why we have the technical choices.

That we've made. These things are interlinked.

Now, in case you didn't read the book, I'm going to give you a brief tour.

Don't worry, you don't need to read all this.

Yes, take pictures. That'll be fine.

Um.

There's a few things about Google that make it somewhat unique.

So, for example, we're deeply engineering-led.

Engineers are always in the room when important decisions are being made.

We're big on transparency,.

Right? We try to make all the docs and code that we can available as often as possible.

We encourage people to be helpful.

In fact, if you talk to anyone who's ever left Google, the helpfulness of their colleagues will be one of the most.

Important things they cite.

We treat code review as an opportunity for mentorship and not test grading.

We're big on standardization,.

Real big on it. Um we believe in continuous improvement.

We're big into blame blameless postmortems.

We're We're big on the idea that sustainability is better than heroics and that automation is better than toil.

Now, we don't always achieve all of these ideals, but this is kind of what we're aiming for culturally.

And on the technical side, we have our monolithic repository you've probably read about.

I'll tell you more about that in a second.

We have trunk-based development where every change lands at head every time.

When you build a binary at Google, almost every line of code is built from source.

That's pretty wild, right? Uh we have a universal build toolchain.

Everybody uses it. We have a global test automation platform.

One place runs all the tests.

Billions of tests a day.

We have a global signal for the last green.

I can tell you the state of any build looking at one simple internal website.

We have a uniform computing environment, so it works on my machine isn't possible, mostly.

Uh we have opinionated developer frameworks and a small set of core languages.

And it's this mixture of culture and technology that give rise to what Google is.

You can't understand one half without the other.

Now, if I had to pick one principle.

One principle that seems to have guided us, implicitly if not explicitly at times, it's this thing called shared fate.

Now, shared fate's a term that describes the degree to which an ecosystem.

And its components are tightly linked to each other.

In a high shared fate ecosystem,.

One component can affect everything else.

Right? Now, in a developer ecosystem,.

Shared fate is as much a technical choice as a social one.

You can't just get shared fate by building this like making everyone use the same technology.

You also have to develop social contracts for how you're going to manage that technology,.

Right? Now, at Google.

Our shared fate starts with our monolithic repository.

Every line of code at Google, with a couple notable exceptions like Android and Chrome, is in one shared repository.

Everything.

Everything is committed to trunk. There are no branches.

There are no versions.

Everything in one place.

This kind of shared fate allows us to apply a security patch in one file and know that within a week.

Every application of the company will have been patched.

That's like a superpower, right?

10 lines of code in the right place in the right place can patch 10 billion lines.

Of application and system software.

That's pretty impressive, right?

Now, shared fate isn't always a a good thing.

Right? Shared fate is a choice.

There are places where shared fate might make less sense.

For example, in our production environment,.

We don't want one service to take down all the other services or one cluster to, you know, an effect an entire.

Region. So, we've worked really hard.

Google in particular has worked really hard to make sure we don't have the dangerous kinds of shared fate that cause things.

Like cascading failures.

Again, the point is shared fate is a trade-off.

You have to figure out the right place to put it and then make sure that it works well for you.

Now, one of the most interesting emergent properties of our large of our, excuse me, of our shared fate environment is this.

Notion of large-scale changes.

Now, long before AI, way before AI, Google's internal tools have made it possible for a single developer to change literally millions.

Of lines of code.

Millions of lines of code. Code they will never look at.

They will never see again. They will might know nothing about it.

Right? We've built tools that make that automatically possible today.

And we've been doing it that way for at least the last 15 years.

This kind of capability has let us evolve our mono repo over time.

We can update languages and frameworks.

It's really what keeps our internal environment from becoming stagnant.

It's no exaggeration to say that without it, we wouldn't be the Google that we are today.

Right? And the folks who work on those tools would tell you it's like it's an unsung hero's kind of job to.

Keep this company moving at the speed it needs to move.

The thing about large-scale changes is you can't appreciate them unless you understand the cultural components and the technical parts of our.

Ecosystem that make it possible. For example, you need a widespread testing culture.

Everybody needs to be writing tests for me to be able to do this.

We need to have a single platform so I know where to look to get the results of those tests.

Right? We It's good to have common build tools so we're all building the same software.

I build it, you build it, we get the same outcome.

We need a standard set of libraries so as we're swapping things out, we're not jumping around trying to find which version.

Of this library is working for you and not me, right?

We need standardized code review. We need transparency in the mono repo itself, so I know which code needs to be changed.

LSCs are truly the ultimate manifestation of this automation over toil ethos at Google, and it's only possible because of the entire.

Ecosystem.

You can't point at one part of our developer environment and say, "That's why LSCs happen."

It's everything linked together.

Right? Now, every developer ecosystem, yours, anyone you've ever worked in, they have these emergent properties.

They're usually the things that feel somewhat unique to the place that you work.

And that's because they're usually the result of the constellation of choices you have made to shape how you want to work.

So, every ecosystem has something like this.

Google has large-scale changes, you have something else.

Google's developer ecosystem embedded in our specific engineering culture has produced a unique set of trade-offs.

They serve our technical and business goals.

However, Google's ecosystem,.

Like every ecosystem, cannot excel at all tasks.

We've chosen to optimize for extreme scale,.

Security, performance, right? And we'll do that typically even if it comes at the expense of developer productivity sometimes.

That's a trade-off we're willing to make in our ecosystem.

The developer ecosystem of other places, like say a five-person startup, is going to look different, and that's okay.

In a five-person startup, velocity and agility are like the most important things you can possibly have.

Somewhere in between a five-person startup.

And Google is where you are, right?

Most of you are inhabiting an ecosystem that's somewhere between five and 200,000.

The trade-offs you're going to make are really important to pay attention to because when you look at the trade-offs being made,.

You can begin to understand the values of the organization.

What does it really care about?

Not what does it say it cares about, but what does your organization.

Actually care about? And when you understand those values, you can begin to shape the transformation as it begins to unfold.

We're all experiencing a lot of transformation right now, so it would be good to understand where we're going.

I I by now the concept of a software ecosystem is a bit more clear.

And I think it's time we talk about the token-eating elephant in the room.

What does an AI-first developer ecosystem actually look like?

Now, it would be nice to build one of these out from from scratch, a greenfield ecosystem, but I would bet none.

Of you have that luxury, right?

You all have to continue shipping software, doing what it is you're doing today, while you're replacing literally every part of it.

No big deal, right?

Your company is depending on you to continue delivering value.

And make sure that nothing breaks.

So, to make sure nothing breaks, let me ask you a question.

How well do you understand your developer ecosystem today?

Right?

Can you map it all out?

Do you know where all the pieces are?

Not just the technical ones, but the social ones.

Can you enumerate what your ecosystem is actually built from?

How well do others in your organization understand it?

What are its strengths or its weaknesses?

Where are your bottlenecks?

Where are you constrained or where are you free?

What what optionality do you have?

What kind of emergent properties have you seen in your own ecosystems?

And perhaps most importantly,.

If your ecosystem suddenly had to grow by, I don't know, 10 to 15x.

In the next 18 months, do you know what would break first?

See, the thing about that last question is we're all going to have to answer it real quick.

Because every developer ecosystem on Earth is going through a radical transformation.

Maybe it hasn't gotten to everywhere you are yet, but it's coming.

Every single developer ecosystem is going to have to wrestle with this idea of this 10x moment.

I wish I could tell you there was a way out of this, but it's coming, right?

These are incredible times,.

But they are also somewhat confusing.

All the tradeoffs we have deliberately evolved over the last 25 years are going to get rebalanced.

You've heard that from probably every speaker here in some form or another.

We don't know yet what the future's going to be.

We're trying to figure it out.

Some folks are predicting productivity that looks like.

10x, 100x. We're measuring things in orders of magnitude.

That's a lot, right? Suddenly, the question of 10x growth.

Is not just a thought exercise.

It's like a code red moment for you and your company.

You're going to have to figure this out.

If not today, certainly in the next 12 months.

Now, before I go much farther,.

I really want to stress that I understand there's a big difference between generating code 10 times faster.

And engineering 10 times faster. These are different things.

And in fact, at Google, we often say that engineering is programming integrated over time.

But the thing is, we're speeding up programming a lot.

We're making the code machine go fast.

So, we're going to have to figure out how we engineer around that code machine in order to deliver real results to.

Our customers.

No one knows yet how far we can push this productivity growth.

I really don't know. We could stop next week.

I don't think so. But we're, you know, one thing's for sure, we're going up from here.

The problem is, I think we have a lot of work to do because I would bet very good money that what.

We're doing today doesn't work at 10x.

I would bet the way you're building software, the way I'm shipping software, doesn't work at 10 or 100x velocity.

Something's going to have to change.

Well, let's start by looking at a standard developer ecosystem.

It's simplified, I know. Hopefully, you'll recognize some of these terms up here, but let me put them in a form you're.

More used to seeing them. A complex graph, right?

In a world with 10x more productivity or 10x more activity, rather, what has to change?

Well, let's start with the nodes related to getting code into the code base.

Now, notably, I have excluded testing and version control.

We'll get to those in a second.

What happens if the green nodes suddenly have to do 10 times more stuff?

Well,.

Let's start with writing source code.

If everyone gets a lot faster at writing code, that's probably going to be a there's probably going to be a lot.

More of it, right?

That's not good. Now seems like a very good time to remind you of an old Jeff Atwood quote.

Software is a liability.

Right? So, right off the bat, 10x more code, 10x more liability.

We're not into a good place.

By the way, you've probably noticed that you can't just hand everyone a bunch of tokens and say good luck.

So, I hope you're investing in retraining.

You are investing in retraining, right?

Do you know where all your engineering practices are documented?

Would you know how to evolve them if you had to?

Okay, well, something to think about when you get home.

Let's move on to the build system really fast.

At a minimum,.

More code is going to mean more compile time, right?

Bigger system, more compile time. Just what we needed.

I'm sure no one at your company has ever complained about slow compiles.

Well, guess what? They're going to get slower.

And if agents are driving a lot of work, that means more compiles.

So, not just bigger, but more.

Compilation isn't free in time or compute.

And it's possible you've never noticed how much time you spend on compilation, but I can assure you.

10 times larger, you're going to notice something.

Right? What about the design of all that code?

Do you have the right agentic skills to encourage decoupling?

What about the right server frameworks to ensure that you can compose capabilities quickly and safely?

Come to think of it, do you know how many ways web applications are served in your company today?

Do you know how many different server frameworks you're actually running?

I don't, actually.

Uh how are you going to manage component reuse if agents are writing all of that code?

Maybe you're betting it won't matter.

Don't be surprised though if agents write code that is easy to write and hard for you to maintain.

That seems to be the benchmark right now.

Agents are good at writing code, but they're not always thinking long term the same way you and I need to.

That code, I'm sure won't be well-factored.

That's okay. We'll figure that part out, but.

The the truth of it is.

Agents are doing a lot of work for us now.

And we're going to have to figure out how we apply that most effectively.

Every single day.

At some point,.

All that agentic work could make your binaries so big you can't compile them anymore.

Or maybe they get so big you can't ship them on phones anymore.

Have you ever asked the question, what is the largest binary you can compile?

I actually don't know what the answer is, but I know we're bumping into limits at Google.

We're getting our binaries so big in some places, we can't compile them anymore.

We'll figure it out, I'm sure of that, but the truth is big has lots of consequences.

Scale has impacts everywhere.

Now, perhaps you're more of a microservices shop, and you're looking at me going, "Why would I ever build a service that.

Big? All my services are tiny."

That's cool for you, except now I have a question.

What's going to happen with 10x more network traffic?

10x more services? 10x more chatter?

10x more network traffic? Are you ready for that?

No one gets out of this unscathed.

Scale has effects everywhere.

Now, let's say you can't reliably compile all this code.

I'm sure you can, right? What happens to your code review process?

Everyone is worried about code review right now, and I think that's for a good reason.

We're putting a lot of pressure on this very human process.

Right? And in many cases, it is becoming a bottleneck.

And one thing I know about people, they do not like to be bottlenecks.

They act funny when you put pressure on them, right?

With 10x more code, you're going to get one of two things: 10x larger changes, or 10x more of them.

So, what does that mean for your code reviewers?

Well, I'd be willing to bet most of your tech leads cannot sustain the review velocity necessary to see, I don't know,.

Even five of these 10x developers through a day, right?

That's a lot of work.

So, what they're going to do in order to not become a bottleneck is they're going to start rearranging their process.

They're going to start cutting corners to make sure they don't block anyone, cuz no one wants to be a blocker.

Now, you may be able to solve part of this with AI.

I'll give you that. You may be able to deploy AI to make your review process better.

Okay? But that only solves part of your problem.

Because if the people on your team aren't writing code, then the only time they're encountering it is during review.

But they're not paying as much attention during review.

That's what we just said. So, who's paying attention to the code base as it evolves?

Well, no one.

Right? Pretty soon, your code base is going to be a mess that no one can understand.

Now, in addition to all that source code, we have to think about token management.

Because tokens are expensive, as some of you probably know, right?

At scale, tokens are a real cost we have to factor.

What happens if everyone in your company starts using 10 times more tokens or 100 times more tokens or what if you.

Accidentally spend your monthly budget in a day, a thing that has happened to a friend of mine.

Right? If you had to prioritize where you're going to put that spend, do you know where you'd put it?

Do you even have the visibility to know where the tokens are going right now?

See, even in just the first few notes of this system, this simple system, we're already finding problems and it is very.

Clear that there's going to be some challenging second-order impacts.

Now, let's move on to testing in version control.

These are a little bit special.

Have you ever looked at how much compute your testing infrastructure takes?

I do not know about you, but at Google, I never have fast enough tests.

I've never said, "Boy, my tests are going faster than I needed to today.

I don't have enough capacity as it is."

Right? Every change that lands in version control has to be tested though.

But also, agents love running tests because it tells them whether or not they're doing good work.

So, again, the agents are doing additional work and I have more work to do.

So, with 10 times more commits and agents doing all that work, now how much test computer are you using?

Actually, it turns out it could be worse than that.

Because what we've seen at Google is that our code as your code base grows, your dependency graph grows quadratically,.

Not linearly with the size of your code base.

So, if your code base is 10 times larger.

And you're trying to test all the dependencies so that you're sure nothing will break, you may have upwards of 100 times.

As many tests running. Maybe it's 1,000 times as many tests running.

That's going to be a really interesting challenge and it's going to be a you know, a an a line item in.

Your budget at some point. That's something you should you should be thinking about.

So, now you're not just running tests more often, they run they may be 100 times bigger.

And quite frankly, if they're not going to get that big, if you're not worried about how much test compute you're spending,.

I'm more worried because that means you probably don't have enough tests to begin with and those agents are yoloing all over.

Your code base with no way to know what is working.

All right?

Now, let's assume you figure that out.

You solved compile, you solved testing.

Let's talk about your version control system.

Most popular version control systems are not optimized for performance.

Not at all. They're optimized for consistency,.

Ordering,.

Right? That's their job. Their job is to keep a complete record, not to go real fast.

What's the performance of your version control system?

How many commits can it take a minute?

I assure you it is less than you think.

Right? It's not going to scale to 10x the the the velocity that you need it to.

When was the last time you even thought about the performance of your version control system?

Ever?

Not unless you work on Git, right?

Honestly, if we're talking about version control performance, something has gone horribly wrong.

Right? We are in the bowels of the developer experience here.

The bowels. But that's what happens when you see systemic change.

Systemic change finds every corner of your system and says, "Hey, you paying attention?

Because here's something that you weren't expecting."

And by the way, for those of you who think you're going to solve this version control problem with a lot of.

Little repos,.

I got some news for you.

Talk to anyone who's run that strategy, who has hundreds or thousands of little repos, and I can assure you it's just.

An entirely new set of challenges, none of which AI is going to necessarily make easier for you.

Right?

So far we've hit problems in every node we've looked at.

And believe it or not, we've only looked at the relatively.

Easy to find capacity nodes. These are all things you could just find.

Like you just, you know, take a number, multiply it by 10, and ask will that go good or bad.

There's a lot of other unexpected challenges.

So we're going to go through a a really quick list of some things I think you want to be worried about.

So first,.

Validation beyond just your compute.

The validation strategy used today is probably something like a lot of unit tests and maybe some integration tests.

But with 10x more code and 10x more services, integration tests are going to become the most important part of your quality.

Strategy. How many of you are happy with your integration testing.

Setup today?

I will note for the live stream there is not a single hand up.

Okay, good. That's what I thought.

I am also not happy.

Right? Integration testing is really hard, and I do not have the tools to do it the way I would like to.

Right now.

Then you have this problem that I refer to as the conjunction of booleans.

In order to ship software today, you request that every test pass.

All the booleans turn green. Everything is good before you ship.

That's a reasonable thing to do.

What happens when you have a million tests and the actual reliability of the underlying test infrastructure to run a million tests.

Is in question?

It might not be possible for to ship software where every boolean has to be true.

So now you're going to need a new strategy.

It's probably something statistical to figure out what are the right tests to run because I can't run everything.

Okay. What about super extra large changes?

It's really exciting that we can refactor and change languages and frameworks everywhere.

Everyone can do it. Do you have the workflows or the social contracts to enable people to manage merge conflicts that are.

Measured in the tens of thousands of lines, hundreds of thousands of lines, millions of lines?

Probably not.

So we're going to need to figure out how do we build the workflows that support very large change sets moving past.

Each other? If everyone at the company can do it, we need we're going to need a new strategy.

And by the way, have you ever seen an agentic edit war?

Where one edit an agent makes a change and then another agent comes in and says, "No, I don't like that change.

Let's do a different change."

Now it's funny to watch until you realize you're paying for the tokens on both sides of that, right?

Let's move on to release. How many times do you release to your customers today?

Daily?

If you're doing daily, you're doing pretty good.

If you're not, here's a problem for you.

You're going to get 10x more software.

And that software has to land somewhere.

And if you're not releasing daily, my guess is that each change is now going to get a lot bigger.

And if there's one thing my my friends will tell me, it is that very large changes are very scary.

Let's not do that. But the code has to go somewhere.

It needs to get deployed to be valuable.

So one thing you're probably going to try to do is release more frequently and that's good.

Our friends at Dora would be proud.

They would say, "Yes, please release more."

But at some point you're going to release diminishing returns.

Releasing every second is probably not going to provide a lot of value to you.

So somewhere between releasing every second and I'm not quite to a releasing a day is the right balance, but still the.

Code will grow and we're going to need to figure out where do we put that code so that we don't create.

More risk.

How about your internal APIs?

We've been talking about building software, but what about the internal developer environment with all the APIs and data?

What I've been telling my friends that I work with is all of your APIs suddenly just became public.

They need the same kind kind of hardening that you would put on anything that you're going to send out to the.

Public internet. Why? Because agents aren't going to negotiate with you.

They're going to find an API, they're going to start calling it and if they can get access to your data, they're.

Going to do it.

I guarantee it. Right? If an agent can access a data set, it's available to them.

So, if you haven't put the same thought into your internal data sets and your internal APIs, you're going to run into.

Some very interesting challenges cuz agents are going to find things you probably didn't want them to.

Well, how about Jevons paradox? This is a word we all learned in the last probably 12 months, right?

No one knew what this was or even how to pronounce it.

But now we all know about Jevon.

Jevon says.

The cheaper and more efficient a resource gets, the more we use it.

And boy, do you see that with tokens?

We are putting them everywhere.

And it's changing how we work and how we think about how we work.

We're now optimizing.