I run a forked and customised markdown editor. Three years ago that sentence would have been a confession. Forking a tool means owning it: every upstream change, every bug nobody else will fix, every hour that goes into it instead of into work that matters. The advice was always the same and it was good advice. Buy it, or use what you are given, and spend your scarce engineering on the thing only you can build.
That calculation has moved. The principle is the same. The arithmetic underneath it is not what it was.
The cost side moved and is still moving
Build against buy was never a philosophical question. It was a sum. What does it cost to make, what does it cost to keep, what else could those people have been doing. The answer came out in favour of buying most of the time because the build number was large and the maintain number was larger and never stopped.
AI-assisted coding has taken a chunk out of both, and the chunk gets bigger with each model. I am not going to put a multiplier on it, because anyone who does is guessing and the number would be stale by the time you read this. What I will say is that the editor I use every day is a fork with about a hundred commits of my own on top, and I would not have started it two years ago. It would have been obviously the wrong use of my evenings. Now it is a weekend and some maintenance, and the thing does exactly what I want.
Multiply that across a department and the interesting consequence is not that you build more. It is that a whole category of small, specific, unglamorous tools become worth having, where before they sat on a wish list until someone left and the wish list was archived.
The part that did not move
Nobody has reduced the cost of being wrong.
Code an agent wrote, that nobody on the team typed, is still code your name is on. The reviewer may never have written a line of it. The person who asked for it may not read the diff. It still ships, it still runs, and when it fails it fails in your service with your customers in it.
That is a genuinely different failure mode from the one our practices were built for, and the guards have to differ in kind. Applying the existing ones harder achieves very little. Tests that assert behaviour rather than shape, because an agent will happily satisfy a shape. Boundaries that are enforced by the build rather than by review, because review is where attention runs out. A reviewer who is accountable for the outcome rather than for having looked.
Sizing the guard
A friend of mine calls the thing you should actually be measuring the blast radius. How far does the damage travel when this goes wrong.
Take the editor. If a bug gets past the tests, I lose a paragraph and swear at my own commit. One user, one afternoon, no data that matters, and the person who caused it is the person who suffers it. The blast radius is one desk. I can be relaxed about how it was built because the worst case is embarrassment, and I hold both ends of it.
Now take the same method and the same confidence and put them on a core banking ledger serving hundreds of thousands of customers. The mechanism is identical. An agent writes, a guard is thin, something slips through. The consequence is not a lost paragraph. It is money that moved and should not have, or money that did not move and should have, on a day somebody needed it. It is a reconciliation that takes a week and a regulator who wants to know how the change was approved and what the approver understood.
Same method, same technology, same team even. The variable that changed is how far the damage travels, and that is the variable the guard should be sized against.
This sounds obvious written down and it is not how most organisations behave. They set one standard of rigour for the department and apply it evenly, which means the internal tool is over-governed and the thing that moves money is under-governed, because the standard was set by averaging.
What a person in the loop has to mean
The conclusion people reach from this is that high blast radius work needs a human sign-off. So they build an approval step. Then the approval step becomes a button somebody presses, because the queue is long and it has never been wrong before.
That is abdication with a form attached. If the person approving cannot say what the change does, what they expect to break, and how they would know within the hour, they are not in the loop. They are in the audit trail.
Being in the loop, at the sharp end, means at least three things. Someone who can explain the change in their own words, which is a higher bar than having read it. A way to tell quickly that it has gone wrong, which is telemetry designed with the change rather than added after. And the ability to reverse it without a committee, because the value of a rollback falls to nothing the moment it needs a meeting.
There is a fourth, and it happens earlier than people expect. The person accountable for the outcome should sign off the plan, before the agent starts, and should be able to read it and say in their own words what it is going to do.
That one move changes the review question. It goes from “what did the agent do”, which is unanswerable once the diff is four thousand lines nobody typed, to “did it follow the plan”, which a person can still hold in their head. A reviewer who agreed the plan is reading for divergence. A reviewer who did not is reading four thousand lines cold and will approve them.
Underneath that sit the layers you would expect. Ordinary good practice, and the agentic patterns emerging on top of it, the committee pattern among them, where several agents check each other’s work before anything lands. Use all of it. It raises the floor and it catches things a person would not. It does not change where the people go, which is at the start and at the end of the loop.
None of that is about trusting the agent less. I trust mine with a great deal. It is about the organisation keeping hold of the part it cannot delegate, which is the answer to the question of who is responsible, and having that answer be a person rather than a process.
The version you can use
Here is the whole thing as something you can run on a real backlog. It takes about ten minutes per item and it is worth doing out loud, with the people who will build the thing in the room.
Four questions place the work. Not one of them is about the technology.
- If this is wrong, who finds out first, and who is harmed?
- How long before we know? Minutes, days, or when somebody complains?
- How long to put it back? And has anyone done that, or do we assume it works?
- Is any of the damage permanent? Money that moved, data deleted, a message sent, a regulator informed.
Question four is the one that reorders the list, because everything else can be recovered from and that cannot.
Then match the guards to the answers.
| Blast radius | What it looks like | Guards that are enough |
|---|---|---|
| One desk | A tool one person uses. Mine is an editor. | Tests you would have written anyway. Ship it. Review is optional and usually theatre at this size. |
| One team | Internal tooling, a script others depend on. | Somebody other than the author can run it and fix it. Rollback is a git revert. Written down where it lives. |
| Your customers | Anything they touch or that touches their data. | Tests that assert behaviour rather than shape. Boundaries enforced by the build, not by review. Telemetry designed with the change so you know inside an hour. One named person who signed off the plan and is accountable for the outcome. |
| Irreversible | Money moves. Data is deleted. Something leaves the building. | Everything above, plus: no single party can make the change alone, the reversal has been rehearsed rather than assumed, and the approver can explain the change in their own words before they approve it. |
Three tests to keep it honest, because a scheme like this decays into a form within about two quarters.
- If your approval step has never rejected anything, it is not a control. It is a queue. Either find out what it is for or take it out, because its presence is doing harm by making people feel covered.
- If nobody has performed the rollback, you do not have one. You have a paragraph about a rollback. Rehearse it on the highest band at least once a quarter.
- If the same standard applies to every piece of work, you have set it by averaging, and the cheap thing is being over-governed to pay for the expensive thing being under-governed.
Where to start if you do nothing else. Take your last ten changes, place each one in a band, and look at what you actually did to each. The spread is usually wrong in both directions at once, and seeing that on one page tends to settle an argument that months of talking about process will not.
Where this leaves the decision
Build against buy is worth reopening. Things that were obviously not worth making are now worth making, and a department that has not looked at that list recently is leaving something on the table.
But the answer to “should we build this ourselves now” is incomplete without “and what happens when it is wrong”. Those two questions have to be asked in the same conversation, by the same people, at the same time. Separated, the first one is exciting and the second one arrives eighteen months later as an incident review.
The editor was worth building because the blast radius is my own afternoon. That is the whole argument for it, and it does not transfer to anything with customers in it without the guards being rebuilt for the distance the damage can travel.
