> Wrong. They will use the model that gives them an edge. If they are using a PhD but their competitors are using Einstein, they will lose.
For some tasks that matters. But for a lot of tasks, "good enough but cheaper" will win out.
I'm sure there will be a market for whichever company has the best model, but just like most companies don't hire many PhD's, most companies won't feel a need for the highest end models either, above a certain level.
E.g. with the release of Sonnet 4.6, I switched a lot of my processes from Opus to Sonnet, because Sonnet 4.6 is good enough, and it means I can do more for less.
But I'm also experimenting with Kimi, Qwen, Deepseek, and others for a number of tasks, including fine-grained switching and interleaving. E.g. have a cheap but dumb model filter data or take over when a sub-task is simple enough, in order to have the smart model do less, for example.
Models will get smarter and cheaper. For those that are burned directly into silicon, there will be a market for old models - as the alternative is to dump that silicon in a landfill.
For models that run on general-purpose AI hardware, I don't know why the vendors would waste that resource on old models.
All of these IDs in the EEA are based on a common set of EU requirements, and in theory that means multiple providers, but in practice in many countries the set of providers is small and with feature gaps. E.g. Norway has several providers, but they provide different levels of security and features, which means in practice most people rely on BankID...
10-20 is fantastic in comparison. Even if people don't have more than one it at least reduces the blast radius..
Did you test actually having command line tools that give you the same interface as the MCP's? Because that is what generally what people are recommending as the alternative. Not letting the agent grapple with <random tool> that is returning poorly structured data.
If you option is to have a "compileSQL" MCP tool, and a "compileSQL" CLI tool, that that both return the same data as JSON, the agent will know how to e.g. chain jq, head, grep to extract a subset from the latter in one step, but will need multiple steps with the MCP tool.
The effect compounds. E.g. let's say you have a "generateQuery" tool vs CLI. In the CLI case, you might get it piping the output from one through assorted operations and then straight into the other. I'm sure the agents will eventually support creating pipelines of MCP tools as well, but you can get those benefits today if you have the agents write CLI's instead of bothering with MCP servers.
I've for that matter had to replace MCP servers with scripts that Claude one-shot because the MCP servers lacked functionality... It's much more flexible.
The issue with German as well as Norwegian is that a space creates a semantically distinct structure, so it's not that they remove the space, but that one wasn't there in the first place, and some of those compounds then become important enough for the dictionary.
Absolutely not all - there's a near unbounded set of possible compounds.
In Norwegian, we in fact have a compound for the incorrect separation of compounds: "orddelingsfeil" (word separation error). Actually, we have two - technically it's "særskrivingsfeil" (separate writing error), but "orddelingsfeil" is more common... We take this seriously.
The problem is that while some are definitely wrong, others change meaning.
E.g. "en norsk lærer" means "a Norwegian teacher" but "en norsklærer" means "a teacher of the subject Norwegian". There's an infinite set of possible -lærer compounds: If you create a new subject then a teacher of that subject is a <subject>lærer. Obviously they can't all go in the dictionary.
Some other examples:
"Røyk fritt" means "smoke freely" while "røykfritt" means "smokefree". "Steke ovn", means "to fry an oven", while "stekeovn" means "oven". These two belong in the dictionary because they are so common and that though technically you can use "ovn" and "fri"/"fritt" to form a near infinite number of other common forms as well, in practice the number of common forms that use them is quite limited.
The key part is that most compounds in languages like German or Norwegian will only have one valid way of writing them. Add spaces, and you usually end up with something ungrammatical or with an entirely different meaning.
Whereas in English whether or not a word can be written with a space, with a hyphen, or combined much more often changes over time, and can differ in different places at different times, as the <separate words> -> <hyphenated> -> <compound> pipeline in English is slow and arbitrary and not necessarily reflecting a change in meaning.
I'd argue that boiled water very specifically refers to the water left ofter after boiling water, not steam. Steam is no longer water, at least not in common parlance.
Boiled water does have the extra connotation that it is presumed to be mostly sterile, which, while not hard to derive from the fact it has been boiling, is not immediately clear. After all the past tense does not tell us how recently it was boiled.
For that reason I'd argue that if one of boiling water and boiled water should be in the dictionary, it should be boiled water. Of the two, it is the term that potentially carries extra information.
If people assume it's "just a type of sausage" it suggests a dictionary entry is needed to explain otherwise.
It's a term referring to a small set of types of sausages served in a specific small set of ways. In some places, a hot dog can be used as a synonym for the predominant type of sausage most common in hot dogs in that place, but the term is still more commonly referring to the assembly of a wiener or frankfurter wrapped in a bread of some sort.
> the term is still more commonly referring to the assembly of a wiener or frankfurter wrapped in a bread of some sort
I had that disagreement in an alpine resort once. A seller was vending some sort of sausage stuffed in a bread, i was hungry so I walked up to them with money in hand and said "A hot dog please" while pointing at the only thing they were selling. The lady was mortified by my utterance, and was not willing to accept the money until I agreed with her that it is a bratwurst and not a hot dog. :D The disagreement felt a bit academical, but given that she was holding the hot dogs hostage and money does not taste that good she won the argument.
Personally think a bratwurst is borderline, in that it is "close enough" that I can see someone calling a bratwurst in a bread a hot dog, and I wouldn't react if a shop listed them as a type of hot dog on a menu.
But, yeah, some places "hot dog" also carries a connotation of potentially using lower quality sausages, so I can also totally see a bratwurst vendor taking offense...
In Norwegian, we have "isvann" - ice water - which can both mean water implied to be cold enough to feel like it has recently melted, or specifically water with ice in it.
If you're asking for isvann at a restaurant, you'd expect to get water with ice, not just very cold water.
But if you're talking about having gone bathing in isvann one spring, it specifically means in water that - whether or not there is actually ice in it - is cold enough that it might have recently melted.
(I'm a native speaker, but had to look up the precise nuance there to be sure I wasn't just making stuff up)
Norwegian is almost as compound-happy as German, and we could've filled many volumes with compounds. But what generally happens for one of the compunds to enter the dictionary is that the compound needs to have a meaning that is non-obvious from the individual parts, at least to some people, and typically that the compound has a non-obvious meaning if interpreted as two separate words.
E.g. "akterutseilt" is an example. "Akterut" means behind, aft. "Seilt" means sailed. "Behind sailed" helps as a way to remember it, but it's not obvious whether it's strictly a sailing term, or means that you've been left behind or have left someone else behind.
In this case if you say someone has been akterutseilt, it means they've been metaphorically left behind, often by their own failure to keep up.
Those kinds of compounds deserve dictionary entries whether they are actually written in two words or one, because they function as a single unit however it is written.
I think black hole is a perfect example in English. And in fact, this is a compound that is written in two words in Norwegian as well, but is in Norwegian dictionaries despite that[1] as "svart hull".
Fun fact: I looked this up in the online version of the Duden (the predominant German dictionary). It does have an entry "Black Hole" (so the English term!) but not for "schwarzes Loch", which is the normal German term for it.
(In the printed versions, you might need to go to the Universalwörterbuch or so to find the English entry, it might not be in the normal "Die deutsche Rechtschreibung"; I have not checked.)
I wrote "predominant", not "official". And I think that is still true.
Also, from what I can tell using the site, it does not serve as a full dictionary. Rather, it lists the general rules of German orthography (as decided by the Rechtschreibrat) and has some limited tables of special words.
Great example — I added svart hull to the article as an illustration of a language that writes it as two words but still puts it in the dictionary because the meaning isn't obvious from the parts. That's exactly the instinct English lacks.
Worse it better for you when it meets your needs better.
I use a lot of my own software. Most of it is strictly worse both in terms of features and bugs than more intentional, planned projects. The reason I do it is because each of those tools solve my specific pain points in ways that makes my life better.
A concrete example: I have a personal dashboard. It was written by Claude in its entirety. I've skimmed the code, but no more than that. I don't review individual changes. It works for me. It pulls in my calendar, my fitbit data, my TODO list, various custom reminders to work around my tendency to procrastinate, it surfaces data from my coding agents, it provides a nice interface for me to browse various documentation I keep to hand, and a lot more.
I could write a "proper" dashboard system with cleanly pluggable modules. If I were to write it manually I probably would because I'd want something I could easily dip in and out of working on. But when I've started doing stuff like that in the past I quickly put it aside because it cost more effort than I got out of it. The benefit it provides is low enough that even a team effort would be difficult to make pay off.
Now that equation has fundamentally changed. If there's something I don't like, I tell Claude, and a few minutes - or more - later, I reload the dashboard and 90% of the time it's improved.
I have no illusions that code is generic enough to be usable for others, and that's fine, because the cost of maintaining it in my time is so low that I have no need to share that burden with others.
I think this will change how a lot of software is written. A "dashboard toolkit" for example would still have value to my "project". But for my agent to pull in and use to put together my dashboard faster.
A lot of "finished products" will be a lot less valuable because it'll become easier to get exactly what you want by having your agent assemble what is out there, and write what isn't out there from scratch.
It is a way of sharing and improving software already today. Not a major way, yet, but I don't agree with you it would be a bad thing for that to become more common, in as much as - to go back to my dashboard example - sharing a skill that contains some of the lessons learned, and packages small parts would seem far more flexible and viable as a path for me to help make it easier for others to do the same, than packaging up something in a way that'd give the expectation that it was something finished.
But also, note that skills can carry scripts with them, so they are definitely also more than a my_feature.md.
> There was surprisingly little repercussion for violating the "one card one person" door policy
Presumably because "everyone" knows that "noone" complies with those policies, in part because it's socially awkward to e.g. close the door on someone who tries to tailgate, and so it needs to be heavily and consistently enforced before it becomes more socially unacceptable to be the person who potentially puts their colleagues at risk of disciplinary actions than to be the person who tells someone they need to swipe.
For some tasks that matters. But for a lot of tasks, "good enough but cheaper" will win out.
I'm sure there will be a market for whichever company has the best model, but just like most companies don't hire many PhD's, most companies won't feel a need for the highest end models either, above a certain level.
E.g. with the release of Sonnet 4.6, I switched a lot of my processes from Opus to Sonnet, because Sonnet 4.6 is good enough, and it means I can do more for less.
But I'm also experimenting with Kimi, Qwen, Deepseek, and others for a number of tasks, including fine-grained switching and interleaving. E.g. have a cheap but dumb model filter data or take over when a sub-task is simple enough, in order to have the smart model do less, for example.
reply