Frameworks

Ideas I reach for often enough that they earned a name. Each one comes out of a specific failure I watched happen, and links back to the essay that works it out in full. Borrow them freely.

The Ownership Gap #

The distance between a tool existing and someone being accountable for it, which is settled by an org chart rather than by a roadmap and shows up in incident response long before it shows up in a budget.

Most build vs. buy analysis prices the license, the integration, and the engineering time. It rarely prices the answer to a simpler question: who is on call for this in eighteen months, and do they know it exists.

The gap is not an awareness problem and it is not a headcount problem. Both of those are downstream. The cause is that ownership was never written into anyone’s job description, so when the person who championed the tool moves on, nothing formally transfers. You can staff a team fully and still orphan a tool, because inheriting accountability was never a step in anyone’s process.

The failure is quiet, which is what makes it expensive. Technical failure is visible and gets triaged. Ownership failure just means the tool slowly becomes nobody’s job, and you discover it during an incident rather than during a review. The symptom to watch for is the utilization complaint: teams reporting they use a fraction of what a tool can do, and haven’t rolled out half the stack they already paid for. That is the gap, measured.

AI lowering the cost to build does not fix this. It raises the number of tools an organization can produce without raising its capacity to own them, which widens the gap rather than closing it.

Spec-to-Code vs. Spec-to-Context #

Two different gaps between a written spec and a shipped feature. AI is closing the first one, which is turning intent into working code. It cannot close the second, which is the undocumented architectural and organizational reality that determines what the intent actually costs.

The spec-to-code gap is mechanical. A PM describes a behavior, an engineer implements it, and the translation loses fidelity along the way. This is the gap that tooling has been chipping at for decades and that AI is now closing quickly.

The spec-to-context gap is different in kind, not degree. A spec cannot contain the storage layer that doesn’t exist yet, the 10MB endpoint limit set by an undocumented decision in 2019, the frontend team’s convention for error states, or the six week compliance review sitting in the critical path. None of that is missing because the spec was written badly. It is missing because it lives in systems and people rather than in documents, and a model reading your codebase reads the first without the second.

The practical consequence: a one paragraph feature request can come back as a month of engineering effort, and the spec will not have been wrong. It will have been incomplete in ways the author had no way to see.

This is why the closing gap makes the remaining one more important, not less. When producing the code stops being the constraint, the accuracy of what you asked for becomes the constraint.