The 5 Phases of Craftship (Why AI Amplifies Wherever You Already Are)

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

1. Code-First — "How do I make this work?" You think in implementations. Every developer starts here.
2. Best Practice-First — "How do I make this easy to change?" You start designing through contracts, testable architecture, feedback loops.
3. 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.
4. Responsibility-First — "Who should own this responsibility?" Ownership replaces structure at every level — objects, services, teams, orgs.
5. 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 phases

So the solution isn't "learn more." It's integrate, one phase at a time, in order. You cannot skip Best Practice-First and land in Pattern-First. Judgment develops through encounter — you hit the wall, it humbles you, you integrate the capability, you move forward with a scar that's actually a map.

As you do this, you end up learning what I call the 12 essentials — the small set of principles that stay true regardless of stack. Every single problem you'll ever hit in a codebase traces back to one of these 12 not being respected. Doesn't matter if it's DDD, TDD, BDD, CI, deployment pipelines. They're closer to universal laws than best practices.

Why fundamentals matter more than ever: the Mirror Principle

Here's the part that explains everything else in this article.

Inside mirrors outside. Whatever capability you've actually integrated is the frame you solve problems from — and AI just gives that frame more horsepower. I call this the Mirror Principle.

If you're Code-First and you hand your work to AI, you don't get better work. You get more of the same mess, produced faster. The gaps you have get amplified, not fixed.

If you're Value-First, the mirror works the other way — you become exponentially more powerful, because the judgment guiding the AI is already sound.

Two stories that show exactly what this looks like at the top:

One of my graduates showed up to a team that was building something creating zero business value, said so, and shipped the actual fix over a weekend. The team he was on effectively made itself redundant — not because he set out to eliminate anyone, but because once you can see what's actually valuable, you can't unsee it, and the byproduct is that busywork stops having a place to hide.

Another graduate got so fast that completing upwards of — I think it was, 20+ tickets in a day — started making other people on his team uncomfortable. His actual work now isn't more tickets. It's reading Crucial Conversations and deliberately slowing down so the people around him don't feel threatened.

Same phase. Same capability. Two completely different problems to manage.

The advice is different depending on your stage

This is why I can't give one piece of advice that applies to everyone reading this. Fay's essay on agentic coding, Cal Newport's junior-year-wall analogy, "just use AI more," "just stop using AI" — all of it is written for a specific phase, and it'll actively mislead you if you're not in that phase.

Where are you? Start here

Take the Phases of Craftship quiz — 7 questions, personalized results. I'm also building a more in-depth archetype quiz that goes phase by phase into which specific archetype you're integrating (and which shadow you're managing) — that'll be live soon.

If you're Code-First or Best Practice-First

Your job right now is to catch up, deliberately and fast. The gap is closeable while it's still small — it gets more expensive to close every month you wait. The Software Essentialist is where I teach this end to end, or book a call with me and we'll figure out exactly what to focus on first.

If you're Value-First

Your problem is a completely different one. It's rarely technical anymore. It's personal development — learning to slow down, building the confidence to pitch what you know, figuring out how to build your own thing instead of just being excellent inside someone else's. A lot of the developers at this stage end up building their own SaaS or service business.

If that's you, this is exactly the work we do inside the Abstractionist Mastermind.

And as always, To Mastery

Khalil