Table of contents
Open Table of contents
The lie we tell ourselves
For years I believed my job was writing code. I’d open the editor, stare at the screen, and feel productive when the lines piled up. More lines = more progress. Right?
Wrong. Nobody has ever paid me for keystrokes. They pay me because a customer clicks a button and something useful happens. The code is just the middleman — and a pretty expensive middleman at that.
The real job was always three things: understand the problem, design the solution, make sure it actually works. Typing was just the part that happened to take the most time. Until it didn’t anymore.
Claude didn’t change my job — it revealed it
A few months ago I started using Claude seriously. Not for toy prompts. For actual work. I’d describe a feature, constraints, edge cases, and it would spit out a working implementation in seconds.
The first time this happened I felt uncomfortable. It felt like cheating. Then I realized something: the thinking I did before the prompt — that was the job. Clarifying the spec, spotting the edge cases, knowing which patterns to ask for — none of that was typing. All of it was engineering.
Claude didn’t take my job. It just stripped away the part that was never the job to begin with. What was left — the thinking part — got sharper because I had to articulate it more precisely.
The uncomfortable truth about “coding skills”
We’ve built entire career ladders around syntax fluency. Interview processes that test whether you can invert a binary tree from memory. Seniority tracks measured in lines of code. Conferences full of talks about clean code and design patterns and the latest framework.
All of that is about to be rewired. Not because coding is dead — because the bar moved. If a tool can produce correct, idiomatic code from a decent spec in seconds, then the coding part of your job is now the cheapest part. The thinking, deciding, and verifying — that’s the expensive stuff.
The engineers who struggle with this shift are the ones who tied their identity to typing speed. The ones who thrive are the ones who always knew the typing was just a delivery mechanism.
The thinking I did before the prompt — clarifying the spec, spotting the edge cases, knowing which patterns to ask for — that was always the real engineering.
What actually matters now
So if writing code isn’t the job, what is?
Problem definition. The ability to take a vague business ask — “we need better search” — and turn it into something precise enough that a machine (or a junior dev, or you-next-week) can execute on it without thirty clarifying questions.
System judgment. Knowing that a solution is wrong not because it doesn’t work, but because it doesn’t fit. It introduces the wrong coupling. It ignores a constraint that wasn’t in the spec because the spec assumed human common sense.
Verification at speed. When code appears in seconds instead of hours, the bottleneck moves to review. Can you validate output as fast as it’s produced? This is a muscle, and most of us have never had to build it — enough that I gave it its own post.
Taste. AI produces plausible solutions endlessly. Knowing which plausible thing is correct — for your users, your system, your constraints — that’s human work. And the supply of good taste has always been low.
The practical shift
Here’s what this actually looks like day to day. I still open my editor. I still read code. I still make commits. But the ratio has flipped.
Before: 80% typing, 20% thinking. Now: 20% typing (or less), 80% thinking, reviewing, iterating on the spec.
I spend more time in conversation — with Claude, with colleagues, with myself in a notes file — clarifying what needs to exist. By the time code appears, it’s mostly a formality. The real work happened before a single line was written.
This isn’t a downgrade. It’s what senior engineers always did — they just didn’t have a way to skip the typing part. Now we do.
Why this scares people
I get why this makes people nervous. If “writing code” isn’t the job, what do you put on your resume? How do you prove you’re productive? What do you point to at the end of the day?
These are identity questions, not engineering questions. And identity shifts are hard. But they’re also inevitable. The tools aren’t going backwards. The typing part gets cheaper every quarter. Fighting it is like fighting autocomplete — technically possible, strategically pointless.
The engineers I respect most have already made the shift. They don’t talk about how many lines they wrote today. They talk about what they shipped, what they decided, what they caught in review. Same conversation we always should have been having.
What to do tomorrow
If any of this resonates, here’s the simplest thing to try: for your next task, don’t touch the keyboard until you can describe exactly what success looks like in plain English. Not pseudocode. Not technical design. Just “here’s the problem, here’s the outcome, here’s the constraint.”
If you can’t articulate that, you don’t understand the task well enough to code it — with or without AI. If you can, hand that description to Claude or whatever tool you’re using and see what comes back. The gap between what you described and what you got? That’s where the real engineering lives.
Writing code was never the job. It just took up enough of the time that we confused it for one. Strip the typing away and what’s left is the job it always was — which is exactly the shift from author to orchestrator my whole AI Engineering practice is built on.