We Choose Our Craft
The craft hasn't died. Its expanded.
Two posts circulated this week that resonated with a lot of developers. Nolan Lawson’s We Mourn Our Craft and Ernesto’s Thinking Hard both articulate something genuine: the grief of watching a profession you love reshape itself faster than you can process. Lawson mourns the end of hand-crafted code. Ernesto mourns the loss of deep intellectual struggle. Both write from real experience, and both capture something many developers feel right now.
These aren’t hot takes. They’re grief, and it’s earned.
I’ve lived through enough paradigm shifts in software development to recognize the pattern. Each one felt, at the time, like an ending. I understand the mourning. I also think the grief is aimed at the wrong thing. What’s dying isn’t the craft. What’s dying is one specific expression of it.
The Lens Shifted
There’s an old adage in software engineering: “It’s 90% planning and problem solving, 10% coding.” If that was ever true, in a growing set of dev shops, the ratio is approaching 99/1 now. That isn’t a loss. It’s the industry catching up to what experienced engineers have always known. The hard part was never the typing.
We’ve already proven this to ourselves. We stopped reading compiled code a long time ago. In this GenAI era trusted, productive developers will increasingly ship code they haven’t written line by line. That sounds alarming until you realize system designers have always operated this way. They held the system model in their heads, made the structural decisions, and partnered with trusted peers to implement the details. The intermediary changed from humans to models. The skill didn’t.
Context engineering isn’t new. Engineers have always needed to understand the domain, the system boundaries, the users. What’s changed is that the cost of code has approached zero. When implementation was slow, gaps in understanding had a chance to surface during the journey to prod. Now those gaps ship. Knowing what to build. Knowing what not to build. Understanding how systems compose and where the failure modes hide. That was always the craft. I explored what that calibration looks like in practice previously. What I’m arguing now goes further: the craft isn’t just about rigor. It’s about knowing where human expertise matters most.
Uneven Ground
I want to be direct about something the optimistic framing risks glossing over.
Developers with two to three years of experience are in the hardest position right now. They’ve built enough skill to feel competent but haven’t yet developed the deep architectural instincts that turn AI into a force multiplier. The playbook they were following got rewritten mid-chapter. That’s a genuinely difficult place to be, and I won’t minimize it. In my experience, the path through looks the same as what’s always built engineering depth: get closer to the problem. The tools can accelerate that learning when approached deliberately rather than as a shortcut around it.
Early-career developers who’ve never known anything else will adapt to the tools fastest. AI-assisted development is simply how they work. Yes, the tooling is rough right now. That’s natural with any new paradigm, and it won’t stay this way.
Experienced engineers carry decades of pattern recognition, systems thinking, and production scar tissue that AI cannot replicate. That judgment layer compounds with experience in ways that are difficult to shortcut. For this group, the tools aren’t a threat. They’re an amplifier.
The optimism I’m offering here isn’t evenly distributed. I won’t pretend otherwise.
The Choice
This moment offers a choice: leverage or loss. The loss is real. I’ve spent two sections acknowledging it. But staying in the loss is also a choice. If you define the craft by what it was, you’ll miss what it’s becoming. The leverage deserves equal attention.
Geoffrey Huntley recently described the experience as teleporting into the future. Timelines collapsing. Previously impractical work becoming suddenly achievable. That framing resonates. The shift isn’t speed. It’s reach.
That’s available at every experience level. For early-career developers, it means building domain expertise alongside the tools rather than after them. For the middle, it means the reinvention they’re already doing is the path, not a detour. For experienced engineers, the judgment they’ve built over decades becomes the multiplier.
What does that reach look like in practice? The craft of software engineering migrates to where human expertise is needed most. For some, that’s designing and guiding reliable systems, with AI handling the implementation. I’ve watched peers do this already: holding the system model, defining the boundaries, then partnering with AI the way they once partnered with junior developers. For others, the path leads to the frontier of computer science itself: novel systems, problems the tools can’t navigate alone. The problems here aren’t getting easier. They’re getting more interesting.
Each paradigm shift in this industry expanded what “developer” meant. The craft has never contracted. Whether you move toward systems design or toward the frontier, both paths require experience, and both are choices that belong to the individual, not to the market or the discourse.
The craft isn’t dying. The definition is expanding. This shift is faster and broader than any I’ve lived through, and we are in genuinely new territory. But the underlying pattern holds. Every paradigm shift creates this same in-between. The old definition doesn’t fit. The new one hasn’t solidified. That’s where we are. It’s disorienting. It’s also temporary. The definition will settle. The craft will absorb this change the way it has absorbed every one before it.
Observe the shift. We’ve done that. Orient to what it means for your current context. Posts like these help. Decide what you become next. Then act.
— OODA Loop