The AI-Native Way
The Bitter Lesson, restated for builders. Rules and logic you write in code don't matter long-term. The only durable strategy is a systems-level data pipeline. That loop is the moat.
The 10x Mandate
Often, you don't realize how bad something is until a truly good alternative appears. Suddenly the old way looks intolerable. However, human nature resists change. Due to switching costs, loss aversion, and status quo bias, getting people to move is incredibly difficult. It takes a new thing at least 10 times better. When a solution is 10x better, it's surprising how fast demand can shift, like water turning to ice.
The ingredients to create such a solution often already exist. The innovation lies in unbundling a currently unscalable system and optimizing it to hit a specific price point with healthy margins. As Jim Barksdale said,
There are only two ways I know of to make money: bundling and unbundling.
The Architectural Playbook
Critical Path Analysis shows us the path to unbundling. The goal is to use Dependency Inversion to parallelize formerly serial steps. High-level and low-level modules depend on abstractions (APIs), not on each other. This approach, however, runs into a fundamental limit: some computations appear to be inherently sequential. Certain problems are P-complete. They are the hardest in P to parallelize. Unless NC = P (widely believed false, but unproven), they lie outside NC, the class of work that massive parallelism can actually speed up. In practice their steps must run one after another no matter how many workers you add.
The trick is to identify the few, true, minimal, and independent causal chains and parallelize everything else. Amdahl's Law then helps quantify the potential speedup from these improvements and reduce waste.
The Brittleness Trap
This structural optimization creates a problem: a brittle system. Foundational constraints always change, thanks to forces like Moore's Law. When they do, the entire system can be disrupted. This puts you on a treadmill, constantly re-architecting just to keep up.
The AI-Native Solution
The "Bitter Lesson" of AI shows the way out of this trap. Don't waste time building things that will be replaced. The rules and logic you write in code don't matter in the long run. Platforms, tools, and logic are all ephemeral.
The only durable strategy is to build systems-level data pipelines. This creates a system that learns and adapts instead of breaking through a continuous loop:
- Find the edge cases where the system fails in production.
- Save these failures as high-value training data.
- Finetune new models that learn from this data.
- Test the new models against edge cases and then in the real world to verify they're better than the current ones.
- Release when ready, and repeat the loop. The loop earns its keep by never asking: it does not wait for a human to notice the error, approve the fix, or bless the retrain. Correction is a standing process, not a request.
Crucially, this requires building for scale from the start. It also requires always designing for verifiability by instrumenting the end-user experience and capturing exceptions. This is what makes the learning loop robust.
The AI-native solution not only creates something truly useful but also comes with a durable moat.
Intellectual lineage
- Richard Sutton — The Bitter Lesson — general methods that scale with computation beat hand-coded domain knowledge.
- Sutton & Barto — Reinforcement Learning: An Introduction — the reward hypothesis: goals as the maximization of expected reward.
- Kahneman & Tversky — loss aversion — switching costs, loss aversion, and status quo bias: why the new thing has to be 10× better.
- Robert C. Martin — the Dependency Inversion Principle — modules depend on abstractions, not on each other. The seam that lets serial steps parallelize.
- P-completeness — some computations are inherently sequential, outside NC unless NC = P.
- Gene Amdahl — Amdahl's Law — the serial fraction caps the speedup no matter how many workers you add.
The ledger IS the loop
Trinity Local is what this essay looks like when you build it.
Every council emits structured Routing JSON — agreed claims,
disagreed claims with why_matters, winner,
provider_scores. The chairman's pick (lens-governed) IS the
supervision signal — no separate rating step. The five-step
loop becomes: chairman synthesizes through your lens →
routing_label.winner persists to ~/.trinity/council_outcomes/
→ compute_personal_routing_table() aggregates
per task_type → next council picks the right chairman →
repeat.
The three labs are commercially prevented from helping you use a competitor. So the cross-model preference signal — the edge-case data — only Trinity gets to see. That's the moat, and it's exactly the shape this essay described.
Part of an ongoing series on durable systems.