Table of contents
Open Table of contents
The disappearing keyboard
I had coffee last month with one of the best engineers I know. He’s the person you call when your architecture is wrong and you need someone to tell you why, kindly but firmly. We were talking about AI tools and he mentioned, almost as an aside, that he writes maybe fifty lines of code a week now.
Fifty lines. A week. This is someone shipping features, fixing bugs, reviewing PRs — everything you’d expect from a senior engineer. And he’s barely touching the keyboard for code.
The rest of the time? He’s in meetings where he draws boxes on a miroboard. He’s writing one-page decision documents(ADRs). He’s reviewing Claude’s output — sometimes accepting, more often redirecting, always with a specificity that comes from fifteen years of having been wrong in interesting ways.
He’s not coasting. He’s leveled up. And the keyboard was the thing holding him back.
What “senior” actually means now
We’ve always had a fuzzy definition of senior engineering. Something about mentorship, system design, owning projects end to end. But let’s be honest — most of our signal for evaluating seniority was “how fast and how well does this person write code?”
That signal is breaking. When Claude can produce a competent implementation of most web features in under a minute, coding speed stops being a differentiator. What differentiates is everything around the coding:
Clarity of thought. Can you describe what needs to exist in terms clear enough that a system with no context can produce the right thing? That’s harder than writing the code yourself. It forces you to confront ambiguities you’d normally resolve on the fly while typing.
Pattern recognition at altitude. Can you look at a generated solution and spot the problem that’s three integration points away? The senior I had coffee with doesn’t read code line by line. He reads structure. He reads coupling. He reads the shape of the thing and knows whether it’ll bend or break.
Decisiveness about trade-offs. Every generated solution makes implicit trade-offs. The senior engineer recognizes those trade-offs and either accepts them or redirects. The junior one accepts whatever Claude produces without questioning the assumptions baked in.
When Claude can produce competent code in under a minute, coding speed stops being a differentiator. Everything around the coding becomes the differentiator.
The tools are the same — the operator isn’t
This is the part that bothers me about the “AI will replace engineers” panic. It assumes all engineers are interchangeable operators of the same tool. They’re not.
Give Claude to a junior engineer and they’ll produce a lot of code that mostly works. Give Claude to a senior engineer and they’ll produce less code that’s precisely right — and more importantly, they’ll produce the decisions that prevent ten wrong implementations from ever being attempted.
The tool is the same. The difference is what the human brings: the taste to know what to ask for, the experience to know what’s missing from the output, and the judgment to know when to throw it away and start over.
What I’m actually doing all day
I’ve been tracking how I spend my time for a while now. Here’s a typical day:
- 7:00–9:00 → Writing specs and decision docs. No code. No editor. Just thinking on paper (or screen).
- 9:00–10:00 → Standup-alt (async check-in), catching up on what the team shipped overnight.
- 10:00–12:00 → Reviewing Claude-generated PRs. This is the heavy cognitive work — every PR needs a decision, and every decision needs a reason I can articulate if asked.
- 13:00–14:00 → Meetings. Design discussions, stakeholder syncs, the occasional architecture review.
- 14:00–16:00 → Working with Claude on net-new features. Describing, iterating, redirecting. This is the closest I get to “coding” but I’m rarely writing actual code — I’m writing descriptions, constraints, and corrections.
The day I wrote thirty lines of actual code was a slow day where Claude was stuck on a tricky state machine and I needed to sketch the structure myself. Even then, those thirty lines were surrounded by a hundred lines Claude filled in around them.
The identity crisis nobody’s talking about
A lot of engineers I talk to are going through a weird phase. They’re shipping more than ever. Their managers are happy. The code works. But they feel like they’re not doing “real engineering” because the typing part — the part that feels like work — has shrunk.
This is an identity problem, not a productivity problem. For years, the sensation of typing was the sensation of progress. Keycaps clicking, lines accumulating, the satisfying scroll of a growing file. Take that away and you feel idle even when your actual output is higher.
I don’t have a clean solution for this. I go through it myself. Some days I close my laptop and think, “did I actually do anything today?” Then I look at the commits, the reviewed PRs, the decision doc I wrote — and yes, I did a lot. It just didn’t feel like it, because feeling productive used to mean feeling busy at the keyboard.
The new feeling is different. It’s quieter. More deliberate. Less frantic. And I’m learning to trust it.
What I’d tell engineers worried about this
The instinct to worry comes from the wrong place. It assumes the keyboard was the skill. It wasn’t. The skill was always the judgment behind the keystrokes — the taste to know what to ask for, the experience to know what’s missing from the output, the nerve to throw a plausible answer away. Those don’t atrophy when you stop typing. They’re the only things that survive.
So if you’re early in your career, learn to code well anyway — not because you’ll code all day forever, but because you can’t direct something you don’t understand. And if you’ve already got the years behind you, the shift isn’t a demotion; it’s the promotion you’ve been training for without noticing. I’ve written separately about what that move from author to orchestrator actually looks like.
The keyboard isn’t the point. It was never the point. It was just the interface we had. Now we have better ones.