LLenny's Podcast
← All frameworks
InnovationLogan Kilpatrick (head of developer relations)

The Better Tool, Same Problems Lens

Every model leap gets normalised within months — build for the boring future, not the euphoric one.

Difficulty
Moderate
Time to result
~months to results
Steps
4
Confidence
90%

Kilpatrick's framing for how to plan around future model releases like GPT-5. Each leap triggers a consensus that everything is different, then reality reasserts: it is a more effective tool for the same problems that already existed. His counterintuitive claim is that planning for rapid normalisation — assuming users will take the new capability for granted almost immediately — is itself a competitive edge, and that assuming the model changes everything is the wrong mental frame.

Origin

Logan Kilpatrick on Lenny's Podcast (Feb 2024), answering Lenny's question about the advice to 'build for a GPT-5 future rather than GPT-4's limitations'. He grounds it in the GPT-4 technical report, which showed OpenAI could reliably predict a model's capability from compute before training it.

Core principles

  • 01Capability advances are increasingly predictable from compute — you can plan around them rather than be surprised.
  • 02The world declares each release changes everything, then returns to reality within months.
  • 03The problems in the world stay the same; only the tool gets better.
  • 04Normalisation is fast. Plan for users treating the new capability as ordinary almost immediately.
  • 05Vertical, specific use cases capture the gains first — the general leap makes specific solutions better, not obsolete.

How to run it

  1. 1

    Anchor on the problem, not the model

    List the durable problems your users have. A model upgrade changes how well you can solve them, not which ones exist. Build the product around the problem so a model leap is an upgrade, not a rewrite.

    Pro tip Kilpatrick's test: the fundamentally same problems will still be the same problems — you just have a better tool.

  2. 2

    Reject the magical-capability assumption

    Do not architect around a hoped-for capability that borders on science fiction. Kilpatrick mocks the expectation that GPT-5 will do backflips in your bedroom while writing all your code and calling your mother.

    Pro tip Assume 'meaningfully better, faster, cheaper' — not 'categorically magical'.

    Watch out Betting the product on an unshipped magical capability is how teams strand themselves.

  3. 3

    Plan for instant normalisation as an edge

    Ask what your product must be if users treat the new capability as completely ordinary within weeks. Design the experience so it still delivers value once the novelty of the model is gone.

    Pro tip This is the explicit edge Kilpatrick names: most competitors are planning for the euphoria phase, which evaporates.

    Watch out The wrong mental framing — 'this changes everything' — is described as an actual downside, not just harmless optimism.

  4. 4

    Route the new capability into a specific use case

    Point the upgraded model at a narrow, well-defined problem where you have domain knowledge. Kilpatrick's view is that people solving very specific use cases are the ones who get to do that much more effectively with each leap.

    Pro tip Package the capability so the user sees one problem solved well, rather than a blank slate they don't know what to do with.

In the wild

The GPT-4 hype cycle

When GPT-4 launched, the consensus was that everything was different — this changes the world, this changes everything. Then, slowly but surely, the world came back to reality: it is a really effective tool that helps solve problems more effectively.

Kilpatrick presents this arc as undoubtedly the lens through which to view all subsequent model advancements, GPT-5 included.

Predictable scaling in the GPT-4 technical report

GPT-4 was the first model where OpenAI could reliably predict the capabilities in advance from the amount of compute going in, and published the scientific study comparing prediction to actual outcome.

Capability becomes a forecastable input to product planning rather than a surprise you react to.

The blank-slate onboarding problem

People who aren't close to AI show up at ChatGPT, see a blank slate that can do anything, and cannot tell how it solves their specific problem. GPTs package one narrow problem so a user experiences a concrete solve, which then motivates them to investigate five other problems.

Narrow vertical packaging is the mechanism Kilpatrick expects to bring the next few hundred million people into AI.

Common mistakes

Assuming the next model changes everything

Kilpatrick calls this the wrong mental framing and an actual downside — it leads teams to defer real product work while waiting for a magical release.

Building for the limitations of today's model

The mirror error: architecting around current constraints that will predictably dissolve, leaving your product built around scaffolding nobody needs.

Shipping a horizontal blank slate

A product that can do anything leaves the user unable to see how it solves their specific problem. Narrow packaging outperforms unbounded capability for adoption.

Is it for you?

Best for

Founders and PMs building AI products who must decide what to architect now versus what to wait for from the next model generation

Not ideal for

Frontier research teams whose entire job is to create the capability discontinuity rather than to build on top of it

From the transcript

but like fundamentally the same problems that exist in the world are still going to be the same problems you now just have a better…

49:30

if you can plan for the world where people become very very used to these tools very quickly actually think that's like an edge

50:00

it's like the wrong mental framing to have of these tools as they come out

50:30

gbt 4 was the first Model that we trained where we could reliably

48:00

From the episode

Inside OpenAI

Logan Kilpatrick (head of developer relations)