Does Claude Mean the End of Expertise?
Not by a long shot. But it does mean not having it no longer stops you on the first step. Maybe you can let that teammate eat lunch after all.
There’s a popular idea that tools like Claude mean the end of expertise. Why spend years getting good at databases, or DevOps, or CSS, when you can just ask?
I’m not sure I have a response to that. Reflexively, I want to say that it’s untrue. To wail and gnash against it. Maybe I’m just defending my own job, here. Regardless, one thing I do know is that Claude definitively changes one thing that matters a lot: you’re no longer blocked immediately by lacking expertise in a particular field.
That’s Bob in the Corner
We all had (or have) that co-worker. The one who’s been there the longest. The one with the vast swath of institutional knowledge. He might be grumpy with the weight of these expectations. She might be scattered, pulled by her colleagues in a million different directions, while still responsible for her own workload.
I’ll call this co-worker Bob. I may or may not have worked with some literal Bobs throughout my career. I also may find myself increasingly resembling them in age, looks, knowledge, and general temperament.
Here’s how it used to go. You’re working on something, and you hit a roadblock. Maybe it’s a server config, a slow MySQL query, or some obscure error message coming out of a server that you’ve never seen before. When you’re a junior, you learn that it’s not wise to just sit quietly and try and figure something out on your own. That’s a recipe for burning time, and frustrating your manager. So you do the sensible thing – you ask the person on your team who actually knows. That’s Bob. That’s always Bob.
It’s the right call, but it’s also an expensive one. It costs their time and their focus, and it costs you the wait. This might have been more easily done when we were all in the office together; everyone was used to that slow period after lunch where we could ask these types of questions, get answers, and move on. Remote work is generally an improvement in every single way, but this is one time where it falls short: if everyone leans on Bob, Bob has a million mentions in Slack, and doesn’t get to get any of their own work done.
Making progress on your own
Now, when I hit a roadblock, I can keep going. Claude can explain the thing I don’t know well enough for me to make a reasonable first pass, and then help me build it. I’ve written here about letting it administer the Linux box in my house. I’ve spent my career on the developer side of the fence, and at PortlandLabs we have DevOps folks precisely so people like me don’t have to babysit servers. At home, Claude filled that gap.
Recently, we started working on some more exotic tooling in AWS. Our lead developer is a big proponent of CDK for describing our infrastructure, and I can see why. However, it’s no secret that my TypeScript experience is rudimentary and my knowledge of AWS internals even less so. If I needed to set up these AWS services in the past (for what amounts to some interesting experiments), I’d have given up. It just wouldn’t be anything I’d ever have explored.
The point isn’t that I became an expert in any of these. I didn’t. The point is that I could make real progress without bothering my teammates, right up until I really needed to integrate with something they’re providing.
A Need For Real Expertise
That’s the line that matters: integration. When your work has to plug into someone else’s system – their API, their infrastructure, their part of the codebase – you still need the buy-in and the expertise of the person who owns it. Not because Claude can’t read their code, but because they know things that aren’t in the code. They understand the decisions about why the code looks the way it does, and what edge cases exist and why. They also know what broke the last time someone did it the way I’m about to do it.
The conversation changes. Instead of “how does this work?” it’s “here’s what I built and how it connects to your piece; does this hold up?” That’s a better question to ask an expert. It respects their time, it’s concrete, and it puts their knowledge to work on the part only they can answer.
Expertise is also what tells you when Claude is confidently wrong. In a field I know, I can spot it. Outside one, I’m taking its word for it, so it’s important to know that my very knowledgeable teammates have my back in this regard.
If anything, this makes the experts on a team more valuable, not less. Their attention stops going to unblocking people on basics and goes to the hard questions, where systems meet and where the expensive mistakes live. For the rest of us, the first step into an unfamiliar field is no longer a wall. It’s more like a climbing gym: you can get surprisingly high on your own, but you still want someone who knows what they’re doing holding the rope.