Just had a quick glance, but I think I found something to add to the Objection!-section of your post:
Brave's Search API is 3$ CPM and includes Web search, Images, Videos, News, Goggles[0]. Anthropic's API is 10$ CPM for Web search (and text only?), excluding any input/output tokens from your model of choice[1], that'd be an additional 15$ CPM, assuming 1KTok per request and Claude Sonnet 4 as a good model, so ~25$ CPM.
So your default "Ratio (Search cost / LLM cost): 25.0x" seems to be more on the 0.12x side of things (Search cost / LLM cost). Mind you, I just flew over everything in 10 mins and have no experience using either API.
Dan Abramov isn't "the creator of React", he just became an evangelist for react ever since he got to the team at Facebook through his work on redux. He is pushing for RSC (as that's where react's future seems to be), but what makes you think he's pushing for Vercel?
Agree with everything you're saying here, but to be fair I think the analogy with Progressive JPEG doesn't sit quite right with your concept. What you're describing sounds more like "semantic-aware streaming" - it's as if a Progressive JPEG would be semantically aware of its blob and load any objects that are in focus first before going after data for things that are out of focus.
I think that's a very contemporary problem and worth pursuing, but I also somehow won't see that happening in real-time (with the priority to reduce latency) without necessary metadata.
It’s not an exact analogy but streaming outside-in (with gradually more and more concrete visual loading states) rather than top-down feels similar to a progressive image to me.
It's data (JPEG/JSON) VS software (HTML/CSS/JS)... you can choose to look at HTML/CSS/JS as just some chunks of data, or you can look at it as a serialized program that wants to be executed with optimal performance. Your blog post makes it seem like your focus is on the latter (and it's just quite typical for react applications to fetch their content dynamically via JSON), and that's where your analogy to the progressive mode of JPEGs falls a bit flat and "streaming outside-in" doesn't seem like all you want.
Progressively loaded JPEGs just apply some type of "selective refinement" to chunks of data, and for Progressive selective refinement to work it's necessary to "specify the location and size of the region of one or more components prior to the scan"[0][1]. If you don't know what size to allocate, then it's quite difficult(?) to optimize the execution. This doesn't seem like the kind of discussion you'd like to have.
Performance aware web developers are working with semantic awareness of their content in order to make tweaks to the sites loading time. YouTube might prefer videos (or ads) to be loaded before any comments, news sites might prioritize text over any other media, and a good dashboard might prioritize data visualizations before header and sidebar etc.
The position of the nodes in any structured tree tells you very little about the preferred loading priority, wouldn't you agree?
I used this analogy more from the user's perspective (as a user, a gradually sharpening image feels similar to a website with glimmers gradually getting replaced by revealing content). I don't actually know how JPEG is served under the hood (and the spec is too dense for me) so maybe if you explain the point a bit closer I'll be able to follow. I do believe you that the analogy doesn't go all the way.
RSC streams outside-in because that's the general shape of the UI — yes, you might want to prioritize the video, but you have to display the shell around that video first. So "outside-in" is just that common sense — the shell goes first. Other than that, the server will prioritize whatever's ready to be written to the stream — if we're not blocked on IO, we're writing.
The client does some selective prioritization on its own as it receives stuff (e.g. as it loads JS, it will prioritize hydrating the part of the page that you're trying to interact with).
This got strong "rise and grind guys thinking about life hack" vibes pretty quickly. Be serious, who's hiring at that rate currently?!
I see whiteboard interviews as an answer to disputes over opinionated tooling. It's just a pen, a blank canvas, and natural language to communicate. There's probably just pseudocode, no IDEs and zero runtimes.
Bringing "AI teammates" into the mix reintroduces some disputes: Candidates would lack the experience to get around your tool and trigger the right responses. Different LLMs have different "characters". As an engineer you'd want to pick the best tool for the job, and no engineer would like be stuck with your choice. It's usually an effort to figure out and setup such a tool for each distinct project.
Besides that, even technical interviews have the social component to rule out any "cultural" differences within the team. I really doubt that good technical leaders could take that much value out of an AI assessment to just skip any in-person step of the interview.
You're right about the "10+ monthly" number - that was probably too high for most companies. More realistic is probably 3-5 monthly for growing startups, but your point stands.
On the tooling disputes - this is actually something we're grappling with. You're absolutely right that engineers want to pick their tools, and being forced into unfamiliar AI interfaces could be worse than a whiteboard. We're experimenting with letting candidates choose their preferred AI assistant (Claude, ChatGPT, etc.) rather than forcing our choice.
The cultural/social component point is spot-on. This isn't meant to replace human interaction entirely - more to supplement the technical assessment part. The in-person cultural evaluation is still crucial.
Curious: do you think there's any way to make technical assessment more realistic without introducing new tool friction?
Isn't the thought process currently understood as a blend of deterministic & probabilistic decision-making and free will? So if LLMs lack the "free will" part, isn't that enough deductive reasoning to satisfy the argument "LLMs don't think"?
I think if you read the article linked and thought: “I can assume that AGI will be birthed by training on the entire Internet” then you didn’t read very carefully or judge the author well.
I read the linked article and thought OpenAI wants to communicate: "We plan our decisions to build AGI in the long term". You know, decisions like the partnership with reddit[0] a year after that announcement.
That’s certainly a style of argument and contains (with "basic logic") an informal fallacy[0].
To quote N. Chomsky when he made an analogy: "When you have a theory, there are two questions you'd need to ask: (1) Why are things this way? (2) Why are things not that way?"[1]
I get it, this post-truth century is difficult to navigate. Engineering achievements get picked up through a mix of technical excitement and venture boredom, its fallacies are stylized by growth hackers as this unsolvable paradox that seems to fit just the right terminology for any marketing purposes, only to be piped through one hype cycle that just paints another picture of the doomsday of capitalism with black and white colors. /rant
Brave's Search API is 3$ CPM and includes Web search, Images, Videos, News, Goggles[0]. Anthropic's API is 10$ CPM for Web search (and text only?), excluding any input/output tokens from your model of choice[1], that'd be an additional 15$ CPM, assuming 1KTok per request and Claude Sonnet 4 as a good model, so ~25$ CPM.
So your default "Ratio (Search cost / LLM cost): 25.0x" seems to be more on the 0.12x side of things (Search cost / LLM cost). Mind you, I just flew over everything in 10 mins and have no experience using either API.
[0]: https://brave.com/search/api/
[1]: https://www.anthropic.com/pricing#anthropic-api
reply