We are hitting a wall trying to force transformers to do actual logic [D]
Our take
The frustration articulated in this piece isn’t just about technical limitations—it’s a growing unease about the trajectory of AI development itself. The author’s exasperation with relying on “refined system prompts” to force LLMs into logical reasoning mirrors a broader industry trend of treating probabilistic models as if they can mimic deterministic systems. This approach ignores a fundamental truth: LLMs are not designed for exact math or structured logic. They are next-token predictors, not calculators. The author’s point about “burning millions on compute” to brute-force logic out of architectures that “can’t do exact math reliably” is a wake-up call. It’s not just about efficiency; it’s about recognizing that scaling alone won’t solve a problem rooted in architectural mismatch. Is LeCun’s $1B seed round the signal that autoregressive LLMs have actually hit a wall for formal reasoning? This article echoes the same sentiment, framing the seed funding as a possible acknowledgment that the current path may be unsustainable. If even visionaries like LeCun are betting against the status quo, it’s worth asking whether we’re clinging to outdated paradigms.
The core issue here isn’t just about LLMs failing at logic—it’s about a misalignment between user expectations and technological reality. Users want tools that can handle complex, multi-step tasks with precision, but LLMs operate on statistical patterns, not rules. The reliance on “chain of thought” hacks or RAG (Retrieval-Augmented Generation) is akin to building a house on sand: it might hold for a while, but it’s inherently unstable. The author’s metaphor of “building increasingly expensive dictionaries” is particularly apt. These workarounds are not solutions; they’re temporary fixes that mask the lack of a true reasoning engine. This has real consequences for productivity and trust. If stakeholders believe that simply training bigger models will solve everything, they’ll overlook the fact that these systems lack the ability to verify correctness or handle edge cases. The result is a cycle of frustration, where teams pour resources into incremental improvements while the underlying architecture remains flawed.
This isn’t just a technical problem—it’s a cultural one. The industry’s obsession with scaling and prompt engineering reflects a desire to fit square pegs into round holes. Energy-Based Models (EBMs), as discussed in the Milken Conference panel, offer a different approach by embedding constraints directly into the model’s design. Unlike LLMs, EBMs can encode logical rules, making them better suited for tasks requiring exactness. Yet, the article notes that this alternative is often sidelined in favor of more “marketable” solutions. The author’s burnout stems from witnessing this disconnect: the tech community is investing heavily in methods that don’t address the root issue. This raises questions about priorities. Are we building tools that align with user needs, or are we chasing hype? The human-centered aspect of this voice emphasizes that progress should be measured by outcomes, not just technical feats. If a system can’t reliably perform basic logic, its “intelligence” is questionable.
Looking ahead, the key question is whether the industry will pivot toward architectures that prioritize reasoning over scale. The author’s suggestion of a “total pivot” isn’t just radical—it’s necessary. Companies that continue down the current path risk perpetuating a cycle of wasted resources and unmet expectations. The challenge lies in communicating this shift without alienating stakeholders who are used to incremental progress. There’s also the matter of education: users need to understand that LLMs aren’t magic boxes but tools with specific strengths and weaknesses. This piece serves as a call to action, urging a reevaluation of what “intelligent” means in this context. Will we embrace alternatives like EBMs, or will we double down on the illusion of capability? The answer could redefine the future of data management, making it more efficient, transparent, and truly human-centered.
seriously losing my mind a bit at work lately. my tech lead keeps telling us to just "refine the system prompt" to stop our production LLM from failing basic multi-step logic tasks. like, no amount of prompt engineering is going to magically turn a probabilistic next-token predictor into a discrete reasoning engine. it's so frustrating watching the entire industry just burn millions on compute trying to brute force logic out of architectures that literally can't do exact math reliably
Was watching a Milken Conference panel on deterministic AI earlier this week (mostly cause im trying to keep track of what the hardware guys like ASML are predicting for compute demand) and they got into this whole discussion about Energy-Based Models vs standard LLMs. and honestly it just reinforced my burnout with our current approach. we keep stacking RAG and "chain of thought" hacks like they're a permanent fix for the fact that the underlying model has zero concept of hard constraints or correctness
tbh it feels like we're just building increasingly expensive dictionaries and hoping a calculator emerges if we make the book big enough. it's exhausting trying to explain to stakeholders that "scaling" doesn't fix a fundamental lack of reasoning architecture. Im really starting to think we need a total pivot toward something more grounded, otherwise we're just going to keep hitting these weird edge-case failures in production forever.
[link] [comments]
Read on the original site
Open the publisher's page for the full experience
Related Articles
- [D] Is LeCun’s $1B seed round the signal that autoregressive LLMs have actually hit a wall for formal reasoning?I’m still trying to wrap my head around the Bloomberg news from a couple of weeks ago. A $1 billion seed round is wild enough, but the actual technical bet they are making is what's really keeping me up. LeCun has been loudly arguing for years that next-token predictors are fundamentally incapable of actual planning. Now, his new shop, Logical Intelligence, is attempting to completely bypass Transformers to generate mathematically verified code using Energy-Based Models. They are essentially treating logical constraints as an energy minimization problem rather than a probabilistic guessing game. It sounds beautiful in theory for AppSec and critical infrastructure where you absolutely cannot afford a hallucinated library. But practically? We all know how notoriously painful EBMs are to train and stabilize. Mapping continuous energy landscapes to discrete, rigid outputs like code sounds incredibly computationally expensive at inference time. Are we finally seeing a genuine paradigm shift away from LLMs for rigorous, high-stakes tasks, or is this just a billion-dollar physics experiment that will eventually get beaten by a brute-forced GPT-5 wrapped in a good symbolic solver? Curious to hear from anyone who has actually tried forcing EBMs into discrete generation tasks lately. submitted by /u/Fun-Information78 [link] [comments]
- Is the ds/ml slowly being morphed into an AI engineer? [D]Agents are amazing. Harnesses are cool. But the fundamental role of a data scientist is not to use a generalist model in an existing workflow; it's a completely different field. AI engineering is the body of the vehicle, whereas the actual brain/engine behind it is the data scientist's playground. I feel like I am not alone in this realisation that my role somehow got silently morphed into that of an AI engineer, with the engine's development becoming a complete afterthought. Based on industry requirements and ongoing research, most of the work has quietly shifted from building the engine to refining the body around it. Economically, this makes sense, as working with LLMs or other Deep Learning models is a capital-intensive task that not everyone can afford, but the fact that very little of a role's identity is preserved is concerning. Most of the time, when I speak to data scientists, the core reply I get is that they are fine-tuning models to preserve their "muscles". But fine-tuning is a very small part of a data scientist's role; heck, after a point, it's not even the most important part. Fine-tuning is a tool. Understanding, I believe, should be the fundamental block of the role. Realising that there are things other than "transformers" and finding where they fit into the picture. And don't even get me started on the lack of understanding of how important the data is for their systems. A data scientist's primary role is not the model itself. It's about developing the model, the data quality at hand, the appropriate problem framing, efficiency concerns, architectural literacy, evaluation design, and error analysis. Amid the AI hype, many have overlooked that much of their role is static and not considered important. AI engineering is an amazing field. The folks who love doing amazing things with the models always inspire me. But somehow, the same attention and respect are no longer paid to the foundational, scientific side of data and modeling in the current industry. I realise it's not always black and white, but it's kind of interesting how the grey is slowly becoming darker by the day. Do you feel the same way? Or is it just my own internal crisis bells ringing unnecessarily? For those of you who have recognized this shift, how are you handling your careers? Are you leaning into the engineering/systems side and abandoning traditional model development? Or have you found niche roles/companies that still value the fundamental data scientist role (data quality, architectural literacy, statistical rigor)? I'd love to hear how you are adapting submitted by /u/The-Silvervein [link] [comments]
- Question for MLEs: How often are you writing your models from scratch in TF/PyTorch?I have about 8 years of experience mostly in the NLP space although i've done a little bit of vision modeling work. I was recently let go so I'm in the midst of interview prep hell. As i'm moving further along in the journey, i'm feeling i have some gaps modeling wise but I'm just trying to see how others are doing their work. Most of my work the last year was around developing MCP servers/back end stuff for LLMs, context management, creating safety guardrails, prompt engineering, etc. My work before that was using some off the shelf models for image tasks, mostly using models I found on github via papers or pre-trained models on HuggingFace. And before that I spent most of my time around feature engineering/data prep and/or tuning hyperparamters on lighter weight models (think XGBoost for classification, or BERTopic for topic modeling). I've certainly read books/seen code that involves hand-coding a transformer model from scratch but I've never actually needed to do something like this. Or when papers talk about early/late fusion layers or anything more complex than a few layers, I'd probably have to look up how to do it for a day or two before getting it going. Am i the anomaly here? I feel like half my time has been doing DS work and the other half plain old engineering work, but people are expecting more NN coding knowledge than i have and frankly it feels bad, man. How often are y'all just looking for the latest and greatest model on UnSloth/HF instead of building it yourself? Brought to you from the depths of unemployment depression.... submitted by /u/GirlLunarExplorer [link] [comments]