1,466 karma · joined September 25, 2017
Most people commenting here know that all models are false but some make good predictions, and achieving that status is enough for most laypeople to classify it as a (potential) answer.
Going further, yes, this is a new theory among others, but afaik is the first one with strong evidence.
If AI is really wrecking the job market structurally due to new efficiencies, one would hope those effects will be permanent (i.e we won't need juniors anymore because AI will fill those spaces permanently, with or without human intervention; and thats not going to change because AI is only going to get better, blabla, yada, yada).
If it is not, it would be a matter of eventually reaching AI winter status and/or just finding a new thing to hype and the tech job market will open its gates again.
Of course there is some nuance to it, both things can happen at the same time with different intensities.
Enough HN for today.
Software engineering for any non-trivial problem means a baseline level of essential complexity that isn't going away, no matter the tool, not even if we someday "code" directly from our minds in some almost-free way via parallel programming thought diffusion. That's because (1) depth and breadth of choice; and (2) coordination/socials, mostly due but not uniquely related to (1) are the real bottlenecks.
Sure, accidental complexity can shrink, if you design in a way that's aligned with the tools, but even then, the gains are often overhyped. These kinds of "developer accelerators" (IDEs, low-code platforms, etc.) are always oversold in depth and scope, LLMs included.
The promise of the "10x engineer" is always there, but the reality is more mundane. For example, IDEs and LSPs are helpful, but not really transformative. Up to a point that people are being payed right now and don't use them at all, and they still deliver in a "economically justifiable" (by someone) way.
Today it's LLMs. Tomorrow it'll be LISP Machines v2.
Just classic hype.
Hackers need just one chain of tired persons to breach a system. Sometimes length(chain) = 1, that's when bad things happen.
Anecdotal PS: I used to work at a bank and had to rotate my password monthly (sometimes even more, because there were unfederated systems that required another password, also with rotation). Eventually all my passwords became [short STRING] + [autoincremental INT]. We had MFA, so it didn't matter that much, but that makes it even more hilarious.
That's not what the paper proposes (i.e. it commits errors => thinking is an illusion). It in fact looks at the failures modes and then it argues that due to HOW they fail and in which contexts/conditions, that their thinking may be "illusory" (not that the word illusory matters that much, papers of this calibre always strive for interesting sounding titles). Hell, they even gave the exact algo to the LRM, it probably can't get more enabling than that.
Humans are lossy thinkers and error-prone biological "machines", but an educated+aligned+incentivized one shouldn't have problems following complex instructions/algos (not in a no-errors way, but rather, in a self-correcting way); we thought that LRMs did that too, but the paper shows how they even start using less "thinking" tokens after a complexity threshold and that's terribly worrisome, akin to someone getting frustrated and stopping thinking after a problem gets too difficult which goes contrary to the idea that these machines can run laboratories by themselves. It is not the last nail in the coffin because more evidence is needed as always, but when taken into account with other papers, it points towards the limitations of LLMs/LRMs and how those limitations may not be solvable with more compute/tokens, but rather exploring new paradigms (long due in my opinion, the industry usually forces a paradigm as panacea during hype cicles in the name of hypergrowth/sales).
In short the argument you say the paper and posters ITT make is very different from what they are actually saying, so beware of the logical leap you are making.
> There is this armchair philosophical idea, that a human can simulate any turning machine and thus our reasoning is "maxomally general", and anything that can't do this is not general intelligence. But this is the complete opposite of reality. In our world, anything we know that can perfectly simulate a turning machine is not general intelligence, and vice versa.
That's typical goalpoast moving and happens in both ways when talking about "general intelligence" as you say, since the dawn of AI and the first neural networks. I'm not following why this is relevant for the discussion though.
Sure, humans may fail doing a 20 digit multiplication problems but I don't think that's relevant. Most aligned, educated and well incentivized humans (such as the ones building and handling labs) will follow complex and probably ill-defined instructions correctly and predictably, instructions harder to follow and interpret than an exact Towers of Hanoi solving algorithm. Don't misinterpret me, human errors do happen in those contexts because, well, we're talking about humans, but not as catastrophically as the errors committed by LRMs in this paper.
I'm kind of tired of people comparing humans to machines in such simple and dishonest ways. Such thoughts pollute the AI field.
*In this case for some of the problems the LRMs were given an exact algorithm to follow, and they didn't. I wouldn't keep my hopes up for an LRM handling a full physical laboratory/factory.
As far as we can tell without messing with complex experiental concepts like qualia and the possibility of philosophical zombies, language mainly helps higher order animals communicate with other animals and (maybe) keep a train of thought, though there are records of people that say that they don't. And now also it allows humans talk to LLMs.
But I digress, I would say this is an open academic debate. Suggesting that there is always language deep down is speculation.
In that case BigQuery is more managed than both, PAYG for analytical queries without thinking about compute nor clusters whatsoever.
Come on dude, tech we can discuss a lot and there is no totally correct objective response. Irresponsible financials are an entirely different beast. A proportionally big data team in a non-data focused / non-tech company is a low-key red flag, and that's what I'm referring to (i.e. >10% of headcount). CFOs don't (and should not talk) in relatives, like "us vs them".
> Fwiw, I use Kafka regardless of scale. It's the only mainstream system out there that doesn't encourage throwing away your receipts. It's the programming equivalent of "accountants don't use erasers".
About Kafka, as far as I've experienced it and also read about, it is mostly safe if you are paying for managed solutions like Confluent or heavily investing on infra for covering for ordering and other issues. But Kafka is as good a technology as it is recognizedly messy, up to a point where I've seen people loving it and then hating it months-years down the line.
I would stick with batch processing if I don't care for receipts. You need to take care for them? Cool, then take charge but if not then don't tackle complexity your business don't/won't need. That's the point, even big banks have survived without taking care about the receipts.
This article and vocal supporters are not being reasonable at all, they make a not so between-the-lines separation between skeptics (which are nuts) and supporters ("My smartest friends are blowing it off." in a smug "I'm smarter than my smarter friends").
I mean, come on.
These kinds of articles that heavily support LLM usage in programming seem to FOMO you or at least suggest that "you are using it wrong" in a weak way just to invalidate contrary or conservative opinions out of the discussion. These are pure rhetorics with such an empty discourse.
I use these tools everyday and every hour in strange loops (between at least Cursor, ChatGPT and now Gemini) because I do see some value in them, even if only to simulate a peer or rubber duck to discuss ideas with. They are extremely useful to me due to my ADHD and because they actually support me through my executive disfunction and analysis paralysis even if they produce shitty code.
Yet I'm still an AI skeptic because I've seen enough failure modes in my daily usage. I do not know how to feel when faced with these ideas because I feel out of the false dichotomy (pay for them, use them every day, but won't think them as valuable as the average AI bro). What's funny is that I'm yet to see an article that actually shows LLMs strengths and weaknesses in a serious manner and with actual examples. If you are going to defend a position, do it seriously ffs.
Wouldn't be surprised if 5 years down the line we see DuckDBaaS execs offering fully paid trips to DuckDBForce or smth like that.
Yes, there must be some use cases where you need all the data loaded up and addressable seamlessly across a cluster, but those are rare and typically FAANG-class problems.
Well, obviously, navigating complexity in the middle of a tech cycle is hard, and after the storm, anyone can claim to be a captain. I'd say the best we can do is stay conscious of the pattern (and how it affects you and others), engage in architectural discussions with critical thinking (especially around incentives and epistemology, as a concrete example, cloud certifications and consultants are often brought up to muddle this up in infra context), and bring technical humility and empathy into the room. Also, if possible, try to help younger engineers recognize these dynamics earlier.
It's a genuinely hard problem. And sometimes, there isn't much more to do than to engage honestly, because your own perspective can be just as biased or context-blind as anyone else's.
> It's still cool to reflect on all these longstanding general SE tradeoffs and truisms.
Yep, totally. Philosophy is always fun, even when the only universal truth is that the truth is elusive.
The whole overengineering problem does have a yin/yang quality to it, especially around themes like designing "for the future or for scale" (generalization) vs YAGNI/"premature optimization is the root of all evil", and engineering is, after all, largely about calibration. But it's not just abstract philosophy. There are plenty of concrete signals and they tend to appear in cycles, which suggests the industry collectively relearns how to navigate complexity over time: the rise of DuckDB and Iceberg over Spark or Hive, the cycle of people embracing MongoDB then returning to PostgreSQL, and even companies moving workloads off the cloud and back to colocated metal after complexity hit them hard, both in direct costs and in hidden ones like engineering headcount. These aren't just trends, they’re signs that overengineering is a concrete problem with real-world, objective consequences, and not merely a matter of opinion.
That being said, I'd just add (and perhaps the article fails to acknowledge this, maybe contributing to the perceived tone of superiority) that no one is completely safe from falling into these traps. We're more human than engineer, after all. It's easy to slip into complexity, for all sorts of reasons: ego, incentives, time pressure, misguided intellectual curiosity, or simply chasing what's familiar, even when familiar isn't the right fit for the context.
In my context, one funny pattern always shows up. I think of it as a data-related 'rite of passage': junior data engineers and data scientists often dismiss SQL as an old language, assuming it can be easily replaced by something shinier. But over time, they hit a wall: they can't match the speed, performance, or clarity of more experienced peers. Eventually, they come back to SQL and recognize its strengths (especially when paired with an imperative language for tasks like ML, plotting, or report generation). I was that junior once too, stubbornly trying to do everything in Python, only to learn the hard way that joins in pandas are not only slower but also far more painful to write than in good old SQL. It turns out that writing code which outperforms a mature SQL engine is extremely difficult, and realizing that takes a bit of humility and experience (which younger engineers usually haven't developed yet, and honestly, it's not expected from them either).