Expansion, Not Speedup

The question everyone asks about AI coding is the wrong one. “How much faster does it make you?” is a speedup question — it assumes the work stays the same and you measure time saved. Karpathy’s more interesting observation is that the real effect isn’t speedup at all. It’s expansion.

Expansion means doing work that was never on the table before. Not the same tasks in less time, but different tasks entirely — ones that were previously too expensive, too peripheral, or just beyond reach.

I built an FAQ chatbot for internal use at a bank. Not a simple wrapper — it needed to handle a genuinely convoluted policy document, reason across cross-references, and hold up under adversarial testing. A few years ago that would have been a multi-person project with a proper engineering allocation. I did it as a side proof-of-concept, alone, over a few evenings. The chatbot exists not because it became faster to build software, but because the threshold for “worth building” dropped low enough that it cleared.

That’s expansion. The marginal project that wouldn’t survive a resourcing conversation now gets built because the economics changed.

There’s a second form of expansion Karpathy points to: approaching code in domains you don’t fully own. A data scientist venturing into unfamiliar infrastructure, a product manager who can now implement a prototype directly rather than writing a spec. The LLM becomes a translation layer between your intent and the implementation, lowering the knowledge barrier enough to make entry worthwhile. You’re not faster at what you already know. You’re now capable in areas you weren’t before.

For financial services, this has specific implications. The compliance analyst who can now explore data directly. The risk manager who can prototype a model validation before handing off to engineering. The audit team that can run a quick analysis without opening a ticket. None of this is faster — it’s newly possible. And newly possible things don’t show up in time-saved calculations.

The productivity conversation in most organisations is still framed as efficiency: same outputs, lower cost. That framing misses most of the value. The harder question to ask — and to answer — is what would we now build that we wouldn’t have touched before? That’s where the real number lives. And it’s a harder number to measure, because the counterfactual — the project that never got proposed, the analysis that never got run — is invisible by definition.