Yeah, that struck me too. Measuring wealth by spending disguises inequality because higher earners have less reason to spend more, and the difference in freedom to choose not to spend more is a large part of the inequality.
There are interesting aspects to the data, but they overstate what the numbers they present tell us about inequality.
It also ignores a similar phenomenon among the poor. Decreased self-supply.
In a rich country this might mean paying for childcare so you can work. Your expenditure has gone up, but you are only better off by the increased post tax income less the cost of childcare. Even worse is paid childcare has substituted for family provided (e.g. grandparents) childcare.
In a poor country it might mean buying food instead of growing it. An industrial worker will buy their food, a subsistence farmer will grow their own. There is a huge increase in expenditure, but they might well end up with a worse diet.
This is not new. The initial workforce for the industrialisation of Britain (the first country to industrialise) was available because of the enclosure of common land forced people to seek work in cities.
The point is that the unspent income has significant value.
I earn a multiple of the UK median. Above a lower multiple of the median, the primary increased value I got out of earning more was the freedom to stop thinking about what an increasing subset of things cost. I still need to think about what my housing cost, but I don't know what most groceries cost, because it doesn't matter to me.
The mental cost of detail budgeting, planning, and saving for most smaller costs, as well as the associated anxiety, is something I never want to pay again.
My actual spending thus tells a flawed story about the advantage I have over someone earning less.
Power. Why do you think people who already have huge amounts of money want more? Money is a way of acquiring power.
That is why billionaires typically give money away by putting it in foundations they control (so they keep the power) rather than just giving it to poor people (which would be more effective as people could spend it on what they most need).
power is one aspect but i think it is valid for billionaires to have power.
buying goods is the other aspect and the poor and the rich more or less consume similarly.
i do want to live in the world where money doesn't dictate _consumption_ as much as power. money has to mean something, and its good that it goes into power more than consumption. that means the poor can have a dignified life to buy what they want but they don't get to dictate how money will be allocated.
Marx said that concentration of wealth can be a good thing as rich people can invest their money in capital heavy things, such as factories, whereas poor people tend not to do that.
Despite the common image, Marx was a huge fan of capitalism. He thought it was a huge step forward, and not least that capitalism was an absolute necessity to bring production to a level where he believed socialism would become possible... He just also thought it had flaws that he believed would eventually make it obsolete.
Probably a lot easier, but the moon looses a major selling point of data centres in space, namely reasonable latency. To be clear, I don't think it's a good idea. But I think that specifically the way Musk is trying to position it, the moon would be an even harder sell.
The ISS has giant heat sinks[1]. Those heat sinks are necessary for just the modest heat generated on the ISS, and should give an idea of what a sattelite full of GPU's might require...
For agent, read sub-agent. E.g. the contents of your .claude/agents directory. When Claude Code spins up an agent, it provides the sub-agent with a prompt that combines the agents prompt and information composed by Claude from the outer context based on what Claude thinks needs to be communicated to the agent. Claude Code can either continue, with the sub-agent running in the background, or wait until it is complete. In either case, by default, Claude Code effectively gets to "check in" on messages from the sub-agent without seeing the whole thing (e.g. tool call results etc.), so only a small proportion of what the agent does will make it into the main agents context.
So if you want to do this, the current workaround is basically to have a sub-agent carry out tasks you don't want to pollute the main context.
I have lots of workflows that gets farmed out to sub-agents that then write reports to disk, and produce a summary to the main agent, who will then selectively read parts of the report instead of having to process the full source material or even the whole report.
OK, so you are essentially using sub-agents as summarizing tools of the main agent, something you could implement by specialized tools that wrap independent LLM calls with the prompts of your sub-agents.
That is effectively how sub-agents are implemented at least conceptually, and yes, if you build your own coding agent, you can trivially implement sub-agents by having your coding agent recursively spawn itself.
Claude Code and others have some extras, such as the ability for the main agent to put them in the background, spawn them in parallel, and use tool calls to check on the status of them (so basic job control), but "poor mans sub-agents" only requires the ability for the coding agent to run an executable the equivalent of e.g. "claude --print <someprompt" (the --print option is real, and enables headless use; in practise you'd also want --stream-json, set allowed tools, and specify a conversation id so you can resume the sub-agents conversation).
And calling it all "summarising" understates it. It is delegation, and a large part of the value of delegation in a software system is abstraction and information hiding. The party that does the delegation does not need to care about all of the inner detail of the delegated task.
The value is not the summary. The value is the work done that the summary describes without unnecessary detail.
A bit of caution: it's perfectly able to look up and read the slash-command, so while it may be true it technically can't "invoke" a slash-command via TaskTool, it most certainly can execute all of the steps in it if the slash-command is somewhere you grant it read access, and will tend to try to do so if you tell it to invoke a slash command.
Agents add a docs index in context for skills, so this is an issue of finding that the current specific implementation of skills in Claude Code is suboptimal.
Their reasoning about it is also flawed. E.g. "No decision point. With AGENTS.md, there's no moment where the agent must decide "should I look this up?" The information is already present." - but this is exactly the case for skills too. The difference is just where in the context the information is, and how it is structured.
Having looked at their article, ironically I think the reason it works is that they likely force more information into context by giving the agent less information to work with:
Instead of having a description, which might convince the agent a given skill isn't relevant, their index is basically a list of vague filenames, forcing the agent to make a guess, and potentialy reading the wrong thing.
This is basically exactly what skills were added to avoid. But it will break if the description isn't precise enough. And it's perfectly possible that current tooling isn't aggressive enough about pruning detail that might tempt the agent to ignore relevant files.
The current tooling isn't aggressive enough in that it's not the first thing that the agent checks for when it is prompted, at least for claude code. Way more often than not, i remind the agent that the skill exists before it does anything. It's very rare that it will pick a skill unprompted. Which to me kind of defeats the purpose of skills, I mean if I have to tell the thing to go look somewhere, I'll just make any old document folder in any format and tell it to look there.
I agree, but this is at least partly down to how well the descriptions are composed, because that is pretty much the only difference between a skill and what Vercel does. It might well be there's a need for changes to surrounding prompting from the tools as well, of course.
Exactly, many people seem to not understand that frontmatter’s description field needs to be longer „when?” Instead of shorter „what” - this is the only entry-point into the skill.
Agreed. I think being overly formal about what can be in the frontmatter would be a mistake, but the beauty of doing this with an LLM is that you can pretty much emulate skills in any agent by telling it to start by reading the frontmatter of each skills file and use that to decide when to read the rest, so given that as a fallback, it's hardly imposing some massive burden to standardise it a bit.
The description "just" needs to be excruciatingly precise about when to use the skill, because the frontmatter is all the model will see in context.
But on the other hand, in Claude Code, at least, the skill "foo" is accessible as /foo, as the generalisation of the old commands/ directory, so I tend to favour being explicit that way.
I mean, the entire name of Mechanical Turk plays on "packaging up humans as technology", given the original Mechanical Turk was a "machine" where the human inside did the work.
reply