“AI Skills” are worthless in 2026

wonderful irony that you linked to an article no one can read without paying. a billing screen is the future of everything.

i think this is true, i have coworkers spending $20k+ a month in AI. I do wonder what will happen when the price of tokens normalise to a break even point

“AI skills” in this post means the skills of humans who use AI. I had initially thought it meant skills for AI agents, the Markdown-based format for reusable prompts.

I’ve been unwell lately (well, I have a physical ailment that’s progressively worsened over nine years or so), so I’ve done a lot more programming in the pre-AI era than the post-AI era. So maybe that’s why the idea of “AI” only skills is lost on me. From my perspective, it’s all systems engineering as I’ve had to figure out tooling for MCP servers, automating ad hoc skills development, configuring context engineering, and much more than I can describe with any meaningful technical depth in this comment. I am not sure where people are getting the “it’s only chats” impression. That’s for consumers of AI services. If you’re developing AI services, or doing research, then you’re doing a lot more than chats. The prompts part of prompt engineering is a “chat”, but you’re not going to get anything useful or productive if you haven’t done the legwork to set things up before you get chatting. The setting things up part is the software/systems engineering part that’s still the same. I am not evangelizing here, so I don’t care if you’re not convinced. I am okay because I know what’s working for me and what doesn’t.

I’d never seen or heard of that Stephen Bradbury ice skating Olympic race. Brilliant!

My “plain language” skill is the last bulky skill that should be folded into the model. Models are terrible communicators and would improve amazingly with better communication skills. Every other skill is very specific to my work, which is how this should be. Skills should generally be pretty light weight.

There's so many different types of developer jobs. The thesis statement here is probably true for lots of them.

One type I've had where it's less true is doing exploratory greenfield product engineering in an early stage startup. You can automate or optimise some simple and time consuming business processes with a well-considered integration to a frontier model API. This has been the case long enough that the people with a few years of experience with it have a meaningful advantage in terms of job performance over someone who doesn't. You develop an intuition for which problems are and aren't tractable to that kind of solution, which models and effort levels to try, how to formulate prompts, the likely quality level of the results and so on. Often the "AI skill" is combining that experience with an awareness of what the business is doing and spotting the next automatable thing. Smaller startups always have more work than anyone can possibly do, so rather than putting anyone out of a job you're generally just giving someone more time for other things.

Some (but by no means all) employers are already beginning to filter for this kind of thing when hiring. It's a niche, but everyone's in one niche or another. Been a couple years since I've been in that niche BTW and I'm finding I miss it, my CV and email's in my bio if someone needs a (remote EU) full-stack JS kind of person like that.

I think there's a bit of nuance lost in this one. It may look like "Anyway, remember prompt engineering?" is truly a funny dig now... but that's not the whole story. You can still prompt engineer for good results and you need to learn more about how to do it. It's closer to good search skills from before Google became useless.

For example: what do you expect to give you better results? "Does this app have bugs?" or "In context of this app, what approaches would an experienced software engineer use to validate it works correctly? Make a list ordered by effectiveness-vs-cost and spawn subagents to check the trivial ones. Make a plan for review to run the remaining checks. Check the project history for areas which needed most bug fixing work." The second one requires almost no familiarity with software engineering - and a similar prompt can be derived for other industries.

But it takes some experience to realise this is possible and how to push the boundaries yourself. We needed the basics of prompt engineering and now we can take it to the next level. It never went away.

When I was first learning the C programming language, in my early 20s, it was common knowledge that of the two ways to increment a variable, i++ was slower than ++i. The post-increment function returned the original value of i, which meant stashing a copy of that value before performing the increment. Pre-increment avoided this wasteful operation.

And by “common knowledge” I really mean folklore, because I turned 20 in 1995 and even by then, the most basic of optimising compilers knew to check if you ever used the return value of i++, and if not, skip the operation to save it.

The folklore survives in C++, I think, at least for class-type iterators. With built-in integers and raw pointers the two forms compile to the same thing when the result is discarded. A user-defined postfix operator++(int) has to copy the old value and return it by value, though, while the prefix one increments in place and returns a reference. For trivial iterators like std::vector<T>::iterator an optimizer will usually erase the copy, and with optimization on you probably won't measure much, as this revisit of an old benchmark found. Debug builds are another story, which is why static analyzers like PVS-Studio still flag it++ where the result is unused. ++it costs nothing to type, so it stays my default.