There’d be two Mes – two instantiations of the Me pattern co-occurring. And that would likely be confusing for both of us!

> To illustrate, two instances of a programs can share the exact same binary code (the "pattern") and yet they are separate instances.

Exactly! If we suspend a Docker image, transfer it to a new compatible host machine, and fire it up, we consider it a resumption of the same process (pattern) in a different instance.

Likewise, say we found a mathematical function that would compute the entire state of that Docker image at that moment, and then wiped the image – such that there was no current physical instantiation of it anywhere, on any machine – and subsequently used the function to regenerate it bit for bit.

A dualist would say there’s something fundamentally different about the human analogue of that; that the Mind has a separate existence Elsewhere – and not just in the mathematical sense of patterns not requiring instantiation to still be patterns, since that would apply to all patterns, Minds or not.

- there is no separate “stuff” that minds are made out of, no privileged plane of existence specific to minds; minds are just patterns like everything else

- destroying an instantiation of a pattern != destroying the pattern

And speaking of squaring ideas – if I draw a square on a piece of paper, and then light that paper on fire, I haven’t destroyed the concept of a square. I can always draw an identical square on another sheet of paper. If the square had consciousness, it’d be none the wiser.

The times, as they say, are a-changin’.

Open software is not inherently more secure than closed software, and never has been.

Its relative security value was always derived from circumstantial factors, one of the most important of which was the combination of incentive and ability and willingness of others in the community to spend their time and attention finding and fixing bugs and potential exploits.

Now, that’s been the case for so long that we all implicitly take it for granted, and conclude that open software is generally more secure than closed, and that security through obscurity falls short in comparison.

But this may very well fundamentally change when the cost of navigating the search space of potential exploits, for both the attacker and the defender, is dramatically reduced along the axes of time and attention, and increased along the axis of monetary investment.

It then becomes a game of which side is more willing to pool monetary resources into OSS security analysis – the attackers or the defenders – and I wouldn’t feel comfortable betting on the defenders in that case.

Not sure who you're replying to here – this is not a claim I made.

When you give prompt P to model M, when your goal is for the model to actually execute those instructions, the model will be in state S.

When you give the same prompt to the same model, when your goal is for the model to introspect on those instructions, the model is still in state S. It's the exact same input, and therefore the exact same model state as the starting point.

Introspection-mode state only diverges from execution-mode state at the point at which you subsequently give it an introspection command.

At that point, asking the model to e.g. note any ambiguities about the task at hand is exactly equivalent to asking it to evaluate any input, and there is overwhelming evidence that frontier models do this very well, and have for some time.

Asking the model, while it's in state S, to introspect and surface any points of confusion or ambiguities it's experiencing about what it's being asked to do, is an extremely valuable part of the prompt engineering toolkit.

I didn't, and don't, assert that "asking the model if the instructions are good" is a replacement for evals – that's a strawman argument you seem to be constructing on your own and misattributing to me.

When the model that’s interpreting it is the same model that’s going to be executing it, they share the same latent space state at the outset.

So this is essentially asking whether models are able to answer questions about context they’re given, and of course the answer is yes.

There are some very interesting information network theories that present information growth as a continually evolving and expanding graph, something like a virus inherent to the universe’s structure, as a natural counterpoint to entropy. And in that view, atomic bonds and cells and towns and railroads and network connections and model weights are all the same sort of thing, the same phenomenon, manifesting in different substrates at different levels of the shared graph.

To me, that’s a much better and deeper explanation that connects the dots, and offers more predictive power about what’s next.

Highly recommend the book Why Information Grows to anyone whose interest is piqued by this.

When a human is coding against a traditional API, it might be a bit annoying if the API has four or five similar-sounding endpoints that each have a dozen parameters, but it's ultimately not a showstopper. You just spend a little extra time in the API docs, do some Googling to see what people are using for similar use cases, decide which one to use (or try a couple and see which actually gets you what you want), commit it, and your script lives happily ever after.

When an AI is trying to make that decision at runtime, having a set of confusing tools can easily derail it. The MCP protocol doesn't have a step that allows it to say "wait, this MCP server is badly designed, let me do some Googling to figure out which tool people are using for similar use cases". So it'll just pick whichever ones seems most likely to be correct, and if it's wrong, then it's just wasted time and tokens and it needs to try the next option. Scaled up to thousands or millions of times a day, it's pretty significant.

There's a lot of MCP servers out there that are just lazy mappings from OpenAPI/Swagger specs, and it often (not always, to be fair) results in a clunky, confusing mess of tools.

There'd be a little extra friction compared to MCP – the agent would presumably have to find and download and read the OpenAPI/Swagger spec, and the auth story might be a little clunkier – but you could definitely do it, and I'm sure many people do.

Beyond that, there are a few concrete things MCP provides that I'm a fan of:

- first-class integration with LLM vendors/portals (Claude, ChatGPT, etc), where actual customers are frequently spending their time and attention

- UX support via the MCP Apps protocol extension (this hasn't really entered the zeitgeist yet, but I'm quite bullish on it)

- code mode (if using FastMCP)

- lots of flexibility on tool listings – it's trivial to completely show/hide tools based on access controls, versus having an AI repeatedly stumble into an API endpoint that its credentials aren't valid for

I could keep going, but the point is that while it's possible to use another tool for the job and get _something_ up and running, MCP (and FastMCP, as a great implementation) is purpose built for it, with a lot of little considerations to help out.

God, I used to be _really_ into Minesweeper.

One of the earliest games I made back in college was a 3D Minesweeper cube. I remember being really proud of one little detail – the detection and automatic resolution of ambiguous clues that would require guessing, which always annoyed the heck out of me in every other version of Minesweeper.

I thought about the deterministic generation aspect, but there's no "random seed" equivalent for frontier LLMs to my knowledge that would guarantee deterministic output (even temperature=0 is still nondeterministic).

You could "discover" monsters by popping in any arbitrary CD in your house – music, a PS game, a PC game, whatever – and it would generate a monster based on the disc's metadata, and add it to your ranch. It was a game about collecting, breeding, and battling these monsters.

The generated monster usually had nothing at all to do with the disc's content, of course. There were some specific discs that were hard-coded in that would give you a relevant monster, but not a ton.

It was a fairly niche thing, though, and the death of CDs sort of killed the whole idea.

But now in the age of LLMs, it feels like maybe the time has come back around for something like this to be pretty fun again, so I've implemented it as an Agent Skill that:

1. accepts a URL and reads the content (or any input, really) 2. follows some standard guidance on generating monster JSON for it 3. uses a Gemini image model to generate a monster avatar 4. renders it all in a fun little trading card image 5. allows you to breed them into hybrids, battle them, and share them to Github Gists

This was mainly a scratch-my-own-itch nostalgia indulgence. I briefly considered doing this as a full blown site, but agent skills give a fair bit more interactive flexibility while not costing me a dime. You can just point your agent (Claude Code, etc) to aiwebb/llmonster-rancher and tell it to get going.

Hope y'all have fun with it.

Comments URL: https://news.ycombinator.com/item?id=47398350

Points: 2

# Comments: 3

Unbelievable. This is why we can’t have nice things.

Wow! Surprised that hasn't been mentioned here already. Jumped out to me immediately as a morbidly curious bit of trivia.

A smaller, more concise statement means less surface area for the IRS to potentially object to / lower overall liability.