Mile-hi · Field Notes on AI Effectiveness
From efficiency
to effectiveness.
What if, instead of measuring how fast or cheap AI runs, we measured how much it helps people, teams, and organizations evolve? Perhaps effectiveness — not efficiency — is the lens we've been missing.
The Framework
Read the thesis →Sixteen cells. Four tiers of effectiveness × four technical lenses. Each cell holds essays in its quadrant.
The Series
All essays →Each series is a book — multi-part essays designed to be read together. Pull one off the shelf.
Latest Thinking
View all →The Bug Is in the Design, Not the Code
Amazon found a bug in DynamoDB that had survived design review, code review, and testing — a thirty-five-step sequence no test would ever generate. The catastrophic failures live in the design, where AI writes code but not judgment, and where a unit test cannot reach.
The Right to Merge
An AI agent opens a pull request. Every test is green. Do you let it merge? Tests sample inputs; for the slice of code where a silent bug is catastrophic, the gate should be a proof — against a property a human still has to write. The scarce skill is no longer the code. It is deciding what "correct" means.
AI Built Layer 1. The Seam Still Needed a Human Adversary.
AI collapsed the cost of building the pieces of a data pipeline that ingested nearly half a billion rows. It did not collapse the cost of integrating them honestly. The data-loss bugs lived in the seam between the pieces — where no review of any single piece could see them.
When You're More Correct Than the Source of Truth
We set out to reproduce the numbers a reference dataset published, and found the reference was wrong. The hard part of the Information layer is rarely access. It is the judgment to know when you are more correct than the thing you are validating against — and a gate that can tell a fix from a regression.