I agree that prompting is a much shallower skill than engineering, and I really hate the term “prompt engineering” since I feel it puts something that (by design) is easy to learn on the same level as something relatively hard to learn.
There is admittedly a bit of skill to use these tools, but they’re really not hard to use. For the most part Claude can decipher my typo’d-to-hell prompt and figure out what I want, and even if it gets it wrong the first time I can usually correct it. The hardest part is determining some objective test for Claude Code to test against and “anchor” it, but I still think that’s easier than writing a bunch of unit and integration tests.
I like these tools; I think Claude Code is very useful and even if I didn’t like it I would still use it because it’s clear that’s where the world is headed and I want to stay competitive.
For personal projects I actually care about, I still write code by hand. I do think I write better code than Claude but I would still do it by hand even if I didn’t, just because I realized I was losing my intuition about software because I was outsourcing to Claude for everything.
There are plenty of things that I am honestly fine losing my intuition with. I don’t really derive much enjoyment from reading dmesg logs, and I am more than happy to let a robot have its fun with that, but it can take the mathey shit from my cold dead hands now.
The skill isn't "prompting", it is figuring out what to do, validating that it works the way you want, and thinking about how to best support future iterations of things you might want to do.
Which, not coincidentally, is pretty much the same description as what the job was already about.