Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Context engineering is sleeping on the humble hyperlink

mbleigh.dev

Post reply on HN
Print view View original

51–60 of 69 posts

Re: Context engineering is sleeping on the humble hyperlink

#51

Post by simonw »

CuriouslyC wrote: post #50
simonw wrote: post #46

Earlier quoted context omitted.

That article appears to be very confused about how skills work. It seems to think they are a vendor lockin play by Anthropic, running as an opaque black box. To rebut their four complaints: 1. "Migrating away from Anthropic in the future wouldn't just mean swapping an API client; it would mean manually reconstructing your entire Skills system elsewhere." - that's just not true. Any LLM tool that can access a filesyst…

This isn't an accurate take either. You can load client skills, sure, but the whole selling point from Anthropic is that skills are like memory, managed at the API layer "transparently" and that those skills are cross project. If you forced Claude to only use skills from the current project to try and be transparent, it would still be a black box that makes it harder to debug failures, and it'd still be agent and ven…

What do you mean by "managed at the API layer"?

I'm talking about skills as they are used in Claude Code running on my laptop. Are you talking about skills as they are used by the https://claude.ai consumer app?

Re: Context engineering is sleeping on the humble hyperlink

#52

Post by blackmanta »

CaptainOfCoit wrote: post #42
ako wrote: post #32

The article seems a few months too late. Claude (and others) are already doing this: i've been instructing claude code to generate code following certain best practices provided through URLs or asking it to compare certain approaches from different URLs. Claude Skill uses file "URLs" to provide progressive disclosure: only include detailed texts into the context if needed. This helps reduce context size, and improves…

Codex run locally doesn't have access to any "web search" tool, but that doesn't stop it from trying to browse the web via cURL from time to time. Place hyperlinks in the documents in the repository and it'll try to reach them best it can. It doesn't seem overly eager doing so though, and only does that when absolutely needed and it can't find the information elsewhere. This has been my experience with gpt-5-high at…

You can actually enable search in codex but adding the following to the config file

[tools] web_search = true

Re: Context engineering is sleeping on the humble hyperlink

#53

Post by matharmin »

simonw wrote: post #47
CaptainOfCoit wrote: post #42

Earlier quoted context omitted.

Codex run locally doesn't have access to any "web search" tool, but that doesn't stop it from trying to browse the web via cURL from time to time. Place hyperlinks in the documents in the repository and it'll try to reach them best it can. It doesn't seem overly eager doing so though, and only does that when absolutely needed and it can't find the information elsewhere. This has been my experience with gpt-5-high at…

You can run "codex --search" and it gains a search tool. I'm not sure why that isn't the default (like it is for Claude Code.)

Probably a security feature. If it can access the internet, it can send your private data to the internet. Of course, if you allow it to run arbitrary commands it can do the same.

Re: Context engineering is sleeping on the humble hyperlink

#54

Post by not_kurt_godel »

alexpetros wrote: post #17
not_kurt_godel wrote: post #15

Earlier quoted context omitted.

Altering the presentation layer is not the same thing as deriving it from a semantic API definition.

Altering the presentation layer is possible precisely because HTML is a semantic API definition: one broad enough to enable self-description across a variety of domains, but specific enough that those applications can still be re-contextualized according to the user's needs and preferences.

Your point would be much stronger if all web forms were served in pure HTML and not 95% created by JS SPAs.

Re: Context engineering is sleeping on the humble hyperlink

#55

Post by not_kurt_godel »

tsimionescu wrote: post #20
not_kurt_godel wrote: post #11

Earlier quoted context omitted.

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

Yes, which is exactly true of the Web. There is no aspect of a web page that is not derived from the HTML+JS+CSS files served by a server.

...which are a presentation layer and not a semantic, RESTful API definition.

Re: Context engineering is sleeping on the humble hyperlink

#56

Post by not_kurt_godel »

tsimionescu wrote: post #21
not_kurt_godel wrote: post #8

Earlier quoted context omitted.

I worked on frontend projects and API designs directly related to trying to achieve HATEOAS, in a general, practical sense, for years. Browsing the modern web is not it.

I think you are confusing the browser with the web page. You probably think that the Javascript code executed by your browser is part of the "client" in the REST architecture - which is simply not what we're talking about. When analyzing the WWW, the REST API interface is the interface between the web browser and the web server, i.e. the interface between, say, Safari and Apache. The web browser accesses a single end…

I'm not confusing it. I was heavily motivated by business goals to find a general solution for HATEOAS-ifying API definitions. And yes, a web page, implemented in HTML/CSS/JS is a facsimile for it in a certain sense, but it's not self-contained RESTful API definition.

Re: Context engineering is sleeping on the humble hyperlink

#57

Post by not_kurt_godel »

tsimionescu wrote: post #18
not_kurt_godel wrote: post #5

Earlier quoted context omitted.

I appreciate the conceptual analogy, but that's not really HATEOAS. HATEOAS would mean your browser/client would be entirely responsible for the presentation layer, in whatever form you desired, whether it's buttons or forms or pages or not even a GUI at all, such as a chat interface.

The Web is not only true HATEOAS, it is in fact the motivating example for HATEOAS. Roy Fielding's paper that introduced the concept is exactly about the web, REST and HATEOAS are the architecture patterns that he introduces primarily to guide the design of HTTP for the WWW. The concept of a HATEOAS API is also very simple: the API is defined by a communication protocol, 1 endpoint, and a series of well-defined media…

It's a broader definition of HATEOAS. A stricter interpretation with practical, real-world benefits is a RESTful API definition that is fully self-contained that the client can get in a single request from the server and construct the presentation layer in whole with no further information except server responses in the same format. Or, slightly less strictly, a system where the server procedurally generates the presentation layer from the same API definition, rather than requiring separate frontend code for the client.

Re: Context engineering is sleeping on the humble hyperlink

#58

Post by not_kurt_godel »

alganet wrote: post #19
not_kurt_godel wrote: post #11

Earlier quoted context omitted.

It's not. The whole point of HATEOAS is that the presentation can be entirely derived from the API definition, full stop.

That is just wrong. https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty... The server MUST be stateless, the client MAY be stateful. You can't get ETags and stuff like that without a stateful client.

Deriving a presentation layer from an API definition has no bearing on whether the client has to be stateful or not. The key difference for 'true' HATEOAS is that the API schema is sufficiently descriptive that the client does not need to request any presentation layer; arguably not even HTML, but definitely not CSS or JavaScript.

https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st...

> any concept that might be the target of an author's hypertext reference must fit within the definition of a resource

Re: Context engineering is sleeping on the humble hyperlink

#59

Post by labrador »

tmoravec wrote: post #27
labrador wrote: post #4

I just discovered that I can paste a link into a Claude prompt and ask it to follow read the page so we can talk about it. I no longer have to copy the text of the page and paste it in. Claude uses the web_fetch command. So we're heading in the direction this article discusses.

Except that more often than not, Claude is blocked from reading the article. This used to work great two years ago when chatgpt first got the Web browsing feature. Nowadays, no eyeballs on ads: no content.

It refused to read this complaint about Grok because of the NSFW topic

"The irony is they trained their model on so much porn even barely NSFW prompts get flagged because Grok the Goon Commander thinks a simple fully-clothed lapdance requires a visible massive dong being thrusted up her piehole."

https://old.reddit.com/r/grok/comments/1ofd6xm/the_irony_is_...

Re: Context engineering is sleeping on the humble hyperlink

#60

Post by alganet »

not_kurt_godel wrote: post #58
alganet wrote: post #19

Earlier quoted context omitted.

That is just wrong. https://ics.uci.edu/~fielding/pubs/dissertation/net_arch_sty... The server MUST be stateless, the client MAY be stateful. You can't get ETags and stuff like that without a stateful client.

Deriving a presentation layer from an API definition has no bearing on whether the client has to be stateful or not. The key difference for 'true' HATEOAS is that the API schema is sufficiently descriptive that the client does not need to request any presentation layer; arguably not even HTML, but definitely not CSS or JavaScript. https://ics.uci.edu/~fielding/pubs/dissertation/rest_arch_st... > any concept that migh…

Dude, he literally mentions Java Applets as an example (it was popular back then, if it was written today it would have been JavaScript). It's all there. Section 5.1.7.

It's an optional constraint. It's valid for CSS, JavaScript and any kind of media type that is negotiable.

> resource: the intended conceptual target of a hypertext reference

> representation: HTML document, JPEG image

A resource is abstract. You always negotiate it, and receive a representation with a specific type. It's like an interface.

Therefore, `/style.css` is a resource. You can negotiate with clients if that resource is acceptable (using the Accept header).

"Presentation layer" is not even a concept for REST. You're trying to map framework-related ideas to REST, bumping into an impedance mismatch, and not realizing that the issue is in that mismatch, not REST itself.

REST is not responsible for people trying to make anemic APIs. They do it out of some sense of purity, but the demands do not come from HATEOAS. They come from other choices the designer made.

Post reply on HN