> "The idea that inflation and the money supply are linked is one of the most dumb one in folk economics"
"folk economics" implies it is by untrained people.
Milton Friedman's famous quote of "inflation is always and everywhere a monetary phenomenon" shows that he deeply believed the relationship between inflation and money supply, and one certainly cannot call Friedman a "folk economist" considering he won the Nobel prize in economics and was a professor at the University of Chicago.
Note: I am not saying he is right or supporting his belief. I am merely stating that such a belief is not a "folk economics" belief. This belief is still very prevalent in the freshwater schools of economics. [1]
As a personal anecdote, at Ronald Coase's 100th birthday party, I personally got Gary Becker and Richard Posner debating a very related topic (whether and by what degree the velocity of money of fluctuates and whether helicopter drops of cash would have been better during the early days of the money supply collapse in 2008/2009 than just giving money to the banks). In a room full of Nobel Prize winning economists in 2010, there was a very rigorous debate on the topic.
> "folk economics" implies it is by untrained people.
The problem is mostly its appropriation by untrained people though.
> Milton Friedman's famous quote of "inflation is always and everywhere a monetary phenomenon" shows that he deeply believed the relationship between inflation and money supply
Creationists theoreticians believe in creationism too. The problem arise when their theory reach the mainstream… (Influential people inside the Swedish Central bank making a fake Nobel prize to promote these ideas didn't help of course…)
Lagged processes are one of the most fundamental concepts in economics. If merely recognizing the possibility that one could be at play here is throwing you for a loop, you need the simplified monetary model more than most.
Where's the hell is the lag on these graphs though!? The money supply grows both before, and after the inflationary spike. (And the fact that it stops increasing when inflation is high is not surprising at all, by the way, high inflation make the central bank raise interest rates, which reduce credit, which is where money comes from).
This is pretty much true for all high level competition in the US.
It’s extremely hard to get good at chess. It’s extremely hard to get good at math. It’s extremely hard to get good at gymnastics. It’s extremely hard to get good at Piano.
Meanwhile, in China or Russia, there are dedicated schools for mass producing concert, pianist, etc.
That assumes Tokens will remain a meaningful expense. I’m not sure developers will find uses for ever more tokens nearly as quickly as the prices fall.
How are we so confident that prices will fall? Isn't the exact opposite happening, right now, during arguably the most critical part of this whole saga (pre-IPO to make things appear as beautiful and as not-obviously-illegal as possible)? And the only reason they were "falling" previously was for hyper growth.
The Growth aspect mentioned is that VCs are subsidizing the bill right now, so it is hard to know if at the current moment the demand curve would promote as much usage without it, but assuming demand remained constant (not even growing), you could expect token prices to be competed down. It is a commodity without a moat.
Now that we have pretty decent open source models, anyone can create a new business to supply more tokens. Sure there’s short term scarcity: energy, GPUs, cooling, but this is a scale up problem. More token demand = more data center build = more energy plant build. This downward pressure will also keep frontier private model prices in check.
Differentiation seems to be happening at the harness level, whereby we can expect token spend to be a metric to compete on and drive down for the customer (at least hoping tools in the application space don’t continue token based billing as their primary revenue stream).
These are not short term hyper growth forces, but a fundamental alignment of incentives.
Pricing on SToA models probably won’t fall, there’s no reason for the frontier labs to lower their prices.
But we’re seeing lots of open weight models that are either pretty close to SToA, or more importantly, perfectly capable of doing all the low level token insensitive grunt work when writing code. Pairing them with SToA models for long horizon task management, and you’ve got a very cost effective system.
The frontier labs have put little effort into cost efficient inference, they don’t need to, but folks like DeepSeek clearly are, and have achieved some impressive cost improvements. Given DeepSeeks models give you 70% of the capabilities for 30% of the cost, expect people to start moving lots of workloads to providers that provide cheap inference for open models, and huge competition to appear to provide that cheap inference. It’s truly commodity LLM inference.
In turn expect more companies to focus on building inferences efficient models, because someone that can build a model that provides 70% of SToA capabilities for 10% of the token cost, immediately eats up huge amounts of the available inference market.
Another factor in all this, is it’s becoming increasingly clear that building custom agents/workflows for LLM to operate in, is required to get the best out of these models. That means people are implicitly building the infra needed to use multiple model types and evaluate workflow performance end-to-end. Which in turn means they have everything they need to plugin in future, cheaper, inference providers and quickly evaluate if they can change their model provider.
it is falling if you look elsewhere, deepseek made their 75% discount on their V4 models permanent, on one hand there's LLM improvements that make inference cheaper (e.i. MoE, hybrid attention), on the other hand we're getting more inference focused chips that break the nvidia monopoly.
i don't think a lot of people know this, but a cluster of GPUs can serve multiple clients without much of a drop in performance, e.i. worst case scenario you band together with 6-16 people to run a 2-3 H100 server to host deepseek V4 Flash or 4-6 to run Pro, and you're getting the same performance as if you ran it alone, this means a lot of companies can afford throwing 50-100k into their own LLM server cluster.
We're at a price point where if you push it further people will move, there's no real vendor lock in, your agent config, skills, MCP servers etc are all reusable with other models and harnesses, so unless you get all providers to collude on a price hike, you risk an exodus of customers
In the one direction the hardware continues to improve, new buildouts continue to come online, and methods for improving the parameter efficiency of models continue to be discovered.
In the other direction models continue to grow larger, new customers continue to arrive, and existing customers continue to find ever more creative ways to burn large quantities of tokens as the prices fall.
I doubt anyone can say with certainty where the equilibrium will be 1 or 5 years from now largely because (among many other things) it's impossible to predict how much of the current economy AI will end up eating. In general though the third party providers of open weights models are probably the most reliable data source available since they have little to no incentive to subsidize usage.
Prices have fallen dramatically over the last few years. It’s just that our standards have increased because we are using AI in ways that were not possible with worse models. But for the same level of “intelligence” as we had a couple years ago, the prices are so much lower.
I would easily pay a lot of money to have access to AI for my job. I actually do pay. If the cost was significant I'd just add it to hourly rate that I consider acceptable. Company always pays in the end, because company is the only entity with money in this setup.
That depends entirely on how they and I are using tools available. There must be a sweet spot. Best person at finding that sweet spot wins on price. I'd be up for that.
I do quite a lot of what this post describes in a reasonably large project. Here's what works for me:
- write gherkin features for new features; update them for enhancements; don't touch them for refactors. Label your PRs with these nouns.
- use pre-push hooks for type checks, linting, unit tests, and other quick, scriptable validations.
- make a viteperess subsite in your repo, have the agents maintain it - document important principles, architecture, etc.
- make a cli command which lists all pages along with the yaml frontmatter description so agents can choose what to read without blowing up the context window.
- use ddd and monorepo - write your logic in headless layers, and compose layers into apps. agents navigate layers very successfully.
- use zod (or your language equivalent) and contract-first API development; this is my favourite bit tbh, I use orpc
- make a single skill called "code" which describes the lifecycle: open a worktree, setup .env to guarantee no conflict with other agents (choose unused ports etc - docker is good here), write or update feature file (this is where you negotiate the spec), implement, validate (e.g. using playwright mcp), pre-push checks, push and wait for review, tear down and fast forward main
- testcontainers is great for ensuring multiple agents can run tests that don't conflict
Seriously I only have one skill that's it. Everything else is in the docs. I'm feeling very productive like this, in a "making good software" sense not a LoC sense.
I agree with many of the points made by nimonian above (esp the one starting with 'make a single skill called "code" which describes the lifecycle'), based on my limited experience with these things.
That's a big ask. This kind of harness usually contains plenty of proprietary insights about their business. And also, nowadays, a good harness is a major competitive advantage.
Your hostile tone is unfortunate, especially since my post was actually friendly. I was just trying to point why it is very likely the OP won't give you what you're asking so you're not left confused if he ends up ghosting you.
Many people use the term harness to refer to the agent coding software (eg. Opencode, Claude Code...), i use this term more broadly to refer to the environment (set of skills, system prompts, constraints, memory, hooks etc...). What the OP is referring to is not just one giant skill. It's usually a comprehensive ecosystem of skills, bespoke tools to make certain agent tasks deterministic (eg localization), and so on.
I've seen someone post Github repos in this thread, these can be very useful especially if you use the same tech stack, but you won't reach the level of productivity reported by successful teams unless you invest substantial time to build your own harness. But the way to do so is to do it progressively : start with something simple to address the need you have on day 1 . And then, turn recurring prompts into skills, turn recurring coding patterns and coding style recommendations into guidelines, turn repetivive tasks for which the LLM tends to build a python script that it occasionally gets wrong into a deterministic tool documented in a skill etc...
And after a couple of days, weeks, and months, you'll have a very dependable harness giving you optimal productivity, without needing to invest weeks of work upfront or take the fun out of agent-assisted coding.
I have an example of a side-project [1] where I think I naturally applied the best practices described in this article. My goal was to see if it's possible to code an entire project using a single agent (Claude).
To do this, I "simply" asked the agent, every time it encountered an issue, how to resolve it, using a validation tool or script. I also asked it to code these tools during audits. As a result, I now have over 30+ rules [2] for validating their commits. It's working pretty well now.
Instead of reading articles like this one end to end, I ask AI to read them in detail and prepare a new harness for me. The important part is not to do this in a single prompt, but to first create a detailed plan and let the model think deeply about each aspect. This approach lets me build the new harness without the missing didactic information you mentioned.
Basically, I am moving from “I build products without writing or reading the code” to “I build products without writing or reading the harness.”
Once the new implementation harness is prepared, I start it, but I keep the original session open. In that original session, “we” monitor the implementation harness from the outside: how effective it is, where the bottlenecks are, what breaks down, and what could be improved. From time to time, the monitoring session suggests changes to the implementation harness. We apply those changes, restart the harness, and monitor it again.
The overall approach is not to spend X hours understanding an article like this in detail, because another similar article will appear in 3 weeks. Instead, I take immediate action, learn on the fly, and replace the harness when a better pattern emerges. And yes, I still have to spend X hours on setting up, monitoring and fine tuning the new harness, but at the end I have the latest fancy "thing" working for me.
A lot to these blogposts are trying to catch on the next buzzword "harness". It's almost close to the productivity porn mindset that we witnessed 10-15 years ago where creating the complicated system is more exciting than using the system for daily tasks.
I agree. I followed this article for a repo I'm working on, and I had a very hard time inferring how, specifically, they implemented "providers" and enforced import layers. A sample repo would've been nice.
Not if you’re claiming that the spells, once cast, automatically get exponentially spellier until they awaken into a spell god, capable of literally anything, including casting more complicated spells than any wizard is capable of. If that were true, you’d have no need for wizards. The fact that wizards are still around means it’s probably bullshit.
So in your opinion AIsnd LLMs aren’t improving? They can’t do it today, therefore they never will?
Certainly has never been times in the recent past when people have confidently predicted computers could never do something that computers were then able to do shortly after the prediction was made.
What really happens is the spells only have other spells to draw from and they begin to degenerate over time, eventually turning into chaotic eldritch horrors that randomly add limbs to people or adamantly refuse to discuss goblins or just shriek in gibbering madness. Our Evil Overlord sacrifices the dreams of children to keep the magic sustained and controlled, and soon the people can't even think or speak without the help of magic. And they think they're wizards even though they can't even read a grimoire.
My family has a harpsichord, so I've learned a fair amount about it, though I'm not the one who plays it.
Harpsichords went out of tune easily and quickly, so they had to be tuned at least as often as every performance.
The way I look at it, a musical scale is a technology. Often, a particular technology is chosen because it solves multiple problems with acceptable compromises. A problem for the harpsichord is that the musician has to tune it themselves, often quickly, to make it sound good enough for a performance.
Organs are and were tuned all the time. While he didn't have a piano, the organ was tempered in some way.
His well tempered clavier was a plea to give him organs that could play in any key. We don't know what temperament he used (there is plenty of debate), but it is clear he was trying to show how the key in his system changes the sound/mood of the piece - something lost in equal temperament.
By "tuning was what it was" I did not mean that JS Bach's organs were out of tune with themselves. But rather the obvious thing that pipe organs can't be retuned to arbitrary temperaments in a practical manner.
And to be clear, Well Tempered Clavier is generally believed to have been written for harpsichord not organ. There is not more evidence that it was a plea than that it was simply JS Bach writing experimental music for the latest technology.
Granted tuning an organ is an all day (or even multi-day) problem, but it is perfectly possible to change temperament. Tuning a piano to change temperament will take a skilled tuner some time as well.
harpsichord - I knew that, but couldn't think of the right instrument...
reply