AI makes building software cheap. It can implement in minutes what might previously have taken a developer days. That changes one of the oldest decisions in software development: build or adopt.

For years, the economics were straightforward. If a library or platform already solved most of your problem, you used it. Building your own version meant spending weeks recreating something someone else had already built. Now an agent can build exactly what you need, without the dependencies and features you don’t. So why install someone else’s SDK when your agent can call the API directly? Why bring in a UI library when it can build the component?

The argument for building suddenly looks much stronger. The problem however is that we’re comparing the cost of creating something with the cost of adopting it. Creation is only the first payment.

Start with one API call

Take Microsoft Graph. Imagine you’re building an application and all you need is the current user’s profile. You could install an SDK, configure it, learn its abstractions and use it to call /me. Or you could make an HTTP request. With an AI coding agent helping you, the request is trivial (it’s trivial even without an agent), and introducing an SDK might genuinely be unnecessary.

Then you add mail. You make a few more REST calls and everything works until your application gets a 429 because someone’s inbox is particularly busy. Your agent adds throttling and retry handling. Later, a token expires at an inconvenient moment, so the agent fixes the token lifecycle. Then you need pagination, followed by large file uploads and upload sessions.

Perhaps batching comes next, together with more sophisticated error handling. None of these additions feels unreasonable. That’s what makes the decision difficult. Every time you encounter another exception, the agent can probably fix it. Your implementation works until you find the next exception.

Whether you find it tomorrow, six months from now, or never depends on how thoroughly you test and how many users expose your software to conditions you didn’t anticipate. At some point, your API calls have grown into infrastructure for retries and pagination. You’re also responsible for compatibility with API changes. Congratulations, you’re maintaining an SDK.

Easy things are easy

The same pattern appears far beyond APIs. Ask an agent to build a dropdown and, a few moments later, you can have something polished that matches your application’s design. Click it and it works. Demo complete.

What happens when someone navigates with a keyboard or uses a screen reader? How does it behave with touch or right-to-left text? What does a mobile browser do differently from the browser on your laptop? A mature UI library is valuable because of everything that happened after someone rendered the first rectangle below a button.

Authentication follows the same pattern. Your agent can implement an OAuth flow, and that is no longer a particularly interesting test. The real decision is whether you want your application to own another authentication implementation, together with its security and compatibility details. Easy things are easy. Real software accumulates exceptions.

Mature software contains accumulated knowledge

We often describe software reuse in terms of implementation effort: why write something that already exists? That argument weakens as AI makes implementation cheaper. It also misses much of what mature software contains.

A mature SDK might contain years of bug fixes and production incidents. Customer reports and API changes shape it over time. So do security fixes and obscure edge cases. Some of that knowledge appears in documentation or tests. Some exists only as a strange implementation choice that nobody would make when starting from scratch. The code is partly accumulated knowledge.

When you adopt mature software, you inherit exceptions other people have already discovered. An agent can account for a requirement you tell it about. It can inspect documentation and source code, then fix an exception after you encounter it. But it cannot reliably implement a requirement that neither you nor the agent knows exists.

You don’t know what you don’t know

Better testing can compensate for some of the risk in a custom implementation, and it should. Tests still begin with the conditions you know you need to cover. If your application has five users who behave roughly like you do, your software may look remarkably robust.

But put it in front of 50,000 people across different organizations and devices, and they will discover assumptions you didn’t realize you had made. A mature dependency has often been through some version of that process. Its maintainers have had more opportunities to discover the next exception than you have.

That creates an enormous asymmetry. When you build, you begin with what you know and discover exceptions as reality presents them. When you adopt, you inherit many of the exceptions reality has already presented to someone else.

AI moves the line

You shouldn’t always adopt. If all you need from an API is a profile picture, make the HTTP request. The available abstraction can also be genuinely bad. An SDK might impose an awkward programming model or carry inappropriate dependencies. It might simply lag behind the API. AI makes walking away from bad abstractions considerably more practical.

What changes is where the decision between adopting and building lies. Before AI, the friction of building forced the adoption decision relatively early because another piece of infrastructure meant another meaningful chunk of engineering work. Now the agent says, Sure, I can add that, and a few minutes later it does. The next requirement appears, and it can add that too.

Every individual decision is reasonable, while the custom implementation keeps growing. Its tests grow with it. New changes must remain compatible with previous decisions, and changes in the underlying platform become your problem. AI reduces the marginal cost of the next fix while the total cost of ownership keeps accumulating.

Your private implementation also creates work for future agents. A widely used SDK may appear throughout documentation and public repositories. In comparison, your code and its decisions need to be loaded into context, understood and preserved every time an agent works on it. Cheap implementation can therefore increase the amount of private context your team must maintain.

Decide what you want to own

The build-versus-adopt decision is a spectrum. Calling /me yourself may be cheaper than introducing an SDK. Rebuilding authentication and upload protocols would be much harder to justify when a well-maintained implementation already handles years of errors.

AI moves the point between those ends. It lets us economically own more bespoke software and gives us leverage against poor abstractions. That’s powerful in itself. But before you build, ask what you are choosing to maintain when the happy path ends. Consider how quickly the underlying platform changes, how widely users will expose the implementation to reality, and how costly an undiscovered exception would be.

The value of shared software is changing with that decision. Don’t spend three weeks building this becomes less persuasive when an agent can reproduce the visible functionality in twenty minutes. We’ve already encountered thousands of things you haven’t is a stronger argument because agents make code abundant without giving a new implementation years of production experience.

Building is only the beginning. The agent can help you handle each exception as you discover it. A mature abstraction lets you inherit many of them before you do. Being able to build it is no reason to own it.