When the tools work too well

There's a quote buried in the latest Ars Technica piece on AI coding that I can't stop thinking about. A Microsoft engineer named Darren Mart says the software development role is "abruptly pivoting from creation to supervision," and then adds: "While some may welcome that pivot, others certainly do not. I'm firmly in the latter category."

The article is full of developers saying the same thing in different ways. The tools work. They really work. 10x speed improvements on complex tasks. Features that would take a year done in two weeks. Prototypes spun up in an hour. And yet, running underneath all that velocity is this current of unease.

The Thing We Don't Talk About

When we talk about productivity tools, we frame everything in terms of output. Faster shipping. More features. Reduced friction. All metrics that sound obviously good because who wouldn't want to ship faster?

But here's what gets lost: for a lot of developers, the act of writing code isn't just a means to an end. It's the thing itself.

There's a specific kind of satisfaction that comes from wrestling with a problem for hours, finally understanding it, and then crafting a solution that feels elegant. It's the satisfaction of building something with your hands, even if your hands are just typing. It's the reason many of us became developers in the first place.

When AI agents handle "the surface level of detail," as one developer put it, that satisfaction gets outsourced. You're left directing, reviewing, supervising. Still valuable work, sure. But it's not the same work.

The Tightrope

The efficiency is real. I use these tools. I've felt that rush of watching Claude spin up something in minutes that would have taken me hours. It's genuinely incredible.

But I also notice what happens to my brain when I work this way too much. The muscle that understands how things fit together gets less exercise. The deep familiarity you get from typing every line, seeing every error, understanding every dependency, that starts to fade.

One developer in the article only uses AI for tasks he "already fully understands," specifically because there's "no way to know if I'm being led down a perilous path" otherwise. That's the tightrope. You need expertise to use the tools safely, but the tools themselves might prevent you from building that expertise in the first place.

Vibe Coding and Technical Debt

There's this term floating around: "vibe coding." Programming by conversing with AI without fully understanding the resulting code. It sounds dismissive, but it points to something real.

When you don't understand the code deeply, you can't see the architectural problems forming. The shortcuts that will cause pain later. The "code smells" that lead to maintenance nightmares. One developer mentioned AI is "driving down obvious bugs but increasing code smells." Fewer crashes today, more technical debt tomorrow.

The question isn't whether we can ship faster. Clearly we can. The question is whether we're building things we can maintain, extend, and truly understand.

What Gets Optimized Away

I keep thinking about what happens to junior developers in this world. One dev put it bluntly: "It's going to get harder for junior positions to get filled when I can get junior-quality code for less than minimum wage."

If junior work gets automated, where do people learn? How do you build the judgment needed to supervise AI agents if you never got to struggle through the details yourself?

There's a real possibility we're optimizing away the path to mastery. The inefficient, messy, frustrating process of learning by doing. The part that takes time but builds intuition.

The Questions That Keep Me Up

So here's what I'm sitting with:

Is velocity always the right metric? What if the slower path builds something more durable, both in the code and in the developer?

What happens to craftsmanship when craft becomes supervision? Can you love being an architect if you never laid bricks?

Who gets to decide what's worth preserving? Efficiency is compelling because it's measurable. But the satisfaction of creation, the joy of solving problems with your own hands, those are harder to quantify. Do they matter less because they're harder to measure?

Can we use these tools without losing what made us want to code in the first place? Or is that just nostalgia for a way of working that's already gone?

I don't have clean answers. I just know that when a technology works this well this fast, it's worth pausing to ask what we might be trading away for all that speed.

The tools aren't going anywhere. They're only getting better. Which means we need to be intentional about what we want to keep human, not because humans are more efficient, but because some kinds of inefficiency are actually the point.