tsunego's comments

On: Geography of generative AI workforce impact to differ from previous technologies

[tsunego]

AI is expensive so no surprise

On: QwQ-32B: Embracing the Power of Reinforcement Learning

[tsunego]

Can’t wait to see if my memory can even acocomodate this context

On: Richard Sutton and Andrew Barto Win 2024 Turing Award

[tsunego]

> This has nothing to do with his professional life.

you mean his personal life?

[vonneumannstan → tsunego]

oops, yes.

On: The Differences Between Deep Research, Deep Research, and Deep Research

[tsunego]

Love me some good old whataboutism (sure, LLMs are now super-intelligent at writing software, but can they clean my kitchen? No? Ha!)

[jvanderbot → tsunego]

The computer beat me at chess, but it was no match for me at kickboxing. - Emo Phillips

Tale as old as time. We can make nice software systems but general purpose AI / Agents isn't here yet.

[TeMPOraL → jvanderbot]

Worse than that: it seems that it's much easier to make computer achieve superhuman feats in cognitive work, than it is to make it do even most basic physical interactions with the real world.

In short: the natural order of things is that computers are better at thinking, and people are better at manual labor. Which is the opposite of what we wanted.

[jvanderbot → TeMPOraL]

AI is just hydraulics for the mind. Or should be.

I choose a direction and apply force.

On: The Differences Between Deep Research, Deep Research, and Deep Research

[tsunego]

Neat summary but you forgot Grok!

[jvanderbot → tsunego]

Maybe the article has been edited in the last four minutes since you posted, but Grok is definitely in there now.

On: AI: Where in the Loop Should Humans Go?

[tsunego]

Great reminder that AI is basically overpriced copilot: impressive enough to sell, flawed enough to need babysitting, and guaranteed to make sure humans still get blamed when things inevitably go wrong.

On: Enhancing Frame Detection with Retrieval Augmented Generation

[tsunego]

Cool paper but unsurprising results since anything benefits from RAG

[0xdeadbeefbabe → tsunego]

Also, grep is really exciting with lots of data.

On: Show HN: Agents.json – OpenAPI Specification for LLMs

[tsunego]

I like your approach but it's not clear to me whether it's MCP compatible

Anthropic just announced a MCP registry

[yompal → tsunego]

MCP is great for the stateful systems, where shared context is a benefit, but this is a rarity. Developers generally write clients to use APIs in a stateless way, and we want to help this majority of users.

That said, agents.json is not mutually exclusive to MCP. I can see a future where an MCP for agents.json is created to access any API.

[winkle → yompal]

I think MCP being stateful is true in the short term. It's currently at the top of their roadmap to add to the protocol https://modelcontextprotocol.io/development/roadmap.

[yompal → winkle]

We've been keeping a close eye on this topic: https://github.com/modelcontextprotocol/specification/discus...

The options being considered to do this are:

1) maintain a session token mapping to the state -- which is still statefulness

2) create a separate stateless MCP protocol and reimplement -- agents.json is already the stateless protocol

3) reimplement every MCP as stateless and abandon the existing stateful MCP initiative

As you can tell, we're not bullish on any of these.

[esafak → yompal]

Isn't the idea to create a data lake to better inform models? Why are you bearish on stateful protocols? Could you elaborate on your thinking?

[yompal → esafak]

Bearish on everyone needing to be on stateful protocols. Developers should have the option to have their state managed internal to their application.

[esafak → yompal]

Can't you simply use a stateful protocol and not report any state? Doesn't statefulness subsume statelessness? I am beginning to wrap my head around this space, so excuse the naive questions.

[yompal → esafak]

No worries! In other cases, I believe you would be right. But splitting up context is not optional with MCP. Part of the whole state will always reside in an external entity.

On: An Attempt to Catch Up with JIT Compilers

[tsunego]

chasing inline cache micro-optimizations with dynamic binary modification is a dead end. modern CPUs are laughing at our outdated compiler tricks. maybe it's time to accept that clever hacks won’t outrun silicon.

[saagarjha → tsunego]

JITs typically are too broken for compiler tricks so I don't think it's time to accept that just yet.

[andrekandre → tsunego]

what is the better approach?

[Sparkyte → andrekandre]

You don't, there are equal trade offs. JIT might use more memory because of what it does at the runtime, but it is also the exact reason it is faster to start. A good trade off is just using the type of languages best suited for the workload.

On: Show HN: I built a modern Goodreads alternative

[tsunego]

No offense, but you're completely missing why Goodreads is still relevant.

People aren't sticking around for shiny features or slick UI—they stay because Goodreads has a critical mass of users and reviews.

The value isn't in half-stars or fancy shelves; it's in the network effects. Unless you have a way to bring over millions of active reviewers (and their reviews), you're just building another pretty ghost town.