a builder's codex
codex · operators · Ethan Mollick · ins_pin-workflows-to-capabilities-not-models

Pin workflows to capabilities you re-baseline quarterly, not to a model snapshot

By Ethan Mollick · Professor, Wharton; author of Co-Intelligence · 2026-04-23 · essay · Sign of the Future — GPT-5.5

Tier B · TL;DR
Pin workflows to capabilities you re-baseline quarterly, not to a model snapshot

Claim

Model progress is not tapering; every few months something previously impossible becomes easy, and the size of the leaps grows. The operating implication for any AI-native flywheel commitment: pin workflows to capability classes you can re-baseline each quarter, not to one model snapshot.

Mechanism

Workflows hardcoded to a specific model version inherit that model's failure modes and miss the gains of the next release. Capability-pinned workflows (e.g. "long-context summarization at quality X") survive model swaps and benefit from each upgrade.

Conditions

Holds when: the team has a quarterly cadence to re-evaluate model choice per workflow.

Fails when: a workflow depends on a model-specific quirk that capability framing doesn't capture (rare).

Evidence

"Every few months a new model arrives... something that was impossible becomes easy, while the size of the leaps grows each new release cycle."

— Ethan Mollick, One Useful Thing, 2026-04-23

Signals

Counter-evidence

For regulated or audited workflows, model-pinning is required for reproducibility — capability framing can't override compliance.

Cross-references

Open the interactive view → View original source → Markdown source →