Skill Issue
Explore the paradox of modern programming where writing instructions and curating skills overshadow the joy of solving problems firsthand.
I opened a work repo last week and counted the markdown before I found the code.
CLAUDE.md. AGENTS.md. A .cursor/rules/ directory with eleven files. A skills/ folder with a SKILL.md for the deploy, a SKILL.md for the tests, a SKILL.md describing how to write the other skills.
The Go was in there somewhere. Eventually.
This is the job now. You don't write the thing. You write the instructions for writing the thing, you review the thing, and then you write more markdown explaining why the thing came out wrong so it comes out less wrong next time.
We invented prose programming. It compiles to a diff and a vague sense of disappointment.
For fifty years we built languages to get away from English. English is ambiguous. You say "handle the edge case" and nothing happens, because nothing has ever seen your edge case.
So we built types. We built a language that fails in your face when you're wrong, on purpose — because being told you're wrong immediately is the whole gift of the work.
Now we write "please handle the edge case" in a bulleted list. With a heading. And we call it engineering.
Here's the trade the workday actually made.
Before: you held the problem in your head and the language did exactly what you said. Intention, keystroke, feedback, now. When it broke it broke where you could see it, and the fixing was the part you liked.
After: you describe the problem imprecisely in a file. You pay for the imprecision once when the machine guesses, and again when you read three hundred lines of plausible code hunting for where the guess went sideways. The hard part didn't leave. It moved from your hands to your eyes, and someone called it leverage.
Reading is not making. A man who reviews furniture catalogs all day does not have a workshop.
And the skills. So many skills.
One skill becomes a skills directory becomes a skills framework becomes a meeting about skill governance becomes a senior engineer whose whole week is curating prose for a statistical text generator. We used to call this writing documentation, and we admitted we hated it. Now it's on the roadmap.
Let the machine write the third identical CRUD handler. Let it write the YAML. That work was never the point and I won't miss it.
But somewhere we started handing off the good part too — the part that was the reason anyone got into this. And here's the thing nobody says out loud: some work is valuable because you do it, not because of what comes out the other end. Nobody sends an intern to the gym and gets stronger. The sitting-with-the-problem until it yields — that was the job. That was the part that felt like anything at all.
Delegate it and you keep the repo and throw away the reason you wanted the repo.
So when you find yourself opening a new file to write careful English explaining to a machine how to do the one part of your job you still enjoy — stop. Close the markdown. Write the code.
That was the whole thing. Don't outsource the whole thing.
Skill issue, indeed. Just not the model's.