You can build almost anything now. That's the problem.

I could have written a database twenty years ago, and so could plenty of other people. What none of us could do, in any timeframe that made commercial sense, was build one that spreads across hundreds of machines, keeps every copy in agreement, survives an entire data center going dark, and stays correct through all of it. That took a specialist team years.

I could probably do that now. With some patience, so could you.

Point a capable coding agent at it and keep going. It would still take a long time and it would still be genuinely hard, but "hard" is not the wall it was two years ago. My company builds infrastructure for AI applications, and we wrote most of it by directing agents. We would not have finished without them, and their technical skill is now such that we could build almost anything from scratch.

So why are we still paying Amazon to run a database for us?

Not because we couldn't build one. That answer used to be enough, and it is quietly becoming useless.

Why "can I build this?" stopped being a useful question

It was a good filter for a long time, because the answer was frequently no. A no ended the conversation and saved you from yourself.

The answer is now usually yes, which means the question no longer helps you decide anything.

What should replace it is a question about cost rather than capability: specifically, which costs actually fell.

What got cheaper, and what didn't

Building got enormously cheaper, and faster than most people have adjusted to.

Running the thing afterward did not, or nowhere near as fast. Planning for growth. The outage at 3am. The upgrade you have to perform on live data without losing any of it. The way it breaks that you have not seen yet, and therefore could not have tested for. The security patch. The change that quietly breaks a customer you forgot was using it. The corrupted data you discover six months after it started.

And underneath all of that sits something that has not moved at all: accountability. An agent can write the code that keeps your data copies in sync. It cannot be the person who is responsible when they fall out of sync. It does not carry the pager, sign the contract, or sit across from the auditor. Those cost exactly what they always did, and they scale with the number of things you own, not with how quickly each one was built.

Which is why "I built it in a weekend" is such a misleading way to measure. The weekend is the cheapest part, and it was already the cheapest part before any of this.

Why running things stays expensive

Software has two kinds of requirement, and they behave completely differently under automation.

Functional requirements are what the thing does. Does the form submit. Does the total add up. Does the right screen appear when you click. Non-functional requirements are everything about how it does it: safely, quickly, at scale, without leaking one customer's data to another, in a way you can prove afterward.

Functional correctness was always the easier half, and it is now close to trivial. That is the real reason the visible part of software fell first: it is almost purely functional. A front end still has to be decent about security and performance, but it carries a fraction of the load. Almost everything it must get right, it can be caught getting wrong.

That is what makes it such good territory for a coding agent. The button is in the wrong place. The screen comes up blank. The test goes red. You find out in seconds, and the damage from being wrong is one screen for one person.

That density is not incidental to why the models are good at it. A model gets strongest where the training signal was thickest and where being right or wrong could be checked automatically, and functional code is the richest such territory in existence: billions of examples, each with a compiler, a type checker, and a test suite standing by to say yes or no. Non-functional correctness has almost none of that. There is no vast public corpus of "here is the isolation model that turned out to be subtly wrong four years later," because nobody publishes those, and the ones that exist are not labeled.

So the failures that matter underneath arrive with no signal at all. They ship invisibly.

A missing filter, the one that keeps one customer's records separate from another's, does not announce itself. It hands over the data to somebody with no reason to question it, in a response that looks exactly like a correct one. A record of who-changed-what with a gap in it looks perfect right up until an auditor asks it a question it cannot answer, which might be two years later. A flaw that leaks information through how long a request takes will keep producing correct answers forever.

Nothing goes red. There is no failing test unless somebody who already understood that specific way of going wrong sat down and wrote it first, which means finding these takes directed, comprehensive, expensive effort rather than iteration. Better models write better code, and plenty of this is recoverable from the code itself if you know to go looking. But what tells you a correct answer from a plausible one usually lives in a requirement or a threat model that nobody ever wrote down, and no amount of reading the code will recover something that was never in it.

Cheap building makes choosing harder, not easier

More options make choosing harder, which is obvious enough. The part worth noticing is that scarcity used to do that choosing for you, for free, and it has stopped.

As building gets cheaper, the number of things you could build expands. Your attention does not. So the bar for what deserves to exist goes up rather than down.

The obvious objection is that attention should deflate along with everything else. Agents triage alerts, watch for anomalies, sit on call, and write the tests. Why would this one input stay scarce while every other one gets cheap?

Because the scarce thing was never the doing. It is deciding what should exist, and then being the one who answers for it. Those do not transfer, for the same reason the pager does not: an agent can tell you a system is behaving strangely, but it cannot hold the goal that determines whether strange matters, and it cannot be the party that carries the consequence. Every system you add lands on the same small number of people who can do those two things, and that number does not move when the tooling improves.

Worse, capacity has never once produced restraint. Every previous drop in the cost of building produced more software, not better-chosen software, and the maintenance came due either way.

Everything you own is a permanent claim on somebody's focus. It has to be understood by whoever touches it next, kept current as the world around it moves, and thought about every time something adjacent changes. When building was the constraint, scarcity did the choosing for you: you built what you had time to build. Now that building is cheap, choosing is the scarce skill, and nothing is doing it on your behalf. The pressure to be selective gets worse, not better.

And the problem is magnified because of the temptation to "build the hard things". Scripts and small tools were never out of reach. This newfound power draws us toward building the substantial pieces that used to be obviously somebody else's job: the store, the queue, the search layer, the permission model. Those are exactly the systems whose failures arrive without a signal. Building is now cheap enough to lower your guard, and that is the moment you start acquiring the things you are least equipped to know are broken.

Where the answer really did flip to build

For anything whose lifetime cost is mostly the building, the answer really has shifted toward building, and correctly so. A one-off script to move some data. A small internal tool. A little utility you would previously have pulled in somebody else's library for, and then owned that library's updates and security patches for years afterward. Write those yourself now. The economics really did invert.

What actually governs the decision is not whether agents can do hard technical work:

The build-or-buy line moves in proportion to how much of a thing's total cost is building it rather than running it.

For a script, building is nearly all of it, so the line moved a lot. For something durable and always-on, holding many customers' data, where being subtly wrong is expensive, building is a small fraction of the total, so the line barely moved. A database sits about as far from that line as anything gets.

So will there ever be a time to build your own?

No, and I think the answer gets more firmly no rather than less.

The same wave that makes it cheaper for you to build a database also makes it cheaper for the people already running one to keep improving theirs. Both sides get cheaper together, so the relative gap holds. And the cost of your attention rises the whole time, because the list of more valuable things you could be doing keeps growing.

Renting a database stopped being about capability a while ago. It is that somebody else has already absorbed a decade of ways it can go wrong, which you would otherwise meet one at a time, in production, on a schedule you do not control. You are not buying the code. You are buying the scar tissue, and the fact that the pager belongs to someone else.

That is the entire argument for infrastructure, and it has not changed. What changed is that "I could build that myself" was never much of a reason to do it, and it used to be rare enough that this did not matter. Now it is true for almost everyone, so you need a better one.

It is also why we built Vectros the way we did, and why we did not replace any of that hardened machinery. It sits on top of proven storage and search components rather than instead of them, so the decade of accumulated scar tissue underneath stays somebody else's. What we took on is the part with no incumbent to rent: the isolation model, the audit trail, and the permissions that have to hold across all of those pieces at once. That work is non-functional almost end to end, which by the argument above is the part that stays expensive however good the tooling gets. It seemed worth doing once, carefully, rather than once per customer.

Try this on whatever you have running. Take any piece of it and ask: if this were broken right now, what would tell me, and how soon?

For most of it, the answer is fast and obvious. Where the answer is hard to find, no amount of AI capability substitutes for somebody who already knows what to look for. You can build almost anything now, but the things you should be hesitant to build are the ones that would take you a year to discover you got wrong.