The Craft Problem

I’ve been reading Brad Stulberg’s “The Way of Excellence ” over the past few weeks, and one idea keeps nagging at me: genuine excellence in a craft requires something that most AI productivity advice is actively working to eliminate.

Stulberg’s argument, roughly: pseudo-excellence offers hacks, shortcuts, and intensity. It looks productive, produces artifacts, and eventually produces burnout. Real excellence comes from deep engagement with the work itself, from showing up consistently over time, and from the kind of durable confidence that only gets built by doing hard things under conditions that aren’t ideal.

A few things Stulberg identifies as necessary:

Deep engagement with the work itself. Not just producing outputs from it. You have to be in contact with the thing you’re making, understanding it, grappling with it.

Mastery and mattering are linked. You can’t fully separate developing real competence from doing work that contributes something. Both require caring enough to stay engaged when the process is slow or difficult.

Durable confidence, built under hard conditions. The kind of confidence that can survive a bad sprint, a failed build, or a hard debugging session only gets built in those moments. Shortcuts around the difficult conditions skip the exact thing that builds resilience.

Process over outcome. Fulfillment lives in the doing. The artifact you produce at the end is secondary to whether you actually understood and cared about how you got there.

Caring deeply takes courage. Disengagement is easier than deeply caring about what you are doing and why. Performative busyness is easier than spending the time really understanding what it is you are trying to do. Producing outputs without fully understanding them is, in the short run, easier. But none of those paths lead anywhere worth going.

Where Vibe Coding Sits in That Framework

I kept thinking about vibe coding as I read the book.

For anyone who missed the original: Andrej Karpathy coined the term and his framing was something like “fully give in to the vibes… forget that the code even exists.” You describe what you want, the AI writes everything, you don’t read it and you ship it.

Run Stulberg’s framework against that and you’ll find it’s as far from the idea of excellence as possible.

Real excellence requires deep engagement with the work. Vibe coding eliminates that by design.

Real excellence requires performing under hard conditions to build durable confidence. Vibe coding removes the conditions. There’s nothing difficult to push through, because you’re not doing the thing — you are telling an AI to do the thing.

Real excellence comes from caring about the process. Vibe coding makes the artifact the entire point and the process is stripped away. The process becomes a prompt.

Real excellence requires mastery and mattering to stay connected. Vibe coding can produce artifacts that matter in the sense that they run and ship, without any of the mastery.

That last one is what I think gets missed in most of the discussion. The outputs can be real; features work and tests pass but the developer isn’t developing. They’re getting faster at something they’re not actually getting good at.

And here’s what that costs, practically: organizations quietly build a deficit of people who can understand, debug, maintain, and explain the systems they’ve ostensibly built. The artifacts exist but nobody can really explain what they really do, how they are built or how they should be maintained.

Stulberg also talks about the finite game versus the infinite one. A finite game has a fixed endpoint: time-bounded, with winners and losers. The infinite game has no end. The only goal is to keep playing, keep improving, keep discovering what’s possible within the craft. A developer who vibe codes is playing a finite game even when they think they’re building something durable. They’re optimizing for today’s artifact, not for who they’re becoming as a practitioner.

That distinction holds whether you’re a solo developer or running an engineering org. Teams that vibe code ship faster in the short run and struggle with maintenance, onboarding, and anything that requires actually reasoning about their own codebase. The technology debt is real and it will show up down the road.

The AI productivity conversation still revolves mostly around output: lines of code per day, features per sprint, velocity numbers. Those aren’t useless, but Stulberg’s book made me more confident in asking a different question alongside them: what is the person actually learning while this is happening?

If the answer is nothing, the developer is getting faster at a skill they’re not building. That cost doesn’t show on the velocity dashboard. It shows up in the debugging session that goes nowhere, in the architecture decision made without the judgment that comes from having written code that failed and having had to understand why, in the system that runs fine until it doesn’t and nobody can explain it.

This isn’t an argument against AI tools. I use them heavily across writing, code, research, and analysis, and I’m not pretending otherwise. The question is where you draw the line on how I (and you) use these tools.

Stay close to the work. Not because the old way was better, but because the understanding you build by staying in contact is what builds upon previous and separates a practitioner who can debug, adapt, and explain from someone who can only prompt.

Stulberg’s point isn’t that you have to do everything the hard way. It’s that staying in contact with the work, at the level where understanding actually develops, is the thing you can’t outsource.