Why I slow down external contracts when implementation gets faster
Building on a bad interface used to be slow enough that the awkwardness arrived while the decision was still fresh. That signal is gone, and nothing replaced it.
Generating an implementation got cheap. Reversing an interface that other businesses have already built against did not, and most of my caution now goes into the distance between those two facts.
The work I do sits behind contracts other companies consume. When one of them changes badly, their customers notice before ours do, and the cost lands later, on whoever is maintaining it by then.
The friction used to be the warning
Get a data model wrong, or the shape of an endpoint, or how specific an error is about what went wrong, or where the line falls between identity and permissions, and you used to find out fairly quickly. Building on top of a bad decision was slow, so the awkwardness surfaced while the decision was still fresh and cheap to revisit. I have seen versions of this several times: somebody hits the ugly part early and says so.
That signal is gone. You can now produce a great deal of correct-looking code over a bad foundation before anyone has reason to examine the foundation, and each new line makes it harder to change. By the time a design is visibly wrong it is load-bearing, and the question has quietly changed from whether it is right to what it would cost to move.
The code is usually fine, which is what makes this hard to see. What disappeared is the friction that had been doing the work of a warning, and nothing took its place. Speed does not surface the mistake. It buries it under software that works.
So the contract gets the old pace
The rule I ended up with: implementation can go as fast as it likes; anything a third party will hold onto moves at the speed it moved before.
Concretely, that means arguing the shape of an interface while there is still nothing built on it, and not generating the client until the shape has survived the argument — because the moment a client exists it becomes evidence for the interface, regardless of whether the interface deserved it. It also means writing down what a change would cost the consumer rather than what it costs us, since ours is the smaller number and the one we reach for by reflex. And an absence of complaints is no information: a partner who has built a translation layer over us has worked around the problem instead of reporting it.
The surfaces that get this treatment are few — data models, endpoint shapes, error semantics, identity, permissions, anything with a version number a partner pins. Everything else can be fast, and most things are everything else.
None of this is a general claim about building with AI. It is one property of one kind of business, the kind where somebody else’s product depends on a decision you made once, and the property is that the cost surfaces late. Cheap implementation made the late part later.
What I am least sure of is how long it holds. If models get reliably good at keeping a whole system’s constraints in view, some of that friction comes back without anyone arranging it, and the discipline I am describing turns into overhead.