tl;dr There are two types of developers right now: those still polishing the axe handle and those ripping through forests with a chainsaw. The person paying for the tree to come down doesn’t care which tool you use. If you’re still refusing to pick up the chainsaw, this post is for you.

Fair warning: This post contains a protracted lumberjack metaphor. I’m well aware it’s not an original one - the chainsaw-and-axe framing for AI is practically a cliche at this point, and half the tech blogosphere has beaten me to it. But cliches become cliches because they work, and this one captures something I keep seeing play out in real teams. So here’s my version. If you’re not into axes, chainsaws, or questionable analogies about felling trees, now’s your chance to leave.

I created this article, but it has been reviewed and refined with help from AI tools: Claude and Grammarly.

The Chainsaw and the Axe

For centuries, if you needed to fell a tree, the axe was it. Skilled lumberjacks took genuine pride in their technique.

Then the chainsaw arrived.

Some resisted. They’d spent years mastering the axe. They’d built their identity around it. The chainsaw felt crude, noisy, maybe a bit like cheating. But here’s the thing: the person who needs a tree felled doesn’t care about your axe technique. They care about the tree being down, safely, quickly, and affordably. If one person shows up with a chainsaw and another with an axe, the chainsaw wins on speed and cost every time.

If you’re more attached to the craftsmanship of the axe than you are to the actual goal of felling the tree, you’ve confused the tool for the job.

Software development is living this right now. We’ve been climbing the abstraction ladder for decades - machine code to assembly, assembly to C, C to high-level languages with garbage collection and type systems. Each rung let us express intent more clearly and worry less about the mechanics underneath. We’ve just climbed another one. We can describe what we want in plain English and get working code back. Natural language is now a programming interface. Not a gimmick - an actual shift in how software gets made.

And it’s changing who gets left behind.

Two Types of Developer

Most development teams right now have both types.

There’s the developer who spends time perfecting their Vim config, hand-crafts every function, knows the keyboard shortcut for everything and is proud of it. They view AI-generated code with suspicion, maybe contempt. “I don’t need a crutch.” “It just produces slop.” “Real developers write their own code.” They’ve spent years mastering the axe - the angle of the swing, the sharpness of the blade, the rhythm of the work - and they’re not about to put it down for some loud, unreliable machine.

Then there’s the developer felling trees at five times the rate. They care just as much about quality - but they’ve stopped confusing quality with hand-typing every line. They use Claude Code, Copilot, Cursor, whatever gets the job done, and they put the time they save back into design, testing, and review. They’ve worked out that the hard part of software was never typing. It was thinking. And now they spend more time thinking and less time typing.

Which one are you?

The Stigma Has Flipped

A year or two ago, there was a stigma around AI tools. Admitting you’d used ChatGPT to help write code felt like admitting you couldn’t do the job yourself. Most people just wouldn’t mention it.

That’s flipped. Today, if you walk into a job interview and proudly declare that you refuse to use AI tools, you’re not signalling craftsmanship. You’re signalling that you’ll be slower, less productive, and unwilling to adapt. The stigma hasn’t disappeared. It’s just changed direction.

There’s even a “tokenmaxxing” trend now - engineers competing on AI usage leaderboards. Whether that’s healthy is debatable, but the signal is clear: most organisations are paying for these tools, and if you’re not using them, that’s visible.

Even the Master Axemen Picked Up the Chainsaw

It’s not just juniors or hype-chasers who’ve made the switch. Some of the most respected craftsmen in software - people who literally built their reputations on the quality of their hand-written code - have publicly acknowledged that the game has changed.

Kent Beck, the person who gave us Extreme Programming and Test-Driven Development, tried ChatGPT in April 2023 and tweeted: “The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate.” He later expanded on this, noting that the skills that still matter - having a vision, setting milestones, keeping track of a design - are now hugely leveraged compared to knowing where to put the brackets. He’s since coined the term “augmented coding” and now calls TDD a “superpower” when working with AI agents.

John Carmack - the person who hand-optimised assembly language to make Doom and Quake run on hardware that shouldn’t have been able to handle them - put it bluntly: “‘Coding’ was never the source of value, and people shouldn’t get overly attached to it. Problem solving is the core skill.” He reflected on how his first games involved hand-assembling machine code and turning graph paper characters into hex digits, and that software progress has made that work “as irrelevant as chariot wheel maintenance.” He’s now building AGI at Keen Technologies.

Perhaps the most dramatic reversal came from DHH, creator of Ruby on Rails and a notoriously opinionated voice on software craftsmanship. In mid-2025, he told Lex Fridman he wouldn’t let AI write code directly - he could “literally feel competence draining out of my fingers.” Six months later, in January 2026, he tweeted: “It turns out half the resistance was simply that the models weren’t good enough yet. I spent more time rewriting what it wrote than if I’d done it from scratch. That has now flipped.”

Even Linus Torvalds - creator of Linux and Git, a person who has spent 35 years maintaining one of the most critical codebases on the planet - described himself as “fairly positive” about vibe coding at the Open Source Summit in late 2025. A few weeks later he used AI to write the Python visualiser for a side project, admitting in the README that it was “basically written by vibe-coding.”

Martin Fowler called AI “the biggest shift in programming” he’s seen in his entire career and is now developing frameworks for what he calls “harness engineering” - how to effectively drive coding agents. Scott Hanselman, Microsoft’s VP of Developer Community, offered a memorable framing: “When you’re the expert, AI is the intern with unlimited energy. When you’re not the expert, AI is senior to you.” He and Azure CTO Mark Russinovich co-authored a paper on the profession’s future with AI - not questioning whether to use these tools, but how to make sure the next generation of developers still learns to think without them.

None of these people are saying craftsmanship doesn’t matter. They’re saying what craftsmanship means has shifted. And if the people who literally wrote the books on software quality are telling you it’s time to pick up the chainsaw, maybe it’s worth listening.

The Facts

This isn’t just vibes. Google’s 2025 DORA report found that teams with heavy AI tool use completed 21% more tasks and merged 98% more pull requests. Individual output went up significantly.

But, importantly, increased AI use also correlated with increased delivery instability. More rework, more failed deployments. PR review times ballooned by 91%, creating a new bottleneck at the human approval stage. The report describes AI as an amplifier, not a silver bullet. Strong teams used AI to get stronger. Teams with fragmented processes and poor foundations found that AI just exposed their existing problems faster. As one summary puts it: without the right structures in place, “AI simply becomes a faster way to create chaos.”

In other words: the chainsaw is genuinely faster, but it won’t help if you don’t know which trees to fell or how to fell them safely. The human judgement, the design thinking, the quality gates - those matter more now, not less.

Be Honest With Yourself

I’ve seen a few patterns in the developers who are resisting this. See if any sound familiar.

The “I type faster” developer who refuses autocomplete suggestions because they know what they want. The “at least I know it’s right” developer who spends hours on manual refactors that an agent could do in minutes. The “it’s probably wrong” developer who dismisses AI-generated code without actually reading it. And the “I don’t trust it” developer who says this but hasn’t actually invested any time learning how to use it properly.

There’s also a deeper one that I think a lot of us are dancing around, myself included: the worry that if AI can do your job, maybe your job wasn’t as hard as you thought.

It’s worth being honest about this. Because a lot of what we do as developers isn’t hard. It’s tedious. It’s boilerplate. It’s the hundredth CRUD endpoint, the hundredth React form, the hundredth migration script. The hard part was always the design, the trade-offs, the debugging, understanding what to build and why. AI doesn’t replace that. It replaces the typing.

What it also does - and this is the bit that I think gets overlooked - is let you iterate on the hard stuff faster too. You can sketch out three different approaches to a problem, actually build working versions of each, compare the trade-offs, and throw away the two that don’t work. That kind of exploration used to take days or weeks. Now it takes hours. You’re not just typing faster. You’re thinking faster, because you can afford to try things that you previously wouldn’t have bothered with.

Nobody Cares About Axes

Your product owner doesn’t care whether you hand-crafted the code in Vim or generated it with Claude Code. They care whether the feature works, whether it shipped on time, and whether customers are happy. Full stop.

And if you think about it, this isn’t even new. Product owners have always had to deal with agents that don’t deliver what they want. Those agents were called developers. Every PO has sat in a sprint review watching a demo of something that technically meets the acceptance criteria but completely misses the spirit of what was asked for. Every PO has written a story that seemed perfectly clear to them, only to get back something that makes them wonder if the developer even read it.

That’s exactly what developers now face when wrangling AI agents.

The developer who complains “the AI doesn’t understand what I want” is experiencing the same frustration their PO has felt about them for years. The skills are the same: writing clear requirements, providing good context, reviewing output critically, iterating on feedback. The developers who were already good at understanding what the business actually needed - not just what the ticket said - are the ones who seem to be getting the most out of AI tools.

Where This Is Heading

The work is shifting to either end of the process. On the input side: planning, design, writing good user stories, breaking features down into well-defined, testable pieces. Garbage in, garbage out has never been more literal. On the output side: PR reviews, automated testing, quality gates, security scanning. Someone still needs to understand what was produced and why, and to verify it actually does what it should.

The developer’s role is moving from “person who writes code” to “person who orchestrates the creation and validation of code”. That’s not a demotion. If anything, it’s a promotion. But it requires letting go of the identity that was built around typing.

And the models are getting better. Fast. The gap between what an AI produces and what a skilled developer would write is narrowing. At some point - and I don’t think it’s as far away as we’d like to believe - insisting on hand-written code for routine work will look a lot like insisting on hand-calculated spreadsheets when Excel exists.

Right now we’re in the awkward in-between phase - working out how to get the efficiency gains without sacrificing quality, how to maintain the right level of human oversight without creating bottlenecks that negate the speed advantage. This is genuinely hard. It means rethinking processes, team structures, what we even value in a developer. It means accepting that the tools are imperfect today, but that waiting for perfection isn’t an option. The organisations and developers who work this out first will have an enormous advantage. The ones who keep polishing the axe because that’s what they know will get left behind.

Sharpening the Axe

There’s a quote that gets attributed to Abraham Lincoln - “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” He almost certainly never said it. The earliest version traces back to an anonymous lumberjack in the 1940s, and the idea itself goes all the way back to Ecclesiastes. But the attribution doesn’t matter. The idea does.

I’ve always liked this quote because at its core it’s not really about axes or trees. It’s about sustainability. Teams that never stop to sharpen anything - never invest in their tools, their skills, their processes - eventually grind to a halt. They burn through effort without improving their capacity to deliver. The quote is really about what it takes to produce valuable software sustainably, and that’s always mattered more than raw output.

For most of my career, “sharpening the axe” meant investing in the craft of writing code. Taking a course. Learning a new framework. Practising TDD. Reading the Gang of Four book. Deliberate, focused effort to get better at the mechanics of the job. That interpretation felt right for a long time, and it was.

Those things still matter. But I don’t think they’re the sharpening that makes the biggest difference anymore.

If the axe is the tool you use to do the work, and the work is building software, then the tool has changed. Sharpening the axe now means learning how to write effective prompts. It means understanding how to structure context so an AI agent produces useful output. It means investing time in setting up Claude Code, configuring your MCP servers, building custom rules, and learning what these tools can actually do when you use them properly. It means getting good at the thing that makes you faster - which is no longer your typing speed or your knowledge of keyboard shortcuts.

The developers who are getting the most out of AI right now aren’t the ones who were the fastest typists. They’re the ones who put down the axe and learned to maintain the chainsaw.

Pick Up the Chainsaw

If you’re still holding the axe, I’m not asking you to throw it away. I’m asking you to be honest about why you’re still holding it. Is it because the axe genuinely produces better outcomes in your context? Or is it because you’ve built your professional identity around the swing?

If it’s the second one, put it down. Pick up the chainsaw. Learn how to use it safely. It’ll feel clumsy at first. You’ll miss some of the control. But you’ll fell more trees in a week than you used to in a month.

And if you’re already using the chainsaw - don’t get complacent. The chainsaws are getting better too. The developers who thrive won’t be the ones who adopted AI tools early. They’ll be the ones who kept adapting.

The tree doesn’t care which tool you use. Neither does the person paying for it to come down.

Thanks for reading.