“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.
the ways of working with models that get us to a useful result faster, if they work, are going to be folded back into the product, packaged, and become the default experience a few months later
This is a huge societal problem and I have no clue how to even approach it.
Good journalism costs a lot of money. Journalistic outfits need a source of revenue, and the only way to get that without a conflict of interest is to make your readers pay for articles. But there are lots of funding options if you're willing to do the bidding of billionaires, politicians and industry. As a result, good journalism is inaccessible, while propaganda floods the market.
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
I do wonder what will happen when the price of tokens normalise to a break even point
Given the developments over the past few years and the trends they imply, I’d say what will happen is a reduction in price for the same output quality. But I’m still unsure what that implies for the spending ability of people like your coworkers.
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.
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.
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.
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.
roryokane | 8 hours ago
“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.
kornel | 8 hours ago
ah! I was confused about it.
Clear writing skills still matter.
valpackett | 7 hours ago
Feel free to flag as unhelpful etc. but it seems like the default experience a few months from today will be a billing screen saying you're out of tokens.
lilac | 7 hours ago
wonderful irony that you linked to an article no one can read without paying. a billing screen is the future of everything.
mort | 26 minutes ago
This is a huge societal problem and I have no clue how to even approach it.
Good journalism costs a lot of money. Journalistic outfits need a source of revenue, and the only way to get that without a conflict of interest is to make your readers pay for articles. But there are lots of funding options if you're willing to do the bidding of billionaires, politicians and industry. As a result, good journalism is inaccessible, while propaganda floods the market.
skerritt | 4 hours ago
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
tauonmsdz | 2 hours ago
Given the developments over the past few years and the trends they imply, I’d say what will happen is a reduction in price for the same output quality. But I’m still unsure what that implies for the spending ability of people like your coworkers.
nishnash | 8 hours ago
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.
raoulmillais | 8 hours ago
I’d never seen or heard of that Stephen Bradbury ice skating Olympic race. Brilliant!
henrycatalinismith | 4 hours ago
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.
viraptor | 2 hours ago
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.
markerz | 6 hours ago
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.
Hasnep | 2 hours ago
The article is about the skill of a human using an LLM, not the markdown files called skills.
hongminhee | 2 hours ago
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 likestd::vector<T>::iteratoran 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 flagit++where the result is unused.++itcosts nothing to type, so it stays my default.