I completely disagree with the idea that 2025 "The (only?) year of MCP." In fact, I believe every year in the foreseeable future will belong to MCP. It is here to stay. MCP was the best (rational, scalable, predictable) thing since LLM madness broke loose.
2025: The Year in LLMs
341–350 of 643 posts
Re: 2025: The Year in LLMs
#342Earlier quoted context omitted.
We're very clearly seeing exponential progress - even above trend, on METR, whose slope keeps getting revised to a higher and higher estimate each time. Explain your perspective on the objective evidence against exponential progress?
Pretty neat how this exponential progress hasn't resulted in exponential productivity. Perhaps you could explain your perspective on that?
Sir, we're in a modern economy, we don't ever ever look at productivity graphs (this is not to disparage LLMs, just a comment on productivity in general)
Re: 2025: The Year in LLMs
#343Earlier quoted context omitted.
That's all very impressive, to be sure. But are you sure you're getting the point? As of 2025, LLMs are now very good at writing new code, creating new imagery, and writing original text. They continue to improve at a remarkable rate. They are helping their users create things that didn't exist before. Additionally, they are now very good at searching and utilizing web resources that didn't exist at training time. So…
> They are helping their users create things that didn't exist before. That is a derived output. That isn't new as in: novel. It may be unique but it is derived from training data. LLMs legitimately cannot think and thus they cannot create in that way.
By that definition, nearly all commercial software development (and nearly all human output in general) is derived output.
Re: 2025: The Year in LLMs
#344Earlier quoted context omitted.
I don't get why Nvidia can't do both? Is it because of the limited production capabilities of the factories?
Yes. If you're bottlenecked on silicon and secondaries like memory, why would you want to put more of those resources into lower margin consumer products if you could use those very resources to make and sell more high margin AI accelerators instead? From a business standpoint, it makes some sense to throttle the gaming supply some. Not to the point of surrendering the market to someone else probably, but to a measur…
We will have to wait and see but my bet is that Nvidia will move to Leading Edge node N2 earlier now they have the Margin to work with. Both Hopper and Blackwell were too late in the design cycle. The AI hype and continue to buy the latest and great leaving Gaming at a mainstream node.
Nvidia using Mainstream node has always been the norm considering most Fab capacity always goes to Mobile SoC first. But I expect the internet / gamers will be angry anyway because Nvidia does not provide them with the latest and greatest.
In reality the extra R&D cost for designing with leading edge will be amortised by all the AI order which give Nvidia competitive advantage at the consumer level when they compete. That is assuming there are competition because most recent data have shown Nvidia owning 90%+ of discreet market share, 9% for AMD and 1% for Intel.
Re: 2025: The Year in LLMs
#345Earlier quoted context omitted.
> Skill and Langchain experts with production-grade 0>1 experience. Also , it's just normal backend work - calling a bunch of APIs. What am I missing here?
That is like saying training tensorflow models is just calling some APIs. Actually making a system like this work seems easy, but isn't really. (Though with the CURRENT generation or two of models it has gotten "pretty easy" I think. Before that, not so much.)
No idea about training tenserflow models - is it super complex or is it just calling a couple of APIs ? Langchain is literally calling an API. Maybe you need to get good with prompting or whatever, but I don't see where the complexity lies. Please let me know.
Re: 2025: The Year in LLMs
#346Let's hope 2026 will also have interesting innovations not related to AI or LLMs.
Re: 2025: The Year in LLMs
#347[dead]
Re: 2025: The Year in LLMs
#348Speaking of asynchronous agents, what do people use? Claude Code for web is extremely limited, because you have no custom tools. Claude Code in GitHub Actions is vastly more useful, due to the custom environment, but ackward to use interactively. Are there any good alternatives?
What exactly do you mean by custom tools here? Just cli tools accessible to the agent?
Re: 2025: The Year in LLMs
#349Remember, back in the day, when a year of progress was like, oh, they voted to add some syntactic sugar to Java...
I'm very relieved we've moved away from rewriting everything in Rust.
There's no reason not to use Rust for LLM-generated code in the longer term (other than lack of Rust code to learn from in the shorter term).
The stricter typing of Rust would make sematic errors in generated code come out more quickly than in e.g. Python because using static typing the chances are that some of the semantic errors are also type violations.
Re: 2025: The Year in LLMs
#350Remember, back in the day, when a year of progress was like, oh, they voted to add some syntactic sugar to Java...
I'm very relieved we've moved away from rewriting everything in Rust.
Have we though? I'm glad we're not shouting about it from the rooftops like it's some magical "win" button as much, but TBH the things I use routinely that HAVE been rewritten in rust are generally much better. That could also just be because they're newer and have the errors of the past to not repeat.