Update on August 13th: Thomas Dohmke is stepping down as CEO of GitHub. I wrote a follow-up post with my thoughts on the subject.

I read Thomas Dohmke’s piece about developers being “reinvented” through AI adoption, and while his vision of transformation may appeal to some, something important is missing from this narrative. The piece paints a picture of inevitable change, but it glosses over a fundamental principle that has always driven great software development: the right to choose your own tools and approach.

There’s a troubling undertone to the argument: it suggests that developers who don’t embrace this particular path are somehow destined to become obsolete. The framework assumes that technological advancement follows a single, predetermined trajectory. But anyone who’s been in this industry for more than a few years knows that’s simply not how software development works. We’ve seen countless “revolutionary” tools come and go, each one promising to fundamentally change how we work.

Remember when visual programming languages promised to eliminate traditional coding and when low-code platforms were supposed to make developers redundant? These tools found their niches and served specific purposes, but they didn’t replace the fundamental craft of software development. They became options in a much larger toolkit.

The four-stage progression Dohmke outlines (Skeptic, Explorer, Collaborator, Strategist) reads more like a conversion narrative than a natural evolution. It assumes that every developer who doesn’t reach “Stage 4” is somehow incomplete or behind the curve. But what if some developers are perfectly fulfilled and effective working in what he calls “Stage 1” or “Stage 2”? What if they’ve made a conscious choice about how they want to practice their craft?

Here’s what bothers me most about the “adapt or perish” messaging: it fundamentally misunderstands what makes developers valuable. Yes, AI can generate code quickly. But software development has never been just about typing out syntax as fast as possible. The real work happens in understanding problems, designing elegant solutions, making architectural decisions, and yes, sometimes in the careful crafting of individual functions and algorithms.

Some of the best developers I know are incredibly thoughtful about their tools. They might spend extra time writing code by hand not because they’re resistant to change, but because the act of typing each line helps them think through edge cases, consider performance implications, or ensure they truly understand what they’re building. That’s not inefficiency; that’s craftsmanship.

The piece mentions that Stage 4 developers focus on “delegation and verification” rather than implementation. But this assumes that implementation itself isn’t valuable or intellectually rewarding. For many developers, the process of translating ideas into working code is one of the most satisfying aspects of the job. Why should we abandon that?

Dohmke’s analysis also oversimplifies the incredible diversity within software development. A developer working on embedded systems for medical devices faces completely different constraints and requirements than someone building web applications or mobile games. The idea that all of these roles will converge toward AI orchestration ignores the reality of how specialized and varied our field actually is.

Consider performance-critical applications where every line of code matters, or safety-critical systems where you need to understand exactly how each algorithm works. In these contexts, the “black box” nature of AI-generated code isn’t just suboptimal, it could be dangerous. Developers in these fields aren’t resisting change out of stubbornness; they’re making responsible technical decisions.

Even in less critical applications, there’s tremendous value in having developers who deeply understand the systems they’re building. When something goes wrong at 2 AM, you want someone who can debug from first principles, not someone whose primary skill is prompting an AI agent.

The piece briefly mentions that advanced developers are paying for “top-tier subscriptions” to AI tools, framing this as evidence of their commitment to the new paradigm. But this glosses over a significant economic reality: not every developer can or should be required to pay monthly fees for the privilege of doing their job. Many excellent developers work for small companies, contribute to open source projects, or simply prefer to keep their tool costs minimal. The suggestion that staying current requires expensive subscriptions to multiple AI services creates an artificial barrier to entry and excludes developers who might be brilliant but don’t have the budget for the latest AI tools.

Perhaps most importantly, the push toward universal AI adoption risks stifling the kind of innovation that has always driven our industry forward. Some of the most significant breakthroughs in software development have come from developers who took unconventional approaches, who questioned prevailing wisdom, or who chose to work in ways that seemed inefficient at the time.

If we create a culture where deviating from the AI-assisted workflow is seen as falling behind, we lose that diversity of approach. We end up with a monoculture where everyone is using similar tools, thinking in similar ways, and potentially missing opportunities for genuine innovation.

None of this is to say that AI tools don’t have value or that developers shouldn’t experiment with them. Many of the capabilities Dohmke describes are genuinely impressive, and I know plenty of developers (myself included) who have found AI assistants helpful for certain tasks. The key is choice. Developers should be free to incorporate AI tools where they add value, while also maintaining the option to work more traditionally when that approach serves them better.

A healthy software development ecosystem needs room for both the AI enthusiast who loves orchestrating multiple agents and the craftsperson who prefers to understand every line of code they write. Rather than pushing a single vision of what developers should become, we should celebrate the diversity of approaches that make our field so dynamic.

The developer who spends extra time carefully implementing an algorithm by hand might discover an optimization that the AI-first developer would miss. The team that chooses to limit their AI usage might maintain better understanding of their codebase’s internals. These aren’t inferior approaches; they’re different approaches that can lead to different kinds of insights and innovations.

What I find most concerning about the “reinvention” narrative is the implicit assumption that developers can’t be trusted to make good decisions about their own tools and processes. The piece suggests that resistance to AI adoption is simply a matter of not understanding the benefits or being stuck in old ways of thinking.

But developers are generally pretty smart about tools. We’ve been evaluating new frameworks, languages, and methodologies for decades. When we’re skeptical of a new approach, it’s often for good reasons. Maybe we’ve been burned by similar promises before. Maybe we understand aspects of our specific problem domain that make the new tool less applicable. Maybe we’ve simply found a workflow that works well for us.

The assumption that skepticism equals ignorance does a disservice to the thoughtful analysis that most developers bring to tool selection. Some developers will find tremendous value in AI-powered workflows. Others will use AI tools selectively for specific tasks. Still others will choose to work primarily with traditional tools. All of these can be valid, intelligent choices.

The future of software development doesn’t have to be monolithic. We can embrace the potential of AI tools while still preserving space for developers who choose different approaches. We can celebrate the efficiency gains that some developers achieve through AI assistance while also recognizing the value that comes from deep, hands-on understanding of systems.

What we need is not a single vision of what developers should become, but an ecosystem that supports multiple paths. The developer who masters AI orchestration deserves respect for their skills. So does the developer who becomes incredibly proficient at manual optimization or the developer who finds the perfect balance between AI assistance and hands-on work.

The strength of our industry has always come from its diversity of thought, approach, and expertise. Let’s not sacrifice that diversity for the sake of a single technological trend, no matter how impressive that trend might be. The future is big enough for all kinds of developers.

Great software will continue to be built by people who understand their tools deeply, think critically about problems, and make thoughtful decisions about how to approach their work. Whether those tools include AI agents or not is just one choice among many. Let’s keep it that way, shall we? 😉