The 5 Phases of Craftship (Why AI Amplifies Wherever You Already Are) | Khalil StemmlerThis app works best with JavaScript enabled.khalilstemmler.com<br>Resources<br>Articles<br>Quiz<br>Mentorship<br>Community
Not subscribed? Get advanced dev newsletters straight to your inbox each week.<br>Join 20,000+ other value-creating developers mastering what matters & building incredible careers.
Read for free
The 5 Phases of Craftship (Why AI Amplifies Wherever You Already Are)
The Phases of CraftshipLast updated Jul 16th, 2026
Two developers, same AI, opposite years — one terrified he's falling behind, the other having his best year yet. The difference isn't talent. It's which of the 5 Phases of Craftship they're in, and why AI amplifies whatever capability you've already built instead of replacing it.
the phases of craftshipthe metaphysicsaicode-firstvalue-first
Two developers had calls with me recently.
One is two and a half years in, bootcamp grad, working in a messy codebase, terrified he's falling behind and AI is going to finish the job. The other just shaved milliseconds off a request path at scale — worth millions a year — and is now dealing with colleagues who've started to resent how good he's gotten.
Same industry. Same AI tools available to both of them. Completely different years.
What's the core problem?
The advice out there is split, and it's split because the developers are split.
Half the internet is telling you AI is coming for your job. The other half is telling you to stop worrying and start building. Both groups are right — just not about the same person.
What's actually true?
It depends entirely on where you're at.
Not in a vague, "everyone's on their own journey" way. Literally — there are 5 phases developers move through, and the correct advice for someone in phase one is often the opposite of the correct advice for someone in phase five.
The 5 Phases of Craftship
Code-First — "How do I make this work?" You think in implementations. Every developer starts here.
Best Practice-First — "How do I make this easy to change?" You start designing through contracts, testable architecture, feedback loops.
Pattern-First — "What is the true shape of this problem?" You stop modeling structure and start modeling time — events, reactions, triggers in addition to understanding the way the business works.
Responsibility-First — "Who should own this responsibility?" Ownership replaces structure at every level — objects, services, teams, orgs.
Value-First — "What creates the most value with the least complexity?" Code becomes one tool among many. You become the business.
Here's the thing though: the majority of the industry is stuck somewhere between Code-First and Best Practice-First.
And AI is already a master of Code-First.
The core problem for Code-First developers: architectural judgment
"It feels weird but I can't explain why."
That's what a developer who joined The Software Essentialist Mentorship Group told me, describing some context/provider state management in her app. She wasn't guessing. She could sense it — that specific, uncomfortable feeling of something being off that every experienced developer knows.
Here's the thing: she isn't junior. Her team lead comes to her with hard problems. She can solve those problems, but when asked why that particular approach was done that way, she goes quiet.
What she's missing is the vocabulary to defend decisions she's already made correctly.
I call this the Capable Outsider . It's one of the most common shadows of the Code-First phase — and it's exactly what "architectural judgment" means when it's missing.
As you move through the phases, you integrate increasingly powerful archetypes
Here's what's actually happening underneath all this. As you move through the phases, you're integrating specific archetypes at each one.
At Best Practice-First, you start integrating the Clarifier — someone who gets clear on requirements and expected behavior before touching implementation — and the Feedback Loop Engineer , obsessed with shortening the gap between decision and consequence.
At Pattern-First, you integrate the Event Thinker and the Cartographer — developers who map the shape of a domain before writing a line of code.
Keep climbing and you eventually integrate the Systems Engineer , the Solution Architect , and — at the top — the Essentialist : someone who removes complexity instead of adding it, who asks "what can we eliminate?" before "what should we build?"
And every one of these has a shadow side that has to be managed, not just outgrown. The Clarifier's shadow is the Pattern Collector — applying design patterns by name without being able to reason about why. The Essentialist's shadow is the Business Tourist — speaking the language of value without genuinely understanding how the software creates it. Growth isn't leaving the shadow behind for good. It's learning to catch yourself sliding back into it.
The solution: integrate through the...