Faster Horses
Most AI programs make you efficient at what you already do. Capability is the game with no ceiling, and it’s played somewhere your dashboard can’t see.
A few weeks ago I sat with a team responsible for maintaining and modernizing a core monolith, the kind of system a fintech business actually runs on. They had a mandate from above: make a meaningful impact on product delivery with modern agentic workflows.
So they built agentic skills. Good ones. Skills that automate creating features on the existing stack: scaffolding, wiring, testing, the whole delivery pipeline for the monolith as it stands today. And it worked. Features that took days now take hours. They were, understandably, proud of it.
That was the problem
They had spent their AI budget making horses faster in the age of electric cars. Every automated feature was a feature built the old way, on the old architecture, deepening the organization’s commitment to the thing that needs to change. The agents weren’t modernizing anything. They were pouring concrete around the legacy.
My proposal in that room: keep the feature-automation skills, but invest in a parallel track of agentic skills that expose the monolith’s functionality as APIs. Not because APIs are fashionable, but because APIs are what future agents, yours and your partners’, will build on. One track harvests the current stack. The other makes the stack harvestable.
I keep seeing this pattern, so it needs a name. Faster horses: using AI to accelerate what you already do, on the structure you already have, and calling it transformation.
Efficiency has a ceiling. Capability doesn’t.
The instinct behind faster horses is understandable, because it’s the instinct we’ve all been sold: use AI to be more efficient. But efficiency means doing what you already do, quicker. There’s a ceiling on that, and it’s low. You can only compress your current work so far, and everyone else is compressing theirs too. Efficiency gains are table stakes with a shelf life.
Capability is the other game. Not “how fast can I do my job” but “what can I do now that I couldn’t do before.” That has no ceiling, and it compounds.
Helen Edwards and the team at the Artificiality Institute have spent years researching what makes human work irreducible in the age of AI, asking not “will AI take our jobs” but “what is AI doing to us.” One of their findings deserves more attention than it gets: some of the most defensible human capability is physically situated. It lives in bodies, rooms, warehouses, and incident bridges. It never made it into any dataset, which means no model was ever trained on it.
The takeaway: if it was never digitized, AI can’t replace it. But AI can now help you act on it.
Intuition doesn’t compress into a dashboard
The canonical evidence is thirty years old and still underused. Gary Klein’s research on fireground commanders, 26 veterans with an average of 23 years of experience, probed across 156 real decisions and found that in fewer than 12% of decision points did commanders compare options at all. They recognized situations through accumulated exposure to patterns and acted. The famous case: a lieutenant pulls his crew out of a burning building seconds before the floor collapses. He couldn’t articulate why. Nothing in any data feed told him. Years of being there did.
Klein called it recognition-primed decision-making. I call it the asset your AI program is ignoring.
Here’s the loop that turns it into capability, in three moves.
Situate. Go where your data is born. If you run supply chains from a dashboard, spend a day in the warehouse and stay until you find the thing the dashboard doesn’t know: the workaround everyone uses, the rule nobody wrote down.
Prototype. This is where AI changes the equation. Describe the problem to a frontier model and build a rough tool the same week. It doesn’t have to be good; it has to be real enough that the people on the floor can tell you everything wrong with it. That feedback loop, where they poke holes and you fix and repeat, used to require a funded project and a quarter. Now it requires an afternoon and a coding agent.
Own. Take the validated fix up the chain. Not softened into options. “Here’s what I found, here’s what we should do, here’s why,” with your name on it. Being there becomes owning the decision.
The takeaway: AI can’t give you intuition. It can collapse the time between having it and acting on it, from a quarter to a day.
Three places the loop pays off in software delivery
I promised concrete examples. Here are three patterns with one vivid case each. You’ll recognize where the same shape appears in your own delivery organization.
Dashboard blindness. Your observability stack tells you what it was configured to measure. An engineering leader I know sat in on a week of on-call shifts, not reading postmortems but sitting in the incident channel live, and discovered that half the “15-minute resolutions” were actually one senior engineer’s private runbook of undocumented tribal knowledge. The metric looked healthy; the bus factor was one. The prototype: an agent that drafted runbook entries from incident transcripts, put in front of the on-call rotation for demolition and iteration. The same shape shows up in CI/CD metrics that hide flaky-test roulette, and in DORA numbers that look great because risky changes are quietly batched.
Undocumented workarounds. Every delivery process has a shadow version that actually ships the software. Watch a release manager for one afternoon, and you’ll find the spreadsheet, the Slack DM chain, the “we always ping Marta first” step that exists in no process doc. These workarounds are compressed knowledge about where the official process fails. Prototype the workaround into a tool, together with the people who invented it, and you’ve digitized capability instead of paving over it. Support escalation paths and security exception handling hide the same gold.
Decision distance. Product managers who haven’t watched a real user session in a quarter are running on secondhand reality. One PM I worked with spent two days in actual customer onboarding calls and caught a misunderstanding that no analytics funnel could express: users weren’t dropping off, they were succeeding at the wrong task. A prototype fix was in front of those same customers within the week. The roadmap debate that had run for a month ended in one demo.
The takeaway: the highest-leverage AI prototypes come from insights that were never in your data, which means someone has to go get them in person.
The executive version: parallel tracks or you’re decorating the legacy
For leaders whose IT capability is the business, in banking, logistics, retail, or healthcare operations, the fintech story from the top is the whole lesson in miniature.
Most enterprise “AI transformation” programs are efficiency programs wearing capability costumes. They automate existing workflows on existing systems and report the hours saved. The numbers are real. They are also faster horses: every automated workflow deepens the organization’s dependence on the architecture underneath it, and the architecture is precisely what limits what you can become.
The move that separates capability from decoration is running two tracks in parallel.
The first track is agentic automation of current workflows on the current stack. This funds itself and buys credibility. Do it, measure it, but don’t confuse it with transformation.
The second track is agentic work that exposes core functionality as APIs and well-described services. This is what lets future agents, your own, your partners’, your customers’, compose new things on top of your systems. In an agentic economy, the organizations that matter are the ones whose capabilities are addressable. A monolith with no API surface is invisible to that economy, no matter how fast its features ship.
And apply the situatedness test to your own program: if your AI strategy was written entirely from vendor decks and dashboards, it inherited their blind spots. The five most valuable days an executive sponsor can spend on an AI program are in the warehouse, the branch, the ops floor, finding what the systems don’t know before deciding what the agents should do.
The takeaway: the first track makes the horses faster. The second builds the road for electric cars. Fund both, and never report the first as the second.
The model math, July 2026, and why you’ll redo it in October
Concreteness cuts both ways: these numbers will age, and that aging is the final lesson.
As of this writing, the frontier tier for serious agentic coding, the prototype step of the loop, is led by models like Claude Opus 4.8 (around $5 input / $25 output per million tokens, 88.6% on SWE-bench Verified) and GPT-5.5 ($5/$30, 88.7%), with Gemini 3.1 Pro ($2/$12) as the value play in the frontier tier. This is where you want to be when the problem is messy: multi-file refactors, reasoning over half-structured field notes from your warehouse day, turning a fuzzy observation into a working prototype. Frontier models are expensive per token and cheap per discovery.
The open-weight tier has quietly crossed a threshold. Several open-weight and open-adjacent models now clear 80% on SWE-bench Verified at $0.60 to $2.40 per million output tokens, and DeepSeek’s V4 family sits as low as $0.14/$0.28. On an identical coding-agent workload, the spread between a frontier model and a budget open-weight one can reach roughly 48x. And if you sustain more than about 500K tokens per day, self-hosting open weights starts beating hosted APIs on cost, with the sovereignty and data-residency benefits that regulated industries care about anyway.
The smart pattern is not “pick the cheap one” or “pick the best one.” It’s this:
Frontier to discover, open-weight to operationalize. Use frontier models where ambiguity is high, and the task is novel: the prototyping loop, the gnarly refactor, the first version of anything. Once the insight is validated and the task becomes routine (classification, extraction, the internal tool that now runs every day), route it to an open-weight model at a fraction of the cost. Add caching (frontier providers bill cached reads at roughly 10% of input rates, and DeepSeek’s cache hits are near-free) and a simple router that escalates only the hard cases, and teams routinely cut inference bills by 60 to 80% without a quality cliff.
Then put a recurring event in your calendar: re-price per task, per model, every quarter. Not per month of spend. Per task. The unit that matters is “what does one validated prototype cost” and “what does one day of the routine workload cost.” Both numbers have moved by multiples in the last twelve months and will move again. A model choice made in January and never revisited is, by July, just another faster horse.
Prices and benchmarks checked July 2026 against published provider pricing and SWE-bench Verified leaderboards.
The takeaway: the specific numbers expire; the method doesn’t. Frontier to discover, open-weight to operationalize, re-price quarterly.
What survives
Twenty-plus years in this industry has taught me that tools change faster than judgment. The builders who survive each wave aren’t the ones who adopted the tools fastest. They’re the ones whose judgment about what to build was grounded in something the tools couldn’t see.
That’s what the capability loop protects. Intuition from being there. Prototypes fast enough to test it. Ownership loud enough to matter. AI doesn’t replace any of the three. It removes the excuse for skipping the middle one.
So, a challenge for this week: spend half a day where your dashboard’s data is born. The warehouse, the incident channel, the customer call. Come back with one thing the dashboard didn’t know. Then build the ugliest possible prototype and put it in front of the people who told you.
Don’t breed a faster horse. Go find out what the road actually needs.
With thanks to Helen Edwards and the Artificiality Institute, whose research on irreducible work and physical situatedness sparked this piece, and whose question “what is AI doing to us?” is the right one to keep asking.