tl;dr Two types of developer right now: those 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. Four reasons to keep swinging hold up; most of what I hear isn’t one of them. If you’re refusing to pick up the chainsaw, this post is for you.

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

The lumberjack metaphor ahead runs long, and I didn’t invent it. I keep reaching for it because I keep watching it play out in real teams. For centuries the axe was how a tree came down. Lumberjacks took pride in their technique and had earned the right to. Then the chainsaw arrived, and some of them resisted. They’d spent years mastering the axe and built an identity around it, and the chainsaw felt crude and noisy, close to cheating. But the person who needs a tree felled doesn’t care about your axe technique. They want it on the ground today, with nobody in hospital.

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

We’re living this in software. We’ve been climbing the abstraction ladder for decades: machine code to assembly, assembly to C, C to languages that handle memory and types for us. This is the next rung. You describe what you want in plain English and get working code back. Natural language is a programming interface now, and the developers who adapted are pulling away from the ones who didn’t.

Your Team

Your team probably has one of each, and most people somewhere in between.

One of them tunes their Vim config on weekends and hand-types the code, function by function. They view AI-generated code with suspicion. “I don’t need a crutch.” “Real developers write their own code.” They’ve spent years mastering the axe, the angle of the swing and the rhythm of the work, and they’re not putting it down for some loud, unreliable machine.

The other one is running a chainsaw. They care about quality as much as the first developer does, but they stopped equating quality with hand-typing every line. They use Claude Code, Copilot, Cursor, and they put the saved time into design and review. The hard part of software was always the thinking.

A couple of years ago that second developer would have kept quiet about it. Admitting you’d used ChatGPT to write code felt like admitting you couldn’t do the job yourself. That’s flipped. In April 2025, Shopify CEO Tobi Lütke told his whole company that “reflexive AI usage is now a baseline expectation”, added AI usage questions to performance reviews, and told teams to prove AI couldn’t do the job before asking for more headcount. Declare in an interview that you refuse to use AI tools, and that’s the baseline you’ve just told them you won’t meet.

Your Product Owner Doesn’t Care About Axes

Your product owner doesn’t care whether you hand-crafted the code in Vim or generated it with Claude Code. They care that the feature works and that it shipped when you said it would.

None of this is new. Product owners have spent entire careers dealing with agents that don’t deliver what they want. We called those agents developers. Your PO has sat in a sprint review watching a demo that ticks every acceptance criterion and misses the point of the story. Your PO has written a story they thought was clear, then opened the PR and wondered whether you read it.

That’s what you’re doing now when you wrangle an agent, from the other side of the desk.

Complain that “the AI doesn’t understand what I want” and you’re voicing the frustration your PO has held about you for years. The skills are the same ones: write a clear requirement, and read what comes back with a sceptical eye. Developers who read past the ticket to what the business needed are the ones whose agents build the right thing first time.

Even the Master Axemen Picked Up the Chainsaw

The people saying this loudest built their reputations on hand-written code.

Kent Beck, 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.” The surviving 10%, he later explained, is holding a vision and keeping track of a design, which counts for far more now than knowing where the brackets go. He’s since coined “augmented coding” and calls TDD a superpower when you’re working with agents.

John Carmack hand-optimised assembly to make Doom and Quake run on hardware that had no business running them. He was blunt: “‘Coding’ was never the source of value, and people shouldn’t get overly attached to it. Problem solving is the core skill.” He wrote his first games by converting graph paper characters into hex digits by hand, and he reckons progress has made that work “as irrelevant as chariot wheel maintenance.”

DHH turned the hardest. The creator of Ruby on Rails holds loud opinions about craftsmanship, and in mid-2025 he told Lex Fridman he wouldn’t let AI write his code, because 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.”

Linus Torvalds, 35 years into maintaining the Linux kernel, called himself “fairly positive” about vibe coding at the Open Source Summit in late 2025, then used AI to write the Python visualiser for a side project a few weeks later.

Martin Fowler calls AI “the biggest shift in programming” of his career and now writes about “harness engineering”, his term for the work of driving coding agents well.

Scott Hanselman gave me the framing I keep coming back to: “When you’re the expert, AI is the intern with unlimited energy. When you’re not the expert, AI is senior to you.”

All of them still care about craftsmanship. They’ve changed their minds about what it consists of. The people who wrote the books on software quality are telling you to pick up the chainsaw.

Chainsaws Kick Back

Chainsaws also injure people. You wear a helmet, a face screen and cut-resistant trousers to run one. The training is mandatory, and no crew boss hands a saw to a first-year apprentice and wanders off. The tool is faster and more dangerous, so the trade built a safety culture around the trade-off.

Software sits in the same spot. Google’s 2025 DORA report found that teams leaning hard on AI tools completed 21% more tasks and merged 98% more pull requests.

Those same teams also shipped less stable software, with more rework and more failed deployments, and their PR review times ballooned by 91%. Individual output went up. The queue at the human approval stage went up further. You can be the fastest operator on site and still stand around waiting for someone to certify the cut.

The DORA authors land on amplifier as the word for it. Strong teams got stronger. Teams with fragmented processes found that AI exposed their existing problems faster, and Thoughtworks summed up the failure mode: without the right structures, “AI simply becomes a faster way to create chaos.”

The chainsaw is faster. Trained operators only.

When the Axe Is the Right Tool

Four reasons to keep swinging hold up.

Juniors need to learn to swing. You don’t learn to review AI output without first writing years of bad code and finding out why it was bad. A junior who has accepted suggestions and nothing else has no calibration for when a suggestion is wrong. That’s the strongest argument against blanket adoption, and I haven’t seen anyone solve it.

The review queue is the constraint. If you’re the only person on the team who can review the output with any authority, going faster upstream lengthens your queue. That’s arithmetic, and the DORA numbers back it.

Some code you need to have written yourself. At 3am, on call, staring at a stack trace from a service three people understood and two of them have left, the code you typed yourself is the code you can reason about.

Some shops can’t. Air-gapped networks, or client contracts that name the approved tooling. “Not yet” is a fine answer when a contract says so, rather than a preference wearing a hi-vis vest.

My problem is the scope creep. Those reasons cover maybe twenty percent of the work, and I keep watching people stretch that twenty percent to cover the other eighty. Your admin screens have nothing in common with the 3am incident, and your build scripts aren’t where the junior learns their craft. A real objection should change which trees you take the chainsaw to, not whether you own one.

Be Honest With Yourself

The developers I’ve argued with about this didn’t cite any of those four reasons. That’s my sample, not a survey.

One spends an afternoon on a manual rename an agent handles in a minute, then calls the afternoon “at least I know it’s right”. Another says “I don’t trust it” and hasn’t spent an hour learning to drive it.

A lot of us are dancing around something bigger, myself included. If AI can do your job, maybe your job wasn’t as hard as you thought.

Much of what we do is tedious rather than hard. The hundredth CRUD endpoint, the hundredth migration script.

The tools speed up the hard part too. You can sketch three approaches to a problem, build working versions of all three, compare what breaks, and bin the two that don’t hold up. That used to cost days. Now it costs an afternoon. You’re thinking faster, because you can afford to try things you’d have talked yourself out of.

Where This Is Heading

You end up doing more work at both ends of the process. At the input end you’re designing and cutting features into testable pieces an agent can’t misread. At the output end you’re reviewing and running the quality gates, because someone has to understand what the agent produced and why.

You’re moving from the person who writes the code to the person who orchestrates its creation and validation. That’s a promotion, and it costs you an identity built around the swing.

We’re in the awkward in-between phase, working out how to bank the speed without losing the quality, and how to keep a human in the loop without that human becoming the bottleneck that eats the gain. I don’t have the answer and neither does anyone I’ve asked. I’m not waiting for one.

Sharpening the Axe

People attribute a line to Abraham Lincoln: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” He didn’t say it. The earliest version comes from an anonymous lumberjack in the 1940s, and the idea itself goes back to Ecclesiastes. It survives the bad attribution.

I’ve liked the line for years. A team that stops investing in its tools and its skills burns more effort every year for the same output.

For most of my career, sharpening the axe meant getting better at writing code: a course, TDD practice, the Gang of Four book, all of it aimed at the mechanics of the job. That was the right reading for a long time, and those skills still matter.

They’re no longer where the sharpening pays off most.

The tool changed. Sharpening it now means learning to write a prompt that survives contact with a real codebase, and learning to structure context so the agent produces something you’d merge. It means the unglamorous setup work: wiring up your MCP servers, writing the rules file that stops the agent making the same mistake for the fortieth time. Your typing speed stopped being the thing worth sharpening.

Pick Up the Chainsaw

Keep the axe if you want. Be honest about why you’re holding it. Does it produce better outcomes on your codebase, or have you built a professional identity around the swing?

If it’s the identity, put it down. The chainsaw will feel clumsy and you’ll miss the control. Learn to run it safely anyway, then stay uncomfortable, because the saws keep getting better. Adopting early buys you nothing on its own. The developers who thrive will be the ones who keep adapting.

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

Thanks for reading.