You buy to learn. Nobody budgets the exit.

Mihail Eric runs AI at Monaco and teaches Stanford's course on AI-native engineering. Asked on Latent Space how his team decides which tools to buy and which to build, he gave a rule that fits in a sentence: "You buy to learn, and you build to keep."

The receipts he offered were specific. Monaco sampled a range of code-review products, in what he described as a statistically driven review rather than vibes, and converged on Devin for many cases. For the environments where background agents run the product, reproduce a failure and test a patch, they built their own, because the details depend on how Monaco's cloud is set up. They built in-house, he said, when they felt there was no mature offering, and they are not dogmatic about revisiting it.

I have spent 18 years in this industry and the last 4 running AI platforms in production. I sit in the fractional CTO chair for a series of client leadership teams, which means I am usually the person who signs off the renewal, or refuses to. From that chair, Eric's rule is the best short version of this decision I have heard in a while. It is also one line short, and the missing line is the expensive one.

The standard rule has no clock

The rule most companies actually use is older and sounds just as reasonable: buy the commodity, build the differentiation. It is a rule about the thing. Is this capability generic or is it ours? Decide that, and the verb follows.

Eric's rule is about time. Buying is tuition: you pay a vendor to find out what your problem actually is, what the team actually needs, and which parts of the first answer were wrong. Building is what you do once the lesson has landed, for the thing you intend to still own in three years.

Put that way, the decision made on signing day is not whether to buy. It is when the tuition ends and what you take with you when it does. The exit is decided at the entry, and in most companies I enter, nobody has written it down.

Buy to learn

Adopt a vendor's product in order to discover what the company needs, with the understanding that the arrangement has an end date. The purchase is tuition, not infrastructure.

Build to keep

Build in-house only what the company intends to still own and maintain in three years. Everything built is a liability with a maintainer attached.

The exit

What has to happen for the company to stop using a bought tool: what data, configuration and behaviour would have to leave with it, and what each of those costs to carry out.

Deletion cost

The priced, dated version of the exit. Not "could we leave", but what leaving costs in weeks and money, stated before the day you need to know.

What the exit actually costs

The clearest case I have worked on followed Eric's rule exactly, without anyone having stated it. A client had bought a commercial white-label product. It did the job while the company was learning what the job was. Then the company outgrew it, and we replaced it with a proprietary AI-driven platform.

Read as a story, that is buy to learn and then build to keep. Read as a ledger, the lesson is different. The code was the cheap part of the exit. A bought tool holds more than features. It holds the data in the vendor's shape, the configuration that encodes two years of decisions, and the behaviour the team has quietly come to depend on without anyone recording why. Those do not come out through an export button. They come out through people who remember, and by the time you are leaving, some of them have left too.

You do not pay for a vendor on the day you sign. You pay on the day you leave.

That is the line Eric's rule leaves out. "Buy to learn" is true and cheap only if the learning is written down somewhere the vendor does not own, and if the day the tuition ends is on a calendar rather than in a feeling. Otherwise the company has not bought to learn. It has bought to stay, and it finds out when the renewal arrives with a price nobody agreed to.

Build to keep assumes you can keep

The second half of the rule has its own hidden condition. "Build to keep" assumes the team can keep what it builds. Monaco can. Most Series A and B companies I meet cannot, and the honest version of their build decision is "build to keep for about eighteen months, until the engineer who understood it leaves."

Keeping is not a cost on the day of the build. It is the maintainer, the dependency tree, the upgrade that is now blocked on a library nobody has touched, and the on-call rotation that includes the thing. Agents have made the first draft of almost anything cheap to produce. They have not made it cheap to keep, and a team that confuses the two will build a great deal in year one and spend year two discovering what it owns.

So the useful question is not "should we build this" but "where exactly is the line between what we own and what we rent, and does it sit at a place the team can actually defend". The platforms I have run draw that line in three different places, and the location was the decision each time.

None of those three lines is clever. What they have in common is that each was drawn on purpose, at a boundary the team could defend, and each can be moved at a known price. The loan platform could swap its identity provider. The enrichment platform could swap its crawler, or its model vendor, in configuration. That is the whole art of "build to keep": keep less than you think, and keep it at an edge you chose.

The third option nobody budgets

Which brings me to the verb that is missing from both rules. Buy to learn, build to keep, and then, when the lesson has landed, delete.

I optimise for deletion. Every line of code is a future maintenance burden, every service another failure mode, every dependency a supply-chain risk, and every vendor a renewal with someone else's hand on the price. The option that reduces all four is the one that is never on the slide, because nobody gets promoted for removing a tool and no vendor sells the absence of their product.

So the instrument I bring to a new engagement is not a build-versus-buy framework. It is a document, one page, written on the day a tool is adopted, that most leadership teams have never been asked for.

Notice what the record makes impossible. A tool cannot quietly become infrastructure, because its end date is written down. A team cannot lose the lesson when it leaves the vendor, because the lesson was being exported all along. And finance cannot be surprised by a renewal, because the price of saying no was computed before anyone had to say it.

Why agents move the line

Everything above would have been sound advice in 2019. Two things have changed the stakes.

The first is volume. The study cited in the show notes of Eric's episode, from Faros AI's telemetry, found that teams with high AI adoption merged 98% more pull requests, while their review time was 91% longer. More changes, each one reviewed for longer, is exactly the environment in which a company buys a review tool to learn what it can safely stop reviewing. It is also the environment in which the tool's configuration becomes the only place that policy is written.

The second is Eric's own question, asked almost in passing: when an agent proposes a change, where does it look to find out why the team rejected this same change six months ago? If the answer is "inside the vendor's product", the company has handed its institutional memory to a renewal. If the answer is "nowhere", it never had one. I wrote two weeks ago that an agent has no hallway and only has what you wrote down. The bought tool is the sharpest version of that problem: it is the place where the most decisions get made and the fewest get recorded.

Agents made building cheap. They did not make keeping cheap, and they made forgetting free.

What I am not claiming

• Anything about Devin, or about Monaco. I have evidence about neither. Eric's rule is quoted because it is good, and his team's choices are quoted because they are his receipts, not mine.
• That building is cheaper than buying. It usually is not, once you count the keeping. The argument is that both verbs need a dated exit, and only one of them ever gets one.
• That I can show you a chart. I cannot prove that a written exit record lowered anyone's vendor spend. What I can show is the absence, in the first week of every engagement, and the renewal that arrived as a surprise because of it.

Monday

If you run a company and want to know whether you are buying to learn or buying to stay, you do not need a procurement review. You need to pick the three largest vendor lines in the engineering budget and ask three questions about each.

1. What are we learning from this, and by when will we have learned it?If the answer is "it just does the thing", the tuition ended a long time ago and the invoices did not.
2. What would leave with it?Data in the vendor's shape, configuration that encodes your decisions, behaviour the team depends on. If none of that is exported somewhere you own, the learning belongs to the vendor.
3. What does deleting it cost, in weeks and money?Not whether it would be hard. A number, stated before the renewal lands, so that saying no is a decision rather than an emergency.

Those are the questions I ask in the first weeks of a fractional engagement, and the answers decide which renewals get signed. In most companies the answers are not bad. They are absent, which is the whole argument in one observation. Eric is right: you buy to learn and you build to keep. The companies that get hurt are the ones that never decided what they were learning, and so never noticed when the lesson was over.

Buy to learn. Build to keep. Write down the exit before you need it.