Sounds like every AI KPI I've seen. They are all just "use solution more" and none actually measure any outcome remotely meaningful or beneficial to what the business is ostensibly doing or producing.
It's part of the reason that I view much of this AI push as an effort to brute force lowering of expectations, followed by a lowering of wages, followed by a lowering of employment numbers, and ultimately the mass-scale industrialization of digital products, software included.
> Sounds like every AI KPI I've seen. They are all just "use solution more" and none actually measure any outcome remotely meaningful or beneficial to what the business is ostensibly doing or producing.
This makes more sense if you take a longer term view. A new way of doing things quite often leads to an initial reduction in output, because people are still learning how to best do things. If your only KPI is short-term output, you give up before you get the benefits. If your focus is on making sure your organization learns to use a possibly/likely productivity improving tool, putting a KPI on usage is not a bad way to go.
We have had so many productivity improving tools/methods over the years, but I have never once seen any of them pushed on engineers from above the way AI usage has been.
I use AI frequently, but this has me convinced that the hype far exceeds reality more than anything else.
> organization learns to use a possibly/likely productivity improving tool
But that's precisely the problem with not backing it with actual measures of meaningful outcomes. The "use more" KPIs have no way of actually discerning whether or not it has increased productivity or if the immediate gains are worth possible new risks (outages).
You don't need to run cover for a csuite class that has become both itself myopic and incredibly transparent about what they really care about (cost cutting, removing dependencies on workers who might talk back, etc.)
Ethics are all well and good but I would prefer to have quantified limits for water quality with strict enforcement and heavy penalties for violations.
Of course. But while the lawmakers hash out the details it's good to have companies that err on the safe side rather than the "get rich quick" side.
Formal restrains and regulations are obviously the correct mechanism, but no world is perfect, so whether we like it or not ourselves and the companies we work for are ultimately responsible for the decisions we make and the harms we cause.
De-emphasizing ethics does little more than give large companies cover to do bad things (often with already great impunity and power) while the law struggles to catch up. I honestly don't see the point in suggesting ethics is somehow not important. It doesn't make any sense to me (more directed at gp than parent here)
Is it ethical for a water company to shutoff water to a poor immigrant family because of non-payment? Depending on the AI's political and DEI-bend, you're going to get totally different answers. Having people judge an AI's response is also going to be influenced by the evaluator's personal bias.
I note in the UK that it is illegal for water companies to cut off anyone for non-payment, even if they're an Undesirable. This is because humans require water.
How useful/effective would a business AI be if it always plays by that view?
Humans require food, I can't pay, DoorDash AI should provide a steak and lobster dinner for me regardless of payment.
Take it even further: the so-called Right to Compute Act in Montana supports "the notion of a fundamental right to own and make use of technological tools, including computational resources". Is Amazon's customer service AI ethically (and even legally) bound to give Montana residents unlimited EC2 compute?
A system of ethics has to draw a line somewhere when it comes to making a decision that "hurts" someone, because nothing is infinite.
Asan aside, what recourse do water companies in the UK have for non-payment? Is it just a convoluted civil lawsuit/debt process? That seems so ripe for abuse.
Civil recovery, yes. It's not like you don't know where the customer lives.
Doesn't seem to be a problem for the water companies, which are weird regulated monopolies that really ought to be taken back under taxpayer control. Scottish Water is nationalized and paid through the council tax bill.
Or whatever's cheapest for your local food supply. Every time I've done this game with supermarket produce, it comes under £1/day to support someone's nutritional requirements, currency tells you where I played that game.
McD is pretty expensive these days, I've seen cheaper even in the caregory of fast food.
I'd love to see a return to the idea of government cheese, or at least align food stamps with WIC (WIC in US is a specific food aid program restricted to ostensibly healthier foods), instead of allowing the ridiculous moral hazard and waste posed by regular foodstamps.
Right, authoritarian oligarchy is much closer to what certain parties desire here in the States. Is unfortunate that the prospective oligarchs chose technology as their vehicle (of both oligarchy and authority, via surveillance, of course), and it's even more unfortunate that we let them do so.
This. The thesis statement is so confused and I cannot tell if it's deliberate clickbait or the author legitimately is that confused about the distinction between program-level language features and program structure and systems design and how they are two closely related but really distinct things.
> Here is the central claim: the unit of correctness in production is not the program. It is the set of deployments.
The thesis essentially boils down to: functional programing paradigm, type systems, strong interfaces, etc, are all fantastic tools for ensuring the correctness of a program, but the system is not a program, and so these tools are necessary but not sufficient to ensure the correctness of a distributed application.
I am a technical writer. This article is not good technical writing.
Good technical writing allows you to get to and understand the point in a minimum of time, has a clear and obvious structure, and organizes concepts in such a way that their key relationships are readily apparent. In my opinion this article achieves none of these things (and it also is just bad insofar as its thesis is confused and misleading in a very basic way—namely the relationship between functional programming philosophy and distributed systems design is far more aligned than it suggests, and it sets up a false dichotomy of FP versus systems, when really the dichotomy is just one of different levels of design (one could write the exact same slop article about what OOP "gets wrong" about systems—it gets it "wrong" because low level programming paradigms techniques are in fact about structuring programs, not systems, and system design is largely up to designers—the thesis is basically "why don't these pragmatic program-leave techniques help me design systems at scale" or in other words "why don't all these hammering techniques help me design a house?")
I would only loosely categorize this as technical writing, depending on how you categorize technical writing. It seems much more a survey of problems and discussion piece, with notes about projects making inroads on the problem. It's definitely not a "this is how you solve this problem, and these are the clear steps to do so" type of article. Maybe that's some of the disconnect in how we view it. If I was hoping that this communicated a clear procedure or how to accomplish something, I would be disappointed. I don't think that was their intention.
I came away with some additional understanding of the problem, and thinking there are various nascent techniques to address this problem, none of them entirely sufficient, but that it's being worked on from multiple directions. I'm not sure the article was aiming for more than that.
I'm a highly literate reader and writer of technical topics, and there are a lot of bad technical writers who think they aren't. Except perhaps for the title, which is way too narrow, the article is excellent writing about a technical topic (which is quite different from technical writing)--but then I actually read it, so I know that he doesn't talk about a dichotomy between FP and systems, but rather between single programs and systems, and he explicitly says that his points aren't restricted to FP, but that because FP addresses the single program issues so well, FP programmers are particularly prone to missing the problem.
What? Distributed systems 101 is to write workers that execute stateless, pure, functions and to manage state centrally (basically monads in yet another guise, fan in/fan outs) and to use functional operations to merge and transform data (map reduce).
There are a lot of reasons people don't succeed in systems thinking or in writing good distributed architectures, but functional programming is not one of them. If anything it's an inability to think functionally and to leak state and establish brittle dependencies absolutely everywhere that scuppers systems. Yes, FP has ton's of techniques that aid in good design at lower levels too, that doesn't mean it hampers you at high levels. In fact, much of what this article puts forward is a false dichotomy. None of the lower level FP principles and techniques like strong and expressive types systems are in conflict with the much more general principles of system design covered in the article (and they actually help you realize these principles—think version skew is bad in Haskell? good luck figuring out wtf is even happening in a tangled javascript async promises monstrosity undergoing version skew)
Also, slop, gross. At least edit some of that empty AI verbiage out of the final essay. It has the character and charm of a wet rag and adds zero information.
Probabilities are a philosophical rat's nest of sorts. When it comes to statistics, it's generally agreed that we're working with a frequentist interpretation of the meaning of probabilities, but you are right that a person with no prior background could well have a completely different understanding here (subjectivist probability, degrees of belief).
I also think stating presuppositions and limitations around observation and prior knowledge is monumentally important as soon as you begin talking in terms of probabilities, if you really want your statements to be clear, but most people don't do this. There are some ways in which I think the casual use of probabilities can actually be more harmful than encouraging a simple binary boolean dichotomy of "I know" or "I don't know" and need more information.
Isn't "I know" just a subjective threshold for the probability of being true? A layman may put that probability at 90%, while I scientist may put the probability at 99.999% before saying, "I know".
But the absence of papers is precisely the problem and why all this LLM stuff has become a new religion in the tech sphere.
Either you have faith and every post like this fills you with fervor and pious excitement for the latest miracles performed by machine gods.
Or you are a nonbeliever and each of these posts is yet another false miracle you can chalk up to baseless enthusiasm.
Without proper empirical method, we simply do not know.
What's even funnier about it is that large-scale empirical testing is actually necessary in the first place to verify that a stochastic processes is even doing what you want (at least on average). But the tech community has become such a brainless atmosphere totally absorbed by anecdata and marketing hype that no one simply seems to care anymore. It's quite literally devolved into the religious ceremony of performing the rain dance (use AI) because we said so.
One thing the papers help provide is basic understanding and consistent terminology, even when the models change. You may not find value in them but I assure you that the actual building of models and product improvements around them is highly dependent on the continual production of scientific research in machine learning, including experiments around applications of llms. The literature covers many prompting techniques well, and in a scientific fashion, and many of these have been adopted directly in products (chain of thought, to name one big example—part of the reason people integrate it is not because of some "fingers crossed guys, worked on my query" but because researchers have produced actual statistically significant results on benchmarks using the technique) To be a bit harsh, I find your very dismissal of the literature here in favor of hype-drenched blog posts soaked in ridiculous language and fantastical incantations to be precisely symptomatic of the brain rot the LLM craze has produced in the technical community.
I do find value in papers. I have a series of posts where I dig into papers that I find noteworthy and try to translate them into more easily understood terms. I wish more people would do that - it frustrates me that paper authors themselves only occasionally post accompanying commentary that helps explain the paper outside of the confines of academic writing. https://simonwillison.net/tags/paper-review/
One challenge we have here is that there are a lot of people who are desperate for evidence that LLMs are a waste of time, and they will leap on any paper that supports that narrative. This leads to a slightly perverse incentive where publishing papers that are critical of AI is a great way to get a whole lot of attention on that paper.
In that way academic papers and blogging aren't as distinct as you might hope!
In my opinion the relationship between level of detailed care and resulting beauty is proportional. Can you get the same level without getting your hands dirty? Sure, maybe, but I doubt a painter or novelist could really produce beautiful work without being intimately familiar with that work. The distance that heavy use of AI tools creates between you and the output does not really lend itself to beauty. Could you do it, sure, but at that point it's probably more efficient to just do things yourself and have complete intimate control.
To me, you sound more utilitarian. The philosophy you are presenting is a kind of Ikea philosophy. Utility, mass production, and unique beauty are generally properties that do not cohere together, and there's a reason for this. I think the use of LLMs in the production of digital goods is very close to the use of automation lines in the production of physical goods. No matter how you try some of the human charm, and thus beauty will inevitably be lost, the number of goods will increase, but they'll all be barely differentiable souless replications of more or less the same shallow ideas repeated as infinitum.
I agree, LLMs definitely sand off a lot of personality, and you can see it in writing the most, at this point I'm sure tons of people are subconsciously trained to lower the trust for something where they recognize typical patterns.
With the code, especially interfaces, the results will be similar -- more standardized palettes, predictable things.
To be fair, the converging factor is going on pretty much forever, e.g. radio/TV led to the lots of local accents disappearing, our world is heavily globalized.
It's part of the reason that I view much of this AI push as an effort to brute force lowering of expectations, followed by a lowering of wages, followed by a lowering of employment numbers, and ultimately the mass-scale industrialization of digital products, software included.
reply