The pilots were trying to save the plane up until the last moments. They declared an overspeed condition soon after they ran into trouble, so they were aware of it, but did not intentionally cause it.
And if they were so iced over that control surfaces weren't responding and the wings were no longer generating lift, at that point they were well past the "Anything we do is going to have any effect whatsoever on the future" point.
I don't intend to listen to the audio. Second-hand, it sounds as though they did absolutely everything they could after hitting the cell, and the only way to have avoided this whole situation was "Don't fly that route that day."
... a problem that, in general, we see more often in private-jet and single-engine aviation than commercial-carrier aviation. Far more incentives to make a really, really bad call... And when the bad call happens, the Venn diagram of victims and responsible parties tends to have a lot more overlap, so there's, practically speaking, fewer consequences to discourage such bad decisionmaking in the future (can't meaningfully punish the dead, and the dead can't learn from experience what a bad call "smells" like on the lead-up to it).
I don't agree they had no way to avoid this. Every accident is a chain of mistakes, gaps or mechanical issues. We don't know the whole story here, but I do know that planes of this class are not given up for dead when they hit a surprise weather system. If they are, that means they missed something earlier - weather radar was misinterpreted or a bad judgment call was made.
> Productivity is a measure of economic performance that compares the amount of goods and services produced (output) with the amount of inputs used to produce those goods and services.
The inputs here are money and the labor of the engineer. With this new form of automation, it takes far less of both. So much less in fact, that a previously uneconomical project is now positively cheap.
If your point is that the result isn't worth what it would have cost before, that's true, but it's the increase in productivity that changed the value proposition and allowed the project to be accomplished economically.
I'm being sarcastic as to the specifics but didn't productivity go down 199k because the 200k engineer is now replaceable with a 1k subscription and will soon be fired?
Literally the output of the labor dropped to almost zero value?
The subscription didn’t do any work though. It didn’t magically create a new knowledge worker any more than a lawn mower in a shed cuts grass. The output of the labor massively skyrocketed in value. If you fire that dev, who do you think will use Claude?
This instead is a concern for newer devs. There is now no argument for bringing on the cadre of workers you’d need to do all the hand-jamming, testing, and reviewing, learning how to code in the process.
If you’re the CIO/CTO/etc. obviously you wouldn’t be fired, but any other position is useless down to the dev.
Dev teams should be leaner now, with maybe at most a director as their manager up to executive level.
As for ‘how much software do I really need?’ Well, what sort of company is it? Do you have internal applications to support your orgs? If you seriously need to ask ‘how much software do I need?’ Then you should just fire yourself.
I don’t think your point is meritless, but this is specifically a discussion about that top-10% dev. The one doing this type of work is not the one who will be let go.
I know a lot of people think that the AI tools level the playing-field, but we aren't experiencing that. The guy that did this translation is doing more tickets than the other 4 software devs combined. And it's not because they are low-effort tickets. That's also on top of the 6 hours a week of meetings he has that the other devs don't.
Productivity can be measured in many ways. Neoclassical economists will tell you there’s only one.
In this case, is the change of this software from one language to another/framework to another even valuable?
Example: if I manufacture $1,000 worth of some illegal drug that will potentially turn a normal functioning adult into an addicted criminal, how shall we measure my productivity?
The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep. I think this is a good time to invoke Stein's Law: "If something cannot go on forever, it will stop." These efficiency improvements won't continue forever. It's more likely that the per-call cost of high-quality, compiled software like grep will be a lower-bound that LLMs asymptotically approach, rather than a line that they blow past with perpetual exponential progress. (Barring a true breakthrough in something like quantum computing or room-temperature superconductors.)
You can burn anything* into an ASIC to make it cheaper per-call.
non-backreferencing grep is not very difficult to implement in an ASIC either. But it's probably not worth it because of how relatively rarely you use it and of the data transfer costs.
LLMs are great candidates for ASIC-burning because they're slow compared even to network speeds and run all the time. The issue is that you don't want to burn a specific model or architecture that then becomes obsolete.
So you've got two possible futures, and both guarantee large price drops: (a) LLMs keep getting better and better and better, so ability/$ keeps rising; or (b) LLMs plateau in ability, in which they will start getting ASIC'd.
Grep (or ripgrep at least) is i/o bottlenecked at this point. It's impossible to process data at faster than i/o speeds, since you have to get the data to the processor somehow. That doesn't change whether that processing is grep on a CPU, or LLM on an ASIC.
I did a toy project once implementing a limited version of grep on an FPGA and was able to get some speedup over GNU grep at the time, though marginal.
And a patch panel and a bunch of patch cables that you plug in and out to construct your pipelines.
And eventually hire people whose job it is to patch pipelines on demand for everyone in the office.
“Hey Jim, I’m gonna output the systemd logs of nginx on line five, can you assemble a grep pipeline for me to match all HTTP 500 status codes from /api/cart POST request log lines? Connect the filtered output to Tim’s desk, line 7. He’s there now, we are trying to figure something out.”
I wonder how close you can get with Nvidia's GPUDirect. Hook the fast NVME directly up to the GPU (well, it gets direct DMA to GPU at any rate), then implement parallel grep in CUDA... profit?
GPUs and inference ASICS also have large amounts of high bandwidth memory, plus lots of high speed storage cache, and dedicated very high bandwidth scale-out and scale-up networks. Because they are also often bound by I/O bandwidth.
If your problem is grepping crazy amounts of data, the infrastructure for LLMs isn't a bad place to look for an example.
I wouldn't be surprised if that's what Apple is focused on for their next generation platforms – I wonder if more layers of caching between their SSDs and unified memory are on the cards.
i/o could still be sped up though? And I dunno, maybe this actually is an argument for how the llm version could end up being faster, because there is lots of investment in crazy fast i/o hardware and protocols to get the data into the chips.
It's almost a certainty that LLMs have a "core" that will essentially never become obsolete, possibly even 80% to 90% of their parameters. The rules of English and other languages, core ideas in math and science, all of history, nearly all literature, etc. We don't really understand what's going on inside LLMs enough yet to make good use of this, but one day we will have "core logic" neural networks with stable weights burned into ASIC that are doing the heavy lifting, with more dynamic continually-tuned models manipulating the inputs and outputs into those core models. There are also likely stable expert models on topics that don't change much that we could already do this with.
Inference costs cannot keep falling forever, but they do still have a long way to go.
> LLMs plateau in ability, in which they will start getting ASIC'd.
They don't need to plateu for that to happen. There are companies already building AI on ASIC, and IIRC they were approach 12 months lead time. A 12 months old frontier model (Sonnet 4.5, GPT-5, Kimi K2) for 1% of the price is still a rather good value proposition.
In order for the ASIC to achieve 1% of the price, there'd have to be 99% overhead in GPU implementations which for some reason you'd have to be able to eliminate in ASICs but not in GPUs. That seems rather implausible.
It will be a better value proposition now than it was 12 months ago. It's likely to be better yet in another 12 months. There may be room for a parallel to Moore's Law here.
Right now, I do actually use OpenAI's gpt-oss-safeguard-20b for somethings, was released 11 months ago, and is $0.075/M input / $0.30/M output now. I could see this model being in fairly widespread use at 10x speed and 1/10th cost if it was introduced today. Meaning, that for some usecases (moderation) i think dedicated chips can pan out today.
But for more general models, its tougher. Gemini 3 pro was launched in November, if ASICs brought it down 1/10th in cost, it would be $0.20/$1.2. GPT 6 Luna is $0.1/$0.50. Luna is better at a lot of things, but not everything. So 1/10th doesn't really make the ASICS investment worth it in my opinion, but if it brought it down to 1% ($0.02 / $0.12) it would be a really compelling model with a lot of use.
BUT, do i think something like Luna is probably generally capable of doing a huge amount of knowledge work. So if Luna came out at 1/10th the cost a year from now, it would probably be compelling for a while.
It all depends on the rate of improvement in cost/capability.
To be clear, I agree with the overall premise of the article!
But I would probably take a long horizon bet that the grep implementation on my machine will remain cheaper than an equivalent ai task, even though I think those ai tasks will become far cheaper over time.
I just think the original comment's model of asymptotic approach is probably more likely to be accurate than the model of the line blowing through this grep-like cost level.
This whole story really reminds me of crypto coins. Like.. going from mining one coin, or lets say token, to millions of fractions like 0.00000000001 bitcoin a week.
And the progress humanity made in the last 100 years alone... some things end up to be completely world-changing because they enable things that only were an unfeasible dream before. The invention of the printing press, sanitation, vaccines , computers, the Internet certainly are such enabler technologies.
With AI, the question is still open if this will actually turn out to be something useful or if it will in the end just be another way for the elites to make untold profits.
I probably replied to the wrong comment with my previous response. The low lying fruit, in this case, should be going from single cell to multi cell, but that took ages.
It accelerated from there rather than slowing down.
No, it just gets much more complicated to implement grep both in general, and especially in hardware if you support backreferences, since those make it impossible to compile the regular expression into a state machine.
depends on what you are grepping ... greapping a large file might be more expensive one day than generating n-th token with LLM that works fully in hardware
you could make hardware implementation of grep and store the file itself next to it in some ROM but that's not a very useful grep ... while hardware LLM is exactly as useful as software LLM only orders of magnitude faster
4-5 orders of magnitude is huge. Assuming an order of base 10, it's 10000x-100000x. So a call to grep may return in 1s on a typical PC. That means a GPT call takes equivalent energy of 10000-100000 PCs to do the same in 1s. That's a difference that can't be equalized with scaling. It would require a revolutionary breakthrough.
I also don't understand where the idea that frontier models are getting better efficiency comes from. The results are certainly improving, but that comes from feedback and multiplexing requests, which cost more.
LLM is spicy memoizing, so it can potentially be faster than a tool call. But people will spend a month tweaking and testing to ensure they have the level of determinism they need, which means it's more expensive, and that they should have used actual memoization in the first place.
> The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep.
At some future point where LLM hardware is cheaper than simply running grep, then grep equivalent would benefit from those selfsame hardware improvements and be cheaper to run as well, probably still by the same ratio.
It might never beat out grep, but it could beat some more expensive to call tools, similar to how heuristics will often be faster than exact answers. Rust Analyzer can be slow at times, I could see an AI tool taking over a subset of its work.
It's probably better to optimize rust-analyzer first (and now, this became easier). I mean, see rust-glance: it's not feature complete but it points out to different tradeoffs in this space
Storage access isn’t, though. You have to read every byte of a (non-sorted) file to find words in it. And whether it’s disk or RAM, the bandwidth is usually a key constraint.
That’ll be just as true for an ASIC NN as it is for good ole grep.
When storage bandwidth is a big enough problem, that will get addressed.
NVMe v1 wasn't released until 2011 and there was no hardware available until 2012. Before that the fastest drive interface was 6 Gbps SAS. Then we got 4 GBps (32 Gbps) with NVMe v3, 8 Gbps (64 GBps) with v4, and 16 Gbps (128 Gbps) with v5. V6 is slated to double again. v7 is currently planned to double that. This is less than 15 years of progress.
In the 1990s, we went from 33 Mbps to 66, to 100, then 133 with IDE. We went from the 40 Mbps of 1986's SCSI 1 to 80 of SCSI 2 in 1994. Since then parallel SCSI has gone to 80, 160, 320, 640 (Ultra 2 wide), 1280 (Ultra 3), 2560 (Ultra-320), and 5120 (Ultra-640) Mbps.
SAS has also gotten faster, with 6 Gbps, 12 Gbps, and 22.5 Gbps. NVMe is still lower overhead and lower latency.
Memory bandwidth can also be addressed. Stock servers with EPYC are 16 channel DDR5. That's 409.6 GBps. Four channels of DDR3 was only 102.4 GBps. Video and accelerator card memory bandwidth is also increasing.
But if the problem is literally grep (search this file you've never seen before), no index can pre-exist.
If you assume the file arrives ahead of time, can be indexed, and that this is worthwhile because we want to support multiple pattern matched retrievals, then sure it makes sense to consider indexed query schemes and upper/lower bounds. Each query could be faster as an inference if it doesn't have to re-scan the whole file.
But I don't think anybody, in good faith, can pretend that any LLM can digest a file faster than grep can. Particularly, if you admit the vector processing dedicated to doing the convolution kernel(s), you should also admit similar hardware could run a vectorized grep.
The LLM doesn't have an index of every single file I might want to grep, though. In practice it has an index of very few of them, and perhaps even none of them.
A few years is hardly forever and the state of the world here indicates a lot of low hanging fruit still exists.
An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte in what can be a relatively complex state machine for a regex based grep. There are other scales to consider like the scale of your local hardware vs the highly multitenant and high end hardware of the hyper scale inference providers.
There are already high volume models for coding inference where the reasoning time is crazy low and cheap per token where it can build reasonably simple software so blindingly fast it isn’t implausible the bottleneck is the latency in tools and networks. I find them hard to use at times because I don’t have time to think through the next turn by the time it’s done.
Regardless I wouldn’t be surprised to see a world where tokens are so cheap it’s not worth metering them but charging licensing feels with meter tiers at the far horizons to prevent abuse, charge outliers. Subscription models already set this stage well.
The other side to consider is bountiful capacity will also drive tokens to near zero price. The data center build out is barely underway and as it materializes, as hardware efficiencies improve, as techniques and model science and technology improves, harnesses, methodologies , etc improve, the economics flip from load shedding to trying to keep the data centers utilized. The economics lead to the world where tokens are not a unit of measurement for cost for anyone other than the inference providers to manage their utilization.
> An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte
You mean a grep over terabytes of data vs a LLM with gigabytes of parameters?
If you have so much data, you can use an index to search. It's unlikely that LLMs are going to be cheaper than properly indexed search DBs (which is what we should be comparing them with)
Gigabytes loaded into GPU memory being processed by custom silicon designed for the task that’s exactly the same on every inference? Even now parameters physically baked into the silicon for super low latency? Yes.
The point of a grep is for adhoc analysis of data that isn’t in a database. At best you could use an inverted index, which is extremely expensive to create and maintain, but if you don’t know a priori what you’re going to search for, or even if an inverted index helps with your query, it’s pointless and expensive to index literally everything you could ever use to save some time on a tool call.
The point isn’t to find a way to make searching more efficient. It’s that LLMs are becoming very efficient, and a measure is relative to grep. Making grep and searching more efficient has been a task in CS for decades. LLMs is relatively new beyond a very small crowd. It’s also not a goal to make LLMs better at grep than grep, but as a relative reference point that inference is getting cheap and fast and has opportunity to get faster far beyond grep simply due to unclaimed optimizations more available for the newer technology.
From a computational standpoint this is obviously nonsense, but from an attentional one I'm not so sure. It may already be more attentionally expensive to use grep in some cases, such the moment you need to remember a non standard arg. And if this applies for performing a simple http operations, then it certainly applies going up the complexity chain.
What if the tool is more advanced, like an optimizing compiler: `g++ -O3 -march=native -x c++ - <If the compiler invocation is sufficiently slow, the llm could consider outputting a binary directly?
For all we know matrix multiplications are a faster way to generate optimized machine code than branchy sequential compiler code with tons of heuristics and passes.
room-temperature superconductors, sure, but I fail to see how quantum computing will disrupt – in the medium term (25 years or so) – classical computing in any meaningful way
Is running LLMs (or some other ML workload) on/with quantum computers expected to bring efficiency gains?
There is no reason to assume that quantum computers would benefit LLMs in particular. Perhaps we could implement LLMs as analog circuits to save energy.
I think it's an interesting thought experiment: could an LLM call be a "cheaper" grep?
Especially for deterministic activities it just feels impossible to imagine general LLM tech handling the problem better, despite everything being said.
But hey, tech is filled with "smashing the generalist hammer works better than the specialized tooling". Would be odd though!
One thing that's easy to miss about performance is that it depends on framing.
An example I like to give: optimizing a data processing program's runtime by 5x is obviously 5x speedup for everyone. But if, for some reason[0], this means it crashes and restarts more often, it stops looking like this to end users. If every restart means it needs to start from scratch, and it restarts 10 times on average now where it didn't restart before, the 5x speedup suddenly looks like 2x slowdown to end user.
In this sense, LLMs are already much more efficient than most CLI tools, by a combination of:
- User not having to remember the exact invocation, or even the name of the CLI tools
- LLM being able to run the CLI tools and chain them on its own
- LLM being able to self-correct in case it got things wrong, or when actual output show that user's idea was right, but the instructions were wrong
Prompting "okay, list those processes sorted by runtime and match them against these output files" is both faster to type than the actual commands, it also end-to-end completes much faster than doing it by hand.
--
[0] - And I don't mean a bug. Say it's some batch processing run on a cluster with aggressive resource usage management; 5x speedup means it runs much hotter than before, which may put it on the top of "kill list" for when the cluster managing code needs to free up some resources.
Yes, Meta has consistently acted with integrity and has earned the benefit of the doubt in situations like these. It's safer to assume that the massive PR team working for this one-woman play in Spain has manufactured the whole thing, including the damning quotes, which the Guardian has somehow published without properly verifying.
The guy you’re responding to is acknowledging FB’s crap practices and is suggesting a PR team may be using that to their advantage for guerrilla marketing. Not an insane suggestion, actually savvy and common in our modern rage landscape.
Could this be mitigated by allowing voters to vote multiple times and receive multiple confirmations, but only count the last vote for each person? That way an individual could prove that they voted a certain way to a third party, but there would be no way for the third party to know whether it was their final vote. Meanwhile the individual knows that they spoiled their previous vote or votes and that their final vote is included.
You’d have the same issue as you’d need to be able to verify that your last vote was being counted, for displaying your vote back to you to have any value.
A scheme to be able to show coercive parties fake votes would be known to them immediately.
This wouldn't solve anything. The person doing the coercion would be able to store the hash and double check after the election if the vote was still the way they wanted.
I would expect to see LLMs that are creative in math before any that are creative in writing. Creativity is more easily specified in math and the solutions can be formally verified. There's no good way to classify creative writing. Many truly great works are overlooked by experts and the public until decades later. Many derivative works are commercially successful.
LLMs, both in writing and mathematics seem to only be capable of coming up with texts that are inside the distribution of the training data.
With writing it's just more obvious. LLMs don't write with personality. They don't create new and exciting worlds on their own. Everything they output feels derivative.
In mathematics you see the same effect. They are very good at finding results that humans missed, taking advantage of their broad knowledge and tireless work ethic.
But just as they have been unable to create new literary worlds, they also have so far been unable to create new mathematics.
I believe this lack of creativity is intrinsic to how these models are architected and trained. We want models that produce these in-distribution outputs because those types of models are more economically valuable. Nobody wants a coding agent with spontaneity, we want models that predictably and obediently solve problems - and that's what we got.
Man the cope on HN is something else. Neighbour, 99.9(9)% of professional mathematicians don't go around creating new mathematics. The goalposts have been moved so far that we're now at "AI isn't Grothendieck yet".
Not to mention it is all subjective taste. There is nothing objective beyond consensus that a "great" work of creative writing is "great" no matter how great a consensus thinks it is.
reply