The Thrill Question: Type-2 Fun, Flow, and Why We Hike at All

A strategic look at what AI-assisted development does to the motivational engines of engineering organizations — and why the last 10% of the climb is now a leadership problem. (~11 min read)

---

Consider a four-mile hike. The first three and a half miles are pleasant — moderate grade, steady elevation, conversation possible. The final half-mile is the one with the scramble, the exposure, the burning legs. Now imagine a hiker airlifted to the 90% mark and asked to finish. Same summit. Same view. Same photo for the group chat.

But does the hiker get the thrill? And — the question that matters more — does the hike give them the gains?

The software industry has quietly built the helicopter. AI coding assistants now generate a substantial share of new production code at large organizations, and "generate a lot, tweak a little" has gone from experiment to default workflow in roughly two years. Andrej Karpathy gave the extreme version a name — vibe coding — describing a style of programming where the human barely reads the diff. Executive attention, predictably, has locked onto throughput: cycle time, PR velocity, features shipped per quarter.

Almost no one in the boardroom is asking the thrill question. That is a strategic error, because the thrill is not a perk. It is the engine.

Type-2 Fun and the Retroactive Paycheck

Outdoor culture has a useful taxonomy. Type-1 fun is enjoyable while it happens. Type-2 fun is miserable in the moment and glorious in retrospect — the glory is caused by the misery. Type-3 is simply suffering, no redeeming narrative. Michael Easter's The Comfort Crisis popularized the underlying psychology: humans are wired to derive deep, durable satisfaction from voluntary hardship, and that satisfaction is retroactive. It is paid out after the struggle, in proportion to it. Teleport to the summit and the view becomes scenery rather than triumph.

Engineering runs on Type-2 fun. The actual reward system of the profession is not the shipped artifact — it is the war story. The production incident that took four engineers and one wrong assumption about DNS. The migration nobody believed would land. The bug that survived three senior reviewers and one load test. These stories get told at retros, at conferences, in interviews, in onboarding. They are how engineers construct identity, status, and meaning at work. Matthew Crawford's Shop Class as Soulcraft traced the same dynamic in the trades: satisfaction comes from grappling with a world that pushes back.

An AI that pre-solves the hard parts does not merely save time. It deletes the deposit from which the satisfaction gets withdrawn.

Flow Is the Production Function

There is a harder-nosed version of this argument. Mihaly Csikszentmihalyi's decades of research on flow — the state of full absorption produced when challenge matches skill — remains the best available model of where elite engineering output actually comes from. Organizations do not employ senior engineers for keystrokes; they employ them for hours of deep, engaged, expert cognition. Flow is both the indicator that this asset is being well used and the mechanism that makes the work feel worth doing.

AI adoption perturbs the flow channel in two opposite directions, and both are costly:

• Boreout. When the challenging 90% collapses into approving diffs and tweaking prompts, challenge falls below skill. The work becomes supervision of a machine that is mostly right — cognitively closer to airport security than to mountaineering.
• Anxiety. When engineers are airdropped into the brutal final 10% — the integration failure, the Heisenbug, the migration gone sideways — without the scaffolding that walking the first 90% would have built, challenge exceeds skill. This is the airdropped hiker: same summit, no legs.

And here is the uncomfortable empirical wrinkle: the feeling of momentum is not momentum. In METR's 2025 randomized controlled trial, experienced open-source developers using AI tools estimated they were about 20% faster. Measured, they were 19% slower. Perceived velocity and actual value had decoupled. Leaders optimizing for how the tooling feels in a demo are optimizing for the wrong variable.

The IKEA Effect and the Rental-Car Problem

Behavioral economics adds a third mechanism. In the IKEA effect studies (Norton, Mochon, & Ariely, 2012), people who built their own furniture — or folded their own lopsided origami — valued their creations dramatically more than non-builders valued identical objects. Labor creates attachment, irrationally and reliably.

Code is no exception. Software that an engineer sweated over gets defended in review, maintained with care, and fought for during the 3 a.m. incident. Software that arrived fully formed from a model is a rental car — and nobody washes a rental car. Early code-quality telemetry is consistent with this: GitClear's analysis of post-Copilot codebases found rising churn and copy-pasted blocks, patterns associated with weaker ownership. The business translation is direct: review diligence, maintenance quality, and incident accountability all ride on perceived authorship. Erode authorship and the hidden maintenance tax compounds quietly for years.

Effort Is a Signal — and AI Is Inflating It

Open source is the canary. Maintainers of major projects are increasingly vocal about a flood of AI-generated pull requests where the cost of generation is near zero and the cost of review is unchanged. The asymmetry breaks a signaling system the whole industry depends on. Effort has always been proof of commitment: a well-researched PR says "this author respects reviewer time." When effort costs nothing, it stops meaning anything. Trust — the real coordination technology of engineering — suffers inflation.

The same dynamic enters internal teams. When "ready for review" no longer implies "the author understands this," review becomes adversarial archaeology instead of collaborative improvement. Addy Osmani's widely circulated essay on the "70% problem" describes exactly this gap: AI gets a project most of the way there quickly, and then the human pays full price for the hardest part with none of the context.

The Strategic Error: Treating Struggle as Toil

The reflexive executive response — "automate everything tedious" — contains a category mistake. Google SRE's classic definition of toil is precise: work that is manual, repetitive, automatable, and produces no enduring value. Toil should be eliminated aggressively, and AI is genuinely excellent at eliminating it.

But there is a second category that looks identical on a throughput dashboard: struggle — difficulty that compounds into mastery, judgment, and meaning. Debugging a subtle race condition is struggle. Rewriting the same boilerplate for the fortieth time is toil. From a metrics console, both are "hours spent on a task." From a talent-strategy perspective, one is an asset and the other is waste. The defining leadership decision of the AI era is not which model to buy. It is which difficulty to keep.

Why This Shows Up on the P&L

Motivation is infrastructure: slow to build, fast to destroy, expensive to rebuild. Three mechanisms connect the thrill question to business outcomes:

• Adverse-selection attrition. The engineers most motivated by craft are the ones with the most external options. A motivation-destroying AI rollout does not reduce headcount uniformly — it selectively loses the top of the distribution, at replacement costs routinely estimated at 1.5–2x salary plus irreplaceable context.
• Employer brand. Elite engineers choose employers partly on craft quality. "A place where engineers approve diffs all day" is not a recruiting pitch.
• Innovation capacity. Step-change ideas come from deep engagement with a problem space, not from supervising generated outputs. An organization of bored approvers ships more and invents less.

What Leaders Should Do

1. Audit the difficulty portfolio before automating it. Classify recurring engineering work into toil versus struggle. Automate the former aggressively; protect the latter deliberately.
2. Institute mandatory manual mode. Aviation solved the automation paradox by requiring pilots to hand-fly landings to keep skills alive. The engineering equivalents: AI-free deep-work rotations, incident ownership, periodic from-scratch builds.
3. Measure engagement with the same rigor as throughput. Pair DORA metrics with the SPACE framework and developer-experience surveys. If velocity rises while satisfaction and flow time fall, that is a leading indicator, not a win.
4. Set an effort floor for review. Require authors to defend every line of generated code. If the author cannot explain it, it is not ready — regardless of whether the tests pass.
5. Rewrite the reward narrative. Celebrate the climb, not just the summit: debugging heroics, judgment calls, and prevented disasters deserve the same visibility as shipped features.
6. Watch provenance. Track what share of merged code is AI-generated versus authored, by team, alongside defect and churn rates. The correlation over the next two years will be one of the most important datasets in the industry.

For Deeper Exploration

• Intrinsic motivation science — Daniel Pink's Drive and self-determination theory (Deci & Ryan)
• Flow and deep work — Csikszentmihalyi's research program and Cal Newport's Deep Work
• The behavioral economics of effort — the IKEA effect and effort-justification literature
• Craft, agency, and meaning in technical work — Shop Class as Soulcraft
• Engineering metrics beyond velocity — SPACE, DORA/Accelerate, and developer-experience measurement
• Empirical research on AI coding assistants — the METR productivity study and GitClear's code-quality analyses

The hikers who take the helicopter still reach the summit. The question for every CPO and CTO is what arrives there with them — judgment, attachment, and the appetite to climb again, or just a photograph. The organizations that win the next decade will be the ones that figured out which parts of the mountain to pave, and which parts to leave steep on purpose.